5 SOAP Protocol Binding Framework | XML, Web Services, and the Data Revolution


Team-Fly

	XML, Web Services, and the Data Revolution By Frank P. Coyle
	Table of Contents

	Appendix B. SOAP Version 1.2 Part 1: Messaging Framework

5.1 Introduction

SOAP provides a simple messaging framework with a core set of functionality which is primarily concerned with providing extensibility. The SOAP processing model ( 2 SOAP Message Exchange Model ) describes the behavior of a single SOAP node with respect to the processing of an individual message.

The sending and receiving of SOAP messages by a SOAP node is mediated by a binding to an underlying protocol. A SOAP underlying protocol binding operates between adjacent SOAP nodes along a SOAP message path . A binding does not provide a separate processing model and does not constitute a SOAP node by itself. Rather a SOAP binding is an integral part of a SOAP node. There is no requirement that the same underlying protocol is used for all hops along a SOAP message path.

As part of communicating between SOAP nodes it may be necessary to introduce a variety of abstract features generally associated with the exchange of messages in a protocol environment. Although SOAP poses no constraints on the potential scope of such features, typical examples include "reliability", "security", "correlation", and "routing". In addition, the communication may require message exchange patterns (MEPs) beyond the one-way MEP that SOAP provides. MEPs are considered to be a type of feature; unless otherwise stated, references to the term "feature" apply also to MEPs.

In some cases, underlying protocols are equipped, either directly or through extension, with mechanisms for providing certain features, in whole or in part. Features are the modular components from which the contract between SOAP nodes and the bindings they support are formed . The SOAP binding framework provides a framework for describing these features and how they relate to SOAP nodes. A SOAP binding specification declares the features provided by a binding and describes how the services of the underlying protocol are used to honor the contract formed by the declaration of features supported by that binding. In addition, a binding specification defines the requirements for building a conformant implementation of the binding being specified.

The combination of the SOAP extensibility model and the SOAP binding framework provides some flexibility in the way that particular features can be expressed: they can be expressed entirely within the SOAP envelope (as blocks), outside the envelope (typically in a manner that is specific to the underlying protocol), or as a combination of such expressions. It is up to the communicating nodes to decide how best to express particular features; often when a binding-level implementation for a particular feature is available, utilizing it when appropriate will provide for optimized processing.

Editorial note: HFN 20011201

Some discussion continues on how best to represent the balance of responsibility between binding specifications in particular, vs. other software at the SOAP node, when dealing with features that are represented entirely within the SOAP envelope. The paragraph above may need some additional work to clarify.

5.2 Goals of the Binding Framework

As described above, SOAP messages can be transported using a variety of underlying protocols. SOAP Part 2: Adjuncts[1] includes the specification for a binding to HTTP. Additional bindings can be created by specifications that conform to the binding framework introduced in this chapter. The goals of the binding framework are:

To set out the requirements and concepts that are common to all binding specifications.
To facilitate homogenous description of bindings that support common features.
To facilitate homogenous description of bindings that support common features.

Note, that the second and third goals above are related : two or more bindings may offer a given optional feature, such as reliable delivery, with one operating using an underlying protocol that directly facilitates the feature (the protocol is reliable), and the other providing the logic (logging and retransmission) in the binding. The feature can be made available to applications in a consistent manner, regardless of which binding is used.

5.3 Binding Framework

The creation, transmission, and processing of a SOAP message, possibly through one or more intermediaries, is specified in terms of a distributed state machine. The state consists of information known to a SOAP node at a given point in time, including but not limited to the contents of messages being assembled for transmission or received for processing. The state at each node can be updated either by local processing, or by information received from an adjacent node.

Section 2 SOAP Message Exchange Model of this specification describes the processing that is common to all SOAP nodes when receiving a message. The purpose of a binding specification is to augment those core SOAP rules with any additional processing that may be particular to the binding, and to specify the manner in which the underlying protocol is used to transmit information between adjacent nodes in the message path.

Thus, the distributed state machine that manages the transmission of a given SOAP message through its message path is the combination of the core SOAP processing (see 2 SOAP Message Exchange Model ) operating at each node, in conjunction with the binding specifications connecting each pair of nodes.

As described above, SOAP can be augmented with optional features, (such as reliable message delivery, request/response MEPs, multicast MEPs, etc.). The specification of each such feature MUST include the following:

The information (state) required at each node to implement the feature.
The processing required at each node in order to fulfill the obligations of the feature.
The information transmitted from node to node, and in the case of MEPs, any requirements to generate additional messages (such as responses to requests in a request/response MEP).

Every binding specification MUST support the transmission and processing of one-way messages as described in this specification. A binding specification MAY state that it supports additional features, in which case the binding specification MUST provide for maintaining state, performing processing, and transmitting information in a manner consistent with the specification for those features.

In cases where multiple features are supported by a binding specification the specifications for those features must provide any information necessary for their successful use in combination; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features.

The binding framework provides no fixed means of naming or typing the information comprising the state at a given node. Individual feature and binding specifications are free to adopt their own conventions for specifying state. Note, however, that consistency across bindings and features is likely to be enhanced in situations where multiple feature specifications adopt consistent conventions for representing state. For example, multiple features may benefit from a consistent specification for an authentication credential, the transaction ID, etc. The HTTP binding in SOAP Part 2[1] illustrates one such convention.

As described in 4 SOAP Envelope , each SOAP message is modeled as an XML Infoset that consists of a document information item with exactly one child: the envelope element information item. Therefore, the minimum responsibility of a binding in transmitting a message is to specify the means by which the SOAP XML Infoset is transferred to and reconstituted by the binding at the receiving SOAP node and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol. The binding framework does NOT require that every binding use the XML 1.0[8] serialization as the "on the wire" representation of the Infoset; compressed, encrypted, fragmented representations and so on can be used if appropriate.

Bindings MAY depend on state that is modeled as being outside of the SOAP XML Infoset (e.g. retry counts), and MAY transmit such information to adjacent nodes. For example, some bindings take a message delivery address (typically URI) that is not within the envelope; the HTTP binding in Part 2[1] (see Using SOAP in HTTP) transmits an HTTP field named SOAPAction that is not contained within the SOAP XML Infoset.

5.4 Binding to Application-Specific Protocols

Some underlying protocols may be designed for a particular purpose or application profile. SOAP bindings to such protocols MAY use the same endpoint identification (e.g., TCP port number) as the underlying protocol, in order to reuse the existing infrastructure associated that protocol.

However, the use of well-known ports by SOAP may incur additional, unintended handling by intermediaries and underlying implementations . For example, HTTP is commonly thought of as a "Web browsing" protocol, and network administrators may place certain restrictions upon its use, or may interpose services such as filtering, content modification, routing, etc. Often, these services are interposed using port number as a heuristic.

As a result, binding definitions for underlying protocols with well-known default ports or application profiles SHOULD document potential ( harmful ?) interactions with commonly deployed infrastructure at those default ports or in-conformance with default application profiles. Binding definitions SHOULD also illustrate the use of the binding on a non-default port as a means of avoiding unintended interaction with such services.

5.5 Security Considerations

Editorial note: MJG 20010926

This section will in a future revision provide some guidelines for the security considerations that should be taken into account when using the binding framework defined in this document.


Team-Fly

Top