Proposed Feature List

The published experimental Email binding establishes a single feature, specific to email, to enable SOAP operation over a non-synchronous protocol collection. Rather than adopt this binding-specific approach, this proposal instead puts forward a number of generic features, which other bindings may implement as well. It is suggested that such an approach will lead to greater interoperability (or at least greater reuse).

Two of the proposed features, correlation and message-address, are proposed as standard features. That is, it is proposed that these features SHOULD be implemented by any protocol binding. Alternatives are also set forth, and the use of implicit values for properties is discussed, in each proposal.

Overview

The features 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.

Specifically, this means that the properties described in these features are abstract. Although the descriptions include sample module implementations, it is generally expected that a binding or application will specify how each abstract property is bound, and that may not (and probably will not, most of the time) be a SOAP header. Properties may be bound to protocol headers, to information contained in a message, to information emergent from a message as a result of processing, or in any other fashion that allows unambiguous retrieval (and sometimes, but not always, storage/update) of the value of the property.

It has been suggested that the language of the SOAP specification be modified to state that a module implements features through the use of SOAP headers. This is the approach adopted here, as some modules currently exist which specify functionality similar to that expressed in these features. It is hoped that such module definitions would revise their content to express implementation of generic features.

Each feature specification included here contains a section on implementation as a module. That is, each feature specification (with one exception) shows a set of SOAP headers which may be used to implement the feature. Most features also support direct protocol binding (one feature, MIME-composite, cannot be bound to a module, because its use implies use of a MIME-compliant protocol with the structural changes to messages corresponding to the use of the composite message types).

Feature specifications have been generated with the goal of general applicability and reuse. While there is an obvious role for less general, less reusable features, all of the features presented here should have obvious application beyond the particular binding in which they are used.

Contents

message-correlation

message-address

failure-destination

mime-content

mime-composite


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