WS-Addressing is one of the newer WS-* specifications.  The specification brings us closer to the reality of sending SOAP messages across multiple transports in an interoperable way.  Going down the plumbing level with WS-Addressing helped me highlight the gap between the specification and implementations.  Along the way there's a great SOAP Mail sample application using WSE 2.0 that highlights some of the promise of being able to send SOAP messages via HTTP and SMTP.

SOAP is transport neutral, but started with a HTTP binding
SOAP is simply an XML format for describing a message; it doesn’t say how to actually send the message.  SOAP was always meant to be a transport protocol neutral and to define bindings that map how to send SOAP messages over each protocols (like HTTP or TCP). The SOAP 1.2 specification defines a framework for binding the SOAP message exchanges to particular protocols and also includes a description of the SOAP HTTP Binding.  In order to send the SOAP message via HTTP the address is placed in the HTTP header, as this sample SOAP 1.1 message shows:

POST /StockQuote HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://electrocommerce.org/abc#MyMessage"

So the SOAP specification provides a way to put a letter inside of an envelope, but doesn't define a place to write the address on the front.  To continue with the real-world anology, the early solution was to simply tell the postman or courier (the transport protocol) the address.  There are obviously some problems with this approach:

• It's harder to send the item across different protocols.  For example, if you wanted to send the message via postman, then courier, if only the postman knows the address then there has to be some other mechanism to give that address to the courier.  In the SOAP example this translates to sending a SOAP message through intermediaries such as an XML firewall, or across different protocols such as HTTP and SMTP
• If the postman quits then no-one else will know where the message should go.  Since only the postman knows the address, if he drops the letter or quits his job before delivering it, there's no information about where it should go.  In the SOAP example, this translates to a message timeout.

WS-Addressing describes a way of putting the address on the (SOAP) envelope.

WS-Addressing provides a way of describing address information in the SOAP header
The WS-Addressing specification provides a way of placing all of the addressing information inside the SOAP header.  Is provides an XML syntax that can be used in the SOAP Header to describe message destinations.  It uses the concept of endpoint reference to describe a destination that a message can be targeted at.  The endpoint reference contains the address of the endpoint, as well as extra information that can be useful when sending messages such as the message identifier, and any other properties that may be useful when processing a message (such as message correlation, or session information).  There is also the concept of a different address for the reply and fault information.  This post describes how airline luggage stickers can help understand WS-Addressing.

As this WS-* overview article from MSDN says the benefits of WS-Addressing:

The combination of fine-grain control over addressing coupled with the transport-neutral encoding of the message source and destination enables Web service messages to be sent across a range of transports, through intermediaries, and it enables both asynchronous and extended duration communication patterns.

Further, WS-Addressing is designed to:

convey information that is typically provided by transport protocols and messaging systems in an interoperable manner. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application.

So all of this sounds great.  Finally we can put an address on the envelope so that it's possible to send a SOAP message across different protocols.

The WSE 2.0 SOAP Mail sample shows the benefits of WS-Addressing
Expanding the Communications Capabilities of Web Services with WS-Addressing on MSDN shows how to use WS-Addressing and WSE 2.0 Tech Preview to create a SOAP Mail application that allows SOAP messages to be sent over HTTP and SMTP.  The benefits include being able to send a secure message through firewalls and routers, asynchronous and event-based communication.  The article is an excellent demonstration of the benefits promised by WS-Addressing.

The article also highlights the major problem with WS-Addressing: while it's useful to be able to put the address on the enveloped there's still more work to be done to define how to bind the address onto the protocol.  In the article they use a simplified version of the SOAP Version 1.2 Email Binding by changing the content type of the message to make it easier for Outlook to read the email and removing the need for email headers that are already contained in the WS-Addressing policy.  This is fine, but how interoperable is it, or what is being done to improve the Email Bindings to make the solution interoperable?

But there's still work to be done to put the Address in WS-Addressing
So, we're not quite there yet with WS-Adressing.  For one thing, WS-Addressing it doesn't say anything about the content of the address.  It just says it has to be a URI, and that this may be a network or logical address.  This has the benefits of flexibility for the specification, but this needs to be defined for the specification to be implemented.  In the SOAP Mail article they use the following experimental URI:

soap.mail://soapmailrouter@example.com/HttpSyncStockService

As the article says:

The soap.mail URI scheme used by SoapMail is experimental and should not be construed as a proposal for a new URI scheme at this time. Nor should it be mistaken to be a feature of the WS-Addressing specification. The scheme likely will change in a future revision of the sample.

Christian Weyer provides a post from the Indigo newsgroup on the SMTP implementation in Indigo, which also uses a different addressing scheme for sending SOAP messages via email.

What I want to know is what is happening in standards land?  Why doesn't the SOAP Version 1.2 Email binding have a definition for the format of the address URI when sending SOAP messages via email?  This information is essential if the reality of interoperability is to be achieved.

Why isn't WS-Addressing the answer and where are we up to?
So WS-Addressing defines a space for the address on the front of an envelope but not what should be written there.   The WS-Address specification leaves it up to the protocol bindings to say how the logical address is translated into a physical network address:

When a message needs to be addressed to the endpoint, the information contained in the endpoint reference is mapped to the message according to a transformation that is dependent on the protocol and data representation used to send the message. Protocol specific mappings (or bindings) will define how the information in the endpoint reference is copied to message and protocol fields.

Marting Gudgin tells me via email that resolving a logical address to a physical network address on a particular protocol isn't specified by the WS-Addressing specification, but might be done via a local configuration file or talking to the equivalent of a DNS server.  WSE 2.0 Tech Preview has a mechanism using local referral cache xml files that can translate logical addresses into a physical address.  However, the problem still remains - at some point a physical address is needed.

While the high level of abstraction makes the WS-Addressing specification composable, it also makes the process of understanding web service standards so frustrating.  The specifications are obtuse and often difficult to understand unless you work around the people who were on the committees that wrote them.  The overview article makes it sound like the specification solves the problem, but actually the specifications just provide a way that the problem might be solved and leave the smaller parts of the problems to the protocol bindings.  I'm still unsure as to where the protocol binding specifications are at or when they may be delivered.

I'm looking forward to seeing how WSE 2.0 sorts this out
Hervey Wilson has mentioned that final release of WSE 2.0 has taken longer to complete than they thought because they are doing extra work to incorporate WS-Addressing.  I'm looking forward to seeing what they come up with.  I'm hoping that WSE will have worked through some of the issues to do with mapping WS-Addressing specifications onto the different protocols so that it will be possible to send SOAP messages across multiple transports in an interoperable way.