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.
You know Craig, right now I tend to agree with you. But you too are old enough to realize that we'll start adding context (services, metrics, methodologies) till REST is SOAP is COM+ is MTS is COM is OLE and such.
ReplyDeleteMy real question is: what we be ther silver bullet after REST ?
-- Henkk
I've made it through most of the book as well and was pleasantly surprised that the religious bits got over with quickly and there was good practical advice. I agree with you about GET/PUT. In some cases, there isn't an equal and opposite PUT for every GET. I use POST for updates, which means that the URIs are really processing endpoints rather than locations of concrete resources (which are what I GET). But I've learned to get past that inconsistent thinking.
ReplyDeleteHenk - I totally agree that the industry is likely to do that...only it didn't really happen with COM+. People just sort of learned that it hurt when they went like that and went back to doing things the simple, manual way. Unless you count SOAP a la WCF, I guess.
ReplyDeleteAnyway, I care less about what the industry does these days, and more about what *I* do. I'm glad to have had some insight about what the utility of the SOAP stacks actually is. That arms me to make better decisions for the future.
Erik - I think that as long as you make use of RESTish URL design, you're getting the main benefits, even when you use POST when you could use PUT. Further, I think if you design your web service to be usable via a modern browser (i.e. GET+POST, serve XHTML "microformats", use HTML forms) then you have a lot of practical benefits that weigh strongly in the balance against the supposed uniformity of interface that PUT and DELETE provide.
ReplyDeleteI think. :)
Resonates, resonates and all of which begs the question:
ReplyDeleteAs for the next silver bullet, aka total freedom as the common-denominator:
Which tools, what stack, and where does it apply?
Any thoughts on that much appreciated Craig.
I have no idea. Right now I'm busy exploring LISP.
ReplyDeleteSo regarding 'all but few edge cases', seems to me with Lisp or not, you will still end up looking for a good (liberating):
ReplyDelete1. HTTP plumbing,
2. text/mark-up processing stack, and
3. some tools to transcend frameworks.
Am I missing something?
No, you're not missing anything. I'm going to start with LISP and see how far that takes me. It's an experiment.
ReplyDeleteHTTP plumbing is easy, though: IIS or Apache fit the bill nicely.
I agree in part - i do think that WCF should make interop with POST and GET easier. I am doing some stuff on precisely that at the moment as we need mobile phone clients in Java to be able to call them! I have it working, but although i like a REST approach to reading data, creating and updating is tricker.
ReplyDeleteIn a more complex scenario - and most outside of demonstrations get that way pretty quickly - i like what WCF and SOAP give you (one of the first things i did was add SOAP headers to save passing tokens etc with every call body). I can go quickly to P2P and it's easy to separate my services and data in WCF.
We're in a era of plugging services on the web via simple API's at the moment, but longer term this will become complex again - it has to coz business rules are complex. If i want to update Twitter and Jaiku at the same time it's two POST's, but if i was updating something important i'd want a transaction to wrap them and so on. Heck, even it is wasn't i'd *like* this (i've got a lot of positive opportunities from "throw away" posts).
My concern is, and continues to be that i need to do work to get this to work on browsers and for other simple API clients. I'd like MS to have a tool that helps me do this and sets up the necessary settings (based on API usage scenario rather than pure service implementation).
A few comments:
ReplyDelete* Why does it have to be WCF? WCF is designed to abstract the protocol. But the things that REST gives you are all about embracing the protocol. Sounds like a recipe for complexity to me. And indeed it is if you look at WCF in any detail.
* SOAP-the-format is not exclusive with REST. SOAP-the-protocol is. Go ahead and use SOAP payloads in your HTTP POSTs. Of course, if all you care about is headers, there are a million easy ways to do that. Cookies, for example.
* If you need to scale, then protocol independence is not a viable option. The idea that you can "just go P2P" inherently means abandoning things like eTags and cache control that are important for some apps. Maybe not for yours, though.
* It's trivial to design systems for transactions without having to resort to WS-*. What about HTTP makes you use two POSTs? Unless they're two different businesses, and then frankly you have a whole host of different problems that have nothing to do with technology. Also, I have a hard time thinking of a real world scenario where this would actually come up. When it does (e.g. banking), then WS-* is probably the right approach. I don't write apps like that, though.
* Tooling is somewhat of a concern, but frankly having spent the last five years working inside the scope of the tooling, I have found that it makes simple things simple and hard things hard. Which means I'm going to be reasonably well off doing it myself a lot of the time.
But I'm not trying to say that *you* don't need WCF and WS-*. Maybe you do - it certainly has its uses. Just like COM+ did and still does. Just that I think they're a lot fewer and farther between than I used to. To the point where I can't think of anything I've done that actually needs it.
I think that the biggest problem with SOAP are two of it's pillars: WSDL and XML Schema.
ReplyDeleteTo quote Jim Webber, WSDL is a turd. That pretty much sums it up. Check out SSDL http://ssdl.org/ for a brilliant alternative.
XML Schema isn't so bad, it's the validation contraints that make it cumbersome. Schematron is the best tool for Doc-Literal validation, and RelaxNG is a decent alternative.
SOAP (+WS-Addressing) as the lowest abstraction in the WS stack is just fine, it's some of the things used along with it that make it ridiculous.
I should point out, that this post which claims to talk about the failure of SOAP, doesn't seem to really talk about the failure of SOAP. It simply talks about some alternatives to SOAP.
ReplyDeleteIt seems like we're discussing a Known Truth(tm), that isn't well defined.
The article was attempting to say that SOAP is no longer *my* default choice for programming web services, in much the way that COM+ is no longer my default choice for programming transactional systems. And for many of the same reasons.
ReplyDeleteIn that sense, I believe it failed to live up to the promise that many marketed it as having. I was one of the many who were out there promoting SOAP, so I certainly take my share of responsibility on that count.
If you thought I was trying to prove more than that, well, sorry. :) The title was as much a play on the title of a previous post as it was a comment on the success of SOAP: taken together, the two parts showed how one guy (me) wrote a very successful SOAP service and yet found the technology ultimately lacking compared to a simpler alternative. It's sort of a theme in my career. ;)