Soap

SOAP is a messaging protocol specification used for exchanging structured information. It is primarily used in the implementation of web services within computer networks. By providing a standardized messaging layer, SOAP allows different software applications to communicate effectively. It relies on the XML Information Set for its message format. This means the data is organized in a way that machines can easily parse and integrate.

A SOAP message is built using a specific architecture consisting of several layers. These layers include the message format, message exchange patterns, and underlying transport protocol bindings. The protocol also defines message processing models and extensibility. At its core, a SOAP message is an XML document containing specific elements. The most important element is the envelope, which identifies the document as a SOAP message. Inside the envelope, there is a mandatory body that contains the actual call or response information. There is also an optional header that can contain discrete computational blocks. If a node fails to process a message, it adds a SOAP fault element inside the body to explain the error.

To understand how messages move, we must look at the different roles and nodes involved. SOAP nodes are the physical or logical machines that transmit, receive, and process messages. These nodes assume specific roles during the journey of a message. For example, a node might act as the initial SOAP sender, which is the root of the message path. Other nodes act as intermediaries, processing header blocks and forwarding the message. The journey ends at the ultimate SOAP receiver. This destination node is responsible for processing the message body and any targeted header blocks. The entire route taken by the message is known as the SOAP message path.

SOAP is defined by three major characteristics: extensibility, neutrality, and independence. Extensibility means the protocol can be expanded with new features like security or WS-Addressing. Neutrality refers to the fact that SOAP can operate over almost any protocol. While it most often uses Hypertext Transfer Protocol (HTTP), it can also use Simple Mail Transfer Protocol (SMTP), TCP, or UDP. Independence means that SOAP allows for any programming model to be used. This flexibility makes it much easier to use than older protocols like DCOM. DCOM often requires specific security rights on machines, whereas SOAP allows for a loosely coupled system.

The history of SOAP began with a predecessor called XML-RPC. In June 1998, Dave Winer released XML-RPC as part of Frontier 5.1. He worked alongside Don Box, Bob Atkinson, and Mohsen Al-Ghosein. At that time, Atkinson and Al-Ghosein were working for Microsoft. The official SOAP specification was submitted to the IETF on 13 September 1999. Don Box noted that a delay in availability was due to politics within Microsoft. Because of this hesitation, Dave Winer shipped XML-RPC in 1998. The specification eventually evolved through different versions. Version 1.1 was published as a W3C Note on 8 May 2000. However, version 1.2 finally became a W3C recommendation on 24 June 2003.

While SOAP is powerful, it has specific trade-offs regarding speed and size. Because it uses XML, the syntax can be quite lengthy. This length helps with error detection and avoids problems with byte-order, also known as endianness. However, the extra tags and delimiters create more overhead than earlier binary protocols. In the world of financial messaging, SOAP messages were found to be 2 to 4 times larger than previous protocols like FIX or CDR. To help with this, researchers are exploring Binary XML to increase throughput. Despite the larger size, SOAP is highly valued because it tunnels easily through firewalls using HTTP. This allows it to work with existing internet infrastructure without needing major changes.

We can see SOAP in action through a simple real-estate or stock example. An application can send a SOAP request to a server that has web services enabled. For instance, a user might request the stock price for a company using a specific ticker symbol. The request is wrapped in an XML envelope and sent via HTTP. The server receives the request, processes the parameters, and generates a SOAP response. This response is an XML-formatted document containing the resulting data, such as prices or locations. Because the data is standardized, the requesting application can integrate the information directly into its own system without manual work.