 |
|
 |
 |
|
|
 
Michael Champion's BlogWhen does SOAP add value over simple HTTP+XML?Posted by mchampion on June 13, 2003 at 11:04 AM | Comments (5)Sean McGrath seems to be the first to link to this weblog, and I'll return the favor by publicly disagreeing with him <grin>. Actually, there's not a whole lot in the XML world that Sean an I disagree about, I strongly recommend his ITWorld columns . But apparently the benefits of SOAP are one of them, as he says: " I would argue that it is not the case that for more complex apps, SOAP is better. Sure, there comes a point where you cannot encode parameters into a URI but I don't see why it follows that these more complex web services need to throw out the huge advantages of having a GETable URI." First, as of SOAP 1.2 (very soon to be a W3C Recommendation) there is no conflict between SOAP and "having a GETable URI." SOAP has a web method feature: Bindings to HTTP or such other protocols SHOULD use the SOAP Web Method feature to give applications control over the Web methods to be used when sending a SOAP message. In short, SOAP 1.2 allows and encourages the use of HTTP GET to invoke services that simply return data, thus allowing one to hyperlink to SOAP services, exploit HTTP caches of the results of frequently-accessed services, etc. But, one might ask (and people very frequently do!), what benefit does one get from SOAP if just GETing or POSTing XML data works just fine in your application? One very reasonable answer is "not much." Sure, once WSDL 1.2 (which wll support the web method feature in SOAP) is out we can expect tools to make it very easy to generate programming language code to invoke "GETable URI" SOAP services, but that is in the future sometime. A better answer, I think is that SOAP provides an architectural foundation for extended services as requirements evolve. For example, "raw XML over HTTP" works just fine for simple services over a secure intranet (or the public internet when SSL provides adequate security). But what happens as the requirements on the service creep upwards and one must: support:
So, if you are likely to have some of these challenges, building SOAP into the architecture lets you leverage emerging technologies such as WS-Security, WS-Routing, one of the several reliable messaging proposals, WS-Transaction, WSBPEL, etc. that build on the SOAP infrastructure. If, on the other hand, you are saying to yourself "that's WAY more complicated than anything I want to do," then SOAP may not be for you. Likewise, if you are saying "I need to do that stuff MY way rather than the way some industry committee's way," then perhaps you are better off putting this stuff into your own application rather then buying an off-the-shelf solution, and SOAP doesn't offer anything you need. But this is something to be analyzed -- it's just as "wrong" to blindly reject SOAP as to blindly accept. it. Still, at a more fundamental level I think Sean and I agree on the basic architectural principle here :"I have learned to really appreciate the power of the "distributed systems as stateless document exchange," which I believe lies at the heart of what makes HTTP so stunningly successful. " It often makes more sense to think of XML-powered applications as transformation pipelines (see Propylon's PropelX and Software AG's EntireX Mediator as pioneering tools that support this approach) rather than objects to be exposed with APIs. More on this in a future edition ...but in either scenario, SOAP may add enough value to justify its use. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
