WS-Addressing


WS-Addressing is one of the WS-* specifications that has been widely embraced by the software vendor community. It provides a framework for one of the most fundamental tasks of any service-oriented application-indicating the target of a message. To this end, all other WS-* specifications (for example, WS-ReliableMessaging, WS-Security, WS-AtomicTransac-tion, and so on) build on WS-Addressing. The full WS-Addressing specification is available at http://www.w3.org/TR/ws-addr-core/.

This specification defines two constructs that are normally found in the transport layer. The purpose of these constructs is to convey addressing information in a transport-neutral manner. These two constructs are endpoint references and message addressing properties.

Endpoint References

So far, we have used the terms initial sender, intermediary, and ultimate receiver to describe the entities participating in a message exchange. These participants can also be considered service endpoints. Simply defined, a service endpoint is a resource that can be the target of a message. Endpoint references, as defined in the WS-Addressing specification, are a way to refer to a service endpoint.

Can’t we just use a URL to identify the target of a message? URLs will work in some cases, but not all. URLs are not well suited for expressing certain types of references. For example, many services will create multiple server object instances, and we might want to send a message to a particular instance of the server object. In this case, a simple URL just won’t do. Based on our experience with the Internet, we might assume that we could add parameters to the address, thereby associating our message with a specific set of server objects. This introduces a few problems. For example, adding parameters to a URL will tightly bind our message to a transport, and we might not know the specific parameters until after we have initiated contact with the server (as is the case with Amazon’s session IDs).

image from book
A Legitimate Debate

It’s reasonable to ask the question “Why do we need more than a URL to refer to a service endpoint?” In fact, this is a really good question, and one that is actively debated in distributed architecture communities today. On one side of the discussion is a community that says a service should be referenceable via a URL. Furthermore, it is even possible to reference a specific instance of a service through a URL, as this is commonly done on the Internet today. All you have to do to prove this point is take a look at the URL generated as you purchase something at Amazon.com. You’ll notice that after you sign in, your URL changes to contain a unique session ID. That session ID is tracked on the Amazon server and associated with you and your shopping cart. The people on this side of the debate see no reason to ever venture outside of describing a service with the URL, and they use the global adoption of the Internet as evidence of the viability of their position. Representational State Transfer (REST) is an architectural style that embraces this mode of thought. WCF can be used in the REST architectures.

On the other side of the debate is a group that says that HTTP URLs and the PUT/DELETE/GET/POST HTTP commands are not sufficient for all services. If we take another look at the Amazon example, several things are implicit. For example:

  • HTTP is always the right transport.

  • Security is provided via the transport (HTTPS).

  • We need to secure only the message transmission (from client to Web server).

  • It is OK to make a request for session-specific parameters.

The people on this side of the debate claim that these limitations are not acceptable for all services and distributed applications. In their opinion, service orientation demands transport independence and security outside the transport. Those who agree with SOAP and the WS-* specifications embrace this side of the debate.

In my view, there is room for both architectural styles, and each has its place. There is no question that the architecture of Amazon.com is wildly successful for publicly available services, but for back-end processing, I do not think that the implicit limitations in a REST architecture will work in all circumstances. The big limitations I see with the REST architectural style are dependence on a single transport, a lack of message-based security, and a lack of transactional support.

Clearly, WCF can be used in SOAP/WS-* implementations, and most of this book is dedicated to describing these concepts. In future releases of WCF, there will be more support for REST architectures.

image from book

image from book
URI, URL, and URN

The terms URI, URL, and URN (Uniform Resource Indicator, Uniform Resource Locator, and Uniform Resource Name) are used frequently in the WS-* specifications. To comprehend the full impact of what the WS-* specifications reference, we must understand the subtle differences between these three terms. In general, URI, URL, and URN are ways to name and/or locate a resource. If we were to think of the information world as an information space, a URI is a string that one can use to locate or name a point in that space. A URL, as opposed to a URI, is strictly intended to locate a resource. A URN, as opposed to a URL, is strictly intended to name a resource. From a set perspective, the URL and URN sets are members of the greater URI set.

image from book

These logical properties are physically implemented as XML Infoset element information items. Some properties, like Reference Properties, Reference Parameters, and Policy, can wrap other XML element information items. Here’s how these properties can be represented in XML:

 <wsa:EndpointReference xmlns:wsa="http://schemas.xmlSOAP...">   <wsa:Address> ... </wsa:Address>   <wsa:ReferenceProperties> ... </wsa:ReferenceProperties>   <wsa:ReferenceParameters> ... </wsa:ReferenceParameters>   <wsa:PortType> ... </wsa:PortType>   <wsa:ServiceName> ... </wsa:ServiceName>   <wsp:Policy> ... </wsp:Policy> </wsa:EndpointReference>

Message Information Headers

WS-Addressing also defines a set of standard SOAP headers that can be used to fully address a message. As you might expect, these headers are actually XML Infoset element information items that represent the same functionality we derived in the section “Addressing the Message” earlier in this chapter. The real benefit seen here is a standard set of headers whose function can be commonly agreed upon between application vendors.

The following code snippet contains message information headers and their data types as defined in the WS-Addressing specification. These headers should look quite familiar:

 <wsa:MessageID> xs:anyURI </wsa:MessageID> <wsa:RelatesTo RelationshipType=""?> xs:anyURI </wsa:RelatesTo> <wsa:To> xs:anyURI </wsa:To> <wsa:Action> xs:anyURI </wsa:Action> <wsa:From> endpoint-reference </wsa:From> <wsa:ReplyTo> endpoint-reference </wsa:ReplyTo> <wsa:FaultTo> endpoint-reference </wsa:FaultTo>

Notice that the MessageID, RelatesTo, To, and Action elements are of type xs:anyURI. Why is To of type xs:anyURI instead of an endpoint reference? After all, we just went through great pains describing the reasons a simple URI is not enough to address a message. The answer lies in how additional properties that would normally be in an endpoint reference are serialized into a message header. WS-Addressing defines a default way to represent an endpoint reference that happens to be the target of a message as follows.

If a message is going to be sent to the endpoint reference as described here:

 <wsa:EndpointReference xmlns:wsa="..." xmlns:wnt="...">   <wsa:Address>http://wintellect.com/OrderService</wsa:Address>   <wsa:ReferenceProperties>     <wnt:OrderID>9876543</wnt:OrderID>   </wsa:ReferenceProperties>   <wsa:ReferenceParameters>     <wnt:ShoppingCart>123456</wnt:ShoppingCart>   </wsa:ReferenceParameters> </wsa:EndpointReference>

That endpoint reference can be serialized in a message as follows:

 <S:Envelope xmlns:S="..." xmlns:wsa="..." xmlns:wnt="... ">   <S:Header>     ...     <wsa:To>http://wintellect.com/RcvService</wsa:To>     <wnt:OrderID>9876543</wnt:OrderID>     <wnt:ShoppingCart>123456</wnt:ShoppingCart>      ...   </S:Header>   <S:Body>     ...   </S:Body> </S:Envelope>

Notice that the ReferenceProperty and ReferenceParameter elements for To were promoted to full-fledged headers, no longer subordinate to the EndpointReference element. This happens only for the To element, as the From, FaultTo, and ReplyTo elements are endpoint references.

Message Information Header Block Dependencies

As you might expect, certain message information header blocks depend on other message information header blocks. For example, if a ReplyTo header block is present, it would stand to reason that a MessageID header must also be present. Table 2-2 describes the dependencies of the standard message information headers.

Table 2-2: Message Information Header Dependencies
Open table as spreadsheet

Header #

Header Name

Min Occurs

Max Occurs

Depends On

1

wsa:MessageID

0

1

N/A

2

wsa:RelatesTo

0

Unbounded

N/A

3

wsa:ReplyTo

0

1

1

4

wsa:From

0

1

N/A

5

wsa:FaultTo

0

1

1

6

wsa:To

1

1

N/A

7

wsa:Action

1

1

N/A




Inside Windows Communication Foundation
Inside Windows Communication Foundation (Pro Developer)
ISBN: 0735623066
EAN: 2147483647
Year: 2007
Pages: 106
Authors: Justin Smith

Similar book on Amazon
Learning WCF: A Hands-on Guide
Learning WCF: A Hands-on Guide
Essential Windows Communication Foundation (WCF): For .NET Framework 3.5
Essential Windows Communication Foundation (WCF): For .NET Framework 3.5
Programming WCF Services: Mastering WCF and the Azure AppFabric Service Bus
Programming WCF Services: Mastering WCF and the Azure AppFabric Service Bus
Microsoft  Windows  Communication Foundation Step by Step (Step By Step Developer Series)
Microsoft Windows Communication Foundation Step by Step (Step By Step Developer Series)

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net