You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by David Illsley <da...@uk.ibm.com> on 2006/07/21 13:41:10 UTC
[Axis2] Pluggable Target Resolution
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
Re: [Axis2] Pluggable Target Resolution
Posted by David Illsley <da...@uk.ibm.com>.
Sanjiva Weerawarana <sa...@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
Re: [Axis2] Pluggable Target Resolution
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
I must be missing something .. what's the diff between this and
dispatchers?
Sanjiva.
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
Re: [Axis2] Pluggable Target Resolution
Posted by Bill Nagy <na...@watson.ibm.com>.
Hi Sanjiva,
We were originally simply going to add a new phase into the outbound
chain, but we realized that the OperationClients (e.g. the
OutInAxisOperationClient) contain code that depends upon the EPRs being
set to determine the transport, and in the case of a wire-level async
req/rsp, to query the transport for the ReplyTo EPR. If we put the
mechanism that David is talking about after the code in the
OperationClients, then we'll run into difficulties (e.g. a request to
generate a ReplyTo would most likely cause a listening port to be opened
if one didn't already exist, which we of course wouldn't want to happen
if the invocation was actually "local".)
If you want to suggest that the transport code be moved out to a
separate phase in the chain, before which our phase could execute, then
we'd happy to make that change instead. (This still leaves us
potentially with some unnecessary cloning occurring in the AxisEngine
since the handler chains may actually be altered , but I believe that we
can deal with that later.)
-Bill
On Fri, 2006-07-21 at 23:15 +0530, Sanjiva Weerawarana wrote:
> On Fri, 2006-07-21 at 17:04 +0100, David Illsley wrote:
> > > So why dont you set the required transport out into options , and you
> > > can do that as follows;
> > > option.setTransportOut(TransportOutDescription transportOut).
> >
> > These absolutely are the properties that matter and it is easy for
> > application to set them but I'm trying to allow the targeting to be
> > transparent to the application such that they can set the destination EPR
> > and the TargetResolver can realise that the service can be satisfied by
> > another URI and rewrite the target EPR transparently. This code could be
> > put in a handler which would work if the transport can't change but this
> > precludes a local-optimisation (as by this point the listeners for an
> > async invocation will already be set up for the http transport) and also
> > precluses the idea of different handler chains based on different
> > transports.
>
> This can be done with a straight module .. I'm still not clear why we
> need to add a new programming model component for it.
>
> Why not just write a "router" module that does whatever function you
> want and inserts handlers before/after/wherever it wants? Synapse for
> example is capable of doing what you're looking for and it works simply
> as a module - there was no need to introduce anything new.
>
> Sanjiva.
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Axis2] Pluggable Target Resolution
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-07-21 at 17:04 +0100, David Illsley wrote:
> > So why dont you set the required transport out into options , and you
> > can do that as follows;
> > option.setTransportOut(TransportOutDescription transportOut).
>
> These absolutely are the properties that matter and it is easy for
> application to set them but I'm trying to allow the targeting to be
> transparent to the application such that they can set the destination EPR
> and the TargetResolver can realise that the service can be satisfied by
> another URI and rewrite the target EPR transparently. This code could be
> put in a handler which would work if the transport can't change but this
> precludes a local-optimisation (as by this point the listeners for an
> async invocation will already be set up for the http transport) and also
> precluses the idea of different handler chains based on different
> transports.
This can be done with a straight module .. I'm still not clear why we
need to add a new programming model component for it.
Why not just write a "router" module that does whatever function you
want and inserts handlers before/after/wherever it wants? Synapse for
example is capable of doing what you're looking for and it works simply
as a module - there was no need to introduce anything new.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Pluggable Target Resolution
Posted by David Illsley <da...@uk.ibm.com>.
Deepal Jayasinghe <de...@opensource.lk> wrote on 07/21/2006 04:30:10 PM:
> Hi David
> Please see my comments below;
>
> David Illsley wrote:
>
<snip />
> >
> >
> So As I can understand you are trying to keep different handler chains
> for different transports ?
That is something which has been suggested to me and which I'd like to
retain support for but it's not the point of this proposal.
>
> 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.
Nope, nothing to currect, I'm not suggesting it be used on the receiving
side.
>
> >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).
These absolutely are the properties that matter and it is easy for
application to set them but I'm trying to allow the targeting to be
transparent to the application such that they can set the destination EPR
and the TargetResolver can realise that the service can be satisfied by
another URI and rewrite the target EPR transparently. This code could be
put in a handler which would work if the transport can't change but this
precludes a local-optimisation (as by this point the listeners for an
async invocation will already be set up for the http transport) and also
precluses the idea of different handler chains based on different
transports.
>
> 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 ?
Sorry, I'm not really sure what you're saying here.
David
>
>
> 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
> >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
Re: [Axis2] Pluggable Target Resolution
Posted by Deepal Jayasinghe <de...@opensource.lk>.
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
>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