When does SOAP add value over simple HTTP+XML?

Michael Champion makes some good points, but Sean McGrath blows him away.
Both of their writings are included below.

   Adam



http://weblogs.java.net/pub/wlg/118

When does SOAP add value over simple HTTP+XML?
Michael Champion (June 13, 2003 11:04AM PT)

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:

Routiing and reliable messaging across multi-node networks, such as when one must perform content-based routing from an HTTP gateway to the appropriate back-end service (e.g., the one nearest to the consumer). 
End to end encryption (from consuming application to service rather from consuming application to SSL gateway) 
integration of legacy services that may not have an HTTP URI 
Non-HTTP communications protocols and interfaces such as BEEP, MQ and JMS 
Multipart service transactions that must be committed or rolled-back/compensated as an entity 
More complex interactions between service suppliers and consumers that need to be described and choreographed. 
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.

Michael Champion is a research and development specialist at Software AG, working out of Ann Arbor, Michigan. 


http://seanmcgrath.blogspot.com/2003_06_08_seanmcgrath_archive.html#200423565

Bursting a couple more SOAP bubbles 

As Mike says on his java.net blog, there is very little that we disagree about in the XML world. We see eye to eye on way more things than we disagree on. Mike points to some areas where he suggests SOAP can add value over XML/HTTP. I can confirm that this is something we do disagree on.


Mike puts forward 6 areas where SOAP can add value of HTTP/XML. Lets look at each one:




Routiing and reliable messaging across multi-node networks, such as when one must perform content-based routing from an HTTP gateway to the appropriate back-end service (e.g., the one nearest to the consumer). 



No problem. Put your XML message payloads in a suitable business level envelope and use RESTian URIs to issue receipts for two-phase commit reliable messaging. [Irony alert - the Biztalk Framework from Microsoft has offered this facility using nothing fancier than ASP pages for years now :-)].



End to end encryption (from consuming application to service rather from consuming application to SSL gateway) 



No problem. I can encrypt XML for end-to-end delivery just fine. I don't need SOAP for encryption.



integration of legacy services that may not have an HTTP URI 



No problem. HTTP proxies are wonderful things.a HTTP "stack" is a trivial thing to put together in comparison to a SOAP stack.



Non-HTTP communications protocols and interfaces such as BEEP, MQ and JMS 



No problem. HTTP is ubiquitous, proven and simple. Need JMS, MQSI etc? Tunnel'em over HTTP. A lot of JMS stuff out there works this way right now. SOAP adds nothing here.



Multipart service transactions that must be committed or rolled-back/compensated as an entity 



No problem. I can rollback a transaction by exchanging a message in XML over HTTP just fine. If anything, SOAP is counter-productive here as it encourages a mindset in which the network disappears from the equation. See The Eight Fallacies of Distributed Computing. I have heard developers say that SOAP gives them what they need to do ACID transactions on their intranet. ACID in a distributed system where the network is not under your complete control doesn't work, hasn't worked and won't work. If you really want to give it a go, try CORBA!



More complex interactions between service suppliers and consumers that need to be described and choreographed. 



No problem. Description and choreography are orthoganal issues. I can describe business processes and orchestrate them just fine without regard to how the nodes in the process communicate. Again I think this is an area where SOAP is positively counterproductive. When I see developers bludgeoning their business process state machinery into what is basically the envelope structure of a software interrupt I weep :-)





Yes its good that the SOAP WG took the concerns of the TAG on board and added GETability to simple SOAP services but its , well, "tokenism" is one possible word for it.


Fact is, the last thing the budding world of web services needs is a premature standardisation of the wrong paradigm. RPC. Thats where SOAP started and it has been backpedalling like crazy, adding more and more layers of goo, ever since. HTTP is not a transport protocol guys. It is a resource transfer protocol. A very different - and very powerful thing.


This one needs to be ripped up, torn down, rethought and started again - *when* and only *when* there is sufficient body of lore on how web services really will work. We cannot just standardise our way around finding out what really works! Lets do that,then worry about standards when there is something worth standardising.


I would urge anybody interested in this stuff to read Mark Baker and Paul Prescod.



-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5