Web Services and Stateful Resources - Role of WS-Addressing

(Page 4 of 5 )

We'll now describe the role WS-Addressing plays in the WS-Resource Framework, leading up to the concept of the implied resource pattern that codifies how stateful resources are used as context in the processing of Web services requests. WS-Addressing was introduced by BEA, IBM, and Microsoft in March 2003 in order to standardize the notion of a pointer to a Web service. WS-Addressing is an XML representation of such a pointer together with a specified SOAP binding that describes how WS-Addressing is to be used by applications. By standardizing the mechanism of a pointer to a Web service, applications can share references to a Web service, including passing a Web service pointer as part of a Web service request message.

For example, in SkatesTown's StockAvailableNotification Web service, the registrationRequest message contains an application-specific means to identify the Web service to be notified when currently out-of-stock items become available. This is a significant interoperability issue for SkatesTown's customers. If each vendor has its own XML representation of a pointer to a Web service for notification, it becomes expensive for a customer to interoperate with each vendor. The solution is to establish a standard XML representation of a pointer to a Web service and have all vendors and customers adopt the standard. WS-Addressing provides this standard to SkatesTown and its customers.

WS-Addressing Endpoint Reference

In WS-Addressing, the XML representation of a Web service pointer is called an endpoint reference. A WS-Addressing endpoint reference contains a transport-specific network address to a Web service and an optional set of additional meta-data about the Web service. Let's examine a WS-Address endpoint reference used by SkatesTown:

<wsa:EndpointReference
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/

03/addressing" 
xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/

12/policy"
xmlns:tns="http://www.skatestown.com/services/

StockAvailableNotification">
<wsa:Address> http://www.skatestown.com/services/

StockAvailableNotification
</wsa:Address>
<wsa:PortType>tns:StockAvailableNotificationPort

Type</wsa:PortType>
<wsa:ServiceName

PortName="StockAvailableNotification">
tns:StockAvailableNotification 
</wsa:ServiceName>
<wsp:Policy ... 
<wsa:ReferenceProperties>
<tns:someProperty> ABC 123 </tns:someProperty>
</wsa:ReferenceProperties>
</wsa:EndpointReference>

This endpoint reference points to the StockAvailableNotification service from Chapter 4. The only required element of an endpoint reference is Address; all the others are optional. Note the similarity between an endpoint reference and a WSDL 1.1 service element. The Address element contains the transport-specific address of the Web service (in this case, an HTTP URL). The PortType element gives the name of the portType implemented by the Web service located at http://www.skatestown.com/services/ StockAvailableNotification—that is, StockAvailableNotificationPortType. Note that the application examining the endpoint reference could retrieve the actual WSDL definition of the portType by querying an XML registry repository, trying to resolve the namespace URI, or some other means. The ServiceName element explicitly identifies the WSDL service element that this endpoint reference is equivalent to. The Policy element contains a Policy expression associated with this Web service. Recall from Chapter 4 that WS-Policy is the language that specifies various nonfunctional characteristics of the Web service, such as security requirements, quality of service guarantees, and so on. We'll discuss the other element, ReferenceProperties, in more detail in the next section.

Given there is so much overlap with the WSDL 1.1 service element, why do we need an endpoint reference? The major reason is that WSDL 1.1 has very limited extensibility; the roles of the service and port are fixed and don't allow sufficient extensibility to support environments such as dynamic generation of new Web services and environments where specific shared understanding exists between requestors and providers. And as you'll see later in this chapter, the endpoint reference is handy when you're referring to the combination of a Web service and a stateful resource.

When a requestor receives an endpoint reference as part of an input message request, or perhaps as part of a response message, the requestor's middleware typically forms a software component called a proxy to the Web service referenced by the endpoint reference. This proxy typically encapsulates the requestor's application from the binding and policy details associated with the Web service.

Next: Using the Endpoint Reference >>
 

More Web Services Articles
More By Sams Publishing

Comments On: Web Services and Stateful Resources

· This article is an excerpt from the book "Building Web Services with Java: Making...   >>> Post your comment now!

Buy this book...

This article is excerpted from chapter 8 of the book Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418). Check it out today at your favorite bookstore. Buy this book now.