axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Illsley <david.ills...@uk.ibm.com>
Subject Re: [Axis2] Pluggable Target Resolution
Date Fri, 21 Jul 2006 15:00:14 GMT
Sanjiva Weerawarana <sanjiva@opensource.lk> wrote on 07/21/2006 03:44:54 
PM:

> I must be missing something .. what's the diff between this and
> dispatchers?
> 
> Sanjiva.

I shouldn't have said 'dispatched to', that was sloppy use of terminology. 
The idea here is that the service may be hosted on multiple servers with 
different addresses (including potentially the local machine) and the 
actual network target that the message will be _sent_ to needs to be 
determined.

Thus this would be used before a message is sent over the wire to finalise 
which target (server) to send the message to whereas the dispatchers 
determine which AxisService/AxisOperation object a received message should 
be associated with.

David

> On Fri, 2006-07-21 at 12:41 +0100, David Illsley wrote:
> > I'm trying to embed Axis2 into a clustered environment and have found 
that 
> > the code doesn't neatly fit into the existing extensible handler 
chain.
> > 
> > The scenario I'm trying to support is non-Axis2 code which can decide 
to 
> > override the target address which is dispatched to based on some 
> > clustering information. This could either recognise that the address 
is 
> > local, allowing a local optimisation or decide to workload balance to 
> > another member of the defined cluster.
> > 
> > This doesn't really fit into the handler chain because the decision on 

> > which transport to use is (and should be) taken before the handler 
chain 
> > is selected and invoked. This is important because it allows different 

> > chains to be executed depending on the transport - e.g.a local-only 
> > transport might not need to encrypt the message.
> > 
> > In order to support this scenario I'm proposing that we add pluggable 
> > TargetResolvers. They would be registered in axis2.xml and be 
available 
> > from the AxisConfiguration object. The OperationClient would then 
invoke 
> > the chain prior to selecting the transport and invoking the AxisEngine 

> > (and hence the handler chain). This would also be done in the 
> > MessageReceivers prior to the AxisEngine.send() so any non-anonymous 
> > ReplyTo is treated properly.
> > 
> > A TargetResolver would simply be passed the MessageContext which it 
could 
> > then modify appropriately.
> > 
> > Thus we'd have:
> > 
> > interface TargetResolver{
> >         /**
> >          * resolveTarget examines the MessageContext and updates the 
> > MessageContext
> >          * in order to resolve the target.
> >          */
> >         void resolveTarget(MessageContext mc);
> > }
> > 
> > an additional section in axis2.xml looking like:
> > 
> > <targetResolvers>
> >   <targetResolver name="LocalOptimisationResolver" class="..."/>
> >   ...
> > </targetResolvers>
> > 
> > and a new method on AxisConfiguration:
> > /**
> >   * getTargetResolverChain returns and instance of
> >   * TargetResolver which iterates over the registered
> >   * TargetResolvers, calling each one in turn when
> >   * resolveTarget is called
> >   */
> > public TargetResolver getTargetResolverChain();
> > 
> > I'll have code for this ready in a few days.
> > Questions/Comments?
> > David
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message