July 12, 2004
@ 01:46 PM
Comments [2]
Addressing insight over beer

I might be blind to not have seen that before, but this here hit me over the third Guinness at an Irish Pub while answering a sudden technical question from my buddy Bart:

<wsa:ReplyTo xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
 <wsa:Address>http://server/service_second_intermediary</wsa:Address>
 <wsa:ReferenceProperties>
  <wsa:ReplyTo>
   <wsa:Address>http://server/service_first_intermediary</wsa:Address>
   <wsa:ReferenceProperties>
    <wsa:ReplyTo>
     <wsa:Address>http://server/service_outer_caller</wsa:Address>
    </wsa:ReplyTo>
   </wsa:ReferenceProperties>
  </wsa:ReplyTo>
 </wsa:ReferenceProperties>
</wsa:ReplyTo>

Read the EPR binding rules section 2.3 in the WS-Addressing spec and you'll find out just like me how distributed "call-stacks" work with WS-Addressing, if your choice of communication pattern is the far more flexible duplex (or here) pattern for datagram-based message conversations instead of the rather simplistic request/response model. Of course, any endpoint-reference can be stacked in the same way. I always wondered where the (deprecated) WS-Routing "path" went, which allowed specifying source routes. I think I ran into it.

Categories: Web Services

« Epiphanies | Home | The Nerd, The Suit and The Fortune Telle... »
Wednesday, November 10, 2004 5:31:57 AM UTC
Clemens - this is cool, but It is important to note that section 3.1 of the spec states that message information header blocks are immutable, so all of this path information needs to be known a priori by the sender of the message. In other words, the path is not dynamically built as the messages pass through intermediaries, but rather, this is a way for the sender to advertise the path a response should take back to it.
Cheers,
Ed
Ed Pinto
Tuesday, December 21, 2004 10:50:30 AM UTC
Clemens --

This is an interesting trick I'd never noticed before. =)

Alas, I don't think it would strictly work with request-reply messages. If it were request-reply, the client would generate an ID "1" to service_second_intermediary. Service_second_intermediary would then generally add two headers -- a MessageID header with a new unique ID "2", and a RelatesTo header with value of "1". Service_first_intermediary would put RelatesTo of "2" and new MessageID "3", etc. Once the message got to the ultimate receiver, and the ultimate reciever constructed a reply, the RelatesTo would reference an ID unknown to the client.

This might work for a one-way message, but I don't know if we'd consider this a "best practice." ;)

-mike
Mike Vernal
Comments are closed.