axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepal Jayasinghe <>
Subject Re: [Axis2] Pluggable Target Resolution
Date Fri, 21 Jul 2006 15:30:10 GMT
Hi David
Please see my comments below;

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.
So As I can understand you are trying to keep different handler chains
for different transports ?

In the case of receiving side (server) I dont think you will have any
problem , because when you start the transport receiver (or the server)
you can start the server with whatever the handler chain that you want
to have (create your own AxisConfiguration).

So in the receiving side I can not understand why do you want to have
TargetResolver , please correct me if I have misunderstand any.

>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.
In the case of client side , you can set the properties into options , I
mean you can set
  - targetEPR
  - TransportSender (TransportOut)  etc...

So why dont you set the required transport out into options , and you
can do that as follows;
option.setTransportOut(TransportOutDescription transportOut).

In the case of Message receiver , you have a point , but then again you
can do that by just adding a handler into chain , isn't that possible ?

As I can understand this is big architectural change in Axis2 , but I
have no objection of doing that if we really want to do that.

Thoughts .....

>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 
>         * in order to resolve the target.
>         */
>        void resolveTarget(MessageContext mc);
>an additional section in axis2.xml looking like:
>  <targetResolver name="LocalOptimisationResolver" class="..."/>
>  ...
>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.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message