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 Bill Nagy <na...@watson.ibm.com> on 2006/05/17 02:13:42 UTC
Re: [Axis2] Proposal: Extending the handler invocation pattern
Since v1.0 has been released, and now that everyone has had time to
recuperate, I would like to resume the discussion below. The full
thread can be found at http://marc.theaimsgroup.com/?l=axis-
dev&m=114573566701675&w=2 if you need your memory refreshed.
-Bill
On Sat, 2006-04-22 at 15:53 -0400, Bill Nagy wrote:
Hi Sanjiva and Glen,
On Tue, 2006-04-18 at 01:35 +0600, Sanjiva Weerawarana wrote:
> > OK, so you're suggesting that we architect another plug point in the
> > message receivers where handler (type)/message receiver (programming
> > model) specific plugins can be added to move things between the Axis2
> > contexts and whatever is required by the programming model. I
> > completely agree, and was actually going to suggest that in a later
> > discussion (for a different reason.)
>
> Basically yes but I wasn't suggesting another plugpoint- u can just use
> the message receiver plugpoint and write your own message receiver
> right??
>
I'm going to start a new discussion thread for this, as it's really a
separate issue from the discussion below.
> > That still doesn't really address
> > the general problem of allowing handlers to "clean up" when necessary.
> > If a handler acquires a resource/starts a protocol, it's not generally
> > desirable to leave everything waiting for a timeout upon completion or
> > an error (which is all that can currently be done under some
> > circumstances.)
>
> Accepted.
>
> > I was trying to keep my examples simple for the sake of discussion. You
> > could imagine scenarios where responsibility of managing transactions
> > falls upon the middleware (handler in this case.) If the handler
> > creates a transaction when a message comes in, it may be desirable for
> > the handler to be responsible for committing the transaction after the
> > message finishes being processed.
>
> OK then let's address that .. what you're suggesting is that it would be
> useful for a module author to be able to give some code that should be
> run once a MEP is complete. I agree with that .. so let's come up with a
> model to make that work.
>
I'm not sure that I would necessarily tie the code to the module itself.
Logically the code is most likely tied to the piece of function that a
single handler is implementing (e.g. if a handler creates a transaction,
it seems most logical that it should be the one to commit or abort the
transaction.) That is why I was suggesting extending the Handler
interface with another method. I will agree that this is more of a code
structure issue than anything. (While it does require a retrofit of
existing handlers, it does not require changes to the deployment
mechanism/module.xml.)
Likewise, I'm not sure that I would tie it to a MEP either. [The
following is from the inbound perspective:] In the case of a failure,
there is no guarantee that a MEP will have been resolved (e.g. if the
dispatch fails after security and one of the initial RM handlers has
executed, there would be no way for them to clean up if the execution of
their completion code is tied to the MEP.) The only handlers/modules
who would be assured that their completion code would be executed in the
case of all faults are those who execute everything post-dispatch. This
would create an avoidable inconsistency in the handler/module
mechanism.
I believe that a more consistent solution would be to have the
handlers/phases that have executed during the processing of the message
be invoked again (in the reverse order) after processing of the message
path has been completed (e.g. Key: IH == inbound handler, OH == outbound
handler -- one-way inbound: IH1, IH2, MessageReceiver, IH2, IH1 --
request-response inbound: IH1, IH2, MessageReceiver, OH1, OH2,
Transport, OH2, OH1, IH2, IH1) Since the phases are executed
explicitly, some portion of the completion path will depend upon the
unwinding of the Java call stack, while some will be explicit. While I
recognize that this is more complex of a solution than what Glen
proposed, I believe that it addresses the issues above and that it will
lead to a more easily understandable flow in the code.
-Bill
>
>
>
Re: [Axis2] Proposal: Extending the handler invocation pattern
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Bill,
Please comment on performance impact as well.
Sanjiva.
On Thu, 2006-05-18 at 11:42 -0400, Bill Nagy wrote:
> OK, I'll do that and then post a link to the page.
>
> -Bill
>
>
> On Thu, 2006-05-18 at 11:27 -0400, Davanum Srinivas wrote:
> > How about a summary in wiki of what you think the solution should look
> > like? with code snippets? I got lost reading all the emails on the
> > thread:)
> >
> > -- dims
> >
> > On 5/18/06, Bill Nagy <na...@watson.ibm.com> wrote:
> > > Hi dims,
> > >
> > > I'm happy to do that, but it's not an insignificant amount of work and
> > > so I wanted to try to get some high-level agreement before I went down
> > > that path.
> > >
> > > -Bill
> > >
> > > On Thu, 2006-05-18 at 11:08 -0400, Davanum Srinivas wrote:
> > > > Bill,
> > > >
> > > > Could u please flesh it out? It may be easier to push the proposal
> > > > with a proposed patch :)
> > > >
> > > > thanks,
> > > > dims
> > > >
> > > > On 5/16/06, Bill Nagy <na...@watson.ibm.com> wrote:
> > > > > Since v1.0 has been released, and now that everyone has had time to
> > > > > recuperate, I would like to resume the discussion below. The full
> > > > > thread can be found at http://marc.theaimsgroup.com/?l=axis-
> > > > > dev&m=114573566701675&w=2 if you need your memory refreshed.
> > > > >
> > > > > -Bill
> > > > >
> > > > >
> > > > > On Sat, 2006-04-22 at 15:53 -0400, Bill Nagy wrote:
> > > > > Hi Sanjiva and Glen,
> > > > >
> > > > > On Tue, 2006-04-18 at 01:35 +0600, Sanjiva Weerawarana wrote:
> > > > > > > OK, so you're suggesting that we architect another plug point in the
> > > > > > > message receivers where handler (type)/message receiver (programming
> > > > > > > model) specific plugins can be added to move things between the Axis2
> > > > > > > contexts and whatever is required by the programming model. I
> > > > > > > completely agree, and was actually going to suggest that in a later
> > > > > > > discussion (for a different reason.)
> > > > > >
> > > > > > Basically yes but I wasn't suggesting another plugpoint- u can just use
> > > > > > the message receiver plugpoint and write your own message receiver
> > > > > > right??
> > > > > >
> > > > >
> > > > > I'm going to start a new discussion thread for this, as it's really a
> > > > > separate issue from the discussion below.
> > > > >
> > > > > > > That still doesn't really address
> > > > > > > the general problem of allowing handlers to "clean up" when necessary.
> > > > > > > If a handler acquires a resource/starts a protocol, it's not generally
> > > > > > > desirable to leave everything waiting for a timeout upon completion or
> > > > > > > an error (which is all that can currently be done under some
> > > > > > > circumstances.)
> > > > > >
> > > > > > Accepted.
> > > > > >
> > > > > > > I was trying to keep my examples simple for the sake of discussion. You
> > > > > > > could imagine scenarios where responsibility of managing transactions
> > > > > > > falls upon the middleware (handler in this case.) If the handler
> > > > > > > creates a transaction when a message comes in, it may be desirable for
> > > > > > > the handler to be responsible for committing the transaction after the
> > > > > > > message finishes being processed.
> > > > > >
> > > > > > OK then let's address that .. what you're suggesting is that it would be
> > > > > > useful for a module author to be able to give some code that should be
> > > > > > run once a MEP is complete. I agree with that .. so let's come up with a
> > > > > > model to make that work.
> > > > > >
> > > > >
> > > > > I'm not sure that I would necessarily tie the code to the module itself.
> > > > > Logically the code is most likely tied to the piece of function that a
> > > > > single handler is implementing (e.g. if a handler creates a transaction,
> > > > > it seems most logical that it should be the one to commit or abort the
> > > > > transaction.) That is why I was suggesting extending the Handler
> > > > > interface with another method. I will agree that this is more of a code
> > > > > structure issue than anything. (While it does require a retrofit of
> > > > > existing handlers, it does not require changes to the deployment
> > > > > mechanism/module.xml.)
> > > > >
> > > > > Likewise, I'm not sure that I would tie it to a MEP either. [The
> > > > > following is from the inbound perspective:] In the case of a failure,
> > > > > there is no guarantee that a MEP will have been resolved (e.g. if the
> > > > > dispatch fails after security and one of the initial RM handlers has
> > > > > executed, there would be no way for them to clean up if the execution of
> > > > > their completion code is tied to the MEP.) The only handlers/modules
> > > > > who would be assured that their completion code would be executed in the
> > > > > case of all faults are those who execute everything post-dispatch. This
> > > > > would create an avoidable inconsistency in the handler/module
> > > > > mechanism.
> > > > >
> > > > > I believe that a more consistent solution would be to have the
> > > > > handlers/phases that have executed during the processing of the message
> > > > > be invoked again (in the reverse order) after processing of the message
> > > > > path has been completed (e.g. Key: IH == inbound handler, OH == outbound
> > > > > handler -- one-way inbound: IH1, IH2, MessageReceiver, IH2, IH1 --
> > > > > request-response inbound: IH1, IH2, MessageReceiver, OH1, OH2,
> > > > > Transport, OH2, OH1, IH2, IH1) Since the phases are executed
> > > > > explicitly, some portion of the completion path will depend upon the
> > > > > unwinding of the Java call stack, while some will be explicit. While I
> > > > > recognize that this is more complex of a solution than what Glen
> > > > > proposed, I believe that it addresses the issues above and that it will
> > > > > lead to a more easily understandable flow in the code.
> > > > >
> > > > > -Bill
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] Proposal: Extending the handler invocation pattern
Posted by Bill Nagy <na...@watson.ibm.com>.
OK, I'll do that and then post a link to the page.
-Bill
On Thu, 2006-05-18 at 11:27 -0400, Davanum Srinivas wrote:
> How about a summary in wiki of what you think the solution should look
> like? with code snippets? I got lost reading all the emails on the
> thread:)
>
> -- dims
>
> On 5/18/06, Bill Nagy <na...@watson.ibm.com> wrote:
> > Hi dims,
> >
> > I'm happy to do that, but it's not an insignificant amount of work and
> > so I wanted to try to get some high-level agreement before I went down
> > that path.
> >
> > -Bill
> >
> > On Thu, 2006-05-18 at 11:08 -0400, Davanum Srinivas wrote:
> > > Bill,
> > >
> > > Could u please flesh it out? It may be easier to push the proposal
> > > with a proposed patch :)
> > >
> > > thanks,
> > > dims
> > >
> > > On 5/16/06, Bill Nagy <na...@watson.ibm.com> wrote:
> > > > Since v1.0 has been released, and now that everyone has had time to
> > > > recuperate, I would like to resume the discussion below. The full
> > > > thread can be found at http://marc.theaimsgroup.com/?l=axis-
> > > > dev&m=114573566701675&w=2 if you need your memory refreshed.
> > > >
> > > > -Bill
> > > >
> > > >
> > > > On Sat, 2006-04-22 at 15:53 -0400, Bill Nagy wrote:
> > > > Hi Sanjiva and Glen,
> > > >
> > > > On Tue, 2006-04-18 at 01:35 +0600, Sanjiva Weerawarana wrote:
> > > > > > OK, so you're suggesting that we architect another plug point in the
> > > > > > message receivers where handler (type)/message receiver (programming
> > > > > > model) specific plugins can be added to move things between the Axis2
> > > > > > contexts and whatever is required by the programming model. I
> > > > > > completely agree, and was actually going to suggest that in a later
> > > > > > discussion (for a different reason.)
> > > > >
> > > > > Basically yes but I wasn't suggesting another plugpoint- u can just use
> > > > > the message receiver plugpoint and write your own message receiver
> > > > > right??
> > > > >
> > > >
> > > > I'm going to start a new discussion thread for this, as it's really a
> > > > separate issue from the discussion below.
> > > >
> > > > > > That still doesn't really address
> > > > > > the general problem of allowing handlers to "clean up" when necessary.
> > > > > > If a handler acquires a resource/starts a protocol, it's not generally
> > > > > > desirable to leave everything waiting for a timeout upon completion or
> > > > > > an error (which is all that can currently be done under some
> > > > > > circumstances.)
> > > > >
> > > > > Accepted.
> > > > >
> > > > > > I was trying to keep my examples simple for the sake of discussion. You
> > > > > > could imagine scenarios where responsibility of managing transactions
> > > > > > falls upon the middleware (handler in this case.) If the handler
> > > > > > creates a transaction when a message comes in, it may be desirable for
> > > > > > the handler to be responsible for committing the transaction after the
> > > > > > message finishes being processed.
> > > > >
> > > > > OK then let's address that .. what you're suggesting is that it would be
> > > > > useful for a module author to be able to give some code that should be
> > > > > run once a MEP is complete. I agree with that .. so let's come up with a
> > > > > model to make that work.
> > > > >
> > > >
> > > > I'm not sure that I would necessarily tie the code to the module itself.
> > > > Logically the code is most likely tied to the piece of function that a
> > > > single handler is implementing (e.g. if a handler creates a transaction,
> > > > it seems most logical that it should be the one to commit or abort the
> > > > transaction.) That is why I was suggesting extending the Handler
> > > > interface with another method. I will agree that this is more of a code
> > > > structure issue than anything. (While it does require a retrofit of
> > > > existing handlers, it does not require changes to the deployment
> > > > mechanism/module.xml.)
> > > >
> > > > Likewise, I'm not sure that I would tie it to a MEP either. [The
> > > > following is from the inbound perspective:] In the case of a failure,
> > > > there is no guarantee that a MEP will have been resolved (e.g. if the
> > > > dispatch fails after security and one of the initial RM handlers has
> > > > executed, there would be no way for them to clean up if the execution of
> > > > their completion code is tied to the MEP.) The only handlers/modules
> > > > who would be assured that their completion code would be executed in the
> > > > case of all faults are those who execute everything post-dispatch. This
> > > > would create an avoidable inconsistency in the handler/module
> > > > mechanism.
> > > >
> > > > I believe that a more consistent solution would be to have the
> > > > handlers/phases that have executed during the processing of the message
> > > > be invoked again (in the reverse order) after processing of the message
> > > > path has been completed (e.g. Key: IH == inbound handler, OH == outbound
> > > > handler -- one-way inbound: IH1, IH2, MessageReceiver, IH2, IH1 --
> > > > request-response inbound: IH1, IH2, MessageReceiver, OH1, OH2,
> > > > Transport, OH2, OH1, IH2, IH1) Since the phases are executed
> > > > explicitly, some portion of the completion path will depend upon the
> > > > unwinding of the Java call stack, while some will be explicit. While I
> > > > recognize that this is more complex of a solution than what Glen
> > > > proposed, I believe that it addresses the issues above and that it will
> > > > lead to a more easily understandable flow in the code.
> > > >
> > > > -Bill
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: [Axis2] Proposal: Extending the handler invocation pattern
Posted by Davanum Srinivas <da...@gmail.com>.
How about a summary in wiki of what you think the solution should look
like? with code snippets? I got lost reading all the emails on the
thread :)
-- dims
On 5/18/06, Bill Nagy <na...@watson.ibm.com> wrote:
> Hi dims,
>
> I'm happy to do that, but it's not an insignificant amount of work and
> so I wanted to try to get some high-level agreement before I went down
> that path.
>
> -Bill
>
> On Thu, 2006-05-18 at 11:08 -0400, Davanum Srinivas wrote:
> > Bill,
> >
> > Could u please flesh it out? It may be easier to push the proposal
> > with a proposed patch :)
> >
> > thanks,
> > dims
> >
> > On 5/16/06, Bill Nagy <na...@watson.ibm.com> wrote:
> > > Since v1.0 has been released, and now that everyone has had time to
> > > recuperate, I would like to resume the discussion below. The full
> > > thread can be found at http://marc.theaimsgroup.com/?l=axis-
> > > dev&m=114573566701675&w=2 if you need your memory refreshed.
> > >
> > > -Bill
> > >
> > >
> > > On Sat, 2006-04-22 at 15:53 -0400, Bill Nagy wrote:
> > > Hi Sanjiva and Glen,
> > >
> > > On Tue, 2006-04-18 at 01:35 +0600, Sanjiva Weerawarana wrote:
> > > > > OK, so you're suggesting that we architect another plug point in the
> > > > > message receivers where handler (type)/message receiver (programming
> > > > > model) specific plugins can be added to move things between the Axis2
> > > > > contexts and whatever is required by the programming model. I
> > > > > completely agree, and was actually going to suggest that in a later
> > > > > discussion (for a different reason.)
> > > >
> > > > Basically yes but I wasn't suggesting another plugpoint- u can just use
> > > > the message receiver plugpoint and write your own message receiver
> > > > right??
> > > >
> > >
> > > I'm going to start a new discussion thread for this, as it's really a
> > > separate issue from the discussion below.
> > >
> > > > > That still doesn't really address
> > > > > the general problem of allowing handlers to "clean up" when necessary.
> > > > > If a handler acquires a resource/starts a protocol, it's not generally
> > > > > desirable to leave everything waiting for a timeout upon completion or
> > > > > an error (which is all that can currently be done under some
> > > > > circumstances.)
> > > >
> > > > Accepted.
> > > >
> > > > > I was trying to keep my examples simple for the sake of discussion. You
> > > > > could imagine scenarios where responsibility of managing transactions
> > > > > falls upon the middleware (handler in this case.) If the handler
> > > > > creates a transaction when a message comes in, it may be desirable for
> > > > > the handler to be responsible for committing the transaction after the
> > > > > message finishes being processed.
> > > >
> > > > OK then let's address that .. what you're suggesting is that it would be
> > > > useful for a module author to be able to give some code that should be
> > > > run once a MEP is complete. I agree with that .. so let's come up with a
> > > > model to make that work.
> > > >
> > >
> > > I'm not sure that I would necessarily tie the code to the module itself.
> > > Logically the code is most likely tied to the piece of function that a
> > > single handler is implementing (e.g. if a handler creates a transaction,
> > > it seems most logical that it should be the one to commit or abort the
> > > transaction.) That is why I was suggesting extending the Handler
> > > interface with another method. I will agree that this is more of a code
> > > structure issue than anything. (While it does require a retrofit of
> > > existing handlers, it does not require changes to the deployment
> > > mechanism/module.xml.)
> > >
> > > Likewise, I'm not sure that I would tie it to a MEP either. [The
> > > following is from the inbound perspective:] In the case of a failure,
> > > there is no guarantee that a MEP will have been resolved (e.g. if the
> > > dispatch fails after security and one of the initial RM handlers has
> > > executed, there would be no way for them to clean up if the execution of
> > > their completion code is tied to the MEP.) The only handlers/modules
> > > who would be assured that their completion code would be executed in the
> > > case of all faults are those who execute everything post-dispatch. This
> > > would create an avoidable inconsistency in the handler/module
> > > mechanism.
> > >
> > > I believe that a more consistent solution would be to have the
> > > handlers/phases that have executed during the processing of the message
> > > be invoked again (in the reverse order) after processing of the message
> > > path has been completed (e.g. Key: IH == inbound handler, OH == outbound
> > > handler -- one-way inbound: IH1, IH2, MessageReceiver, IH2, IH1 --
> > > request-response inbound: IH1, IH2, MessageReceiver, OH1, OH2,
> > > Transport, OH2, OH1, IH2, IH1) Since the phases are executed
> > > explicitly, some portion of the completion path will depend upon the
> > > unwinding of the Java call stack, while some will be explicit. While I
> > > recognize that this is more complex of a solution than what Glen
> > > proposed, I believe that it addresses the issues above and that it will
> > > lead to a more easily understandable flow in the code.
> > >
> > > -Bill
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [Axis2] Proposal: Extending the handler invocation pattern
Posted by Bill Nagy <na...@watson.ibm.com>.
Hi dims,
I'm happy to do that, but it's not an insignificant amount of work and
so I wanted to try to get some high-level agreement before I went down
that path.
-Bill
On Thu, 2006-05-18 at 11:08 -0400, Davanum Srinivas wrote:
> Bill,
>
> Could u please flesh it out? It may be easier to push the proposal
> with a proposed patch :)
>
> thanks,
> dims
>
> On 5/16/06, Bill Nagy <na...@watson.ibm.com> wrote:
> > Since v1.0 has been released, and now that everyone has had time to
> > recuperate, I would like to resume the discussion below. The full
> > thread can be found at http://marc.theaimsgroup.com/?l=axis-
> > dev&m=114573566701675&w=2 if you need your memory refreshed.
> >
> > -Bill
> >
> >
> > On Sat, 2006-04-22 at 15:53 -0400, Bill Nagy wrote:
> > Hi Sanjiva and Glen,
> >
> > On Tue, 2006-04-18 at 01:35 +0600, Sanjiva Weerawarana wrote:
> > > > OK, so you're suggesting that we architect another plug point in the
> > > > message receivers where handler (type)/message receiver (programming
> > > > model) specific plugins can be added to move things between the Axis2
> > > > contexts and whatever is required by the programming model. I
> > > > completely agree, and was actually going to suggest that in a later
> > > > discussion (for a different reason.)
> > >
> > > Basically yes but I wasn't suggesting another plugpoint- u can just use
> > > the message receiver plugpoint and write your own message receiver
> > > right??
> > >
> >
> > I'm going to start a new discussion thread for this, as it's really a
> > separate issue from the discussion below.
> >
> > > > That still doesn't really address
> > > > the general problem of allowing handlers to "clean up" when necessary.
> > > > If a handler acquires a resource/starts a protocol, it's not generally
> > > > desirable to leave everything waiting for a timeout upon completion or
> > > > an error (which is all that can currently be done under some
> > > > circumstances.)
> > >
> > > Accepted.
> > >
> > > > I was trying to keep my examples simple for the sake of discussion. You
> > > > could imagine scenarios where responsibility of managing transactions
> > > > falls upon the middleware (handler in this case.) If the handler
> > > > creates a transaction when a message comes in, it may be desirable for
> > > > the handler to be responsible for committing the transaction after the
> > > > message finishes being processed.
> > >
> > > OK then let's address that .. what you're suggesting is that it would be
> > > useful for a module author to be able to give some code that should be
> > > run once a MEP is complete. I agree with that .. so let's come up with a
> > > model to make that work.
> > >
> >
> > I'm not sure that I would necessarily tie the code to the module itself.
> > Logically the code is most likely tied to the piece of function that a
> > single handler is implementing (e.g. if a handler creates a transaction,
> > it seems most logical that it should be the one to commit or abort the
> > transaction.) That is why I was suggesting extending the Handler
> > interface with another method. I will agree that this is more of a code
> > structure issue than anything. (While it does require a retrofit of
> > existing handlers, it does not require changes to the deployment
> > mechanism/module.xml.)
> >
> > Likewise, I'm not sure that I would tie it to a MEP either. [The
> > following is from the inbound perspective:] In the case of a failure,
> > there is no guarantee that a MEP will have been resolved (e.g. if the
> > dispatch fails after security and one of the initial RM handlers has
> > executed, there would be no way for them to clean up if the execution of
> > their completion code is tied to the MEP.) The only handlers/modules
> > who would be assured that their completion code would be executed in the
> > case of all faults are those who execute everything post-dispatch. This
> > would create an avoidable inconsistency in the handler/module
> > mechanism.
> >
> > I believe that a more consistent solution would be to have the
> > handlers/phases that have executed during the processing of the message
> > be invoked again (in the reverse order) after processing of the message
> > path has been completed (e.g. Key: IH == inbound handler, OH == outbound
> > handler -- one-way inbound: IH1, IH2, MessageReceiver, IH2, IH1 --
> > request-response inbound: IH1, IH2, MessageReceiver, OH1, OH2,
> > Transport, OH2, OH1, IH2, IH1) Since the phases are executed
> > explicitly, some portion of the completion path will depend upon the
> > unwinding of the Java call stack, while some will be explicit. While I
> > recognize that this is more complex of a solution than what Glen
> > proposed, I believe that it addresses the issues above and that it will
> > lead to a more easily understandable flow in the code.
> >
> > -Bill
> > >
> > >
> > >
> >
> >
>
>
Re: [Axis2] Proposal: Extending the handler invocation pattern
Posted by Davanum Srinivas <da...@gmail.com>.
Bill,
Could u please flesh it out? It may be easier to push the proposal
with a proposed patch :)
thanks,
dims
On 5/16/06, Bill Nagy <na...@watson.ibm.com> wrote:
> Since v1.0 has been released, and now that everyone has had time to
> recuperate, I would like to resume the discussion below. The full
> thread can be found at http://marc.theaimsgroup.com/?l=axis-
> dev&m=114573566701675&w=2 if you need your memory refreshed.
>
> -Bill
>
>
> On Sat, 2006-04-22 at 15:53 -0400, Bill Nagy wrote:
> Hi Sanjiva and Glen,
>
> On Tue, 2006-04-18 at 01:35 +0600, Sanjiva Weerawarana wrote:
> > > OK, so you're suggesting that we architect another plug point in the
> > > message receivers where handler (type)/message receiver (programming
> > > model) specific plugins can be added to move things between the Axis2
> > > contexts and whatever is required by the programming model. I
> > > completely agree, and was actually going to suggest that in a later
> > > discussion (for a different reason.)
> >
> > Basically yes but I wasn't suggesting another plugpoint- u can just use
> > the message receiver plugpoint and write your own message receiver
> > right??
> >
>
> I'm going to start a new discussion thread for this, as it's really a
> separate issue from the discussion below.
>
> > > That still doesn't really address
> > > the general problem of allowing handlers to "clean up" when necessary.
> > > If a handler acquires a resource/starts a protocol, it's not generally
> > > desirable to leave everything waiting for a timeout upon completion or
> > > an error (which is all that can currently be done under some
> > > circumstances.)
> >
> > Accepted.
> >
> > > I was trying to keep my examples simple for the sake of discussion. You
> > > could imagine scenarios where responsibility of managing transactions
> > > falls upon the middleware (handler in this case.) If the handler
> > > creates a transaction when a message comes in, it may be desirable for
> > > the handler to be responsible for committing the transaction after the
> > > message finishes being processed.
> >
> > OK then let's address that .. what you're suggesting is that it would be
> > useful for a module author to be able to give some code that should be
> > run once a MEP is complete. I agree with that .. so let's come up with a
> > model to make that work.
> >
>
> I'm not sure that I would necessarily tie the code to the module itself.
> Logically the code is most likely tied to the piece of function that a
> single handler is implementing (e.g. if a handler creates a transaction,
> it seems most logical that it should be the one to commit or abort the
> transaction.) That is why I was suggesting extending the Handler
> interface with another method. I will agree that this is more of a code
> structure issue than anything. (While it does require a retrofit of
> existing handlers, it does not require changes to the deployment
> mechanism/module.xml.)
>
> Likewise, I'm not sure that I would tie it to a MEP either. [The
> following is from the inbound perspective:] In the case of a failure,
> there is no guarantee that a MEP will have been resolved (e.g. if the
> dispatch fails after security and one of the initial RM handlers has
> executed, there would be no way for them to clean up if the execution of
> their completion code is tied to the MEP.) The only handlers/modules
> who would be assured that their completion code would be executed in the
> case of all faults are those who execute everything post-dispatch. This
> would create an avoidable inconsistency in the handler/module
> mechanism.
>
> I believe that a more consistent solution would be to have the
> handlers/phases that have executed during the processing of the message
> be invoked again (in the reverse order) after processing of the message
> path has been completed (e.g. Key: IH == inbound handler, OH == outbound
> handler -- one-way inbound: IH1, IH2, MessageReceiver, IH2, IH1 --
> request-response inbound: IH1, IH2, MessageReceiver, OH1, OH2,
> Transport, OH2, OH1, IH2, IH1) Since the phases are executed
> explicitly, some portion of the completion path will depend upon the
> unwinding of the Java call stack, while some will be explicit. While I
> recognize that this is more complex of a solution than what Glen
> proposed, I believe that it addresses the issues above and that it will
> lead to a more easily understandable flow in the code.
>
> -Bill
> >
> >
> >
>
>
--
Davanum Srinivas : http://wso2.com/blogs/