axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Graham" <sggra...@us.ibm.com>
Subject RE: AxisEngine framework
Date Fri, 20 Apr 2001 19:15:57 GMT
Handler state is a tricky situation.  Without going into the issues, I
might recommend that this counter situation could be solved by saving state
using out of band means (ie using a database or persistent store to
maintain state).

sgg

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
Web Services Architect
Emerging Internet Technologies
++++++++


Dirk Reinshagen_C <DReinshagen_C@zaplet.com> on 04/20/2001 01:15:55 PM

Please respond to axis-dev@xml.apache.org

To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:  RE: AxisEngine framework



I don't understand why the scenario of providing authentication
on one of the listeners requires a whole new SOAP engine.
Why not have two different listeners, but only one engine.
The listener that needs authentication could perform it or
maybe the listener could add to the chain that the engine
processes, i.e. one listener adds an authentication handler to
the chain for a service where a different listener does not.

One of the problems I see with going with a multiple engines
approach (besides adding complexity) is that for handlers that
want to maintain some state information, the state won't be
shared across different engine instances.  For instance, if
I have a handler that is a counter that each time it receives a
request it increases the count.  I won't have a reliable count
if I have two engines because the state is in two different
engines instance of that handler class.

Dirk


-----Original Message-----
From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Friday, April 20, 2001 4:05 AM
To: axis-dev@xml.apache.org
Subject: Re: AxisEngine framework


We will need to work through scenarios.  As you said, in the most simple
case, the deployment engineer will not have to specify a particular axis
engine.
This implies then, that there are more complicated cases when there is a
need for the deployment engineer to specify which engine to deploy to.
Are you thinking the possibility of having a two tier registry of handlers
and services?  First tier is shared amongst all instances of axis engine,
second tier is specific to a particular axis engine?

sgg

++++++++
Steve Graham
sggraham@us.ibm.com
(919)254-0615 (T/L 444)
Web Services Architect
Emerging Internet Technologies
++++++++


"Ryo Neyama" <neyama@trl.ibm.co.jp> on 04/20/2001 01:38:31 AM

Please respond to axis-dev@xml.apache.org

To:   <axis-dev@xml.apache.org>
cc:
Subject:  Re: AxisEngine framework



Hello Steve,

Yuichi said almost all of what I wanted to say.
Multiple AxisEngines means separating the services deployed to the engine.
Of course, the default AxisEngie should be available so that deployment
enginieers don't have to specify the engine in the most simple case.

Regards,
    Ryo Neyama @ IBM Research, Tokyo Research Laboratory
    Internet Technology
    neyama@trl.ibm.co.jp

----- Original Message -----
From: "Yuhichi Nakamura" <NAKAMURY@jp.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Thursday, April 19, 2001 10:37 AM
Subject: Re: AxisEngine framework


>
> Hello Steve,
> Our initial motivation is to utilize platform
authentication/authorization
> mechanisms
> in Axis.  Assume that you have two servlet instances, each of which has a
> different
> authentication policy, i.e. one product search for any user, the other
> ordering for
> registered users.  Users are authenticated by the platform, so it is not
> meaningful
> to handle both requests in a single engine (because you have to get the
> user info.
> again).  In this case, we may want to have completely different
components
> (say
> AxisEngines in Ryo's mail, I am not engine is a good term here).
> In this case, the deployment enginee configures security policy at the
> platform level.
> Off course, if you want to set up fine-grained access control, you should
> provide
> authorization handler.  My point here is that we should consider both
> platform-level
> and application-level authentication, and combine them properly.
> To me, single engine approach only addresses the application-level
> authentication.
> So the benefit is that configration should be much simpler when you only
> need
> coase-grained security (in most cases, this is enough).
>
> BTW, if we assume multiple engines in a single JVM, what impacts do we
> expect
> in the current code base?  To the best of my knowledge, not so much.
>
> Best regards,
>
> Yuhichi Nakamura
> IBM Tokyo Research Laboratory
> Tel: +81-462-73-4668
>
>
> From: "Steve Graham" <sggraham@us.ibm.com> on 2001/04/18 21:29
>
> Please respond to axis-dev@xml.apache.org
>
> To:   axis-dev@xml.apache.org
> cc:
> Subject:  Re: AxisEngine framework
>
>
>
> Ryo:
> This is interesting.
> Do you imagine how a deployment engineer would deploy his service to this
> environment?
> If I have multiple Axis Engines within a single JVM, would there be any
> reason/benefit to specify which engine I wish to deploy my service?
> Or would I deploy my service to this environment, and therefore be
> available to any and all Axis Engines running within the JVM?
>
> sgg
>
> ++++++++
> Steve Graham
> sggraham@us.ibm.com
> (919)254-0615 (T/L 444)
> Web Services Architect
> Emerging Internet Technologies
> ++++++++
>
>
> "Ryo Neyama" <neyama@trl.ibm.co.jp> on 04/18/2001 03:47:25 AM
>
> Please respond to axis-dev@xml.apache.org
>
> To:   <axis-dev@xml.apache.org>
> cc:
> Subject:  AxisEngine framework
>
>
>
> Hello,
>
> I will provide an Axis framework that enables more than one Axis or
remote
> references to AxisEngine on a single Java VM.
>
> So far, only one local AxisEngine in an web application is assumed.  This
> indicates that it is hard to clearly separate the domain of service
entries
> registered in the AxisEngine.  I think, however, it is not so good from
the
> security's and flexibility's point of view.  As for security, it is
> possible
> that a service might be called illegally against user's intention due to
> the
> wrong ACL to the deployed services.  As for flexibility, in the current
> implementation the servlet and the engine are tightly coupled in the same
> Java VM.
>
> I'm not sure if there is consensus on this idea, so I hope we can discuss
> on
> this.
>
> Anyway, when I complete prototyping at some level, I will commit the code
> to
> the CVS repository.
>
> Regards,
>     Ryo Neyama @ IBM Research, Tokyo Research Laboratory
>     Internet Technology
>     neyama@trl.ibm.co.jp
>
>
>
>
>
>
>
>





Mime
View raw message