Web Services and Stateful Resources - Using the Endpoint Reference
(Page 5 of 5 )
The other important part of the WS-Addressing specification is the way in which the endpoint reference is used by requestors to form Web service messages. The WS-Addressing specification requires that each binding type associated with the Web service define a set of rules that dictate how the components of the endpoint reference must be used to form request messages to the Web service pointed to by the endpoint reference. The specification itself defines only the rules specific to SOAP binding.
The SOAP rules are simple: The contents of the Address field must appear in the SOAP message's To header, and the contents of the reference properties element must appear as headers in the SOAP message. Here's an example SOAP message that represents a registration request (see Chapter 4 for more details) to a StockAvailableNotification service, as pointed to by the endpoint reference we showed earlier:
<tns:someProperty> ABC 123 </tns:someProperty>
The way the reference properties flow (as SOAP header elements of the message) is important to establish context for processing the message. The WS-Resource Framework exploits this feature, as you'll see later in this chapter.SOAP Headers Defined by WS-Addressing
WS-Addressing also standardizes a collection of SOAP headers. You saw one of these SOAP headers in the previous example: the To header. The other headers are summarized in the Table 8.1.Table 8.1
SOAP Headers Standardized by WS-Addressing
WS-Addressing SOAP Header
The destination header. WS-Addressing requires this header to appear on messages sent to a Web service pointed to by an endpoint reference. Its content is a copy of the contents of the Address element in the endpoint reference.
An optional header. It contains a copy of the endpoint reference of the Web service that is the intended recipient of the message. If this header appears, it may help middleware intermediaries to process and route the message.
An optional header that contains an endpoint reference of the Web service that created the message.
An optional header that contains an endpoint reference of a Web service to which any reply to the message should be sent. If this header doesn't appear, the receiver of the message can use the From element to send reply messages. This aspect of WS-Addressing is useful for asynchronous messaging situations where the network transport protocol can't be relied on to target the response message.
An optional header that contains an endpoint reference of a Web service to which any fault messages should be sent. If this header doesn't appear, the receiver of the message can use the ReplyTo or From element to send fault messages.
A mandatory element that contains a URI indicating the intent of the message.
An optional URI that uniquely identifies this message.
An optional collection of QName, URI pairs. This allows you to specify the relationship between this message and other messages in a domain-specific way.
We consistently use only two of these headers: To and Action; the others are optional. For more information on the use of the headers specified by WS-Addressing, refer to the WS-Addressing spec at http://www.ibm.com/developerworks/ webservices/library/ws-add/.
Please check back next week for the continuation of this article.