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.

Trackback

no comment until now

Add your comment now