You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Jaliya Ekanayake <ja...@opensource.lk> on 2005/11/12 21:24:13 UTC
[Axis2] Where to start the out messages in the handler flow?
Hi All,
I have noticed some inconsistency in the way we currently send outgoing messages from a handler. I noticed this one in Sandesha2 implementation and think that we need some definite way to do this at least for the modules that we implement.
Say, engine receive RM Specific Create message. We can interpret this message either in RMInHandle or RMMessageReceiver. In addition modules may have pre-dispatch handlers, in RM case we use one to eliminate duplicate messages.
If we interpret this from RMInHandler then we can stop that message from going through all the other handlers.
If we interpret this from RMMessageReceiver then this message will go through the handlers deployed for the service.
Now we need to send CreateSequenceResponse message from any of the above two locations.
If we send the response from RMInHandler we need to decide what is the handler configuration for this message. Is it all the handlers deployed for that service or only the handlers that are after the RMPhase? (RMHandlers deployed in RMPhase)
If we send the CreateSequenceResponse from RMMessageReceiver then this message will go through all the outgoing handlers deployed for that service.
IMHO we should interpret module specific messages using any handler in the module and if there is a response that we need to send for that, it should start from that phase. (not from the beginning of the handler flow)
So in this way, phase n will affect only to phase n+1 as shown in the attached diagram.
We need to decide the same thing from the pre-dispatch handlers as well. If one pre-dispatch handler want to send a response, then what are the handlers that we use in the response path.
Thoughts?
Thanks,
Jaliya
Re: [Axis2] Where to start the out messages in the handler flow?
Posted by Srinath Perera <he...@gmail.com>.
Hi Chamikara, Jaliiya;
In axis2 archtecture point of view create sequence should be handled
via "injecting a operation to the service". But I chat with Jaliya and
it seems there are some complexities when we try to use the
operation.
e.g.
1) That way every operation should go till the end of the flow, e.g.
Security message that request a session key would go though RM Handler
... but do not have RM Headers
2) All the Message (e.g. Create sequence Message) go though all the
service level Handlers
Since you are the guy wrote (and dream about ;) ) RM code, you know
the problems that occurs. May be operations do not slove problem or
can be improved. If we do not use operations injection we should scrap
it from the architecture and generalized what ever the methodolgy use
for RM to address this and add it to Axis2 core.
I will try to have a look at the Sandesha2 code and think a way around
it. Shall we create a wiki somewhere listing the isssues module
archtecture should address. We need to add Ruchith to this discussion
as well
e.g.
1) RM Create Sequence/ Terminate Sequnce Messages should be
proccessed, answered and the Handler chain should be stopped
2) Each RM/Security Handler should reject messages without RM/Security headers
....
Thanks
Srinath
ation and
> think that we need some definite way to do this at least for the modules
> that we implement.
> >
> > Say, engine receive RM Specific Create message. We can interpret this
> message either in RMInHandle or RMMessageReceiver. In addition modules may
> have pre-dispatch handlers, in RM case we use one to eliminate duplicate
> messages.
> >
> > If we interpret this from RMInHandler then we can stop that message from
> going through all the other handlers.
> > If we interpret this from RMMessageReceiver then this message will go
> through the handlers deployed for the service.
> >
> > Now we need to send CreateSequenceResponse message from any of the above
> two locations.
> > If we send the response from RMInHandler we need to decide what is the
> handler configuration for this message. Is it all the handlers deployed for
> that service or only the handlers that are after the RMPhase? (RMHandlers
> deployed in RMPhase)
> >
> > If we send the CreateSequenceResponse from RMMessageReceiver then this
> message will go through all the outgoing handlers deployed for that service.
> >
> > IMHO we should interpret module specific messages using any handler in the
> module and if there is a response that we need to send for that, it should
> start from that phase. (not from the beginning of the handler flow)
> > So in this way, phase n will affect only to phase n+1 as shown in the
> attached diagram.
> >
> > We need to decide the same thing from the pre-dispatch handlers as well.
> If one pre-dispatch handler want to send a response, then what are the
> handlers that we use in the response path.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Jaliya
> >
> >
> >
> >
>
>
Re: [Axis2] Where to start the out messages in the handler flow?
Posted by Srinath Perera <he...@gmail.com>.
Hi Chamikara, Jaliiya;
In axis2 archtecture point of view create sequence should be handled
via "injecting a operation to the service". But I chat with Jaliya and
it seems there are some complexities when we try to use the
operation.
e.g.
1) That way every operation should go till the end of the flow, e.g.
Security message that request a session key would go though RM Handler
... but do not have RM Headers
2) All the Message (e.g. Create sequence Message) go though all the
service level Handlers
Since you are the guy wrote (and dream about ;) ) RM code, you know
the problems that occurs. May be operations do not slove problem or
can be improved. If we do not use operations injection we should scrap
it from the architecture and generalized what ever the methodolgy use
for RM to address this and add it to Axis2 core.
I will try to have a look at the Sandesha2 code and think a way around
it. Shall we create a wiki somewhere listing the isssues module
archtecture should address. We need to add Ruchith to this discussion
as well
e.g.
1) RM Create Sequence/ Terminate Sequnce Messages should be
proccessed, answered and the Handler chain should be stopped
2) Each RM/Security Handler should reject messages without RM/Security headers
....
Thanks
Srinath
ation and
> think that we need some definite way to do this at least for the modules
> that we implement.
> >
> > Say, engine receive RM Specific Create message. We can interpret this
> message either in RMInHandle or RMMessageReceiver. In addition modules may
> have pre-dispatch handlers, in RM case we use one to eliminate duplicate
> messages.
> >
> > If we interpret this from RMInHandler then we can stop that message from
> going through all the other handlers.
> > If we interpret this from RMMessageReceiver then this message will go
> through the handlers deployed for the service.
> >
> > Now we need to send CreateSequenceResponse message from any of the above
> two locations.
> > If we send the response from RMInHandler we need to decide what is the
> handler configuration for this message. Is it all the handlers deployed for
> that service or only the handlers that are after the RMPhase? (RMHandlers
> deployed in RMPhase)
> >
> > If we send the CreateSequenceResponse from RMMessageReceiver then this
> message will go through all the outgoing handlers deployed for that service.
> >
> > IMHO we should interpret module specific messages using any handler in the
> module and if there is a response that we need to send for that, it should
> start from that phase. (not from the beginning of the handler flow)
> > So in this way, phase n will affect only to phase n+1 as shown in the
> attached diagram.
> >
> > We need to decide the same thing from the pre-dispatch handlers as well.
> If one pre-dispatch handler want to send a response, then what are the
> handlers that we use in the response path.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Jaliya
> >
> >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Axis2] Where to start the out messages in the handler flow?
Posted by Srinath Perera <he...@gmail.com>.
Hi Chamikara, Jaliiya;
In axis2 archtecture point of view create sequence should be handled
via "injecting a operation to the service". But I chat with Jaliya and
it seems there are some complexities when we try to use the
operation.
e.g.
1) That way every operation should go till the end of the flow, e.g.
Security message that request a session key would go though RM Handler
... but do not have RM Headers
2) All the Message (e.g. Create sequence Message) go though all the
service level Handlers
Since you are the guy wrote (and dream about ;) ) RM code, you know
the problems that occurs. May be operations do not slove problem or
can be improved. If we do not use operations injection we should scrap
it from the architecture and generalized what ever the methodolgy use
for RM to address this and add it to Axis2 core.
I will try to have a look at the Sandesha2 code and think a way around
it. Shall we create a wiki somewhere listing the isssues module
archtecture should address. We need to add Ruchith to this discussion
as well
e.g.
1) RM Create Sequence/ Terminate Sequnce Messages should be
proccessed, answered and the Handler chain should be stopped
2) Each RM/Security Handler should reject messages without RM/Security headers
....
Thanks
Srinath
ation and
> think that we need some definite way to do this at least for the modules
> that we implement.
> >
> > Say, engine receive RM Specific Create message. We can interpret this
> message either in RMInHandle or RMMessageReceiver. In addition modules may
> have pre-dispatch handlers, in RM case we use one to eliminate duplicate
> messages.
> >
> > If we interpret this from RMInHandler then we can stop that message from
> going through all the other handlers.
> > If we interpret this from RMMessageReceiver then this message will go
> through the handlers deployed for the service.
> >
> > Now we need to send CreateSequenceResponse message from any of the above
> two locations.
> > If we send the response from RMInHandler we need to decide what is the
> handler configuration for this message. Is it all the handlers deployed for
> that service or only the handlers that are after the RMPhase? (RMHandlers
> deployed in RMPhase)
> >
> > If we send the CreateSequenceResponse from RMMessageReceiver then this
> message will go through all the outgoing handlers deployed for that service.
> >
> > IMHO we should interpret module specific messages using any handler in the
> module and if there is a response that we need to send for that, it should
> start from that phase. (not from the beginning of the handler flow)
> > So in this way, phase n will affect only to phase n+1 as shown in the
> attached diagram.
> >
> > We need to decide the same thing from the pre-dispatch handlers as well.
> If one pre-dispatch handler want to send a response, then what are the
> handlers that we use in the response path.
> >
> > Thoughts?
> >
> > Thanks,
> >
> > Jaliya
> >
> >
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [Axis2] Where to start the out messages in the handler flow?
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Jaliya,
Thanks for pointing this out. This is something I also felt that should be
further discussed.
As you have mentioned, the method we currently follow is adding all the
handlers of the outFlow of the request message to the response message, even
thought the response get created in a handler. (there is no inconsistency,
this is the way we follow :) ).
We could easily drop the handlers situated before the current phase (say
RMPhase) in the outFlow and make sure that the response message get
transmitted throught only the RMPhase and the phases after that. But there
is a counter argument to this.
For the Axis2 engine a phase is a marker of a area in a certain flow.
Because of this it is very possible for the set of phases in one flow to
differ from the set of phases in another flow. For example even though the
inFlow has a RMPhase the outFlow may not have it (or there may be a phase in
the outFlow named RMPhase1 which does not have a relationship with the
RMPhase when it comes to the place the Phase is sutuated). Also a module may
have a number of handlers that are situated in different phases in different
flows. Because of these complexities it is difficult to clearly identify the
starging position of an outMessage when it comes to responses that that get
created due to an activity of some handler. I also think this is something
we should clarify and we should ask the module authors to follow that
approach. But still the path is not very clear.
When it comes to the Sandesha module there is a clearly defined RMPhase and
there are only two service specific handlers which are located in the same
phase (of inFlow and outFlow). So what you propose can can be implemented
(we can drop the handlers in the outFlow before the RMPhase). But is this a
general answer ?
Thanks,
Chamikara
On 11/13/05, Jaliya Ekanayake <ja...@opensource.lk> wrote:
>
> Hi All,
> I have noticed some inconsistency in the way we currently send outgoing
> messages from a handler. I noticed this one in Sandesha2 implementation and
> think that we need some definite way to do this at least for the modules
> that we implement.
> Say, engine receive RM Specific Create message. We can interpret this
> message either in RMInHandle or RMMessageReceiver. In addition modules may
> have pre-dispatch handlers, in RM case we use one to eliminate duplicate
> messages.
> If we interpret this from RMInHandler then we can stop that message from
> going through all the other handlers.
> If we interpret this from RMMessageReceiver then this message will go
> through the handlers deployed for the service.
> Now we need to send CreateSequenceResponse message from any of the above
> two locations.
> If we send the response from RMInHandler we need to decide what is the
> handler configuration for this message. Is it all the handlers deployed for
> that service or only the handlers that are after the RMPhase? (RMHandlers
> deployed in RMPhase)
> If we send the CreateSequenceResponse from RMMessageReceiver then this
> message will go through all the outgoing handlers deployed for that service.
> IMHO we should interpret module specific messages using any handler in
> the module and if there is a response that we need to send for that, it
> should start from that phase. (not from the beginning of the handler flow)
> So in this way, phase n will affect only to phase n+1 as shown in the
> attached diagram.
> We need to decide the same thing from the pre-dispatch handlers as well.
> If one pre-dispatch handler want to send a response, then what are the
> handlers that we use in the response path.
> Thoughts?
> Thanks,
> Jaliya
>
>
Re: [Axis2] Where to start the out messages in the handler flow?
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Jaliya,
Thanks for pointing this out. This is something I also felt that should be
further discussed.
As you have mentioned, the method we currently follow is adding all the
handlers of the outFlow of the request message to the response message, even
thought the response get created in a handler. (there is no inconsistency,
this is the way we follow :) ).
We could easily drop the handlers situated before the current phase (say
RMPhase) in the outFlow and make sure that the response message get
transmitted throught only the RMPhase and the phases after that. But there
is a counter argument to this.
For the Axis2 engine a phase is a marker of a area in a certain flow.
Because of this it is very possible for the set of phases in one flow to
differ from the set of phases in another flow. For example even though the
inFlow has a RMPhase the outFlow may not have it (or there may be a phase in
the outFlow named RMPhase1 which does not have a relationship with the
RMPhase when it comes to the place the Phase is sutuated). Also a module may
have a number of handlers that are situated in different phases in different
flows. Because of these complexities it is difficult to clearly identify the
starging position of an outMessage when it comes to responses that that get
created due to an activity of some handler. I also think this is something
we should clarify and we should ask the module authors to follow that
approach. But still the path is not very clear.
When it comes to the Sandesha module there is a clearly defined RMPhase and
there are only two service specific handlers which are located in the same
phase (of inFlow and outFlow). So what you propose can can be implemented
(we can drop the handlers in the outFlow before the RMPhase). But is this a
general answer ?
Thanks,
Chamikara
On 11/13/05, Jaliya Ekanayake <ja...@opensource.lk> wrote:
>
> Hi All,
> I have noticed some inconsistency in the way we currently send outgoing
> messages from a handler. I noticed this one in Sandesha2 implementation and
> think that we need some definite way to do this at least for the modules
> that we implement.
> Say, engine receive RM Specific Create message. We can interpret this
> message either in RMInHandle or RMMessageReceiver. In addition modules may
> have pre-dispatch handlers, in RM case we use one to eliminate duplicate
> messages.
> If we interpret this from RMInHandler then we can stop that message from
> going through all the other handlers.
> If we interpret this from RMMessageReceiver then this message will go
> through the handlers deployed for the service.
> Now we need to send CreateSequenceResponse message from any of the above
> two locations.
> If we send the response from RMInHandler we need to decide what is the
> handler configuration for this message. Is it all the handlers deployed for
> that service or only the handlers that are after the RMPhase? (RMHandlers
> deployed in RMPhase)
> If we send the CreateSequenceResponse from RMMessageReceiver then this
> message will go through all the outgoing handlers deployed for that service.
> IMHO we should interpret module specific messages using any handler in
> the module and if there is a response that we need to send for that, it
> should start from that phase. (not from the beginning of the handler flow)
> So in this way, phase n will affect only to phase n+1 as shown in the
> attached diagram.
> We need to decide the same thing from the pre-dispatch handlers as well.
> If one pre-dispatch handler want to send a response, then what are the
> handlers that we use in the response path.
> Thoughts?
> Thanks,
> Jaliya
>
>
Re: [Axis2] Where to start the out messages in the handler flow?
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Jaliya,
Thanks for pointing this out. This is something I also felt that should be
further discussed.
As you have mentioned, the method we currently follow is adding all the
handlers of the outFlow of the request message to the response message, even
thought the response get created in a handler. (there is no inconsistency,
this is the way we follow :) ).
We could easily drop the handlers situated before the current phase (say
RMPhase) in the outFlow and make sure that the response message get
transmitted throught only the RMPhase and the phases after that. But there
is a counter argument to this.
For the Axis2 engine a phase is a marker of a area in a certain flow.
Because of this it is very possible for the set of phases in one flow to
differ from the set of phases in another flow. For example even though the
inFlow has a RMPhase the outFlow may not have it (or there may be a phase in
the outFlow named RMPhase1 which does not have a relationship with the
RMPhase when it comes to the place the Phase is sutuated). Also a module may
have a number of handlers that are situated in different phases in different
flows. Because of these complexities it is difficult to clearly identify the
starging position of an outMessage when it comes to responses that that get
created due to an activity of some handler. I also think this is something
we should clarify and we should ask the module authors to follow that
approach. But still the path is not very clear.
When it comes to the Sandesha module there is a clearly defined RMPhase and
there are only two service specific handlers which are located in the same
phase (of inFlow and outFlow). So what you propose can can be implemented
(we can drop the handlers in the outFlow before the RMPhase). But is this a
general answer ?
Thanks,
Chamikara
On 11/13/05, Jaliya Ekanayake <ja...@opensource.lk> wrote:
>
> Hi All,
> I have noticed some inconsistency in the way we currently send outgoing
> messages from a handler. I noticed this one in Sandesha2 implementation and
> think that we need some definite way to do this at least for the modules
> that we implement.
> Say, engine receive RM Specific Create message. We can interpret this
> message either in RMInHandle or RMMessageReceiver. In addition modules may
> have pre-dispatch handlers, in RM case we use one to eliminate duplicate
> messages.
> If we interpret this from RMInHandler then we can stop that message from
> going through all the other handlers.
> If we interpret this from RMMessageReceiver then this message will go
> through the handlers deployed for the service.
> Now we need to send CreateSequenceResponse message from any of the above
> two locations.
> If we send the response from RMInHandler we need to decide what is the
> handler configuration for this message. Is it all the handlers deployed for
> that service or only the handlers that are after the RMPhase? (RMHandlers
> deployed in RMPhase)
> If we send the CreateSequenceResponse from RMMessageReceiver then this
> message will go through all the outgoing handlers deployed for that service.
> IMHO we should interpret module specific messages using any handler in
> the module and if there is a response that we need to send for that, it
> should start from that phase. (not from the beginning of the handler flow)
> So in this way, phase n will affect only to phase n+1 as shown in the
> attached diagram.
> We need to decide the same thing from the pre-dispatch handlers as well.
> If one pre-dispatch handler want to send a response, then what are the
> handlers that we use in the response path.
> Thoughts?
> Thanks,
> Jaliya
>
>