Architecture of SOAP XML

The internal architecture of SOAP can be divided into three components, as shown in the following list:

  • The SOAP message
  • The SOAP remote procedure calls (RPCs)
  • The SOAP encoding rules

The following section discusses these components in detail.

The SOAP Message

A SOAP message is a one-way communication from a sending application to a receiving application. The message might contain the request for data from the receiving application. When the request is processed, the result of the request is retuned as another SOAP message. Therefore, several SOAP messages are combined to allow communication between applications that are present on remote computers. This implies that SOAP messages follow the request-response format as depicted in Figure.

The SOAP message is an XML document that contains the data to be transferred. This data is transferred using several network protocols, such as FTP and HTTP. The data to be transferred is internally stored within the components of the SOAP message. These components are as listed:

  • Envelope
  • Header
  • Body

The components of a SOAP message are shown in Figure.

components of a SOAP Message.

components of a SOAP Message.

As you can see in Figure, Envelope forms the root element of the SOAP message. The Header and the Body components are child elements of the Envelope element. The following sections discuss the components of the SOAP message in detail.

Envelope

As the name suggests, the SOAP envelope is a framework of the SOAP message. It contains the essential information about the messages that are sent using SOAP. The SOAP envelope is, therefore, a mandatory component of the SOAP message. This information might include the content or data stored in the message. In addition, the SOAP envelope contains information about the sending application and the receiving application. This information is included in the Envelope element shown in the following syntax:

To understand the data stored in the SOAP envelope, consider the following code, which is an example of a simple SOAP message that demonstrates a function call by passing parameters to it:

The response of the preceding code sample is as shown:

The envelope namespace is included to define the structure of the Envelope, Body, and Header elements of the SOAP message. Figure shows the envelope namespace, represented by the alias SOAP-ENV.

The Envelope Namespace.

The Envelope Namespace

In addition, the SOAP message might include another namespace as shown:

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

Including the encoding namespace in your SOAP message indicates that the text in the body of the SOAP message follows the encoding rules. These rules are defined in the SOAP package. The encoding namespace is shown in Figure.

The Encoding Namespace.

The Encoding Namespace

Note?/td>
It's essential to include the envelope namespace in all SOAP messages. However, including the encoding namespace is optional.

These namespaces point to XML schemas; therefore, they are included in a SOAP message to validate it. The SOAP messages are validated according to the rules that are defined in the XML schemas.

To include a namespace in a SOAP message, you first need to create an element, Envelope. You can include additional attributes in the SOAP envelope. You can also include other namespaces and subelements in the SOAP message by declaring them in the Envelope element.

In addition to namespace declaration statements, a SOAP message includes the serialization rules that are used to define the SOAP message. The serialization rules are defined in the encodingStyle attribute. The value of this attribute is the URI address of the namespace that defines the serialization rules. An example of such a namespace is the encoding namespace discussed earlier.

Header

In addition to the Envelope element, a SOAP message includes the Header element. Header is an optional element that is used as a generic location to provide information in a SOAP message. The information that is included in the Header element is provided in a decentralized manner and is represented by the Header element. The syntax for the Header element is shown in the following code sample:

Note?/td>
The Header element is optional. In a SOAP message, you can include as many Header elements as required. However, the Header element should be an immediate child of the Envelope element. Therefore, the structure of the Header element should be as follows:

The Header element includes information about how the receiving application should process the SOAP message. This information is represented in the form of elements of the Header element. These elements must be fully qualified and include a namespace, which is identified by a URI and a local name.

An example of the Header element is shown in the following code sample:

The Header element might include several subelements. However, the Header attribute applies to only its immediate subelement. Consider a situation in which a SOAP message includes a Header attribute with two subelements, as shown in the following code:

In this case, the first Header element applies only to the currency sub element and not to the country sub element, which is not the immediate sub element of the Header element.

A SOAP Header element can include several attributes to define the information in the Header element. These attributes are explained in the following list:

  • mustUnderstand attribute. The must understand attribute of the Header element specifies whether it is mandatory for the receiving application to process the Header element. This attribute takes a Boolean value. A value of 0 indicates that it is not essential that the receiving application process the Header element. However, if the mustUnderstand attribute takes the value of 1, it is essential for the receiving application to process the Header element. The Header element is processed according to the encoding rules defined in the namespace that you include in the Header element.
  • actor attribute. When a SOAP message is passed from a sending application to a receiving application, the message might pass through one or more intermediary applications. Therefore, to indicate whether the application that receives the SOAP message is the final application or an intermediate application, you can include the actor attribute in the Header element. An example of the actor attribute is shown in the following code:
  • <SOAP-ENV:Header http://schemas.xmlsoap.org/soap/actor/next>
  • ---------
  • </SOAP-ENV:Header>

As you can see, the preceding code includes a URI . This URI indicates that the receiving application is the intermediate application that needs to forward the SOAP message to another application.

  • encodingStyle attribute. The encodingStyle attribute specifies the serialization rules that you can use to encode the Header attribute. These rules that are defined in the encodingStyle attribute apply to the Header attribute and all its subelements. The value of the encoding Style attribute is the URI of the namespace that defines the serialization rules.

Body

A SOAP message includes a mandatory Body element that contains the main text of the message. All data that needs to be transferred in the SOAP message forms a part of the Body element. The body element is denoted by the Body element, which is the child element of the Envelope element. The syntax of the Body element is as shown:

To define the text in the Body element, you can include subelements. The text is encoded in the Body element by using the encoding Style attribute. In addition, the Body element might include a Fault element. This element is used to send the status information or any error message with the SOAP message.

An example of the Body element is as shown:

SOAP Serialization

When a SOAP message is transferred over the network, you must ensure that the message is in the format that the receiving application can easily understand and interpret. This implies that you need to serialize the content of the Header and Body elements of the SOAP message in the format that the receiving application understands. To do this, you can use the System.XML. Serialization namespace, which serializes data to an XML document. Most applications can understand an XML document that is being text based. You can include this XML document in the Body element of a SOAP message to be transferred over the network.

Formats for Serializing SOAP Messages

The SOAP specification supports two formats of serializing SOAP messages, as discussed in the following list:

  • Literal format. In this type of serialization, data is serialized based on the XML schema or XSD. Therefore, the interacting applications deal with the data in the form of XML documents instead of objects and structures. However, in literal format, no special rules of serializing data are followed.
  • Encoded format. In this type of serialization, data is serialized according to some special encoding rules that are defined in the SOAP specifications. These rules define how specific objects, structures, arrays, and so on should be serialized. Unlike literal format, in the encoded format, the interacting applications deal with structures and objects.

Styles of SOAP Messages

The SOAP specification defines two styles in which you can format a SOAP message. These formats are discussed in the following list:

  • Document style. In this style, the SOAP Body element contains one or more child elements called parts. However, the specification does not specify rules for including the child elements in the Body element. It can include any data that the sending application needs to send to the receiving application.
  • RPC style. In this style, the Body element includes the methods or remote procedures that you need to call. In addition, the Body element includes the parameters that the remote procedures accept.

Note?/td>
The Microsoft SOAP Toolkit uses RPC/encoded SOAP messages by default. When you're using .NET, you can expose Web services in two ways: Remoting and .NET Web services. Remoting uses RPC/encoded SOAP, whereas .NET Web services, designed for document exchange via messaging, use the document/literal SOAP by default.

The SOAP RPC

Consider a situation in which you need to call a procedure that is located on a remote computer. While calling the procedure, you need to pass parameters to the procedure call statement. The process of calling a procedure from a remote computer is called RPC.

The request for the procedure can be made using SOAP in the form of a SOAP message. This message includes the request or the response of the request. To define the manner in which the messages are exchanged, a specification called the RPC convention is developed. The RPC convention defines a set of rules that you can use to serialize the procedure calls in the form of a SOAP message.

As discussed earlier, SOAP is based on a request-response format. Therefore, when you need to call a remote procedure, you send in a request. The statement used to request the remote procedure is called a call statement. When the request is processed and the response is returned, this response is called the result of the call statement. Figure explains the RPC procedure in detail.

The RPC Procedure.

The RPC Procedure.

The following sections discuss the call and result statements.

The call Statement

To call a remote procedure by using SOAP, you need to create a SOAP message that includes the call statement. The call statement is an XML statement that includes a struct that makes a serialized call to the required procedure. The parameters of the required procedure are sent as child elements of the struct.

After a call statement is written, it is serialized in the form of an XML message, whose elements define the procedure and its parameters. Therefore, the name of the elements should correspond to the name of the procedure and its parameters. Consider the following example of a procedure that is used to change the case of a string. The string is passed as a parameter to the procedure:

void ChangeCase([in] string str, [out] string str1);

To call the ChangeCase procedure, you need to use the following call statement:

The preceding code calls the ChangeCase procedure and passes a string type parameter to the method call statement.

Note?/td>
The preceding code uses a namespace that is represented by the hypothetical URL http://www.wisdomjobs.com/.

The result Statement

The result statement includes the processed result of the call statement. Similar to the call statement, the result statement also includes a struct and the value that the procedure returns. However, unlike the struct in the procedure call statement, the struct in the result statement can be assigned any name.

Tip?/td>
As a convention, the name of the struct in the result statement is followed by the word Response. For example, the struct in the result statement for the ChangeCase procedure can be called ChangeCaseResponse.

The following code shows the response to the call statement for the ChangeCase procedure:

The preceding code sends a response to the call statement after processing the request. The string type value, soap, that the ChangeCase procedure returns is an output parameter and is defined by the same name: str1.

The SOAP Encoding Rules

When you create a SOAP message, you need to adhere to a set of rules to encode theSOAP message. This set of rules is defined in the SOAP specification and is called SOAP encoding. The SOAP encoding rules are similar to XML schemas and define the types and constructs that you can use to create the SOAP message. These rules are present in the encoding namespace. The URL of the encoding namespace refers to the XML schema that defines the encoding rules for a SOAP message. The URL of the encoding namespace is http://schemas.xmlsoap.org/soap/encoding/.

Types of Data Types

The encoding rules specify the types that you can include in a SOAP message. These data types can be either simple or compound. The following section discusses the simple and compound data types.

The Simple Data Type

The data types that are specified in the XML Schema Specification are called simple types. Therefore, a simple type either is defined in the XML Schema Specification or derived from the data type that is defined in the XML Schema Specification. The simple data types that you can use in a SOAP message are integer, float, negativeInteger, string, date, and so on. These built-in data types are defined in the namespace XMLSchema.

The Compound Data Type

Compound data types are created using one or more simple data types. Compound data types contain child elements that define the elements or the fields of the data type. SOAP encoding supports two types of compound data types: structs and arrays. The following list discusses these data types in detail:

  • Struct. A struct is a collection of variables with the same or different data types. However, the name of the variables that are defined in a struct cannot be the same. Consider the following example of a construct, Student.

To invoke this struct, you need to create an instance as shown:

Student std = {"S001", "Daniel", "Smith", "10932 Bigge Rd.",15};

Now you can serialize the struct Student by using the SOAP encoding rules, as shown in the following code:

In the preceding code, a struct called Student is declared. In addition, a namespace, n, is declared with a Student data type. The n namespace points to the schema that defines the Student struct.

  • Array. An array is a compound data type that ontains values with the same data type. These values are referred to by their index value. To declare a data type of the type array, you need to use the xsi:type attribute. The value of this attribute is SOAPENC: Array. Consider the following example of an array, scores:

The preceding code creates an array called scores. The data type of the array is integer, which is specified by the arrayType attribute. The values are assigned to the scores array by using the item attribute.

Having looked at the types of data types, you will now learn about the rules for encoding data types in a SOAP message.

Rules for Serializing Data Types

The rules for serializing data types are discussed in the following list:

  • You can define values in a SOAP message by using elements.
  • You can define simple values as character data without subelements.
  • You can define compound values as a sequence of elements.
  • You can define arrays as single-reference or multi-reference values.
  • You can declare arrays as compound values by using the SOAP-ENC:Array attribute.
  • You can define the data type of an array by using the SOAP-ENC: arrayType attribute.
  • You can define string and byte arrays as multi-reference simple types.
  • You can encode several references to a value. However, you should not alter the meaning of the XML instance.

Until now, we have discussed the architecture of SOAP. Now we will discuss the processing of SOAP messages.



Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

XML Topics