Proposed Message Exchange Patterns

Existing materials describing message exchange patterns for SOAP 1.2 are almost exclusively focussed on the request/response pattern, with a small amount of material available for the one-way (or input-only) pattern. This tight focus, indeed, has led to a proposal to drop the solicit/response and notification patterns altogether. The following materials attempt to demonstrate the utility of the two existing MEPs (notification and solicit/response) in a publish/subscribe model of messaging, and supplies two additional patterns as an illustration of the need for flexibility in this area.

Discussion of message exchange patterns has been heated. The authors believe that this is, in part, because not all the participants share the same definition of what a message exchange pattern is, which strongly impacts the scope of permissible patterns. In order to clarify, the authors offer the following definition (largely borrowed from the Web Services Choreography Interface specification). A message exchange pattern is:

Overview

The message exchange patterns presented here are intended to be read in the context of the SOAP 1.2 extensibility mechanism. See: http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#extensibility.

Most MEPs specify a set of required features, and some also specify a set of custom properties (basically a built-in feature specific to that MEP). Note that, at the level of the definition of the message exchange pattern, these properties remain abstract. They are not bound to a storage location. Protocol bindings and (more often) service descriptions specify precise bindings of abstract properties to particular storage locations.

Current drafts of the SOAP specification supply material only for the request/response MEP. While this is entirely adequate for synchronous protocols, such as the original target protocol for SOAP (HTTP), it is wholly inadequate to describe existing services that use asynchronous, publish/subscribe models. The attached exchange patterns are supplied in the hope of filling this gap, and in the hope that they are in any event of use to implementers.

The supplied message exchange patterns are all designed to function when bound to asynchronous protocols, but generally include the pattern of a default implicit binding of targeting information to a currently open socket to allow them to reproduce the behavior of the only pattern which is currently fully specified, synchronous request/response. The asynchronous variant of request/response, set forth here, simply adds reliance upon the message-address and message-correlation features.

The general design of these message exchange patterns has been to rely upon external property definitions wherever possible (that is, to rely upon external feature specifications). In some cases, that has not seemed reasonable, as the exchange pattern needs to specify certain properties associated with, for instance, termination of the pattern, which seem inappropriate to generalize into features.

The supplied patterns both flesh out some of the lesser-known existing patterns, and introduce some new multiple-message patterns that seem to fulfill the requirements stated above for conceptual unity of a MEP or operation. The solicit/response and notification message exchange patterns are viewed as critical for the description of publish/subscribe services, when not all participants are themselves services.

Contents

Asynchronous Request/Response MEP

Notification MEP

Solicit/Response MEP

Confirmation MEP

Authentication MEP


Amelia A Lewis
Last modified: Fri Oct 11 12:49:53 EDT 2002