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 …
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.