Sunday, March 13, 2011

Web Service Addressing Mechanisms

    Any web service request from a client to a service goes through the process defined below at the server-side:

  1. The request is received by a Servlet (for a HTTP request)
  2. The Servlet identifies which Endpoint to call (using a strategy mapping)
  3. The Servlet identifies which method/operation in the endpoint to call (using same/alternative strategy)
  4. The Incoming request XML is un-marshaled into an Object (method parameters)
  5. The method is invoked using the parameters from step 4



When we are using a web service framework/toolkit, all of the steps identified above (i.e. step a to step e) are configurable through code/configuration files. The 2 major configurable/customizable feature that are generally provided by any framework are

  1. Addressing System – (step b and c)
  2. Marshalling System (step d)
We limit our discussion to the addressing system in this article and leave the marshalling system for discussion in a later article.

Addressing is the process of identifying the endpoint when a web service request is received by a server/service. In the case of rpc/literal (refer here) this identification is comparatively simpler since the operation name is already available in the incoming request. In the case of document/literal the task gets a lot more challenging since the incoming soap request contains a document alone(which may or maynot have any direct relation to the endpoint/method) and identification of an operation is difficult. In such a case the identification of the operation is determined by some strategy which is commonly known as addressing strategy. Few of the commonly used strategies are discussed below:

    In the above example, the servlet shown in the figure above would be mapped to /* URLs and receive all incoming requests. Once the request is received, based on the URL it would identify which Endpoint and which operation does it invoke.

  • SOAPActionBasedAddressingStrategy
    – In this strategy, the endpoints are mapped to the incoming 'soapAction' value (present in the header of the protocol of the request e.g. HTTP Header). This value could be pre-decided and mentioned in the WSDL (soap:action tag). Since the 'soapAction' value can be different for different method invocations, the method identification (step c) can be resolved using this method also. It should be noted here that soapAction attribute is not supported under SOAP specification 1.2. Hence this approach is applicable only as long as we use SOAP 1.1.


  • PayloadRootQNameAddressingStrategy
    – In this strategy (most commonly used for document-wrapped style) the operations/endpoints are identified by using the PayloadRootQName of the incoming request. PayloadRootQName signifies the Fully Qualified Name (namespace with tag) of the root tag of payload (the contents of the SOAP Body).
    Example:
     <soap:Body>  
       <tns:DocumentRoot xmlns:tns="http://example.com/document" >  
        <tns:SomeContent>…</tns:SomeContent>  
       </tns:DocumentRoot>  
     </soap:Body>  
    
In the above example the PayloadRootQName would be {http://example.com/document}DocumentRoot. The system can map such unique QNames to specific methods in endpoints or endpoints with pre-defined methods.



  • WS-AddressingBasedStrategy – WS-Addressing specifies a transport neutral routing mechanism based on a 'To' and 'Action' tag present in the SOAP:Header. The 'To' tag identifies the destination (the endpoint) and the 'Action' tag signifies the operation (the method). This combination is used to identify step b and step c. Both these data can be specified in a WSDL (through the usage of wsa tags) to communicate to a client. The biggest advantage of using ws-addressing is that it is an industry standard specified by WS-I for promoting inter-operability.
    Example:

     <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"  
     xmlns:wsa="http://www.w3.org/2005/08/addressing">  
     <SOAP-ENV::Header>  
      <wsa:MessageID>urn:uuid:21363e0d-2645-4eb7-8afd-2f5ee1bb25cf</wsa:MessageID>  
      <wsa:ReplyTo>  
       <wsa:Address>http://example.com/business/client1</wsa:Address>  
      </wsa:ReplyTo>  
      <wsa:To S:mustUnderstand="true">http://example/com/fabrikam</wsa:To>  
      <wsa:Action>http://example.com/fabrikam/mail/Delete</wsa:Action>  
     </SOAP-ENV:Header>  
     <SOAP-ENV:Body>  
      <f:Delete xmlns:f="http://example.com/fabrikam">  
       <f:maxCount>42</f:maxCount>  
      </f:Delete>  
     </SOAP-ENV:Body>  
     </SOAP-ENV:Envelope>  
    

In the above example, each unique Action is mapped to an operation.

In all the above discussed strategies, it is the responsibility of the Server Side toolkit (Axis or JAX-WS or Spring-WS) to use some form of metadata (annotations or xml file) to create a map of "strategy value versus the operation/endpoint" and invoke the correct method when a particular request is received by the toolkit. Once the proper method is identified, the toolkit can then go on to un-marshal the incoming request and invoke the identified method. It should also be noted, that there is no sure shot formula in addressing strategy to decide which has to be applied when. The choice of a strategy id decided based on a number of considerations which includes

  • Which version of SOAP we are using?
  • Which strategies are supported by our framework?
  • What level of scalability and complexity is needed?
Most of the above considerations decide finally what kind of addressing strategy is adopted.However this is not the only consideration, often a number of other considerations such as technical viability, development time and cost of development take precedence.

No comments:

Post a Comment