This post originated from an RSS feed registered with Python Buzz
by Sean McGrath.
Original Post: Bursting a couple more SOAP bubbles
Feed Title: Sean McGrath, CTO, Propylon
Feed URL: http://seanmcgrath.blogspot.com/rss/seanmcgrath.xml
Feed Description: Sean McGrath's Weblog.
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.
Previous Topic
