Overview

In the previous articles, We have gone through basics of SOAP Webservice and Steps to create SOAP Webservice. As we are knowing that SOAP forms message before communicating with Server, That message called as a SOAP Message. Today, We will understand in depth of SOAP Message and Structure of the message.

A SOAP based web service message is a hierarchical XML packet, consisting of up to four parts.

  1. Envelope
  2. Header
  3. Body
  4. Fault

SOAP Message Structure:

SOAP Message Structure
SOAP Message Structure

SOAP Envelope

The root element of the XML packet is called the envelope. An envelope is a mandatory element in a SOAP Message. It defines a namespace ending with soap dash envelope. And associates it with a namespace prefix. The prefix can be anything. In some examples, we have seen it named soap, in other others soapenv, or as in this example, just env. What’s important, is that it points to the correct namespace, that identifies the version of SOAP that’s being used.

SOAP Message Header

The XML envelope, defines two child elements named header and body. When we look at the schema [http://schemas.xmlsoap.org/soap/envelope/], We’ll see that there is an attribute called minoccurs, that indicates whether each is required. Zero would mean optional, meaning there is no minimum, and one means required. So, in a SOAP envelope, the header element is optional, but the body is required. If the message contains a header, it shows up as the first child element of the Envelope.

The header contains metadata, It can contain documentation about the particular soap message and any other elements a developer might like to include. Some common uses of the soap header, include API keys, or log-in credentials to validate requests, or timestamps in responses indicating when data was created, or how long it’s good for.

SOAP Message Body

The body element is required in both the request and the response envelope And it contains the actual content of either the request or the response. A request message typically defines a namespace that’s again unique to the web service being called.

The child element in the body, getStockPrice, is the name of a remote procedure that’s defined by the service. And the operation then has child elements, representing parameters that are being passed in. This operation, or procedure, has a single parameter, arg0, set to the value Google. The names of the web services procedures, and the names and data types of each procedure’s parameters, are defined in the service’s WSDL document.

The response message also has a route envelope element. Like the request, it declares a namespace indicating the SOAP version and the body has a namespace that’s unique to the web service. These should always match the namespaces in the request. If the call to the remote operation succeeds, the response message can be as simple as an envelope that contains a body. And then resulting data within the body.

In this example, the response is an element named getStockPriceResponse. That element contains a child element named return, which contains the resulting numeric value. As with the request, the data type of that value, whether it’s a string, integer, float or other. Is defined in the service’s WSDL document.

SOAP Message Fault

If the request fails for any reason, the server sends back a response containing a Fault element which is a child element of the body. The body typically contains either valid response data or a fault, but not both.

In SOAP, the Fault element has a number of child elements with fixed names, including Code, Reason, Role, and Detail. These are the names of the elements in SOAP 1.2. In SOAP 1.1, they’re somewhat different. The Code value can be one of a number of fixed values. In SOAP 1.2, the value sender means that the client sent a malformed request message, that had an error, such an unrecognized operation name, or incorrect data types. But it can also be receiver.

That’s all for SOAP Message, Hope you like it, Keep reading and sharing !! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *