General references: "Reliable Messaging."

A communiqué from David Orchard describes the release of three Web Services specifications from BEA Systems. WS-Acknowledgement, WS-Callback, and WS-MessageData have been issued as royalty-free specifications supporting asynchrony, reliable messaging, and general message data. These specifications and others are now supported in BEA Systems' flagship product, WebLogic 8.1. The Web Service Acknowledgement Protocol "is designed to support reliable message exchange between services by providing for at-least-once and exactly-once SOAP message transfer guarantees." The WS-CallBack Protocol "consists of the CallBack SOAP header and an associated WSDL definition; WS-CallBack is used to dynamically specify where to send asynchronous responses to a SOAP request. To enable the re-use of meta-data about a message across SOAP extensions, Web Services Message Data (WS-MessageData) introduces the MessageData header. As new types of message meta-data are standardized it is hoped that they will be placed inside of the MessageData header so as to more easily enable re-use. The WS-MessageData specification also introduces two specific types of message meta-data, MessageId and RefToMessageId. MessageID is used to provide a Message ID, a URI that uniquely identifies a particular message. RefToMessageId allows one message to identify another message it is associated with by providing the associated message's Message ID. The BEA specifications are intended to provide input to the larger Web services community as it moves towards open and royalty free standard for asynchrony, reliable messaging, security, and transactions."

Bibliographic Information

• Web Service Acknowledgement Protocol (WS-Acknowledgement). By Ruslan Bilorusets (BEA Systems), Yaron Goland (BEA Systems), Mark Nottingham (BEA Systems), and David Orchard (BEA Systems). Version 0.91. February 26, 2003.

• WS-CallBack Protocol (WS-CallBack). By Yaron Goland (BEA Systems), Mark Nottingham (BEA Systems), and David Orchard (BEA Systems). Version 0.91. February 26, 2003.

• Web Services Message Data (WS-MessageData). By Yaron Goland (BEA Systems), Mark Nottingham (BEA Systems), and David Orchard (BEA Systems). Version 0.91. February 26, 2003.

Web Service Acknowledgement Protocol (WS-Acknowledgement)

[Introduction] "The WS-Acknowledgement protocol is designed to enable WS-Acknowledgement senders to request explicit acknowledgement from WS-Acknowledgement receivers that a WS-Acknowledgement Request MessageWS-Acknowledgement Request Message has been received. An Acknowledgement message only acknowledges the receipt of the WS-Acknowledgement Request MessageWS-Acknowledgement Request Message. No guarantee is made that the WS-Acknowledgement Request MessageWS-Acknowledgement Request Message has been or will ever be processed.

If the WS-Acknowledgement sender does not receive an acknowledgement within the pre-arranged retry interval then the WS-Acknowledgement sender will repeat the WS-Acknowledgement Request Message. The WS-Acknowledgement sender will continue to repeat the WS-Acknowledgement Request Message until the WS-Acknowledgement sender has retried the pre-arranged maximum number of times or until it receives an acknowledgement message.

As part of the configuration of a reliable messaging exchange between two parties it is possible to ask for duplicate elimination. In that case the WS-Acknowledgement receiver is required to keep a persistent record of what Message IDs have been received for a pre-arranged period of time. If the WS-Acknowledgement receiver should receive a message whose Message ID matches that of one already in the persistent store then the WS-Acknowledgement receiver will repeat the previous transmitted Acknowledgement message. It will then discard the repeated message.

The exact behavior of a reliable message exchange is decided by a set of configuration parameters defined in section 8. The WS-Acknowledgement sender and receiver, using an out of band mechanism, must agree on these parameters before reliable messaging can be initiated.

WS-Acknowledgement is designed to operate at the SOAP message level and its behavior is therefore independent of any transport to which the SOAP messages may be bound.

WS-CallBack Protocol (WS-CallBack)

"This specification describes the WS-CallBack protocol. WS-CallBack is used to dynamically specify where to send asynchronous responses to a SOAP request."

"The CallBack header is needed in cases where a web service is using asynchronous communication and the address to which to send responses is not known at deployment time. In order to enable asynchronous responses to requests the requestor must specify in the request where to send the responses. The WS-CallBack protocol provides the SOAP and WSDL 1.1 mechanisms needed to enable this behavior."

"A WS-CallBack sender sends a WS-CallBack request containing a CallBack header with a callbackLocation element. The WS-CallBack receiver then sends its response(s) to the URI listed in the callbackLocation element."

"The CallBack header must contain the SOAP mustUnderstand attribute with the value equal to 1 and must contain a callbackLocation element. In the absence of an explicit out-of-band agreement the scheme of the URI in the first callbackLocation element MUST be of the same scheme used to deliver the WS-CallBack request. E.g. if the request was delivered over HTTP and there is no explicit agreement to the contrary then the URL in the callbackLocation element must be of type 'http'."

Web Services Message Data (WS-MessageData)

The Web Services Message Data (WS-MessageData) specification introduces the MessageData header which enables the re-use of meta-data about a message across SOAP extensions. As new types of message meta-data are standardized it is hoped that they will be placed inside of the MessageData header so as to more easily enable re-use.

This specification defines an implementation [under which] each extension [of multiple extensions that agree upon the same token] could implicitly or explicitly refer to a single header that contained the token viz., by reference rather than by value. This specification introduces a single SOAP header that contains common values like a message identifier. The expectation is that other extensions will then rely on the meta-data in that header when defining their own behavior.

The MessageData header is intended as an extensible repository for metadata about a message. For performance purposes it is preferable that the WS-MessageData appear before any SOAP headers that rely upon it... The MessageID element contains a Message ID that must be a URI that associates the message in which it appears with an identifier that is unique across all messages from all possible sources and for all time... The RefToMessageID element must only be used when a message has been generated directly in response to a single previous message. For example, in the case of a request/response pair where the transport is asynchronous the RefToMessageId element on the response message would contain the MessageId value contained in the requesting message."