Proposed Features, MEPs, and Binding

This document outlines and links a number of proposed features, message exchange patterns, and a binding for SOAP 1.2. All of these elements are submitted with a view to showing a) the value of messaging in web services, and b) the issues that need to be addressed in order to support this style of service.

The features, MEPs, and bindings presented here are all intended to both use, and to illustrate the use of, the SOAP 1.2 extensibility mechanism. See: http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#extensibility.

Overview

Note that feature and MEP specifications define abstract properties. These properties are not bound. In particular, they are not bound to modules (to SOAP headers, that is), although examples of such binding are supplied in the definition (as a natural location for such examples). In general, the abstract properties identified by these specifications are bound by the protocol binding or by the application (in its service description). The purpose of defining them, in the abstract, is to allow them to be available to an abstract state machine, and to be bound concretely to a storage location at the level of the protocol binding or the application service description (bindings often suggest several alternatives for binding a particular property, rather than mandating only one).

For reference, a summary table of properties defined in core SOAP specifications and in these proposals may be found in properties-reference.html.

This set of proposals is intended to illustrate the implementation of web services via messaging. Alternately, it may be said to provide an outline of how to describe current messaging-based services in a web-services compatible fashion. Messaging, in this context, refers primarily to the publish/subscribe model, currently widely used within enterprises, and potentially of equal (or greater) value to a larger audience.

The most critical components needed for a description of the publish/subscribe model in web services terms are facilities for message correlation and a more formal description of the commonly used message exchange patterns (notification and solicit/response).

The example chosen for illustration is web services over internet email, a loosely-defined term that potentially includes more than one protocol. The binding is primarily to the standard internet message format defined in RFC 2822, but takes a systemic approach that recognizes the role of SMTP (as the transfer protocol) and local delivery protocols (such as POP and IMAP). A binding to network news (the internet message format plus NNTP) might provide a truer example of publish/subscribe technology. Email was chosen on the grounds that an example able to model existing services (such as mailing lists) has an extremely high value to the community as a whole, and is likely to be familiar to more members than is netnews.

It is hoped that the modularity of this approach (that is, its clear separation into features, which are then required in a MEP, binding, or application) will lend itself to reuse in the definition of additional bindings. Apart from email (described herein) and netnews (mentioned above), true messaging protocols or APIs (for example, JMS) should be relatively straightforward to bind, clearly and precisely, through reference to materials presented here.

Readers with limited time or interest are invited to focus their attention to the following: the correlation and addressing features, the notification and solicit/response MEPs, and the email binding. These are regarded, by the authors, as the core of this proposal; other materials provide support or additional (useful, but less than critical) functionality.

The authors of this proposal welcome feedback.

Contents

Proposed Features

Proposed Message Exchange Patterns

Proposed Alternative Email Binding


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