WSDL, SOAP, XML, HTTP and JavaScript

Writing a SOAP "client" is really quite straightforward, as long as you have an XML parser. You need to wrap an Envelope around the request data, possibly construct a Header, send it off, unpack the result (or an error) from whatever comes back.

If you're in .NET, and you have some WSDL which descibes the SOAP services, this is even easier (assuming that there aren't interop-gotchas lying in wait, which very occasionally happens). Simply wave vaguely in the direction of the WSDL, and you're magically given real, native-to-your-language interfaces which hide all the Web services. Something equivalent also applies for Java (with, say, Axis). Babelfish-for-systems. The stack could be mud, for all you know.

So, if you're writing an application which needs to talk to Groove Web Services, you'd usually start as high up the stack as possible. Otherwise, the lower you start, the more work to be done (and the more difficult decisions along the way).

Groove 2.5j

In the most recent maintenance edition of Groove, we introduced some support for InfoPath form libraries in SharePoint. One feature of this awesome toolkit is that some Groove facilities begin to appear inside InfoPath (ie. not inside the Groove transceiver): there's a task pane which shows online presence awareness of the people in the shared space which the InfoPath document lives in. Not only that, but you can send them instant messages and invite other users into the shared space - from the InfoPath UI. (Much more detail on the SharePoint integration here (pdf)).

And all that's done with some JavaScript and HTML. It's an example of starting "half way down the stack": not assuming .NET, but on the other hand having a regular webpage for user interface (the InfoPath task pane is HTML) rather than building an ActiveX control. I had a lot of fun building that taskpane, and I wanted to be able to leverage the code.

dohyki

Besides being an interesting idea, the "hyki" is also a chance to leverage that InfoPath-oriented taskpane code. But it also inherits its system requirements. And that means: some of Office2003 needs to be there. Specifically, the SOAP/XML/HTTP stack which dohyki uses to do web services has been written for "MSXML 5.0", which only (currently) ships with Office 2003.

MSXML

MSXML has a tortured history. Versions 2.x were (are) widely deployed, but buggy (and bad at namespaces). Version 3 is very common (I think it ships with IE5.5). I think Version 4 was supposed to be the once-for-all-do-it-right version; it's a stonking 5MB install, and I don't know many people who have it installed. But, if you're serious about XML, then version 4 should be waay better than 3.

So, I was as surprised as anyone to find that Office 2003 includes a "version 5" parser. Not only that, but it's still not redistributable: there's nary a mention of it on the whole of Microsoft's web site. (I think InfoPath's SDK has the full API reference, if you're interested).

Google seems curiously useless if you load up dohyki and see "Cannot initialize: Msxml2.XMLHTTP.5.0 is not available".