SOAP message, SOAP request - response

Mirjana's picture
SOAP stands for 'Simple Object Access Protocol'. The acronym is sometimes confused with SOA or Service-oriented architecture, however SOAP is quite different from SOA.
SOAP is an XML-based messaging protocol. It defines a set of rules for structuring messages that can be used for simple one-way messaging but is particularly useful for performing RPC-style (Remote Procedure Call) request-response dialogues. It is not tied to any particular transport protocol though HTTP is popular. Nor is it tied to any particular operating system or programming language so theoretically the clients and servers in these dialogues can be running on any platform and written in any language as long as they can formulate and understand SOAP messages. As such it is an important building block for developing distributed applications that exploit functionality published as services over an intranet or the internet.
Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP, but HTTP has gained wider acceptance as it works well with today's Internet infrastructure; specifically, HTTP works well with network firewalls. SOAP may also be used over HTTPS (which is the same protocol as HTTP at the application level, but uses an encrypted transport protocol underneath) with either simple or mutual authentication, this is the advocated WS-I method to provide web service security as stated in the WS-I Basic Profile.
Simple Object Access Protocol provides an XML-based framework for exchanging structured and typed information between peer services. This information, formatted into Header and Body, can theoretically be transmitted over anumber of transport protocols.
SOAP is an extensible, text-based framework for enabling communication between diverse parties, in general, objects that have no prior knowledge of each other or of each other's platforms. From the point of view of objects on the net, SOAP is the ultimate blind date.
SOAP is extensible, because SOAP clients, servers and the protocol itself can evolve without breaking existing apps.
Network Tiers in Web Services
Three network tiers are evident in the evolution of Web services: TCP/IP, HTTP/HTML, and XML. These tiers build successively on top of each other and remain compatible today.
  • The first tier, the TCP/IP protocol, is concerned primarily with passing data across the wire in packets. A protocol that guarantees transmission across public networks, TCP/IP emphasizes reliability of data transport and physical connectivity
  • The second tier, HTML over HTTP, is a presentation tier and concerns itself with browser-based search, retrieval and sharing of information. The emphasis here is on GUI-based navigation and the manipulation of presentation formats. In many ways, HTML is more show than go and lacks both extensibility and true programming power. Nonetheless, sharing hypertext-linked documents in a browser-based environment revolutionized the way humans communicate text-based information to one another. Networked desktop environments, burdened with proprietary operating systems and platform dependent software, are slowly but surely giving way to the standards-based, open-systems computing of the Internet.
  •  Leading the charge into this brave new standards-based world is XML, the third and possibly the most compelling tier on the Internet. XML, a strongly-typed data interchange format, provides a new dimension to the HTTP/HTML tier, one in which machine-to-machine communication is made possible through standard interfaces. This layer, variously described as A2A (application to application), B2B (business to business) or C2C (computer to computer), allows programs to exchange data formatted in a platform- and presentation-independent manner. XSLT style sheets may be added as an optional presentation and/or transformational component.
  • UDDI is used to register and discover Web services
  • Web Services are typically described in WSDL
  • application uses SOAP to request the Web service
  • SOAP messages are actually delivered by HTTP and TCP/IP
SOAP Clients and Servers
A SOAP client is a program that creates an XML document containing the information needed to invoke remotely a method in a distributed system. SOAP clients need not be traditional, a SOAP client could also be a Web server or a server-based application.
Messages and requests from SOAP clients are typically sent over HTTP. As a result, SOAP documents are able to traverse almost any firewall, enabling the exchange of information across different platforms.
A SOAP server is simply special code that listens for SOAP messages and acts as a distributor and interpreter of SOAP documents. External Web services may interact with application servers based on J2EE technology, which process SOAP requests from a variety of clients.
SOAP servers ensure that documents received over a HTTP connection are converted to a language that the object at the other end understands. Because all communications are made in the form of XML, objects in one language (say, Java) may communicate through SOAP with objects in any other language (C++, for example). It's the job of the SOAP server to make sure the end points understand -- and are happy with -- the SOAP they're being served.
SOAP Message Format
SOAP does all this in the context of a standardized message format. The primary part of this message has a MIME type of "text/xml" and contains the SOAP envelope. This envelope is an XML document. The envelope contains a header (optional) and a body (mandatory). The body part of the envelope is always intended for the final recipient of the message, while the header entries may target the nodes that perform intermediate processing. Headers, for example, may be used to provide digital signatures for a request contained in the body. In this circumstance, an authentication or authorization server could process the header entry, independent of the body, stripping out information to validate the signature.
Attachments, binary or otherwise, may be appended to the body.
SOAP Envelope
The SOAP envelope is the top element of the XML document that represents the SOAP message. Envelope is represented by an Envelope element. The envelope can contain XML namespaces declarations that are used to disambiguate SOAP identifiers from application specific identifiers. Also envelope can contain other attributes such as encoding style.
  • SOAP Header
The header is represented by a Header element. As mentioned before, the header is optional. However, if it's included in a SOAP message, it must be the first child of the Envelope element. The header, through attributes, extends the SOAP message.
In other words, it adds information beyond what is in the body of the SOAP message.
SOAP Header also contains part for security.
It's important to understand that as a SOAP message travels from an originator (a client application) to a final destination (for example, an application providing a requested service), it potentially passes through a set of intermediate nodes along the path. Each node is an application that can receive and forward SOAP messages. The SOAP header can be used to indicate some additional processing at a node, that is, processing independent of the processing done at the final destination. For example, the header could be used to request that each message be logged at a particular node.
  • SOAP Body
The body, represented by a Body element, contains the "payload", that is, the information intended for the final destination. The Body element can optionally contain a Fault element that is used to hold error and status information returned by a processing node. The Body element must be an immediate child element of a SOAP Envelope element. If the envelope contains a header, the Body element must immediately follow the Header element.
SOAP Request as well as SOAP Response have the same structure explained above. Examples follows below.
SOAP Request Example
<SOAP-ENV:Envelope xmlns:SOAP-ENV="" xmlns:SOAP-ENC="" xmlns:xsi="" xmlns:xsd="" xmlns:wsrm="" xmlns:wsa="">
                  <wsrm:Sequence SOAP-ENV:MustUnderstand="1">
            <m:info xmlns:m="">
            <m:mesaAuth xmlns:m="">
                  <m:auth hashType="">password</m:auth>
SOAP Response Example
<soapenv:Envelope xmlns:soapenv="" xmlns:xsd="" xmlns:xsi="">
                        <siInstallDate>2008-11-25 12:00:03.0</siInstallDate>
                        <siComments>GIS installation</siComments>