axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Accessing context for a web service call
Date Sat, 29 May 2004 15:42:03 GMT
Darren,

Please see URL's below:

http://ws.apache.org/ws-fx/addressing/
http://ws.apache.org/ws-fx/wss4j/

join the dev list fx-dev AT ws.apache.org (by emailing
fx-dev-subscribe AT ws.apache.org)

-- dims

On Fri, 28 May 2004 15:37:03 +0100, Darren Marvin
<djm@it-innovation.soton.ac.uk> wrote:
> 
> 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