SOAP (Simple Object Access Protocol)

We will discover everything related to the SOAP protocol: what it is for, its advantages and the structure of the messages.

What is SOAP?

It stands for Simple Object Access Protocol. This protocol derives from a protocol created by David Winer, XML-RPC in 1998. On his website, Userland, you can find a multitude of documentation about this first communication protocol under http via XML. With this protocol, RPC or remote procedure calls were requested, that is, we could either make requests on the client or server via http to a web server. The messages had to have a certain format using XML to encapsulate the request parameters. Over time, the project started by David Winer interested important multinationals, including IBM and Microsoft, and from this interest in XML-RPC, SOAP was developed.”

At the core of Web services is the simple data access protocol SOAP, which provides a standard mechanism for packaging messages. SOAP has received a lot of attention because it facilitates RPC-style communication between a client and a remote server. But there are plenty of protocols created to facilitate communication between applications, including Sum’s RPC, Microsoft’s DCE, Java’s RMI, and CORBA’s ORPC. Why is so much attention paid to SOAP?

One of the main reasons is that SOAP has received incredible support from the industry. SOAP is the first protocol of its kind that has been accepted by virtually every major software company in the world. Companies that rarely cooperate with each other are offering their support to this protocol. Some of the major Companies that support SOAP are Microsoft, IBM, SUN, Microsystems, SAP and Ariba.

Some of the advantages of SOAP are:

• Not associated with any language: Developers involved in new projects can choose to develop with the latest and greatest programming language out there, but developers responsible for maintaining old legacy woes may not be able to make this choice about the programming language they use. SOAP does not specify an API, so the implementation of the API is left to the programming language, such as Java, and the platform, such as Microsoft .Net.
• Not strongly associated with any transport protocol: The SOAP specification does not describe how SOAP messages should be associated with HTTP. A SOAP message is nothing more than an XML document, so it can be transported using any protocol capable of transmitting text.
• Not tied to any distributed object infrastructure Most distributed object systems can be, and some already are, extended to support SOAP.
• Take advantage of existing industry standards: The major contributors to the SOAP specification intentionally avoided reinventing things. They chose to extend existing standards to match their needs. For example, SOAP takes advantage of XML for the encoding of messages, instead of using its own type system that is already defined in the XML schema specification. And as already mentioned, SOAP does not define a means of transporting messages; SOAP messages can be associated with existing transport protocols such as HTTP and SMTP.
• Allows interoperability between multiple environments: SOAP was built on top of existing industry standards, so applications running on platforms with those standards can communicate via SOAP messages with applications running on other platforms. For example, a desktop application running on a PC can communicate with a back-end application running on a mainframe capable of sending and receiving XML over HTTP.

Anatomy of a SOAP message

SOAP provides a standard mechanism for packaging a message. A SOAP message is made up of an envelope that contains the body of the message and any header information that is used to describe the message. Here is an example:

Figure III.1: “Anatomy of a SOAP message”

The root element of the document is the Envelope element. The example contains two sub-elements, Body and Header. A valid SOAP instance may also contain other child elements in the envelope.

The envelope can contain an optional Header element that contains information about the message. In the previous example, the header contains two elements that describe the person who composed the message, and the possible recipient of the message.

The envelope must contain a body element. The body element contains the message payload. In the example the body contains a single string of characters.

A message must be inside a well-constructed SOAP envelope. An envelope is made up of a single envelope element, the envelope can contain a Header element, and it can contain a body element. If it exists, the header must be the immediate child element of the envelope, with the body immediately following the header.

The body contains the payload data of the message and the header contains any additional data that does not necessarily belong to the message body.

In addition to defining a SOAP envelope, the SOAP specification defines a way to encode the data contained in a message. The SOAP encoding provides a standard mechanism for zerialising data types not defined in Part 1 of the XML Schema specification.

The SOAP specification also provides a standard message pattern to facilitate RPC-like behavior. Two SOAP messages are paired to facilitate the association of a request message with a response message.

The call to a method and its parameters are serialized in the body of the request message in the form of a structure.

The root element has the same name as the target method, with each of the parameters encoded as a sub-element.

The response message may contain the results of the method call or a well-defined fault structure. The results of a method call are serialized in the request body as a structure. By convention, the root element has the same name as the original method to which result is added. Return parameters are serialized as child elements, with the return parameter first. If an error is found, the body of the response message will contain a well-defined fault structure.

By convention, the root element has the same name as the original method to which result is added. Return parameters are serialized as child elements, with the return parameter first. If an error is found, the body of the response message will contain a well-defined fault structure.