axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Nagy <>
Subject Re: [Axis2] Proposal: Extending the handler invocation pattern
Date Sat, 22 Apr 2006 19:53:05 GMT
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

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

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.


View raw message