Accessing context for a web service call

[Darren Marvin <dj...@it-innovation.soton.ac.uk>]

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.

 

RE: Accessing context for a web service call

[Glen Daniels <gl...@thoughtcraft.com>]

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.
> 
>  
>