In its most basic form, SOAP is used over HTTP to send a message to a SOAP server. In turn, the server implements some specific functionality and returns a SOAP response message back to the caller. This type of interaction uses HTTP’s inherent request/response design. The original SOAP message may be a method invocation and parameters; the response may be the return values.

A SOAP request may take the form of:

<SOAP-ENV:Envelope
   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <SOAP-ENV:Body>
        <m:GetLocalTemperature xmlns:m="http://localhost/temperApp">
            <zipcode>90872</zipcode>
        </m:GetLocalTemperature>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

This message is sent over HTTP, and can be posted to a specific URI capable of interpreting and responding to the SOAP message. The return SOAP unit contains the response to the query GetLocalTemperature.

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
   <SOAP-ENV:Body>
       <m:GetLocalTemperatureResponse
          xmlns:m="http://localhost/temperApp">
           <Farenheit>59</Farenheit>
       </m:GetLocalTemperatureResponse>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

In this return example, the result of the method invocation is returned to the caller in a SOAP packet.

The current SOAP specification places no constraints on how a SOAP message is sent across the network. SOAP implementations are allowed to take advantage of any special features of their communications medium, be it HTTP, SMTP, or something yet to be imagined.

However, SOAP does define the concept of a Message Path. This critical concept allows a SOAP packet to be dealt with at intermediate steps along the way to its final destination. While it’s simple to think of the message delivery process as one that simply hops a message to its end-point, in reality this powerful concept mimics that of routing. It’s possible to add intelligence to a network to deal with SOAP packets, and distribute them where they need to go. This addition of intelligence to the network allows for a much greater level of scalability and traffic management by allowing multiple, distributed systems to route packets where they need to go, as opposed to forcing them through a central server.

SOAP requires intermediate processors to perform three steps in exact order:

For some middleware and routing applications, no parts of the SOAP message will be intended for them specifically. In these cases, the application may just look at the target URI or SoapAction value, and route the SOAP packet accordingly without modifying it.

The SOAP specification requires that all SOAP messages are encoded using XML. In addition, namespaces are used on elements and attributes, and any SOAP application must understand these concepts. The specification also dictates that messages with incorrect namespaces must be discarded—it defines two namespaces for use in SOAP. For envelopes, the correct namespace is http://schemas.xmlsoap.org/soap/envelope/.For serialization, the correct namespace is: http://schemas.xmlsoap.org/soap/encoding/.

These namespaces are associated with local names and inserted into element and attribute names per the W3C’s Namespaces in XML document. Interestingly enough, given their native development in XML, SOAP messages are not allowed to contain either a Document Type Declaration or a Processing Instruction.

A composite SOAP message contains three broad parts. The first and outermost part is the envelope. Beneath the envelope is the header. The header is the place where routing information or other nonapplication metadata may be stored. It is permissible in the eyes of the specification to temporarily modify SOAP headers during a routing or transport period, leaving the message in its original state when it finally reaches the destination. The SOAP body is the place where the application-specific payload resides.

SOAP allows for the extension of messages through optional header data. The header data may never actually be seen by sending and receiving end-point applications, but may actually only be used and seen by intermediary and middleware applications along the message’s path. However, there is no requirement that forbids the use of headers by applications.

According to the SOAP specification, headers must follow a few rules. First, a header entry must utilize a fully qualified element name within a namespace URI context. Second, the SOAP encodingStyle attribute may be used to denote the encoding style for header members. Third, the SOAP mustUnderstand attribute and actor attribute may also be used to indicate processing directions.

The Body element is the primary piece of a SOAP packet with which an end-point application is concerned. The Body element represents the SOAP packet’s payload.

Child elements of the Body element are called body entries. Each body entry is encoded as an independent element within the SOAP body element. A body entry requires a namespace URI and local name. The encodingStyle attribute can be used within body entries to indicate their encoding style.

The SOAP Fault element is used to communicate error conditions back to a calling application. The SOAP Fault may be used to communicate any type of failure relevant to your application.

SOAP encoding defines a format for data types communicated in SOAP packets. If SOAP is to be used for Remote Procedure Calls (RPC) between applications, then application-specific data must be marshaled to and from the involved parties. These applications must be able to understand the types of data—to be able to distinguish, for example, arrays from strings and numbers from letters.

In the world of SOAP encoding, the SOAP specification sees two types of data. Simple scalar types (dog = "foo") and compound types (dog = {"foo" : "bar", "bar" : "foo"}). SOAP encoding uses the namespace URI http://schemas.xmlsoap.org/soap/encoding/.

SOAP does acknowledge that other types of encoding schemes may be used, but for applications to be interoperable, it’s easiest if they use the same encoding.

There are nine golden rules for data serialization using SOAP. These rules establish guidelines for both simple and complex data types and data representation. These nine rules are explored and illustrated in practice following these simple guidelines.

While these rules may seem quite complicated, learning more about types helps demystify them. When working with some SOAP APIs (and hopefully all SOAP APIs), such strict data typing is not manually required, and is taken care of by the API.

The SOAP specification declares that it adopts the types found in the XML Schema Part 2: Datatypes specification. In other words, the SOAP drafters are not reinventing the wheel, but utilizing the work done for the XML Schema effort.

Using established data typing makes data encoding far simpler to understand than the list of nine rules presented in the previous section. For example:

<element name="FirstName" type="xsd:string"/>
<element name="LastName" type="xsd:string"/>
<element name="Address1" type="xsd:string"/>
<element name="City" type="xsd:string"/>
<element name="State" type="xsd:string"/>
<element name="Zip" type="int"/>
<element name="BalanceDue" type="float"/>

The SOAP specification recognizes two primary types of compound data: structs and arrays. A struct is a compound type in which members are given names, and the names are used to access the values. An array, on the other hand, is an ordered list in which an integer index is used to access the values.

SOAP fits naturally over HTTP. SOAP’s request/response RPC-style transactions are perfect for HTTP’s request/response protocol. When sending SOAP over HTTP, the content-type must be text/xml.

Using SOAP for RPC-style development is really nothing different from using SOAP for any other purpose. The semantics of request/response are still present. A SOAP method invocation is just a SOAP envelope with a method name as payload, accompanied by any data parameters. The response is either the return value or the error status, also within a SOAP envelope.

When performing RPC with SOAP, the method calls and return values are stored in the SOAP body.