My goal was to use existing SOAP components (OK, web services) behind the firewall in an attempt to retrieve a list of insurance policies that I hold. The single biggest problem I had was working out the protocol for each individual invocation and the required sequence of calls. It turned out to be only two calls, but there were many more available and I was unclear on which ones I really needed to perform. WSDL is of no help there; I think it is strictly a documentation issue. I had to resort to looking at how our .ASP scripts go about the process. Since that took the better part of the afternoon I am going to advocate a better way (as soon as I think of it).

The protocol for each call was less difficult, but still required a peek at existing code to figure it out. The parameter names documented in the WSDL did not adequately define the purpose of the parameter (so I was not always sure what to plug in). In one case I found a method that was actually expecting an XML document. I guess the parm name, szSeedXML, kind of hinted at that, but there would be no way for sombody to figure out what the XML doc should look like without some kind of doc or sample code. I want to ponder the advantages and disadvantages of this "just pass a string" approach a bit before pronouncing any judgement.

The Lesson I learned was that some kind of human-readable documentation, retrievable from a guessable location is really neccessary before an outsider can work with somebody else's web services. I have something rolling around in the back of my head about how to do this with Radio. More details in a week.
5:04:41 PM  [Macro error: The file "" wasn't found.]