The computer science meaning of the word “protocol” is a treaty between parties that want to exchange data between their respective computers. We can describe SOAP as a treaty that describes how to call methods on a different computer than the one that we are running on.
SOAP doesn’t involve any new inventions or clever algorithms. In fact, the two strongest features of SOAP are its simplicity and the fact that everyone has agreed to use it. A SOAP message is composed of two mandatory parts—the SOAP envelope and the SOAP body—and one optional part—the SOAP header. In addition, all the XML tags associated with SOAP have the prefix SOAP-ENV. The envelope is SOAP-ENV:Envelope; the header is SOAP-ENV:Header; and the body is SOAP-ENV:Body. Below figure shows the relationship between the parts of a SOAP message.
Image may be NSFW.
Clik here to view.
The SOAP envelope is similar to a physical envelope; we can fill it full of data and send it to someone else. The SOAP body is like the contents of the envelope. We can put any information that we want inside the envelope. The SOAP header is like a sticky note that we place inside an envelope when we are sending things to someone else. It contains data that provides special instructions such as “Send your response directly to Bill,” or “My password is 12345.”
The SOAP-ENV:Envelope Tag
A SOAP message is defined as beginning with the tag <.SOAP-ENV:Envelope> and ending with the tag <./SOAP-ENV:Envelope>
SOAP messages cannot be sent in batches, so you know that you are looking at only one message inside the envelope. There might also be a header section that can contain n header elements.
In SOAP 1.1, the SOAP_ENV:Envelope tag is normally constructed using the following syntax:
<.SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” >
The string xmlns is a keyword in XML that stands for XML namespace. The namespace is used to uniquely identify all tags in order to avoid tag name conflicts. The SOAP-ENV part is the name that SOAP requires to be used as the prefix for all the tag names that SOAP defines. The string “http://schemas.xmlsoap.org/soap/envelope/” looks like the address of an ordinary Web site. In reality, it is a unique string that serves the same purpose as a version number would. A client places a string that indicates indirectly which version of SOAP it is using. The Web service that receives the request can look at this string to determine whether it is capable of communicating using that version of SOAP.
The SOAP-ENV:Body Tag
The body of the SOAP message begins with the tag <.SOAP-ENV:Body> and ends with the tag <./SOAP-ENV:Body>
This is where the payload of the SOAP message is placed. Normally, that payload is a method call to a remote computer, complete with parameter values. Sometimes, however, it is simply an XML document that is being transferred.
At other times, it might be a response message containing a bank balance or a picture of the first moonwalk. The format of the body is under the control of whoever is creating a new Web service. A special XML document, called the Web services Description Language (WSDL) document, is created to describe what a legal method call to that service would look like and what form a valid response can take.
The following snippet shows a body that makes a Remote Procedure Call (RPC) to a method called checkAccountBalance():
<.SOAP-ENV:Body>
<.checkAccountBalance>
<.accountNumber xsi:type=”xsd:int”>123456780<./accountNumber>
<./checkAccountBalance>
<./SOAP-ENV:Body>
The second line, <.checkAccountBalance> provides the name of the method to call, checkAccountBalance. The first element is called accountNumber, and it is a parameter that is being passed in with the checkAccountBalance method:
<.accountNumber xsi:type=”xsd:int”>123456780<./accountNumber>
The xsi:type is an attribute, and the xsd:int means that this value is an integer. 123456780 is the value of the parameter being passed. The net effect of all these characters is a method call.
The SOAP-ENV:Header Tag
The SOAP-ENV:Header element is optional in a SOAP message. If a header is present, however, it must be the first child element that appears in the SOAP envelope. The format of the SOAP-ENV:Header element is not defined in the specification; therefore, it is available to the clients and services for their own use. Typical use would be to communicate credentials such as username and password.
Two attributes associated with the SOAP-ENV:Header element can be used. The first is the SOAP ENV:mustUnderstand attribute. If it is set to “1”, an error message will be generated if the Web service is not programmed to handle the fields in this header. The client programmer has to decide whether the processing can take place on a site that can’t read the header.
The second attribute is called SOAP-ENV:actor. This attribute is used to chain together Web services that this document must visit to be completely processed. Think about how a purchase order could be viewed by the payroll department to calculate commissions, by accounts receivable to create a bill, and by the shipping department to send the physical merchandise. The chain can be created by adding SOAP-ENV:actor tags along with their URIs to the header. The following snippet shows a simple SOAP-ENV:Header:
<.SOAP-ENV:Header>
<.myNS:authentication xmlns:myNS=”http://www.stevepotts.com/auth”
SOAP-ENV:mustUnderstand=”1”>
<.loginID>
admin
<./loginID>
<.password>
rover
<./password>
<./myNS:authentication>
<.SOAP-ENV:Header>
The header contains a made-up element called <myNS:authentication>. That element contains the loginID and password elements. These elements have no standard meaning in SOAP at this time.
SOAP Fault:
Exceptions thrown by an XML Web service method created using ASP.NET are sent back to the client in the form of a SOAP fault. A SOAP fault is a <.Fault> XML element within a SOAP message that specifies when an error occurred. When passing a SOAP fault, ASP.NET follows the method prescribed for propagating errors back to a client by the SOAP specification. The SOAP <.Fault> XML element contains details such as the exception string and the source of the exception. The SOAP-ENV:fault tag has four optional tags:
• SOAP-ENV:faultcode - This element is required by the specification. The faultcode MUST be present in a SOAP Fault element and the faultcode value MUST be a qualified name. It should contain some code indicating what the problem is.
• SOAP-ENV:faultstring - This required element is a human-readable version of the faultcode. It should provide details beyond the “error some place” type of message.
• SOAP-ENV:faultactor - This optional element tells which service generated the fault. This is important when a chain of services was used to process the request.
• SOAP-ENV:detail - This element should contain as much information as possible about the state of the server at the time of the crash. It often contains the values of variables at the time of the failure.
Error codes in SOAP are defined in the specification in a way that you might not have predicted. In other languages, integers are used to represent faults. In SOAP, error codes are represented as two-part strings with major and minor error codes separated by a . like this:
<.SOAP-ENV:faultcode>
Server.customerCreateFailed
<.SOAP-ENV:faultcode>
Four types of generic faultcode are defined by the specification:
• server - An error occurred on the server, but not with the message itself. You should write your client to retry messages that fail with these codes. If the error is with the availability of the service, a subsequent retry would work. Limit the number of retries, however, because the error might be coming from the service itself and would therefore not go away with the passage of time.
• client - These errors indicate that something is wrong with the message itself, such as a bad message format, incomplete message, and so on.
• versionMismatch - This error occurs when the versions of the SOAP processors are different between the client and the server. The version is determined by the namespace URI used in the SOAP-ENV:Envelope tag.
• mustUnderstand - This error is generated when an element in the header cannot be processed and that element is marked as required. If an element contains a mustUnderstand attribute, it requires that the Web service be able to understand all the contents of the element. If not, you want to receive this error message.
An example of a full-blown fault tag is shown here:
<.SOAP-ENV:Fault>
<.SOAP-ENV:faultcode>
Client.Authentication
<./SOAP-ENV:faultcode>
<.SOAP-ENV:faultstring>
This customer is unknown to our system.
<./SOAP-ENV:faultstring>
<.SOAP-ENV:faultactor>
http://www.dotnetcrack.com/pages
<./SOAP-ENV:faultactor>
<.SOAP-ENV:detail>
<.customer custID=”12345”>
<.name>
ABC DEF
<./name>
<./SOAP-ENV:detail>
<./SOAP-ENV:Fault>
The faultcode has a specific format and that the faultactor must contain the URI of a Web service. The other two elements accept any information that you want to provide to your user.