SOAP: Simple Object Oriented Protocol
It is a stateless, platform independent, XML based generic lightweight protocol that uses HTTP as its transport medium and can be used for developing distributed complex computing environments.
Application can communicate directly with each other over the internet using SOAP.
It allows exchange of data between heterogeneous web applications.
SOAP supports RPC like the DCOM or CORBA but it uses the XML Open Standard for the purpose of data exchange between homogenous or heterogeneous distributed applications.
Because of its platform independence, language independence and the usage og message communication, the SOAP protocol is robust and standardized mechanism over homogenous or heterogeneous networks.
In the Remote Procedure Call of SOAP, the client sends a request message to the server. The server in turn sends the response message to the client.
XML is the foundation of the SOAP activities. All SOAP messages are transmitted in XML format and is a standard for the representation and interchange of data in structured form across systems.

Why is SOAP required?

The protocols like DCOM, RPC, IIOP are limited to a homogenous network. However, distributed applications comprise of a heterogeneous network components which necessitates the information to be transferred in common data format across the platforms.
Simple Object Oriented Protocol (SOAP) is an Open Standard protocol and used XMl which has already been accepted as a standard form of information transfer which makes the usage of SOAP a solution to the complexity.

Advantages of SOAP

The following are some of the many advantages that SOAP provides.

• Language neutrality:
  SOAP can be developed using any language.
• Interoperability and Platform Independence:
  SOAP can be implemented in any language and can be executed in any platform.
• Simplicity:
  SOAP messages are in very simple XML format.
• Scalability:
  SOAP uses HTTP protocol for transport due to which it becomes scalable.

Disadvantages of SOAP.

The following are the disadvantages of SOAP.

• Slow
  SOAP uses the XML format which needs to be parsed and is lengthier too which makes SOAP slower than CORBA, RMI or IIOP.
• WSDL Dependence
  It depends on WSDL and does not have any standardized mechanism for dynamic discovery of the services.

Composition of SOAP.

As per the SOAP specification, SOAP is typically composed of the following three parts:

• A framework: It describes the way for the construction and processing of the messages.
• A set of encoding rules: These are used for exchanging the data types
• A convention and a procedure for representing the Remote Procedure Calls.

Purpose of using SOAP:

For many Web services, you need only a combination of XML, HTTP, and an application-specific message protocol. To be sure, SOAP has its uses. But, in my opinion, SOAP’s role is overstated in the early stages of a Web service’s development. Using SOAP for the wrong tasks can easily hijack a Web service development project, because SOAP introduces a large set of problems that are orthogonal to the challenges of building a Web service. SOAP-related issues tend to consume the majority of the development effort.

The most common purpose of Web services today is to exchange XML data. For instance, more than 200 Web services listed on XMethods share that purpose. The classic examples of a stock quote service, weather service, or postal code lookup service are all about sending an XML query message, and receiving an XML reply. That pattern dominates more complex Web services as well: the UDDI registry service or the Liberty Alliance single sign-on and identity federation Web services are all defined in terms of XML-based query-response message exchanges.

At best, SOAP introduces a level of indirection to such XML message exchanges by embedding an XML message in a SOAP envelope. Since the SOAP envelope can carry metadata about the original XML message, such as processing instructions, the envelope can aid a Web service in processing that message. At worst, SOAP makes it difficult, if not impossible, to verify the validity of an XML message traversing between two Web services.

Example:

Here is an example of how a client might format a SOAP message requesting product information from a fictional warehouse web service. The client needs to know which product corresponds with the ID DEVASP123:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

   <soap:Body>

     <getProductDetails xmlns="http://warehouse.example.com/ws">

       <productID> DEVASP123</productID>

     </getProductDetails>

   </soap:Body>

 </soap:Envelope> 

Here is how the warehouse web service might format its reply message with the requested product information:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

   <soap:Body>

     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">

       <getProductDetailsResult>

         <productName>Toptimate 3-Piece Set</productName>

         <productID> DEVASP123</productID>

         <description>3-Piece luggage set. Black Polyester.</description>

         <price>96.50</price>

         <inStock>true</inStock>

       </getProductDetailsResult>

     </getProductDetailsResponse>

   </soap:Body>

 </soap:Envelope>