axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Marvin" <...@it-innovation.soton.ac.uk>
Subject RE: Accessing context for a web service call
Date Fri, 28 May 2004 14:37:03 GMT
Hi Glen,

Thanks for this. I think my approach is very similar to (3) except that
it does not use the MessageContext and instead provides a single
ServiceContext object. The ServiceContext object is populated by
handlers exactly as you suggest and again the actual header parsing
implementation can be swapped out so loose coupling is maintained.
Options (1) and (2) both involve quite complex manipulations to obtain
information so I would like to avoid them if possible.

I have to admit that since the getCurrentContext call is static I
thought the returned MessageContext was not specific to a request.
However digging deeper into the AxisEngine I now realise that this call
will return a separate MessageContext for each request call. I should be
able to use this.

I guess the real value of my ServiceContext object is that it starts to
define a simple API for accessing threes groups of things:

(1) EScienceContext - this is a simple API object that gives convenience
access methods to things like the distinguished name of authenticated
remote user (it shortcuts through all the WS-Security details)
(2) Infrastructure - this provides access to infrastructure services
that might exist at the site e.g. Authorisation services
(3) WSContext - this provides access to APIs for standard SOAP headers
e.g. WSSecurity headers. At the moment I supply an object based API for
WSSecurity headers only.

Of course I can put this ServiceContext into the MessageContext and
retrieve it. I think I will move to this approach very soon. Thanks very
much for the insights.

The third part of my API is possibly of interest to Apache 
Axis if Apache plan to produce implementations of emerging web service
specifications e.g. WSS4J. Libraries for accessing and manipulating
header information will presumably become important for service
developers in the near future. I imagine people will quite like to see
WS-Addressing APIs eventually for example. I would like to get involved
in this if I can - I will have to address WS-Addressing soon anyway and
would prefer to do this as an open contribution. Another thing I need
soon is WSSecurity support of Axis C++. What opportunities exist for
developing these within Apache and how should I go about doing it? I
know that dims started out on sourceforge initially.

Anyway thanks for your comments.

Darren.


> -----Original Message-----
> From: Glen Daniels [mailto:glen@thoughtcraft.com] 
> Sent: 27 May 2004 17:06
> To: axis-dev@ws.apache.org
> Subject: RE: Accessing context for a web service call
> 
> 
> 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