axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <g...@thoughtcraft.com>
Subject RE: Accessing context for a web service call
Date Thu, 27 May 2004 16:05:34 GMT

Hi Darren:

I think there are three ways in Axis to get what you want.

1) Use message-style with SOAPEnvelope/SOAPEnvelope

2) Use any style you want, and get at the SOAP envelope via the MessageContext:

class MyService {
  public void doSomething(int foo) {
    MessageContext mc = MessageContext.getCurrentContext();
    SOAPEnvelope request = mc.getRequestMessage().getSOAPEnvelope();
    ...
  }
}

3) Use a Handler to process the header, and then make any contextual information needed available
in the MessageContext as
well-known properties.

The first two approaches involve directly processing the message structure yourself, and the
third is really the design center for
Axis applications.  You centralize the understanding of the headers in Handler code, and then
concepts that are important beyond the
handler itself are placed with well-known names in the MessageContext.  Then you can just
have:

  public void doSomething(int foo) {
    MessageContext mc = MessageContext.getCurrentContext();
    // Look for the item that the Handler kindly put in the MC for us...
    MySpecialObject obj = (MySpecialObject)mc.getProperty(WELL_KNOWN_NAME);
  }

A nice side-effect of this is that once you have abstracted your context information into
well-known MessageContext properties, you
have decoupled your code from the specific header-parsing implementation which lives in the
Handler(s).  You can therefore switch
out a particular Handler implementation for another one, or even use an entirely different
wire-serialization which does the same
thing, and as long as the new code puts the same value in the same MC slot, you don't need
to change your service code.  Loose
coupling!

Does that help?

--Glen 

> -----Original Message-----
> From: Darren Marvin [mailto:djm@it-innovation.soton.ac.uk] 
> Sent: Thursday, May 27, 2004 11:15 AM
> To: axis-dev@ws.apache.org
> Subject: Accessing context for a web service call
> 
> Hi,
>  
> Firstly this really is not a user question but hopefully 
> points to emerging requirements for Axis functionality.
>  
> I might be wrong but I would like to describe an issue I 
> found concerning the passing of request context to a service 
> implementation. 
>  
> All the emerging WSSecurity specifications use the header to 
> store security context information relating to the SOAP 
> message. In fact most of the emerging web service standards 
> are looking to use the header to hold context information. In 
> many cases the underlying service does not need to know the 
> details of this context, it is handled by the infrastructure 
> e.g. WSS4J handlers and therefore Axis as it stands is 
> sufficient - up to now service developers have concentrated 
> on the payload of the SOAP message. However there are 
> circumstances where the underlying service might wish to 
> access context information e.g. get the distinguished name of 
> the certificate used to authenticate the message under 
> WSSecurity - this could be used for identification / 
> authorisation purposes within the service. This type of 
> contextual information is important in eScience applications 
> that are trying to enable scientific collaboration between 
> academic institutions in the UK. We at IT Innovation 
> (http://www.it-innovation.soton.ac.uk 
> <http://www.it-innovation.soton.ac.uk/> )  are working on 
> several eScience projects and have had to address this issue.
>  
> Looking at the different ways that Axis can integrate with 
> service implementations we have (according to Axis documentation) :
>  
> Document Style:
>  
> public void method(PurchaseOrder po)    
>  
> where PurchaseOrder is a bean that represents a payload 
> defined by some XML schema
>  
> Wrapped Style:
>  
> public void purchaseOrder(String item, int quantity, String 
> description)  
>  
> where some marshalling of the contents of the payload is done
>  
> Message Services:
>  
> 1) public Element [] method(Element [] bodies);
> 2) public SOAPBodyElement [] method (SOAPBodyElement [] bodies);
> 3) public Document method(Document body);
> 4) public void method(SOAPEnvelope req, SOAPEnvelope resp); 
>  
> where elements are passed directly and the underlying service 
> implementation must deal with them
>  
> So overall the only way I can see to obtain the message 
> context e.g. header information is by writing a message 
> service using the fourth method signature. Unfortunately this 
> means that I have to manipulate XML and this is not something 
> that many eScientists would like to do (they tend to be 
> chemists, physicists etc with limited computing emphasis). It 
> also seems plausible that since specifications like 
> WSSecurity are defining standard ways to attach context 
> information to a SOAP message, there should be standard APIs 
> for service developers to access context information too.
>  
> Some of you might remember a query I made to this list about 
> a month ago concerning writing my own provider 
> implementation. You might be pleased to know that I have 
> managed to do this as part of my project work at IT 
> Innovation and it is likely that it will be released as open 
> source very soon. What it does is instantiate a special sort 
> of service object that includes an object that gives access 
> to context information. I have concentrated initially on 
> providing access to WSSecurity information like the DN of the 
> authenticated remote user but my service context object can 
> be extended easily. Context information is set in the service 
> context object using normal Axis handlers. I have a basic 
> WSSecurity Axis handler that can cope with checking message 
> integrity (it uses a WSSecurity library of my own, soon to be 
> released as LGPL, but will eventually use WSS4J)
>  
> I hope I have not missed some obvious functionality provided 
> by Axis but a recent Axis Dev post concerning accessing 
> MessageContext would suggest not. In reality this type of 
> context object is similar to Servlet context objects that 
> have a standard API for accessing servlet context information.
>  
> I obviously welcome any comments and feedback. If this all 
> sounds reasonable then I am willing to supply my code as a 
> starting point for adding service context support to Axis. 
>  
> Thanks in advance,
>  
> Darren.
> 
>  
> 

Mime
View raw message