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.
  

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.

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.

SOAP Communication Model
All communication by SOAP is done via the HTTP protocol. Prior to SOAP, a lot of web services used the standard RPC (Remote Procedure Call) style for communication. This was the simplest type of communication, but it had a lot of limitations.

Now in this SOAP API tutorial, let’s consider the below diagram to see how this communication works. In this example, let’s assume the server hosts a web service which provided 2 methods as

• GetEmployee – This would get all Employee details
• SetEmployee – This would set the value of the details like employees dept, salary, etc. accordingly.

In the normal RPC style communication, the client would just call the methods in its request and send the required parameters to the server, and the server would then send the desired response.

The above communication model has the below serious limitations

1. Not Language Independent – The server hosting the methods would be in a particular programming language and normally the calls to the server would be in that programming language only.
2. Not the standard protocol – When a call is made to the remote procedure, the call is not carried out via the standard protocol. This was an issue since mostly all communication over the web had to be done via the HTTP protocol.
3. Firewalls – Since RPC calls do not go via the normal protocol, separate ports need to be open on the server to allow the client to communicate with the server. Normally all firewalls would block this sort of traffic, and a lot of configuration was generally required to ensure that this sort of communication between the client and the server would work.

To overcome all of the limitations cited above, SOAP would then use the below communication model

1. The client would format the information regarding the procedure call and any arguments into a SOAP message and sends it to the server as part of an HTTP request. This process of encapsulating the data into a SOAP message was known as Marshalling.
2. The server would then unwrap the message sent by the client, see what the client requested for and then send the appropriate response back to the client as a SOAP message. The practice of unwrapping a request sent by the client is known as Demarshalling.

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)