Simple Object Access Protocol (SOAP)

What is Simple Object Access Protocol (SOAP)?

SOAP (Simple Object Access Protocol) is the foundational, XML-based application protocol used to implement Web services within a SOA (Service Oriented Architecture). SOAP is transported primarily via HTTP and middleware messaging systems (JMS, MQ Series, MSMQ, Tuxedo, TIBCO RV) but can also be transported via other protocols such as SMTP (Simple Mail Transfer Protocol) and FTP (File Transfer Protocol).

The official definition, found in the most recent SOAP 1.2 specification, "SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. SOAP uses XML technologies to define an extensible messaging framework, which provides a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics." This definition really gets to the heart of what SOAP. SOAP defines a way to move XML messages from point A to point B (see Figure below). It does this by providing an XML-based messaging framework that is
1) extensible,
2) usable over a variety of underlying networking protocols, and
3) independent of programming models.

source: Microsoft

SOAP was designed by Bob Atkinson, Don Box, Dave Winer, and Mohsen Al-Ghosein at Microsoft in 1998. SOAP was maintained by the XML Protocol Working Group of the World Wide Web Consortium until 2009. Message Format:

• SOAP message transmits some basic information as given below
• Information about message structure and instructions on processing it.
• Encoding instructions for application defined data types.
• Information about Remote Procedure Calls and their responses.
  

History of SOAP
SOAP was designed as an object-access protocol and released as XML-RPC in June 1998 as part of Frontier 5.1 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft, where Atkinson and Al-Ghosein were working. The specification was not made available until it was submitted to IETF 13 September 1999. According to Don Box, this was due to politics within Microsoft. Because of Microsoft's hesitation, Dave Winer shipped XML-RPC in 1998.

The submitted Internet Draft did not reach RFC status and is therefore not considered a "web standard" as such. Version 1.1 of the specification was published as a W3C Note on 8 May 2000. Since version 1.1 did not reach W3C Recommendation status, it can not be considered a "web standard" either. Version 1.2 of the specification, however, became a W3C recommendation on June 24, 2003.

The SOAP specification was maintained by the XML Protocol Working Group of the World Wide Web Consortium until the group was closed 10 July 2009. SOAP originally stood for "Simple Object Access Protocol" but version 1.2 of the standard dropped this acronym.

After SOAP was first introduced, it became the underlying layer of a more complex set of web services, based on WSDL, XSD and UDDI. These different services, especially UDDI, have proved to be of far less interest, but an appreciation of them gives a complete understanding of the expected role of SOAP compared to how web services have actually evolved.

Points to Note About SOAP

• SOAP is a communication protocol designed to communicate via Internet.
• SOAP can extend HTTP for XML messaging.
• SOAP provides data transport for Web services.
• SOAP can exchange complete documents or call a remote procedure.
• SOAP can be used for broadcasting a message.
• SOAP is platform- and language-independent.
• SOAP is the XML way of defining what information is sent and how.
• SOAP enables client applications to easily connect to remote services and invoke remote methods.

Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the initial focus of SOAP is remote procedure calls transported via HTTP.

Other frameworks including CORBA, DCOM, and Java RMI provide similar functionality to SOAP, but SOAP messages are written entirely in XML and are therefore uniquely platform- and language-independent.

The Need for SOAP
Why do we need a standard like SOAP? By exchanging XML documents over HTTP, two programs can exchange rich, structured information without the introduction of an additional standard such as SOAP to explicitly describe a message envelope format and a way to encode structured content.

SOAP provides a standard so that developers do not have to invent a custom XML message format for every service they want to make available. Given the signature of the service method to be invoked, the SOAP specification prescribes an unambiguous XML message format. Any developer familiar with the SOAP specification, working in any programming language, can formulate a correct SOAP XML request for a particular service and understand the response from the service by obtaining the following service details.

• Service name
• Method names implemented by the service
• Method signature of each method
• Address of the service implementation (expressed as a URI)

Using SOAP streamlines the process for exposing an existing software component as a Web service since the method signature of the service identifies the XML document structure used for both the request and the response.

How SOAP Works
SOAP primarily uses the standard HTTP request/response model (see Figure below).

The client wraps a method call in SOAP/XML, which is then posted over HTTP to the server. The XML request is parsed to read the method name and parameters passed and delegated for processing. The XML response is then sent back to the client, containing the return value—or fault data—of the method call. Finally, the client may parse the response XML to make use of the return value.

Source: Techrepublic

The server uses a “listener” to process SOAP requests. The listener is simply the server code at the specified URL for parsing the XML request, making the procedure call, and wrapping the result in XML to send as the response (see Figure below).

Source: Techrepublic

But HTTP is not the only transfer protocol that SOAP supports. In version 1.1 of SOAP, the specification was expanded to cover other transfer protocols such as Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), or any other protocol that can transfer text. These other protocols could be used to make asynchronous SOAP calls, meaning the client application could invoke the SOAP service but would not have to wait for a response from the server.

Soap Message Structure
SOAP messages are transmitted from the sending application to the receiving application, typically over an HTTP session. The actual SOAP message is made up of the Envelope element, which contains a Body element and an optional Header element.

• Envelope. This mandatory element is the root of the SOAP message, identifying the transmitted XML as being a SOAP packet. An envelope contains a body section and an optional header section.
• Header. This optional element provides an extension mechanism indicating processing information for the message. For example, if the operation using the message requires security credentials, those credentials should be part of the envelope header.
• Body. This element contains the message payload, the raw data being transmitted between the sending and receiving applications. The body itself may consist of multiple child elements, with an XML schema typically defining the structure of this data.

A SOAP packet and the corresponding XML is structured in the following way:

Source: IBM

SOAP - SAMPLE CALL and SAMPLE RESPONSE
SOAP perfectly fits into the world of Internet applications and promises to improve Internet inter-operability for application services in the future. In essence, SOAP packages method calls into XML strings and delivers them to component instances through HTTP.

SOAP client requests are encapsulated within HTTP POST or M-POST packages. The following example is taken from the Internet draft-specification.

SAMPLE CALL

The first four lines of code are standard HTTP. POST is the HTTP verb which is required for all HTTP messages. The Content-Type and Content-Length fields are required for all HTTP messages that contain payloads. The content-type text/xml indicates that the payload is an XML message to the server or a firewall capable of scanning application headers.

The additional HTTP header SOAPAction is mandatory for HTTP based SOAP messages, and you can use it to indicate the intent of a SOAP HTTP request. The value is a URI that identifies the intent. The content of a SOAPAction header field can be used by servers, for example firewalls, to appropriately filter SOAP request messages in HTTP. An empty string ("") as the header-field value indicates that the intent of the SOAP message is provided by the HTTP Request-URI. No value means that there is no indication on the intent of the message.

The XML code is straightforward. The elements Envelope and Body offer a generic payload-packaging mechanism. The element GetLastTradePrice contains an element called symbol, which contains a stock-ticker symbol. The purpose of this request is to get the last trading price of a specific stock, in this case Disney (DIS).

The program that sends this message only needs to understand how to frame a request in a SOAP-complient XML message and how to send it through HTTP. In the following example, the program knows how to format a request for a stock price. The HTTP server that receives the message knows that it is a SOAP message because it recognizes the HTTP header SOAPAction. The server then processes the message.

SOAP defines two types of messages, calls and responses, to allow clients to request remote procedures and to allow servers to respond to such a request. The previous example is an example of a call. The following example comes as a response in answer to the call.

SAMPLE RESPONSE

The first three lines of code are standard HTTP. The first line indicates a response code to the previous POST request, the second and third line indicate the content type and the fourth line the lenght of the response.

XML headers enclose the actual SOAP payloads. The XML element GetLastTradePriceResponse contains a response to the request for a trading price. The child element is Price, which indicates the value that is returned to the request.

Advantages and Disadvantages of SOAP
SOAP is an integral part of the service-oriented architecture (SOA) and the web services specifications.

Advantages of SOAP include the following:

• Platform- and operating system-independent. SOAP can be carried over a variety of protocols, enabling communication between applications with different programming languages on both Windows and Linux.
• Works on the HTTP protocol. Even though SOAP works with many different protocols, HTTP is the default protocol used by web applications.
• Can be transmitted through different networks and security devices. SOAP can be easily passed through firewalls, where other protocols might require a special accommodation.

Disadvantages, however, include the following:

• No provision for passing data by reference. This can cause synchronization issues if multiple copies of the same object are passed simultaneously.
• Speed. The data structure of SOAP is based on XML. XML is largely human-readable, which makes it fairly easy to understand a SOAP message. However, that also makes the messages relatively large compared to the Common Object Request Broker Architecture (CORBA) and its remote procedure call (RPC) protocol that will accommodate binary data. Because of this, CORBA and RPC are faster.
• Not as flexible as other methods. Although SOAP is flexible, newer methods, such as RESTful architecture, use XML, JavaScript Object Notation, YAML or any parser needed, which makes them more flexible than SOAP.

SOAP Vs. REST
Both REST and SOAP offer a means of communications between web-service. REST is merely a convention implemented using the HTTP protocol and is therefore considered simpler to learn and implement.

SOAP provides the following advantages when compared to REST:

• Language, platform, and transport independent (REST requires the use of HTTP)
• compatible with distributed enterprise environments ( direct point-to-point communication)
• All calls sent through POST
• Provides significant pre-build extensibility in the form of the WS* standards
• Built-in error handling
• Automation when used with certain language products

REST is easier to use and is more flexible. It has the following advantages compared to SOAP:

• Uses easy to understand standards like swagger and OpenAPI – Specification 3.0
• Easy to learn
• Efficient (SOAP uses XML for all messages, REST mostly uses smaller message formats like JSON) but also support XML format.
• Fast (no extensive processing required)
• Closer to other Web technologies in design philosophy
• Can be stateless or stateful

See Also

Enterprise Service Bus (ESB)
Service Oriented Architecture (SOA)
Enterprise Integration
Enterprise Architecture
Representational State Transfer (REST)