Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 88842 invoked by uid 500); 12 Mar 2002 14:00:36 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 88811 invoked from network); 12 Mar 2002 14:00:36 -0000 Importance: Normal Sensitivity: Subject: Re: Interceptor architecture? To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Russell Butek" Date: Tue, 12 Mar 2002 07:59:00 -0600 X-MIMETrack: Serialize by Router on D04NMS23/04/M/IBM(Release 5.0.9a |January 7, 2002) at 03/12/2002 09:00:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Tom, read the handlers section of the architecture guide. Your solution might be to implement a handler. Russell Butek butek@us.ibm.com Tom Oinn on 03/12/2002 03:09:58 AM Please respond to axis-dev@xml.apache.org To: axis-dev@xml.apache.org cc: 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