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.) -Bill 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 > > http://www.developer.com/java/web/print.php/10935_3529321_4 > > thanks, > dims > > On 4/14/06, Bill Nagy <[EMAIL PROTECTED]> 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 : http://wso2.com/blogs/
