1. Introduction
  2. SOAP Namespace
  3. Basic Structure of SOAP
  4. SOAP Header
  5. SOAP Body
  6. Document/Literal
  7. RPC/Literal
  8. SOAP Faults
  9. SOAP over HTTP
  10. SOAP Data Model


  1. The acronym for SOAP is Simple Object Access Protocol.
  2. SOAP is a standard messaging protocol in web services.
  3. The SOAP messages are represented in XML with additional features such as:
    • Set of rules (Encoding) for sending messages.
    • Network protocol such as HTTP.
    • A way to represent protocol and application Faults.
    • Standard format for RPC-style messaging.
    • Extensibility model.
  4. The SOAP protocol standardizes above concepts otherwise every developer who wants to send XML messages would have to create their own ad hoc solutions to these problems, which causes interoperability quite difficult.
  5. The SOAP messages are automatically and internally generated by Serializers (or Marshaling) component in Web Services.
    • In Web Service, the object in client program is serialized as XML message.
    • The above XML message is added as body to soap message.
    • The above SOAP message becomes Payload (body) of some network protocol such as HTTP.
  6. The HTTP is a convenient way of sending and receiving SOAP messages between applications on a network.
  7. SOAP defines how messages can be structured in a way which is independent of any programming language or platform, and thus achieves Interoperability between applications written in different programming languages and running on different operating systems.

SOAP Namespace

  1. The SOAP message format is defined by a XML schema.
  2. The namespace for soap1.1 version is “http://schemas.xmlsoap.org/soap/envelope/“.
  3. The namespace for soap1.2 version is “http//www.w3.org/2003/05/soap-envelope“.
  4. If a SOAP application receives a message with different namespace, it must generate fault (or error).
  5. All SOAP elements must be namespace qualified, because the XML schema for SOAP1.2 specifies the “elementFormDefault” attribute as “qualified
  6. .

Basic Structure of SOAP

  1. The root element of the SOAP message is <soap-Envelope> element.
  2. The <soap-Envelope> element contains optional <soap-Header> element and a single mandatory <soap-Body> element.

Sample SOAP Message Format

<?xml version="1.0" encoding="UTR-8"?>
<soap-Envelope xmlns:soap="http//www.w3.org/2003/05/soap-envelope">
 <!--optional header element-->
 <!--Header blocks for Security credentials, transaction IDs, etc in XML format-->
 <!--A mandatory body element-->
  <!--Application data in XML format i.e. XML Message-->

SOAP Header

The SOAP header contains XML elements that describes Security Credentials, Digital Signature, Transaction IDs, Routing Instructions, Debugging Information, Payment tokens, etc.

The actor attribute

  1. A node can play one or more roles in soap message path. Unfortunately, the designers of SOAP 1.1 confused the words “actor” and “role” and they specified that we must identify the roles a node will play by declaring an actor attribute.
  2. They have recognized the mistake and in SOAP 1.2 version this attribute has been renamed as “role”.
  3. The SOAP 1.1 applications use the “actor” attribute to identify the nodes that should process a specific header block.
  4. The “actor” attribute uses a URI (Uniform Resource Identifier) to identify the role that a node must perform in order to process that header block.
  5. When a node receives a soap message, it examines each of the header blocks to determine which ones are targeted to roles supported by that node.


<!--header blocks-->
	<mi:message-id soap:actor="http://..../logger"></mi:message-id>
<proc:processed-by soap:actor="http//schemas.xml.soap.org/soap/actor/next"></proc:processed-by>

The mustUnderstand attribute

  1. Header blocks may indicate whether processing in mandatory or not by using the mustUnderstand attribute.
  2. When a header block has a mustUnderstand attribute equal to “1”, it is called mandatory header block.
  3. The SOAP nodes must be able to process any header block that is marked as mandatory.
  4. The SOAP node does not understand a mandatory header block, it must generate a SOAP Fault with fault code “MustUnderstand” and must not forward the message to the next node in the message path.


<!--header blocks-->
	<proc:processed-by soap:actor="http//schemas.xml.soap.org/soap/actor/logging"  mustUnderstand="1"></proc:processed-by>


  1. All SOAP messages must contains exactly one <soap:Body> element.
  2. The <soap:Body> element contains the actual application data in XML format.
  3. The <soap:Body> element contains either application specific data or fault message, but not both.
  4. The <soap:Body> element contains:
    • Xml document fragment.
    • Procedure call with parameters.
    • Fault message(Applicable only in case of error response).
  5. In Soap Request message, the <soap:Body> element contains Application specific data (i.e., either XML Document Fragment or Procedure call with parameters).
  6. In Soap Response message, the <soap:Body> element contains either Application specific data (i.e., either XML Document Fragment or Procedure call with parameters) or fault message, but not both.
  7. Except in case of fault message, SOAP does not specify the contents of the Body element. As long as the Body element may contains well-formed XML the application specific data can be anything.
  8. The format of the soap body is determined by Messaging Style. The SOAP supports 2 Messaging Styles:
    • Document.
    • RPC
  9. The XML data in SOAP body must be validated using set of rules. These rules are determined by Encoding Style.
    The SOAP supports 2 Encoding Styles.

    • SOAP Encoding: It means that XML data is validated against SOAP Encoding rules defined in Section 5 of SOAP 1.1 specification. The SOAP Encoding is not supported by WS-I (Web Services-Interoparibility) conformant, because it causes interoperability problems. Hence, the SOAP Encoding is deprecated in SOAP 1.2 version i.e., SOAP Encoding is not recommended to use.
    • Literal Encoding: It means that the XML data is validated against its XML Schema.
  10. Based on Messaging Style and Encoding Style, there are 4 messaging modes supported by SOAP.
    • Document/Literal.
    • RPC/Literal.
    • RPC/Encoded.
    • Document/Encoded.
  11. The Basic Profile permits the use of Document/Literal or RPC/Literal only. The RPC/Encoded and Document/Encoded modes are explicitly prohibited.


In the Document/Literal mode of messaging, the SOAP Body contains XML Document Fragment (with application data) validated against our own xml schema namespace.



<?xml version="1.0"?>
<xs:schema xmlns:xs="http//www.w3.org/2001/XMLSchema" targetNamespace="www.java2learn.com/po"   xmlns="www.java2learn.com/po" elementFormDefault="qualified">
<xs:element name="PurchaseOrder">
			<xs:element name="AccountName" type="xs:string"/>
			<xs:element name="AccountNumber" type="xs:unsignedShort"/>

In Document style messaging, the top level xml element name from our schema becomes direct sub element of the <soap:Body>


<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http//www.w3.org/2003/05/soap-envelope">
<!--Header blocks go here-->
	<!--XML Document Fragment-->
	<tns:PurchaseOrder xmlns:tns="www.java2learn.com/po">


  1. RPC means Remote Procedure Call.
  2. The RPC/Literal messaging is used expose traditional components such as CORBA, RMI, Stateless Session Bean, DCOM, etc as web services.
  3. These components do not explicitly exchange XML data, rather, they have methods with parameters and return values. Hence, RPC style messaging is standardized in SOAP.
  4. The RPC/Literal mode of messaging specifies how methods and their parameters (including return values) are represented within the <soap:Body> element.
  5. The RPC request message contains the method name and their parameter names.
  6. An RPC response message contains the return value and any output parameters (or a fault).
  7. In RPC Style messaging, the <soap:Body> contains method names and their parameter names.
    Hence, In case of RPC style messaging, the direct sub element of the <soap:Body> is method name.
  8. The following is the Service Endpoint Interface (SEI) of the Web Service.
package com.java2learn.service;
import java.rmi.RemoteException;
public interface BookQuote extends java.rmi.Remote {
	//Get the wholesale price of a book
	public float getBookPrice(String isbn) throws RemoteException, InvalidISBNException;

RPC/Literal SOAP Request Message

The following is the RPC/Literal soap request message for the above Endpoint Interface.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http//schemas.xml.soap.org/soap/envelope/">
<soap:Body xmlns:tns="www.java2learn.com/book">
	<--method name becomes sub element of the soap body element-->
		< parameter names becomes child elements-->

An RPC/Literal SOAP Response Message

The following is the RPC/Literal soap response message for the above Endpoint Interface.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http//schemas.xml.soap.org/soap/envelope/"

RPC-style messaging is a common in distributed technologies, including EIB, CORBA, DCOM, and others, so SOAP defines a standard XML format for RPC-style messaging, called RPC/Literal.


When we say a messaging mode is Document/Literal or RPC/Literal, we are usually describing the payload of the SOAP message.XML document fragment or XML representation of the parameters and return values associated with a remote procedure call.

SOAP Faults

  1. The <soap:Fault> element is added to <soap:Body> in soap response message in case of an error.
  2. A SOAP message that contains a <soap:Fault> element in the <soap:Body> is called as fault message.
  3. A fault message is analogous to a Java exception. The soap fault is mapped to javax.xml.rpc.soap.SOAPFaultException, java.rmi.RemoteException, or Service specific exception.
  4. Faults are caused by improper message formatting, version mismatches, trouble processing a header, and application specific errors.


The <soap:Fault> element contains following child elements:

<soap:Node minOccurs="0"/>.
<soap:Role minOccurs="0"/>.
<soap:Details minOccurs="0"/>.


SOAP defines a small set of SOAP fault codes high level soap faults. The following table summarizes standard SOAP fault codes:

Fault Code Description
VersionMismatch SOAP1.1 and SOAP1.2 version mismatch between SOAP Sender and SOAP Receiver i.e., wrong Envelope namepace.
MustUnderstand Particular SOAP header block(s) which were not understood.
DataEncodingUnknown SOAP node does not support encoding specified using ‘encodingStyle’ attribute.
Sender The SOAP message was incorrectly formed. For example; the message could lack the proper authentication or payment information.
Receiver The message could not be processed for reasons attributable to the processing of the message rather than to the contents of the message itself.


  1. The SOAP is a messaging protocol and the HTTP is Transport protocol.
  2. The SOAP message can be transported over many different network protocols using formal set of rules is called as SOAP binding.
    However the standard network protocol used for SOAP is HTTP.
  3. SOAP messages sent over HTTP are placed in the Payload of an HTTP requested or response.
  4. HTTP is a Request/Response protocol, which means that the sender expects a response (either error code or data) from the receiver.
  5. Web services that use SOAP over HTTP is always use HTTP POST but not HTTP GET, since POST request have a payload area and is perfectly suited to carrying a SOAP message
  6. .


A SOAP request over HTTP.

POST/ws/BookQuote HTTP/1.1
Host: www.java2apsire.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 295

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"


A SOAP Response over HTTP

HTTP/1.1 200 OK
Content-Type: text/xml; charset=’UTF-8′

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

SOAP Data Model

The SOAP Data Model represents application-defined data structures and values as a directed edge-labeled graph of nodes. An edge-label is an XML qualified name. Hence, the purpose of the SOAP Data Model is to provide a mapping of non-XML based data to some wire representation.
Applications which already model data in XML may not need to use the SOAP Data Model.In this case SOAP Data Model is not required.