A quiz for Web services architects on SOAP message paths …<\/p>\n\n
Say we had a purely SOAP based (i.e. not HTTP or other underlying\nprotocol issues to concern us) publish\/subscribe configuration, with\nthree nodes; node A publishes to a queue at node B, and node C subscribes\nto the queue at node B, receiving all documents published to B.\nNow assume a scenario where C is already subscribed to B, and A publishes\na document to B;<\/p>\n\n\n\n
My question is, how many SOAP message paths did I just describe?<\/em><\/p>\n\n Scroll down for the answer.<\/p>\n\n I think there are two possible answers that people will give (though\nonly one correct one, of course 8-). One answer is that this is\none<\/em> message path; A as sender, C as ultimate destination, and\nB as a (non-terminating) intermediary. The other possible answer is that\nthere are two<\/em> message paths; the first path with A as sender and\nB as ultimate destination, and the second with B as sender and C as\nultimate destination (which also happens to make B a terminating<\/em>\nintermediary).<\/p>\n\n I think “two” is the correct answer, primarily because pub\/sub is\nabout identity decoupling; removing the need for A to know about C.\nTherefore C cannot possibly be the ultimate destination since A\ndoesn’t know it exists. From A’s POV, it’s sending the SOAP message\nto B, period. And from C’s POV, it is receiving a SOAP message from\nB, period. The SOAP envelopes sent along each path might be bitwise\nidentical, but they are different SOAP messages<\/em>. FWIW, this\nis why the SOAP spec\nsays<\/a>\n(as a result of a clarification request of mine, IIRC);<\/p>\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n\n\nAn ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message\n<\/blockquote>\n\n