SOAP

In web technology it is important to communicate between two or more different application. SOAP provide the way to communicate between the application having

different operation system,language,technology and transporting Protocol.

What is SOAP ?

SOAP is a lightweight XML based structured protocol specification to be used in the implementation of web service and WCF service. It is used for exchanging

structured information in a decentralized, distributed environment. SOAP uses XML technologies for exchanging of information over any transport layer protocol.

It is independent of any particular programming model and other implementation specific semantics. Learn More about XML

SOAP Messaging Framework

XML-based messaging framework that is

1) Extensible : Simplicity remains one of SOAP's primary design goals. SOAP defines a communication framework that allows for features such as security, routing, and

                reliability  to be added later as layered extensions

2) Inter operable : SOAP can be used over any transport protocol such as TCP, HTTP, SMTP. SOAP provides an explicit binding today for HTTP.

3) Independent : SOAP allows for any programming model and is not tied to Remote procedure                                      call(RPC). SOAP defines a model for processing individual, one-way messages.

                            SOAP also allows for any number of message exchange patterns (MEPs)

Basic SOAP Architecture

SOAP:envelope

The SOAP Envelope construct defines an overall framework for expressing what is in a message and who should deal with it.The Envelope is the top element of the XML

document representing the message. It also helps application to identify the version of the SOAP being used.

SOAP:header

The Header element is a generic container for control information. It may contain any number of elements from any namespace. Header blocks should contain information

that influences payload processing. The element from this part contains application specific information. Header is an optional element of the soap message.

SOAP:body

body is a mandatory element unlike soap header. This part contains all information related to request and response of the web service. Actual soap message goes here.

The format of soap message is as below –

<soap:Envelope

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

<soap:Header>

<!-- Header elements. -->

</soap:Header>

<soap:Body>

<!-- Body elements. -->

</soap:Body>

</soap:Envelope>

The most important aspect of the SOAP is that without making any changes to the original SOAP message it can tunnel through firewalls and proxies.

Most of SOAP servers currently use HTTP as the transport protocol for the XML payload in SOAP message ‘cause HTTP satisfies a number of requirements:

Advance Soap

The xmlns:soap Namespace

Notice the xmlns:soap namespace in the example above. It should always have the value of: "http://www.w3.org/2003/05/soap-envelope/".

The namespace defines the Envelope as a SOAP Envelope.If a different namespace is used, the application generates an error and discards the message.

The encodingStyle Attribute

The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and applies to the element's contents

 and all child elements. A SOAP message has no default encoding.

Syntax

soap:encodingStyle="URI"

Example

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"

soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

  ...

  Message information goes here

  ...

</soap:Envelope>

The SOAP Header Element with mustUnderstand attribute

We have discuss details about SOAP header above, here we will discuss about "mustUnderstand"  attrabute of header element. Header blocks can also be annotated with

a global SOAP attribute named mustUnderstand to indicate whether or not the receiver is required to understand the header before processing the message.

The following example illustrates how to require the processing of the credentials header:

<soap:Envelope

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

 <soap:Header>

  <!-- security credentials -->

  <s:credentials xmlns:s="urn:examples-org:security"

   soap:mustUnderstand="1"

  >

   <username>dave</username>

   <password>evad</password>

  </s:credentials>

 </soap:Header>

 ...

If a header block is annotated with mustUnderstand="1" and the receiver wasn't designed to support the given header, the message shouldn't be processed and a

Fault should be returned to the sender (with a soap:MustUnderstand status code). When mustUnderstand="0" or the mustUnderstand attribute isn't present, the receiver

can ignore those headers and continue processing. The mustUnderstand attribute plays a central role in the overall SOAP processing model.

The actor Attribute

A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path. However, not all parts of a SOAP message may be intended

for the ultimate endpoint, instead, it may be intended for one or more of the endpoints on the message path.

The SOAP actor attribute is used to address the Header element to a specific endpoint.

Syntax

soap:actor="URI"

Example

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"

soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">

<soap:Header>

  <m:Trans xmlns:m="http://www.w3schools.com/transaction/"

  soap:actor="http://www.w3schools.com/appml/">234

  </m:Trans>

</soap:Header>

...

...

</soap:Envelope>

The SOAP Fault Element

The optional SOAP Fault element is used to indicate error messages. The SOAP Fault element holds errors and status information for a SOAP message.

If a Fault element is present, it must appear as a child element of the Body element. A Fault element can only appear once in a SOAP message.

The SOAP Fault element has the following sub elements:

Sub Element                    Description

<faultcode>            A code for identifying the fault

<faultstring>            A human readable explanation of the fault

<faultactor>            Information about who caused the fault to happen

<detail>                    Holds application specific error information related to the Body element

SOAP Fault Codes

The faultcode values defined below must be used in the faultcode element when describing faults:

Error                                            Description

VersionMismatch             Found an invalid namespace for the SOAP Envelope element

MustUnderstand            An immediate child element of the Header element, with the                                                                  mustUnderstand attribute set to "1", was not understood

Client                            The message was incorrectly formed or contained incorrect information

Server                            There was a problem with the server so the message could not proceed

Protocol Bindings

An interesting aspect of SOAP enables message exchange over a variety of underlying protocols. Since the SOAP messaging framework is independent of

the underlying protocol, each intermediary could choose to use a different communications protocol without affecting the SOAP message. Standard protocol bindings are

necessary, however, to ensure high levels of interoperability across SOAP applications and infrastructure.

A concrete protocol binding defines exactly how SOAP messages should be transmitted with a given protocol. In other words, it defines the details of how SOAP fits

within the scope of another protocol, which probably has a messaging framework of its own along with a variety of headers. What the protocol binding actually defines

depends a great deal on the protocol's capabilities and options.

There are a number of SOAP implementations that support other transport layers, such as

• HTTPS – using SSL provides security

• SMTP – enables asynchronous SOAP requests / SOAP report

It can be expected that other transport protocols, such as MSMQ or FTP, will be supported eventually. IBM has an interesting for HTTPR to provide a reliable transport

layer for SOAP messages

Advantages

 • Human readable XML

 • Easy to debug

 • SOAP runs over HTTP

 • Firewalls not affected

 • Services can be written in any language, platform or operating system

Disadvantages

 • SOAP is a simple protocol: As the name suggests it's a simple protocol and works on HTTP, we cannot expect all the functionality's offered by other

   protocols like DCOM or RMI.

 • SOAP may turn out to be slower compared to other proprietary protocols as it requires additional XML processing.

 • Still SOAP fares well in most areas compared to other wire protocol. As per the specifications, SOAP can also use other transport carrier like

   SMTP to transmit SOAP messages. Still lot of information on this topic in not available.