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, 15 Apr 2006 00:07:15 GMT
Hi dims,

Yes I was aware of the four flows, but I don't believe that they provide
the necessary flexibility.  Consider the following two scenarios:

1) A service exposes a one-way operation that requires Authentication.
The authentication handler places context on the thread of execution.
When the message is done being processed, the handler needs to
remove/invalidate the context as the thread may be reused (i.e. placed
back into a thread pool.)  Unless I'm missing something, the OutFlow
will never be followed, so even if we put the handler in the OutFlow
(which I'll discuss in the next scenario), it won't be invoked.

2) A service exposes a bi-directional operation (say request/response w/
fault) that requires Authentication.  As with the previous scenario, the
handler places context on the thread of execution that needs to be
invalidated/removed when the message is done being processed.  While we
could put the same handler in the OutFlow or OutFaultFlow, I would argue
that that's quite a hack (and a difficult one to manage.)  You would, in
fact, be arbitrarily adding handlers depending upon the input path
followed, and they would have no real correlation with the QoS that was
being applied to the particular outbound message.  (This may be an issue
when ReplyTo's and FaultTo's are used to redirect outbound messages, as
there is no guarantee that those endpoints will have the same QoSes
applied as were present for the inbound message.)

Moreover, the semantics between what the current mechanisms allow and
what I am proposing actually differ, both in the order in which the
handlers would be invoked (unless you want to specify them multiple
times) and in when they execute relative to the overall message
processing (e.g. A transaction handler would issue a commit in the
current model before all of the other outbound handlers have executed,
while it would wait until the processing of the message has been fully
completed under what I am proposing.)  Furthermore, the semantics do not
currently accommodate programming models where the delivery of a
response is not directly linked to the completion of a method invocation
(i.e. if the programming model allows for a response to be sent
explicitly and then processing to continue in the operation
implementation, the current mechanisms would not provide the same
semantics in all cases.)


On Fri, 2006-04-14 at 15:13 -0400, Davanum Srinivas wrote:
> Bill,
> There are 4 types of flows in Axis2. Have u run into all of them yet?
> a module can add handlers in whichever flows it wants to work with.
> (As you already know all the data that needs to be shared is in the
> context hierarchy.) FWIW, During the various F2F meetings we
> speficially walked through WS-RM and WS-Security secnarios...
>     * InFlow
>     * OutFlow
>     * InFaultFlow
>     * OutFaultFlow
> thanks,
> dims
> On 4/14/06, Bill Nagy <> wrote:
> > Hi folks,
> >
> > I would like to extend the handler invocation pattern (i.e. the points
> > at which a particular handler is called to process a given message) so
> > that handlers are invoked after the processing of a message has
> > finished.  (This would include both termination due to successful
> > processing as well as the cases when a fault has caused processing to be
> > cut short.)
> >
> > Currently, assuming that my understanding of the code is correct,
> > handlers are invoked exactly one time during the processing of each
> > message.  This is insufficient in cases where the handler/QoS needs to
> > perform work after the operation has completed, e.g. if a security
> > handler needs to remove context that was attached to the thread during
> > execution or if a transaction handler needs to commit a transaction that
> > it initiated.  While there are hacks that work around these issues under
> > some circumstances, e.g. placing the handlers in an outbound chain, they
> > are just that, hacks that only work under certain circumstances.  (They
> > won't work, for instance, for one-way operations.)
> >
> > I realize that this is a non-trivial change (among other things, it
> > involves altering the call path through the runtime as well as
> > maintaining extra state about what work has already occurred,) but
> > believe that it is the only workable solution.
> >
> > I would propose adding a single method to the Handler interface,
> > flowComplete(MessageContext messageContext), that would be invoked for
> > each handler that had had its invoke(...) method called during the
> > processing of the message (with the exception that if a handler threw an
> > exception during its execution, its flowComplete(...) method would not
> > be called.)  The flowComplete(...) method for each handler would be
> > called in the reverse order in which the invoke(...) method was called.
> > For example, a flow may look like: securityHandler.invoke(...),
> > rmHandler.invoke(...), process message, rmHandler.flowComplete(...),
> > securityHandler.flowComplete(...).  If the rmHandler threw an exception
> > within its invoke(...) method, then the flow would look like:
> > securityHandler.invoke(...), rmHandler.invoke(...),
> > securityHandler.flowComplete(...).  (If the flowComplete(...) method
> > throws an exception, the rest of the handlers must still have their
> > flowComplete(...) methods invoked.)
> >
> > Comments/questions?
> >
> > -Bill
> >
> >
> >
> --
> Davanum Srinivas :

View raw message