WCF and the WS-Addressing Specification

When using the WSHttpBinding binding, the mechanism that WCF uses to identify message actions, route a message to a service, and send a response message back follows to the WS-Addressing specification. This specification defines a standard format for the message header, containing information such as the action, the address of the destination service, and the return address for any response, which conforming services should use in a SOAP message. As long as a message contains addressing information in this standard format, neither the service nor the client application cares about the technology used to create the message. This is a key factor enabling WCF client applications and services to interoperate with applications and services running on other platforms; you can use WCF to build a router for Web services developed using other languages and running on platforms other than Windows, as long as these Web services also follow the WS-Addressing specification.

Here is an example showing the addressing header of a typical message sent by the ShoppingCartClient application to the ShoppingCartServiceRouter service:

 <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http:// schemas.xmlsoap.org/ws/2004/08/addressing">   <s:Header>     <a:Action s:mustUnderstand="1">       http://adventure-works.com/2007/03/01/ShoppingCartService/AddItemToCart     </a:Action>     <a:MessageID>      urn:uuid:     </a:MessageID>     <a:ReplyTo>       <a:Address>         http://www.w3.org/2005/08/addressing/anonymous       </a:Address>     </a:ReplyTo>     <a:To s:mustUnderstand="1">       https://localhost:9070/ShoppingCartService     </a:To>   </s:Header>   <s:Body>     …   </s:Body> </s:Envelope>

Much of the information in this header should be reasonably clear, although there are one or two points that require further explanation. In particular, you might expect the Address in the <ReplyTo> element to contain the address of the client endpoint. The question is: what is the address of the client endpoint? In many cases, you cannot easily specify the information for a reply address in a manner that is meaningful in a SOAP header (several applications might share the same address, or the address might even vary between the time the application sends the message and the time the service responds). For this reason, the WS-Addressing specification allows a client application to insert this “anonymous” placeholder instead. However, the client application must provide some alternative mechanism of providing an address to enable the service to send it a response. The way in which the client application and service negotiate the reply address is independent of the WS-Addressing specification and frequently depends on the underlying transport mechanism. For example, the client might expect the service to reply using the same connection that the client used to send the initial request. The exact details of how this happens are beyond the scope of this book.

The other noteworthy part of the WS-Addressing header is the <MessageID> element. Each message that the client application sends has a unique identifier. When a service responds, it should include this same identifier in a <RelatesTo> element in the response header. A typical response to an AddItemToCart message from the ShoppingCartService service looks like this:

 <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http:// schemas.xmlsoap.org/ws/2004/08/addressing">   <s:Header>     <a:Action s:mustUnderstand="1">       http://adventure-works.com/2007/03/01/ShoppingCartService/AddItemToCartResponse     </a:Action>     <a:RelatesTo>      urn:uuid:     </a:RelatesTo>   </s:Header>   <s:Body>     …   </s:Body> </s:Envelope>

When the client application receives this response message, it can use the information in the <RelatesTo> element to correlate the response with the original request.

More Info 

You can find a detailed description of the WS-Addressing specification on the Microsoft Web Services and Other Distributed Technologies Developer Center at http://msdn.microsoft.com/webservices/webservices/understanding/specs/default.aspx?pull=/library/en-us/dnglobspec/html/ws-addressing.asp.

The WS-Referral Specification and Dynamic Routing

The approach to building a router described in this chapter works well, but the routes it defines are static; the addresses of the services are hard-coded into the router. The next evolutionary step is to build a dynamic router that routes messages to services that register themselves with the router. This is actually a common scenario, and the WS-Referral specification defines a protocol that enables a SOAP router to dynamically configure and modify its paths for routing messages. The WS-Referral specification describes a standard set of messages that services can use to register themselves with a SOAP router, and the messages to which they are interested. The SOAP router can store this information in a referral cache. When a client application sends a request message to the SOAP router, the router can query the referral cache, obtain the address of a service that can handle the message, and forward the request to this service.

WCF does not provide explicit support for the WS-Referral specification, but if you are interested in this approach to message routing, you should look at the Intermediary Router sample included with the WCF samples in the Microsoft Windows SDK. This sample is also available online at http://windowssdk.msdn.microsoft.com/en-us/library/ms751497.aspx.

More Info 

For a detailed description of the WS-Referral specification, see the Web Services Referral Protocol page at http://msdn2.microsoft.com/en-us/library/ms951244.aspx.