SOAP was OK in theory but many implementations left something to be desired. In particular I generally found it worked OK if the client code was autogenerated from the same SOAP implementation that the server used, but if you could not use that autogenerated code (such as when your client was using a language that the generator did not support) it was a lot more iffy.

I found a great book at Safari Books Online on SOAP that said that it was written because the author had been bitten by those issues and other things caused by some less than brilliant decisions on the part of those who made the SOAP standard (he was considerably less polite than I have phrased it) and wrote the book so the rest of us didn't have to waste as much time figuring it out as he had.

I don't remember the name of the book or the author, and when I needed a SOAP book a couple years after that it did not show up when I searched.

At one point I got tired enough of the quirks of making servers work with clients not using the server's client generator that I wrote a little proxy that would sit between the server and client. Then I'd write a client using the server's client generator that would just go through all my services and log the communications.

For example lets say I had a server to look up VAT, which takes a sales price and a country code and returns the VAT rate and the VAT amount.

I'd do that through the proxy two or three times, which would save the XML the client sent to the server and the XML response. I'd then compare the XML from the different client requests to see if anything changed, such as timestamps.

I'd then open the client XML in an editor, replace any timestamps with "___TIMESTAMP___", then search for the price and country code to see how those were stored. I'd replace them with "___PRICE___" and "___COUNTRY__".

For the XML from the server, I'd open that in an editor and search for VAT rate and amount. For those I'd figure out a regular expression that could find them.

Then on the client I could dispense with using a SOAP library. When I wanted to look up VAT I'd just use the normal HTTP library of the client language, using the edited client XML as a template. I'd use the normal string or regex client library to replace "___TIMESTAMP___", "___PRICE___", and "___COUNTRY___" with the correct values, send the XML to the server, then use the regex to pull the answers out of the response.

From there it was a simple matter to make a library to handle this. Input was the client XML template, URL of the server, and a list of name => value pairs, and a list of name => regex pairs. It would look for "___name___" in the template for each input name and replace it with its value, call the server, and then for each name in the second list, use the corresponding regex to find the result, and return a list of name => value pairs with those results.

It was a bit tedious. If someone deployed a new SOAP service I had to go generate a client using the same SOAP implementation the server used, call the new service from that through my proxy to get the XML for the templates, and then make a template and the extraction regexes, but it was still usually less hassle than mixing server and client SOAP implementations.