Hi Tom!
What you're proposing is precisely the point of the whole Axis Handler system. Axis allows you to specify per-service or global "request flows" which are Handlers that get access to the current message processing context (represented by a MessageContext object) and are free to read/edit the message, get/set arbitrary context properties, or fault and cease processing. Check out the docs. --Glen > -----Original Message----- > From: Tom Oinn [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 12, 2002 4:10 AM > To: [EMAIL PROTECTED] > Subject: Interceptor architecture? > > > Hi, > > I was wondering how easy it would be to incorporate an interceptor > system into axis, or whether anyone else was already considering doing > so? > > The problem I am trying to solve is as follows: > > We are a research institute, and as such consist of many different > groups, these are almost totally independent in terms of > coding styles, > standards etc. For anyone who's curious, we are the main bioscience > resource hub for europe, the page www.ebi.ac.uk gives some idea of the > problems we're trying to solve as a whole. > > We are trying to sort out some central policy for exposing > our resources > as web services, included in which is a security and load balancing > policy that we would like to apply to all exposed services. > However, if > we were to require all the component services to implement > this it would > be a nightmare; herding cats has nothing on trying to get an institute > full of academics to code to a standard :) > > Soooo... it would be good if we could implement the access control > components independently of the services. The GLUE tool kit allows > something like this but I am not terribly keen on it for many other > reasons, so am investigating the alternatives. We would like to end up > with a model where we can write a request interceptor, which then has > access to parameters of the request (some of which are transport > specific, such as the ssl principal) and can optionally modify or veto > the request altogether, sending a suitable exception message > back to the > client. > > I'm happy to implement or assist with the implementation of this if > people think that it's something that's feasible to do? > > Cheers, > > Tom Oinn >
