SOAP Message Transmission and Processing

This chapter describes:

• SOAP protocol binding.
• The SOAP distributed processing model.
• SOAP extension rules.

SOAP Protocol Binding

The previous chapter shows you how a SOAP message should be constructed. Now let's see how a SOAP message should be transmitted.

Transmitting a SOAP message requires a communication protocol to carry the message. This is called SOAP protocol binding. Unfortunately, the basic SOAP 1.2 specification does not define any rules on protocol binding for any communication protocols.

SOAP protocol binding is defined in SOAP extensions, where a specific SOAP feature or module can define its own binding rules for specific communication protocols.

See next chapters for SOAP features and modules.

SOAP Distributed Processing Model

The SOAP processing model is a distributed processing model, where a SOAP message originated at an SOAP initial node is sent to an ultimate SOAP node via zero or more SOAP intermediate nodes. The processing responsibilities are distributed on the intermediate nodes and the ultimate node.

The SOAP processing model is very open, with only a small number of rules:

• A SOAP node must act in one or more SOAP roles.
• A SOAP header block can be specified to target at one particular SOAP role.
• A SOAP header block can be specified to require a SOAP node who is acting in the specified role "must understand". In this case, this SOAP node must process this header block.
• A SOAP ultimate node must process the body element.
• Any SOAP node can process any header blocks and/or the body element in any order.
• After processing the message, any SOAP node may generate a SOAP fault message in case of process error, or terminate the entire processing if needed.
• After processing the message, a SOAP intermediate node may relay the message to the next node, if needed.

In case of relaying a SOAP message, a SOAP intermediate node must follow these rules:

• It must remove all processed header blocks. But it can reinsert them back into the message.
• It must remove all not-processed header blocks that specified as non-relayable. But it can reinsert them back into the message.
• It must retain all not-processed header block that specified as relayable.
• It may insert new header blocks.
• It may alter almost everything in the header element.
• It may not alter anything in the body element.

Of course, SOAP extended features can specify additional processing rules.

SOAP Features

A SOAP feature is a set of rules that extends the basic SOAP specification for a specific application environment. SOAP specification offers the following guidelines on defining a SOAP feature:

• It must have a unique name space URI.
• It should define how a SOAP node should implement this feature.
• It should define how information will be transmitted from one node to another node.

SOAP Modules

A SOAP module is a specification of one or more SOAP header blocks. SOAP specification offers the following guidelines on defining a SOAP module:

• It must have a unique name space URI.
• It must define SOAP features that are using this module.
• It must define it own header blocks.

Conclusions

SOAP is really a simple and open protocol to distribute information. It defines a very open XML message structure to carry information, and a set of simple rules on how information should be handled along its distribution path.

Actually, SOAP is too simple to be used directly. A number of standard SOAP extensions have also been included in the specification to make it ready to use in real applications.