Related link: http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/
The WS-Addressing specification has reached a status of “Last Call”. This is one of the end-game steps in the W3C process for a specification that is approaching a state of being finalized. “Last Call” basically means that it has reached technical completion by the WS-Addressing Working Group and is now open for public review comments from the public. If the feedback is positive, the Working Group plans to submit this specification for consideration as a W3C Candidate Recommendation. Comments on this document are invited and are to be sent to the public comments list. Comments can be sent until 11 May 2005.
WS-Addressing represents a major milestone in enabling loosely-coupled, interoperable message exchanges between multiple parties. The core WS-Addressing specification describes an interoperable Endpoint Reference (EPR), which can be used in a message to indicate senders, receivers, and other related destinations of a message. These are defined as a <From>, <To>, <ReplyTo>, <FaultTo>, and <RelatesTo> elements. In a world of loosely-coupled, asynchronous communications, these elements are necessary for specifying where a message has been, where it is intended to be headed, and where to send good messages when they behave badly :)
This marks a point in the history of Web Services specifications that clearly indicates we have matured beyond the limited view of single point to point communications between two parties. Using WS-Addressing headers, intermediary services and routers may intercept the path of a message, perform an operation on it, and still maintain the integrity of the intended destination. Using the <FaultTo> element, any intermediary service or router along a multi-hop process may have a single place to route error messages to, rather than try to propagate an SOAP Fault back through the complex set of steps back to the caller. Using the <ReplyTo> header, a message may carry with it a IRI that tells the receiver where to send the reply (if there is one) or perhaps where to forward the message next. This may be an asynchronous or synchronous “reply” that may or may not be the same as the original sender. The <RelatesTo> element can be used to correlate replies with requests in an asynchronous message exchange.