WS-Addressing defines the Recipient as:
/wsa:Recipient This optional element (of type wsa:EndpointReferenceType) conveys the entire endpoint reference of the recipient. Senders MAY elect to add this header as a processing hint to downstream nodes.
This makes it the unexploded form of the EndpointReference that the sender uses when constructing a message. The unfortunate part of the definition above, in my opinion, is "Senders MAY elect...".
Dispatching incoming messages against EndpointReferences requires a complicated matching process between the EPR, it's ReferenceProperties and the various SOAP headers in the message. I think this could be greatly simplified if the dispatch took place against the Recipient header rather than the contents of all the message headers. Matching two EPR's could then be implemented as an IComparer class in the .NET Framework and this makes a nice mechanism if people want their own specialized comparisons.
Going a step further, you could imagine dispensing with the EPR explosion process and just using the Recipient header instead. However, I think that the idea of ReferenceProperties being exploded to SOAP headers is a means of bridging between existing services that need those headers (i.e. cannot deal directly with the Recipient header) and newer services that can operate solely with WS-Addressing.
Posted by herveyw at January 23, 2004 11:45 PMI'm curious to hear what sort of business scenarios do you have in mind that make it essential to be able to select pipeline, target service and policies based on a full set of reference properties instead of single wsa:To header :)
Posted by: Gia at January 26, 2004 12:14 PM