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 16:04:06 GMT
Deepal Jayasinghe <deepal@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


Mime
View raw message