Thursday, February 24, 2011

SOAP Processing Model

    In this article we try and take a look at the SOAP Processing Model. Pre-knowledge of SOAP is a must and can be obtained here. The importance of SOAP lies in its ability to be extremely flexible and extensible. These features are provided by the SOAP Processing Model. The SOAP Processing model is the lifecycle of a single SOAP message in isolation from any other SOAP message. It does not maintain any state; perform any correlation or co-ordination between messages.



Initial Sender – The message originator
Ultimate Receiver – The intended recipient
Intermediaries – Processing blocks that operate on the soap message before it reaches the ultimate receiver.

The extensibility and flexibility in SOAP is provided because of the presence of intermediaries which in an unobtrusive manner allow SOAP messages to be processed. The intermediaries work by intercepting messages, performing their function, and forwarding the altered message to the ultimate receiver. In an implementation, intermediaries are like a listener. They intercept the message and process it and then pass it on.

Before we actually look at features like how to identify an intermediary and how to process, let us try to understand why and where does an intermediary come in the picture. Take the example that a SOAP message is being sent from Client A to Server B. Client A's company has a standard disclaimer which is appended to the header in every message. Instead of every client implementing the disclaimer addition, the company has a gateway which intercepts any SOAP message and adds to its header code in the form of disclaimer. Ex.

 <soap:Header>  
 <company:Disclaimer>All intended recipients … </company:Disclaimer>  
 </soap:Header>  


Such an interceptor could be called as an intermediary. Other common examples of intermediaries would be a logging intermediary, an encryption intermediary, a caching intermediary. Often these intermediaries may want some special input. This input can be provided in the form of targeted header blocks. To target a header block to an intermediary, SOAP provides us with an attribute called soap:actor (in SOAP 1.2 it's called soap:role). This attribute take the value of an URI which is understood by the SOAP intermediary. Ex.

 <soap:Header role=”http://mycompany.com/disclaimer” mustUnderstand=”1”>  
 <company:AddDisclaimer>true</company:AddDisclaimer>  
 </soap:Header>  


In the above example, we have added a SOAP header that can help the intermediary to decide whether the disclaimer should be added or not. To make sure that only our intermediary processes the block we have added a role attribute which tells all the intermediaries whether they are supposed to process the header block or not. Also we have added another attribute soap:mustUnderstand. This takes the value of 1 or 0 and tells if the processing of this block is mandatory for the intended intermediary (i.e. the intermediary with whom the role/actor attribute matches). There are two types of intermediaries

  1. Forwarding intermediaries
  2. Active intermediaries
I will not be going into the details of these because knowledge of intermediaries types is not of much importance to most developers except those working on SOAP implementation tollkits (i.e. creating something like Axis). The SOAP processing model however is of great importance because it lays the foundation for an extensible framework which is the base for most web service implementations like Axis and JAX-WS. The basic knowledge of the horizontal extensibility of SOAP due to the presence of intermediaries is a very important concept. There are a few other details regarding SOAP roles which are available here.

4 comments:

  1. Something i wanted know and here it is :)

    ReplyDelete
  2. Really informative

    ReplyDelete
  3. Thank you Adi! You have explained it neatly. :)

    Rajesh

    ReplyDelete