SOAP - Simple Object Access Protocol

SOAP stands for ``Simple Object Access Protocol'' and is a standardized and extensible messaging framework for exchanging structured information between distributed computing nodes. SOAP is most often applied to remote procedure calls (RPC) scenarios and therefore ideally suits to the communication between Web services. This new protocol has the following key features:

Interoperability:

First and foremost, the purpose of a protocol such as SOAP is inter-operation, giving users and developers choice, eliminating lock-in, and keeping the market open to all size organizations, commercial and open source development, individual developers and hobbyists. The so-called serializer transforms language specific data types into SOAP or XML Schema datatypes¹³. The use of these standardized datatypes in combination with SOAP libraries makes it possible to use the same complex datatypes with Web Services that are coded in different programming languages.

Strict standards compliance:

SOAP is standardized by the W3C consortium, currently in versions 1.1 and 1.2. Key industry players like IBM and Microsoft are participants in this consortium.

Discoverability:

The use of XML makes it possible for developers with basic XML and SOAP knowledge to look at the transmitted data of a SOAP procedure call, understand its techniques and it enables them to modify and employ it fairly quickly.

it's doing, and be able to modify it and have it work on the first or second try.

Firewalls:

SOAP is designed to bypass firewalls to improve the reachability of SOAP Web Services. Firewall software can watch for POSTs whose Content-Type is text/xml or (even better) watch for the presence of a SOAPAction header¹⁴ and apply whatever policies they see fit.

Easy to implement:

Web Service developers who want to use SOAP do not have to encode/decode the protocol by themselves. Quite on the contrary, the SOAP protocol is transparent to them. This is accomplished by special SOAP libraries that exist for several programming languages. With their use, accessing or providing Web Services is nearly as easy as writing a function header. The SOAP library does all necessary tasks, like communication, serialization of data and error handling.

The underlying transport protocol:

SOAP messages can be transported by various protocols like the following:

HTTP:

The Hyper Text Transport Protocol (HTTP) is the most commonly used variant for transporting SOAP messages and is defined in [R2616]. HTTP is properly standardized and widespread. This connection-oriented protocol implements a simple request/response mechanism and is therefore ideally suited to SOAP Web Services issuing RPC calls.

SMTP:

The Simple Mail Transport Protocol (SMTP) is also capable of transporting SOAP messages. It is defined in [R2821]. SMTP is not designed for fast response times, quite on the contrary, its store and forward technology is designed for transporting messages through various SMTP gateways to their destination. SMTP messages can have long delays but the delivery is very reliable. These features make SMTP well suited to asynchronous SOAP messages.

Although most SOAP frameworks are limited to these two transport protocols, most tasks can be accomplished with them. Nevertheless, SOAP can theoretically be transported with different underlying transport protocol, which will significantly enrich its widespread use and acceptance.

Any SOAP message consists of three building blocks, which are depicted in figure 11.

Figure 11: The basic building blocks of a SOAP message.

SOAP Envelope:

This part contains the entire SOAP message and contains the SOAP Header and SOAP Body. This element is mandatory and has to have a namespace that defines which SOAP version is applied to the current message.

SOAP Header:

This section of the SOAP message is optional but must be the first XML element if it is present. Information in this part is interpreted by the SOAP processor which can e.g. be used to implement state-fulness that is not provided by the underlying protocol¹⁵. The SOAP processor needs not necessarily understand the header contents. If this is mandatory, a special flag, called ``mustUnderstand'' can be set to force the SOAP processor to either process the header contents or to dispose the whole SOAP message. Moreover, the SOAP Header contains the so-called SOAP Actor which will be described in detail later.

SOAP Body:

This section is the place where the data for the receiving or sending application is situated. This section is mandatory in a SOAP message. When using SOAP for remote procedure calls, there are three kinds of SOAP bodies:

1. Request:

This message provides the method name of the called Web Service and its input parameters. The first element of the SOAP body specifies the name of the called method. The following elements are parameters that are required to process the request.

2. Response:

A SOAP response message is the counterpart of a request message. It has also to provide the method name with the string ``Response'' added and delivers the requested output parameters of the called method to the querying application.

3. Fault:

If an error in the called method occurs, the method answers with an error message, which is called a ``SOAP Fault''.

These three building blocks fulfill all the needs to a convenient message format for distributed computing nodes. Listing 5 depicts a simple SOAP message which could be a request message from a banking application to a Web Service that calculates exchange rates. In line 1 the envelope is declared which embeds the body which starts in line 2. Line 3 specifies the name of the invoked method and declares a proprietary namespace which is used by this specific Web Service. Line 5 specifies the encoding style, which is explained in section 2.3.3. Lines 5 to 7 are parameters which are passed to the called method.

language=XML