| In this section we will see how XML Web service messages are packaged and enveloped. The most notable mechanism available is SOAP. However, we must be aware that this is not the only enveloping mechanism available for Web services. There are other technologies available including BEEP, [10] HTTP, [11] and IIOP. [12] For example, we could send XML messages over HTTP operations (GET/POST/PUT/DELETE, etc.), which provide some basic enveloping constructs. Since SOAP is the most prominent for XML Web services, we will concentrate our discussion on that protocol and its supported extension mechanisms. SOAP SOAP [13] is a simple and lightweight XML-based mechanism for creating structured data packages that can be exchanged between network applications. Our discussion on SOAP is based on the latest SOAP specification, SOAP 1.2, which passes the recommendation criteria of the W3C organization. The SOAP specification defines the following fundamental components : -
An envelope that defines a framework for describing message structure -
A set of encoding rules for expressing instances of application-defined data types -
A convention for representing remote procedure calls (RPC) and responses -
A set of rules for using SOAP with HTTP -
Message exchange patterns (MEP) such as request “response, one-way, and peer-to-peer conversations SOAP can be used in combination with a variety of network protocols, such as HTTP, SMTP, BEEP, FTP, and RMI/IIOP. As we have noted from previous implementation of Web services, SOAP is currently being used as the de facto standard for XML messaging including enveloping and exchanging messages. SOAP provides a simple enveloping mechanism and is proven in being able to work with existing networking services technologies, such as HTTP. SOAP is also very flexible and extensible. It provides capabilities to add-on standards and application-defined extensions. The wide acceptance of SOAP is based on the fact that it builds upon the XML infoset. The format of a SOAP message is formally defined in SOAP 1.2 Part 1; specifically , the Messaging Framework specification. [14] Figure 5.6 illustrates a simple SOAP message structure, as defined by this specification. Figure 5.6. SOAP message formats.  As illustrated in Figure 5.6, a SOAP message is packaged in a SOAP:Envelope, which consists of zero or more SOAP:Header and exactly one SOAP:Body. The SOAP body and header can be further divided into blocks. While the SOAP body blocks are intended for the final receiver, the header blocks can be interpreted by the SOAP intermediaries. Figure 5.7 illustrates such a message exchange pattern. Figure 5.7. SOAP intermediaries.  The SOAP header blocks carry information such as security, transactional information, correlation, and so on. These intermediaries may act on these header blocks, add more blocks, change them, or leave them untouched. These header blocks can be targeted to some intermediary or final receiver by the use of "roles" attributes ("actors" in SOAP 1.1). The value (specified by URI) of the "roles" attribute can be an address or a standard role name as defined by the SOAP specification, which are: -
" next " ” each SOAP intermediary and the ultimate receiver must act on this role -
"none" ” the SOAP nodes must not act in this role -
"ultimateReceiver" ” the ultimate receiver must act in this role A sample SOAP message with roles is defined in Listing 5.1. Listing 5.1. Sample SOAP message with roles. <?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <a:firstheaderBlock xmlns:a="http://ph.com" env:role="http://ph.com/example/role"> ... </a:firstheaderBlock> <q:secondBlock xmlns:q="http://ph.com" env:role="http://www.w3.org/2003/05/soap-envelope/role/next"> ... </q:secondBlock> </env:Header> <env:Body > ... </env:Body> </env:Envelope> Here <a:firstheaderBlock> is targeted to SOAP nodes who are acting on the role http://ph.com/example/role, whereas the <q:secondBlock> must need to be processed by all SOAP nodes in the path , and finally by the ultimate receiver. If no "role" is specified, it is assumed for the ultimate receiver. We must be cautious in the distinction of these roles, in that we must identify the actor on a message header for the correct processing of the message. There are two other attributes that we must combine with the "role" attribute. They are "mustUnderstand" and "relay." We will note the details in the processing model in the following section. Thus far, we are discussing topics regarding the format of the message. However, SOAP is much more than simply a message format, it also provides a simple framework for extensible messages and message processing features. The SOAP Processing Model The processing of a SOAP message is dependent on the role assumed by the processor. As we have mentioned above, the SOAP headers are targeted using a "role" attribute. If the SOAP intermediary plays the role as defined by the SOAP message, it can then process the message. There are two options related to processing. If the SOAP header is targeted to this node and specifies a "mustUnderstand" flag set to "true," then the processing node must process that header. If there is no such requirement (i.e., mustUnderstand flag is not set), it is up to the processing node to decide on the processing of the message. Once the processing is completed, the message will be directed to the next node. The decision on the next node selection is not specified by the SOAP specification. Therefore, it is now the choice of the processing node to make such a decision. However, there are some standards that exist to specify common routing mechanisms, such as WS-Routing [15] and WS-Addressing. [16] Another interesting aspect of this message-forwarding paradigm is the concept of relaying SOAP headers. A header can have a "relay" attribute value (i.e., true or false) to indicate that nonprocessed headers get forwarded to the next node. The default value is "false." This indicates a SOAP node, which is targeted by this header, will not forward this header to the next node. If we refer back to the SOAP 1.1 specification (SOAP1.1), we could see that there is no standard processing rules for SOAP extensions (header) processing. This causes a number of interoperability problems. However, the SOAP 1.2 specification introduces the following core SOAP constructs in order to support SOAP extensions. SOAP Features A SOAP feature is an extension to the SOAP messaging framework. These features are common in distributed computing such as reliability, security, correlation, routing, and message exchange patterns such as request/response, one-way, and peer-to-peer conversations. Readers must be aware that this is an abstract concept with the indication that there is some processing needs to be done in the SOAP nodes but it does not specify how this processing is done. A SOAP feature has the following characteristics: -
A unique name used to identify the feature and its properties. This enables us to identify whether a SOAP node supports a specific feature. For example, if we have a feature called "secure-ssl-channel," then we can ask the SOAP nodes, including the ultimate receiver, whether they support that feature or not. -
A set of properties associated with a feature that can be used to control, constrain, or identify a feature. For example, we can see in the SOAP request “response message exchange pattern there are properties for accessing the inbound or outbound messages, the immediate sender, and next destination. It is important to understand that SOAP provides two mechanisms for implementing these features: -
SOAP header blocks. In this kind of implementation SOAP header blocks are used to specify a feature. These headers are processed by the SOAP nodes. As we have seen, the SOAP processing model defines the behaviors of a single processing SOAP node in order to process an individual message. The most common example of such a feature is the security features as defined by WS-Security specifications. -
SOAP binding protocol. In this case the features are directly implemented in the protocol binding level. For example, a binding extension to support the SOAP over SSL protocol. As we have noted, in the first case it is more protocol independent and flexible, but this may cause unnecessary processing overhead. The second case is protocol dependent and the flexibility is limited. In addition to the extensions as specified in the above cases, the SOAP specification defined a standard feature for the message exchange pattern called MEP. Let us now explore in further detail exactly how this is defined. Message Exchange Pattern One special type of SOAP feature is the MEP. A SOAP MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. Some examples of MEPs include request/response, one-way, peer-to-peer conversation, and so on. To clarify further, we could consider a special MEP, a request for proposal (RFP) MEP, where we could define a message exchange pattern for the RFP such as submitting a request to the service provider, getting a response from the provider at a later period, and other subpatterns. We can envision building these kinds of message exchange patterns. MEP, similar to other features, is implemented either as headers or using protocol bindings. A MEP may be supported by one or more underlying protocol binding instances either directly or indirectly with support from the software. This software implements the required processing to support the SOAP feature, expressed as a SOAP module. SOAP Modules The combined syntax and semantics of a set of SOAP headers are known as a SOAP module. A SOAP module realizes one or more SOAP features. This enables us to specify a more general-purpose concept such as a secure purchase order, with a combination of one or more features, including the purchase order MEP as described above, the security feature, and more. So far we have discussed message packaging, transmission, and processing in a transport in a rather independent manner. These SOAP messages can be transported through different transport bindings, such as HTTP, TCP, and BEEP. The SOAP defined some protocol bindings for its transport methods . The most notable one is SOAP over HTTP utilizing the GET and POST operations. | 