/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsIntroduction
SOAP is a key element of web-services architecture stack. SOAP is the standardized packaging protocol for messages shared by applications. It is an application of XML.
A SOAP message is a XML document with the following parts:
1. The SOAP envelope construct defines an overall framework for expressing
a. what is in a message?
b. who should deal with it?
c. whether it is optional or mandatory?
2. Optional SOAP header to contain the header information.
3. SOAP body that will contain the request and response information.
SOAP messages are commonly carried in HTTP messages although other network protocols like SNMP.
SOAP Message
SOAP in RPC and EDI
XML messaging has two related applications: RPC and EDI. RPC is the basis of distributed computing. SOAP for RPC is used to represent method calls, parameter or return values. SOAP for EDI is used to exchange business transactions like a purchase order, tax-refund or a similar document. Both these usage of SOAP are known as RPC-style SOAP and document-style SOAP respectively.
RPC Messages
Let’s see an RPC-style message. Imagine the server offers this function, which returns a stock’s price as a SOAP service:
public float getQuote(String symbol)
The XML syntax for expressing a SOAP message is based on the http://www.w3.org/2001/06/soap-envelope namespace. The XML namespace identifier points to an XML Schema that defines the structure of what a SOAP message looks like.
SOAP request
SOAP response
This attribute MUST appear in the instance in order to be effective. 3. The Body Element
The mandatory
The SOAP Body element provides a simple mechanism for exchanging mandatory information intended for the ultimate recipient of the message. Typical uses of the Body element include marshalling RPC calls and error reporting.
SOAP defines one body entry, which is the Fault entry used for reporting errors
SOAP Faults
A SOAP fault is a special type of message specifically targeted at communicating information about errors that may have occurred during the processing of a SOAP message.
The information communicated in a SOAP fault is by the use of faultcode, faultstring, faultactor and fault details.
The SOAP Fault element is used to carry error and/or status information within a SOAP message. If present, the SOAP Fault element MUST appear as a body entry and MUST NOT appear more than once within a Body element.
The SOAP Fault element defines the following four subelements:
1. faultcode
The faultcode element is a code that identifies the fault and it is used for further processing. The faultcode is mandatory in a SOAP Fault element.
2. faultstring
The faultstring element is the string error message and it is not intended for processing. It is also a mandatory element.
3. faultactor
The faultactor element tells who caused the error. Applications that do not act as the ultimate destination of the SOAP message MUST include the faultactor element in a SOAP Fault element. The ultimate destination of a message MAY use the faultactor element to indicate explicitly that it generated the fault.
4. detail
The detail element is intended for carrying application specific error information related to the Body element. It MUST be present if the contents of the Body element could not be successfully processed. It MUST NOT be used to carry information about error information belonging to header entries. Detailed error information belonging to header entries MUST be carried within header entries.
The absence of the detail element in the Fault element indicates that the fault is not related to processing of the Body element. This can be used to distinguish whether the Body element was processed or not in case of a fault situation.
All immediate child elements of the detail element are called detail entries and each detail entry is encoded as an independent element within the detail element.
Standard SOAP Faults
SOAP defines four standard types of faults
VersionMismatch – the SOAP envelope using an invalid namespace for the SOAP Envelope elements.
MustUnderstand – the header block contaning mustUnderstand flag was not understood
Server – error occurred while processing of the message.
Client – when there is a problem in the message.
Encoding Styles
Encoding styles are how applications on different platforms share information, even though they may not have common data types or representations. An encoding style is a set of rules that define exactly how native application and platform data types are to be encoded into a common XML syntax. These are obviously used for RPC-style SOAP.
The data types supported by the SOAP encoding styles are the data types defined by the “XML Schema data types” specification. All data types used within a SOAP-encoded block of XML must either be taken directly from the XML Schema specification or derived from types therein.
Alternate SOAP encoding syntaxes fro values
Versioning
There has been several versions of the SOAP specification. The most recent working draft, SOAP version 1.2 is the first w3c effort to standardize an XML based packaging protocol. Version1.1 uses the namespace http://schemas.xmlsoap.org/soap/envelope/, whereas version1.2 uses namespace http://www.w3.org/2001/06/soap-envelope
SOAP1.2 introduces a versioning model that deals with how SOAP1.1 processors and SOAP1.2 processors may interact.
1. If a SOAP1.1 compliant application receives a SOAP1.2 message a “version mismatch” error will be triggered.
2. If a SOAP1.2 compliant application receives a SOAP1.1 message, the application may choose to either process it according to 1.1 specification or trigger a “version mismatch” error.
References
1. http://www.w3.org/2001/12/soap-envelope
2. http://www.w3.org/2001/12/soap-encoding
4. http://www.whoishostingthis.com/resources/soap/
(The authors can be reached at avijeetd@yahoo.com and satyabrata_dash@yahoo.com)
CIOL Bureau