The standards defining body for web services had to work within the existing Web framework. What did that essentially mean? HTTP had to be the base of what they built. What is the problem with HTTP? It is stateless. It is afflicted with an incurable variety of amnesia. Let's say you are executing a ten-step process. After each step, HTTP forgets all about the previous steps performed. So, before you ask it to do anything for you, set the context of the transaction - every single time. It is deeply frustrating. The protocol contains hardly 4 useful commands: GET, PUT, POST, DELETE.

Anyway, structurally, an HTTP packet looks like this:

Discussing about the various parts of HTTP at this stage would probably lead to acute mental distress. Because we have another gargantuan structure, the SOAP packet, to deal with.Oracle has given two beautiful diagrams to describe SOAP packet structures.Here you go:


The SOAP envelope goes inside the HTTP body. The resultant thing looks something like this:

It is this complexity that led to the downfall of SOAP. The whole thing was backed by academic rigour. Nothing was left undefined. The request XML had to comply with a pre-defined XSD. How did one know about its location? A WSDL document would have its location details. What is WSDL? It is an XML-based language, designed to describe Web Services.

SOAP's legacy is the firm establishment of messaging architecture in Web Services. Messaging is a fairly simple concept. System A sends a message to System B in a pre-defined format. System B understands the content and replies appropriately in another pre-defined format with the required information. It may also perform some actions at its end.

The scheme at a high level looks elegant and expressive. Its success largely depends on how strictly we implement the message template definition and validation framework. SOAP made an overkill of it. Forming your first valid SOAP message for a new API is still a challenge.