1 Introduction | 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

SOAP version 1.2 provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and mechanisms for encoding application defined data. This allows SOAP to be used for a large variety of purposes ranging from messaging systems to remote procedure call (RPC) invocations. In previous versions of this specification the SOAP name was an acronym. This is no longer the case.

Part 1 of the SOAP specification (this document) describes:

The SOAP envelope ( 4 SOAP Envelope ). This construct defines an overall framework for expressing what is in a message, who should deal with it, and whether it is optional or mandatory.
The SOAP binding framework ( 5 SOAP Protocol Binding Framework ). This defines an abstract framework for exchanging SOAP envelopes between peers using an underlying protocol for transport. The SOAP HTTP binding [1](SOAP in HTTP) defines a concrete instance of a binding to the HTTP protocol[2].

Part 2[1] describes adjuncts to the envelope and binding framework including the SOAP encoding rules [1](SOAP Encoding) that define a serialization mechanism that can be used to exchange instances of application-defined datatypes and the SOAP RPC representation [1](SOAP for RPC) that defines a convention that can be used to represent remote procedure calls and responses.

1.1 Design Goals

Two major design goals for SOAP are simplicity and extensibility. SOAP attempts to meet these goals by omitting features often found in messaging systems and distributed object systems such as:

Distributed garbage collection;
Boxcarring or batching of messages;
Objects-by-reference (which requires distributed garbage collection);
Activation (which requires objects-by-reference).

Note that it is possible to implement such features using SOAP but they are out of scope for this specification.

1.2 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3].

The namespace prefixes "env" and "enc" used in the prose sections of this document are associated with the SOAP namespace names "http://www.w3.org/2001/12/soap-envelope" and "http://www.w3.org/2001/12/soap-encoding" respectively.

The namespace prefixes "xs" and "xsi" used in the prose sections of this document are associated with the namespace names "http://www.w3.org/2001/XMLSchema" and "http://www.w3.org/2001/XMLSchema-instance" respectively, both of which are defined in the XML Schemas specification[4],[5].

Note that the choice of any namespace prefix is arbitrary and not semantically significant.

Namespace URIs of the general form "http://example.org/..." and "http://example.com/..." represent an application-dependent or context-dependent URI[6].

1.3 Example of SOAP Message

The following example shows a simple notification message expressed in SOAP. The message contains a header block alertcontrol and the body alert both of which are application defined and not defined by SOAP. The header contains information which may be of use to intermediaries as well as the ultimate destination of the message. The body contains the actual notification message to be delivered.

1.4 SOAP Terminology

1.4.1 Protocol Concepts

SOAP

The formal set of conventions governing the format and processing rules of a SOAP message and basic control of interaction between SOAP nodes generating and accepting SOAP messages for the purpose of exchanging information along a SOAP message path .

SOAP binding

The formal set of rules for carrying a SOAP message within or on top of another protocol (underlying protocol) for the purpose of transmission. Example SOAP bindings include carrying a SOAP message within an HTTP entity-body, or over a TCP stream.

Example: SOAP message containing a header block and a body

 <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2001/12/  soap-envelope">  <env:Header>   <n:alertcontrol xmlns:n="http://example.org/alertcontrol">    <n:priority>1</n:priority>    <n:expires>2001-06-22T14:00:00-05:00</n:expires>   </n:alertcontrol>  </env:Header>  <env:Body>   <m:alert xmlns:m="http://example.org/alert">    <m:msg>Pick up Mary at school at 2pm</m:msg>   </m:alert>  </env:Body> </env:Envelope>

SOAP node

A SOAP node processes a SOAP message according to the formal set of conventions defined by SOAP. The SOAP node is responsible for enforcing the rules that govern the exchange of SOAP messages and accesses the services provided by the underlying protocols through SOAP bindings. Non-compliance with SOAP conventions can cause a SOAP node to generate a SOAP fault (see also SOAP receiver and SOAP sender).

1.4.2 Data Encapsulation Concepts

SOAP message

A SOAP message is the basic unit of communication between peer SOAP nodes.

SOAP envelope

The outermost syntactic construct or structure of a SOAP message defined by SOAP within which all other syntactic elements of the message are enclosed .

SOAP header block

A syntactic construct or structure used to delimit data that logically constitutes a single computational unit within the SOAP header. SOAP header blocks are direct children of the SOAP Header ( 4.2 SOAP Header ) element information item. The type of a SOAP header block is identified by the fully qualified name of the outer element information item of the block, which consists of its namespace URI and local name.

SOAP header

A collection of zero or more SOAP header blocks each of which may be targeted at any SOAP receiver within the SOAP message path.

SOAP body

A collection of zero or more element information items targeted at the ultimate SOAP receiver in the SOAP message path.

SOAP fault

A special SOAP element information item which contains fault information generated by a SOAP node.

The following diagram illustrates how a SOAP message is composed .

graphics/bfig01.jpg

1.4.3 Message Sender and Receiver Concepts

SOAP sender

A SOAP sender is a SOAP node that transmits a SOAP message.

SOAP receiver

A SOAP receiver is a SOAP node that accepts a SOAP message.

SOAP message path

The set of SOAP senders and SOAP receivers through which a single SOAP message passes . This includes the initial SOAP sender, zero or more SOAP intermediaries, and the ultimate SOAP receiver.

Initial SOAP sender

The SOAP sender that originates a SOAP message as the starting point of a SOAP message path.

SOAP intermediary

A SOAP intermediary is both a SOAP receiver and a SOAP sender and is target-able from within a SOAP message. It processes a defined set of blocks in a SOAP message along a SOAP message path. It acts in order to forward the SOAP message towards the ultimate SOAP receiver.

Ultimate SOAP receiver

The SOAP receiver that the initial sender specifies as the final destination of the SOAP message within a SOAP message path. A SOAP message may not reach the ultimate recipient because of a SOAP fault generated by a SOAP node along the SOAP message path.

SOAP Application

A software entity that produces, consumes or otherwise acts upon SOAP messages in a manner conforming to the SOAP processing model.


Team-Fly

Top