In a comment on a pro-REST, anti-SOA post, this gem;
REST has the potential to transform and simplify data exchange using many of the same idioms that have been maturing with the Web for 11 years. In my opinion, SOAP has the potential to…keep us shackled to outdated architectural ideas.
8-)
A quiz for Web services architects on SOAP message paths …
Say we had a purely SOAP based (i.e. not HTTP or other underlying protocol issues to concern us) publish/subscribe configuration, with three nodes; node A publishes to a queue at node B, and node C subscribes to the queue at node B, receiving all documents published to B. Now assume a scenario where C is already subscribed to B, and A publishes a document to B;
My question is, how many SOAP message paths did I just describe?
Scroll down for the answer.
I think there are two possible answers that people will give (though only one correct one, of course 8-). One answer is that this is one message path; A as sender, C as ultimate destination, and B as a (non-terminating) intermediary. The other possible answer is that there are two message paths; the first path with A as sender and B as ultimate destination, and the second with B as sender and C as ultimate destination (which also happens to make B a terminating intermediary).
I think “two” is the correct answer, primarily because pub/sub is about identity decoupling; removing the need for A to know about C. Therefore C cannot possibly be the ultimate destination since A doesn’t know it exists. From A’s POV, it’s sending the SOAP message to B, period. And from C’s POV, it is receiving a SOAP message from B, period. The SOAP envelopes sent along each path might be bitwise identical, but they are different SOAP messages. FWIW, this is why the SOAP spec says (as a result of a clarification request of mine, IIRC);
An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message
Also note that any attempt on A’s part to try to identify a recipient past B is known as source routing, and is, as a wise friend reminded me yesterday, the root of all evil.
For those that might still care about the issue of WS-Addressing’s (and possibly SOAP 1.2’s) abuse of the HTTP Request-URI, some more information…
The semantics of Request-URI are unambiguous in RFC 2616;
The Request-URI […] identifies the resource upon which to apply the request.
Period. Over and out. Elvis has left the building. There are dozens of commercial and open source implementations, and thousands of deployed instances of those implementations, that count on that being the case.
Now, if you buy the position of the WS-Addressing WG (and possibly even of the XML Protocol WG in the form of SOAP 1.2), they’d have you believe that the Request-URI identifies the next hop in the chain. Note that this definition is different than the previous one.
Note to my friends; if you ever find me advocating a position that attempts to redefine, in a non-backwards compatible way, a key part of the most successful application protocol ever developed, you have my permission to shoot me. Thanks.
Still catching up …
So I guess there was a minor hulabaloo over Dare’s piece on his preference for SOAP over REST. From what I can tell though, all he’s saying is that SOA/SOAP is a better fit for his mental model of how distributed systems work. That’s fine. It was mine too, long ago, when I used to hack CORBA ORBs. Then I realized that the Web was a superior platform for large scale integration with documents, which forced me to change my mental model, since obviously one should endeavour to have their mental model match the superior style (at least if one cares about their careers 8-). As Dare concludes;
My point from yesterday was that as far as approaches go, I prefer to think of building distributed applications from a service oriented perspective than from a REST perspective. This is completely different from endorsing SOAP over using POX/HTTP as the technology for building distributed applications. That is a discussion for another day.
Looking forward to it, Dare.
For those that think that the SOAP 1.2 HTTP binding is a transport binding… so sayeth the spec;
This binding of SOAP to HTTP is intended to make appropriate use of HTTP as an application protocol
Here’s a simple question for WS-* advocates; how does one take a SOAP envelope/infoset generated by the WS-Addressing SOAP binding, and send it via the SOAP 1.2 default HTTP binding? Should be trivial, right? Let’s see. Here’s an example envelope (from the WS-A spec);
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<S:Header>
<wsa:MessageID>http://example.com/6B29FC40-CA47-1067-B31D-00DD010662DA</wsa:MessageID>
<wsa:ReplyTo>
<wsa:Address>http://example.com/business/client1</wsa:Address>
</wsa:ReplyTo>
<wsa:To>http://example.com/fabrikam/Purchasing</wsa:To>
<wsa:Action>http://example.com/fabrikam/SubmitPO</wsa:Action>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>
That envelope contains both a wsa:To and wsa:Action header, which are, respectively, where the message is to be sent, and the action that is requested be done. Now, off in SOAP/HTTP land, we have a set of properties of the default binding which are required in order to construct a SOAP/HTTP message. Amoungst these properties are ImmediateDestination – “where the envelope is to be sent” – and then either Action or Web-Method (or both – who knows?!) which define the – you guessed it – “the action that is requested be done”. So, you’d think that WS-Addressing would have to define how to populate those properties from a WS-A infoset, ideally as a function of things like wsa:To and wsa:Action. AFAICT, it doesn’t.
And to think this think got to CR?! Egads.
The concept of a “SOAP binding” is prima facie broken because it necessarily requires treating underlying protocols as transport protocols, as if the SOAP envelope was actually a SOAP message (hint: it isn’t). WS-Addressing should either a) map the relevant part of its infoset to the property model of the default SOAP/HTTP binding (e.g. wsa:To -> SOAP’s ImmediateDestination), or b) define a new SOAP/HTTP binding that does the same thing, should problems be found reusing the default binding.
On axis-user, somebody just posted a link to an old but interesting article titled “Which style of WSDL should I use?”. I had a chuckle at one part, when the author was describing the pros and cons of doc/lit. He used this example message;
<soap:envelope>
<soap:body>
<xElement>5</xElement>
<yElement>5.0</yElement>
</soap:body>
</soap:envelope>
… and then wrote this as one of the “weaknesses” with it;
The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
Yes, heaven forbid that you might have to go to the extreme expense of minting a new endpoint (URI)!
For those playing along on the home-game, that’s now at least two folks who’ve stared truly document oriented services right in the face, but blinked.