This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

WS-Addressing and the Next Hop

Stefan Tilkov,

It’s over a month old, but I second Sanin Saracevic’s call for real-life examples of next-hop routing using WS-Addressing. Aaron Skonnards’s much-cited article attempted to explain how to move from WS-Routing to WS-Addressing, but although it mentions next-hop routing, it doesn’t go into much detail.

Here is my scenario: I want to introduce an intermediary into a communication path between consumer and provider. My initial thought was that the best way to do this is to encode the ultimate receiver’s address (i.e., that of the provider) in a wsa:To header, that of the consumer into the wsa:ReplyTo header, and then send the message to the intermediary. After learning from this post that WSE 2.0 (which is not my target platform, but sort of a reference implementation) rejects a SOAP message if the actual address of the endpoint it’s being sent to and the wsa:To field don’t match, I have to question my own reasoning — this would mean that one has to put the address of the next hop into the wsa headers. But if that is the case, where do I put the address of the ultimate receiver? And what about this mysterious via header that I can’t seem to find in the spec?

In the end, it may well be that my problem simply can’t be solved with WS-Addressing alone since it adds support for addressing only — as its name implies. But that doesn’t really explain how one could possibly move one of the dynamic routing scenarios supported by WS-Routing to WS-Addressing …

On June 1, 2005 1:42 PM, Jan Alexander said:

There is no need to have the transport address same as is the wsa:To address. For example WS-Discovery specification uses soap.udp://239.255.255.250:3702 as a transport address and urn:schemas-xmlsoap-org:ws:2005:04:discovery as a wsa:To address for multicast messages. If WSE refuses to send message to transport address that differs from wsa:To address, it is only for the implementation reasons.

On June 1, 2005 2:41 PM, Stefan Tilkov said:

Thanks Alex. So in your opinion, my initial idea - sending the message to the intermediary with wsa:To pointing to the ultimate receiver would be the right way?

On June 1, 2005 3:04 PM, Jan Alexander said:

Yes. In ideal case you should only care about the address of the ultimate destination and let the messaging infrastructure care about how to route the message to it (using as many intermediaries as necessary). This is very similar to how IP packets are routed through the Internet infrastructure.

On June 1, 2005 5:20 PM, Stefan Tilkov said:

OK.

But thinking about it some more, I’m not really sure I like this approach that much. One of the benefits of WS-A, at least as far as the claims go, is that addressing information is incorporated into the message instead of being kept out-of-band on the transport layer. If this is the case, the message itself should contain all of the information needed to send it. I can understand why the static, pre-defined route approach taken by WS-Routing has been abandoned; still, IMO the message would have to contain at least the address of the next hop in addition to that of the ultimate receiver to be routable by the infrastructure. Right?

On June 2, 2005 11:05 AM, Jan Alexander said:

The goal of WS-Addressing spec is to allow sender to send a message to a recepient without having to care about the message routing details. The infrastructure can decide how to route message using as many intermediaries as necessary. This routing is transparent for both sender and recepient application code.

What you are trying to do is to use WS-Addressing for application level routing where your next hop is potentialy a logical address too. This use case in not targeted by WS-Addressing, you will have to use your application logic and application-specific metadata for the routing decisions among your logical hops and to use WS-Addressing for delivering message just between two adjacent logical hops.

In other words: For your use case using just WS-Addressing for message routing is not enough. There is a gap between the original WS-Routing spec and the WS-Addressing spec, no doubt about that.

On June 2, 2005 11:49 AM, Stefan Tilkov said:

Thanks Alex, that clarifies things for me. We’re yet to make up our mind, but one possible approach I’m considering is to add a via element in a proprietary namespace, but re-use wsa:To and wsa:Action inside of it.

On July 16, 2005 10:29 AM, Joel said:

Stefan, the WSE 2.0 framework implements SOAP routing over HTTP by leveraging the WS-Referral specification; WS-Referral is the gap that Alex spoke of. The SoapHttpRouter class in WSE 2.0 uses a file, named the “referral cache”, that contains routing instructions. Each intermediary has its own referral file that it uses to perform a match against the contents the WS-Addressing “To” field. The result of this match is a URL that the router uses to deliver the message to the next intermediary or ultimately the final endpoint.