If both ends of the communication are on the Microsoft stack, setting up SOAP webservices is straightforward. The tools basically take care of everything. In our case, we have a customer who exposed an ASP.NET webservice that we consume (data flows in both directions). Our production apps use VB.NET to hit the webservice, but I was able to easily write a python client for testing (by handrolling the SOAP messages).

My intuition is that SOAP starts becoming unpleasant if you have lots of parties involved and/or multiple platforms. We haven't hit that wall.

Well, yeah, except you used to be able to throw up an endpoint as an asmx file and it just sort of worked. Now you are guided to create a separate WCF application. So you get a book on WCF and start reading. You create a "hello, world" app but it takes three days of playing with the config file and reading half of MSDN to get it to work. Now that you know all kinds of stuff about message and service contracts, you can't do things like pull the raw HTTP headers because it's not necessarily bound to HTTP (who's using those other protocols, again?) And, you can't latch on to just any point in the request handling because it may be any sort of request. Another week with MSDN and you've finally gotten something kind of close to what you want, which involves running with aspNetCompatibility and might as well just have been an asmx endpoint, and which would have taken about half a day's work with the old toolkit.

Not that I would know from personal experience.

Part of me wonders whether this difficulty of interoperation is intentional on the part of Microsoft.