SOAP

Motivation for learning (problem & outside events that effected to learn about this topic )
When I did Software Development Frameworks, there was a requirement in the assignment to use the Web Services. Our group developed a website for a hotel in Maldives. We decided to use web services to get weather information from the Department of Meteorology website. So as once they update the weather, from our website also the weather gets updated. But we all had a problem, in identifying how to use it. We had no idea about what language or the platform that they have used to develop the weather information website. Somehow we were able to complete, as some of our group members knew about a good way to do it. But when it comes to me, I am totally clueless.

When I develop software I have to rely on calling different procedures to provide functionality. So I will have to put all the procedures into an object. These objects should be created in a way that this can be reused in the future for different systems for different developers. But what happens when the objects are platform specific? As objects created for one platform cannot access the objects of another platform. Calling methods from objects through the internet is difficult. Hence the current distributed technologies require the use of special ports to transmit their data. Most of the corporate firewalls block all the other ports except port 80, which is the default port for HTTP. Most of the administrators fear opening up the other ports, which could pose a potential security problem. So with all these problems how can applications communicate through internet?
To make this happen there is a need for a :
• Platform independent way to call methods located on diverse distributed systems.
• A firewall-friendly way to make the remote call procedures over internet.
• A technology which is light weight and easy to use and cater for the problems.

What is SOAP
(insight Solution)
SOAP is a solution for this. It is a Simple Object Access Protocol that allows accessing an object through the net. It is a platform and language independent communication XML based protocol. Or more simply: SOAP is a protocol for accessing a Web Service and it cold be expressed as SOAP = XML + HTTP. And SOAP is able to leap through firewalls in a single bound. This is possible because it uses XML documents which can easily be transported via HTTP through firewalls without security risks. Furthermore it is light weight and easy to understand and use.

A soap Transaction
(plan of achieving the solutions encountered)
SOAP solves the problems through the use of this plan.

• Messages are sent in a familiar request/response fashion.
• SOAP defines an XML structure to call a method and pass the method through parameters.
• It also defines an XML structure to return values that were requested.
• SOAP defines an XML structure to return the error values (faults) if the service provider cannot execute the requested method.
• Here is a typical diagram that illustrates how SOAP work.

A SOAP transaction begins with an application making a call to a remote procedure. The SOAP client script then encodes the procedure request as an XML payload and sends it over the transport protocol to a server script. The server parses the request and passes it to a local method of the remote object, which returns a response. The response is encoded as XML by the server and returned as a response to the client, which parses the response and passes the result to the original function.


SOAP Syntax

(SOAP Building Blocks and Rules)

• A SOAP message is an ordinary XML document containing the following elements:
• A required Envelope element that identifies the XML document as a SOAP message
• An optional Header element that contains header information
• A required Body element that contains call and response information
• An optional Fault element that provides information about errors that occurred while processing the message

Syntax Rules
Here are some important syntax rules:

• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP Envelope namespace
• A SOAP message MUST use the SOAP Encoding namespace
• A SOAP message must NOT contain a DTD reference
• A SOAP message must NOT contain XML Processing Instructions

The SOAP Message

• HTTP: Responsible for sending SOAP messages back and forth. It’s the equivalent of a postman carrying the SOAP envelope in his hand to the destination.
• SOAP Header: The optional SOAP Header element contains application specific information (like authentication, payment, etc) about the SOAP message. If the Header element is present, it must be the first child element of the Envelope element. It tells the receiving system how to handle the incoming message without requiring the receiver to look inside and deduce the content is SOAP content. If a SOAP server is ready to use, you just need to determine if the server adds anything when this header is present.
• A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path. Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message but, instead, may be intended for one or more of the endpoints on the message path.
• The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.
• Immediate child elements of the SOAP Body element may be namespace-qualified. SOAP defines one element inside the Body element in the default namespace.
• ENVELOPE: Creating a SOAP message is a bit like writing and mailing a letter. Once you’ve created a SOAP message, put it in a SOAP envelope and write instructions on the front.

Here’s what a SOAP envelope looks like:

The ellipses (three dots) indicate where the letter and other content goes.
This is the third set of tags you’ll need. The ,

, and tags (case-sensitive!) are all specified for you by the SOAP standard—they describe the pieces of the envelope that surrounds the SOAP data, even though the envelope is technically separate from the data you’re actually trying to send. The whole thing is called a “SOAP message.”

Skeleton of a SOAP Message.



xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

...
...


...
...

...
...









A SOAP message must always have an Envelope element associated with the "http://www.w3.org/2001/12/soap-envelope" namespace.
If a different namespace is used, the application must generate an error and discard the message.

The encodingStyle Attribute
The SOAP encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and it will apply to that element's contents and all child elements. A SOAP message has no default encoding.

Syntax
soap:encodingStyle="URI"

USING SOAP In the example below, a GetStockPrice request is sent to a server. The request has a StockName parameter, and a Price parameter will be returned in the response. The namespace for the function is defined in "http://www.example.org/stock" address.


The SOAP REQUEST

POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn



xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">


IBM



>


The SOAP Response

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn


Standard SOAP Fault Codes

The optional SOAP Fault element is used to hold error and status information for a SOAP message. An error message from a SOAP message is carried inside a Fault element.
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 standard SOAP fault codes include:

• Version Mismatch
• Misunderstand: specify which header blocks were not understood
• Server: error can’t be directly linked to the processing of the message
• Client: there is a problem in the message (e.g. invalid authentication credentials.
• Misunderstood Header

What SOAP doesn’t do?

• The SOAP specification doesn’t define how the requestor or the responder send and receive messages.

• The implementation of sending and receiving is up to the developer.

• The SOAP doesn’t define how a message will create an instance of an object and execute the method. Implementation details are left to the software developer or a third party software vendor.

Conclusion(Knowledge Acquisition)

This journal has helped me to gain knowledge on SOAP, and I learnt about how to use it for requesting and sending responses for applications.

SOAP is a protocol for passing messages. The most common arrangement for SOAP messages is a request/response pair, basically a question and answer. HTML form submission is also a request-response pair. SOAP is to form submission a bit as if Microsoft Windows is to DOS. DOS does a basic job, which is great if that’s all you want. Windows is more complicated, but once you have learned the detail, it’s more powerful too. You can mimic SOAP concepts with plain HTML forms, but for the real thing, learn the SOAP syntax and buy some three-phase power tools.
• In the deployment of the web services the SOAP acts as a:
• Listener to receive message
• Proxy to take message and translate it into an action to be carried out
• Application code to implement that action

SOAP in short:
• SOAP stands for Simple Object Access Protocol
• SOAP is a communication protocol
• SOAP is for communication between applications
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls

There is a lot more in SOAP. But I am sure that I will not need to learn the whole SOAP inorder to understand all of it.

Total Hours Spent in learning: 11 Hours 45 mins