It may seem odd to see the title of this post, seeing as it immediately follows one entitled "The MTPS Content Service - A SOAP Success Story". But it was always my intention to write these two back-to-back, because my experience writing the MTPS service was a major part of my most recent revelation: SOAP is no longer my default choice for writing web services.
You've seen some of this story already. I said I've been thinking like Tim for a while now. That thinking has really solidified for me over the last few weeks, to the point where I'm ready to essentially walk away from ASMX/WCF/SOAP in all but a few edge cases.
There have been three main ingredients in this solidification of my "conversion". First, I managed to finish RESTful Web Services, by Sam Ruby and Leonard Richardson. This is a first-rate book. It is going on my shelf right next to Transactional COM+ as a "must read". Not that I necessarily agree with everything in it - in particular I'm not sure that PUT and DELETE are appropriate choices for most web services - but the way it helped me think about URL structure in particular puts it on the "must read" list for me.
The second ingredient was a series of conversations I had with John Elliot, one of the better-known posters on the Win Tech Off Topic list. He's been telling me for years about his ideas about web services, so I took the time to correspond with him to get clarification, and it really resonated. In a nutshell, his position is that web services should be accessible via a web browser, an idea I really like. This implies a read/execute bifurcation along GET/POST, metadata via HTML Forms, and XHTML as a the primary payload. Tasty. (Apologies to John if I've misstated or over-simplified his position.)
The final (and key) ingredient was the realization that SOAP is the COM+ of the modern era. I did a lot of COM+ back in the day, even going so far as to teach classes about it and to write an MSDN article on it. So for some value of "expert", I was an expert on the technology. And yet, my main piece of advice to clients these days is: don't use it unless you have to.
Note that I'm not saying that either SOAP technologies or COM+ don't work. They do. If your problem fits the solution (e.g. multi-object transactions in COM+, single-URL RPC interfaces in SOAP, for example), then go ahead. It's just that I get enough benefits and avoid enough overhead from doing it at the lower (and simpler) level in each case that it's not my default choice any more.
It's also interesting to note that in both cases it was Microsoft - the vendor with a vested interest in me adopting the technology in question - that was the primary source of the information that led me to go down the SOAP/COM+ path. I'm not questioning anyone's integrity - it's just the nature of information that of course the COM+ message was going to be "use it for everything". And similarly SOAP. The failure to analyze whether the technology in question was the most appropriate for my problems was, of course, entirely mine. But hey, like Tim always says, "I reserve the right to get smarter." :)
If this seems like a repeat of things I've said already, well, I apologize. But I just had to share - the realization of the parallels between my personal journey with COM+ and my personal journey with SOAP just struck a real chord with me. Your mileage may vary.