axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [Axis2] Proposal: Extending the handler invocation pattern
Date Sat, 15 Apr 2006 17:24:06 GMT
Hi Bill,

> 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.

This is not the right way to do this in Axis2 ... you shouldn't be
putting stuff in the thread context as you run thru Axis2. The right way
to store it is in one of the *Context classes in Axis2 and then move it
to the thread where appropriate (for example, in the message receiver).
If you follow that approach then the behavior is absolutely fine- the
message receiver is fully in charge and can do the right thing.

> 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.)

I don't grok what the problem is .. subject to my comment above.

> 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.) 

That's a pretty unacceptable semantic for a Tx handler if the tx is done
when the message is delivered to the message receiver.

>  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.)

Um why not? If you want to send a response and continue then you can
fire the response off in another thread (or the remaining work in
another thread). I don't think your approach makes sense as a solution
for this scenario at all: you're saying block everything until the
message is gone. 

Also I believe there are issues in realizing your approach with the
servlet thread model as the flow is not really complete until the
response is written and the response doesn't get written until you
relinquish control to the servlet. Seems like a chicken and egg problem
to me.

In any case, there's no way to consider this type of a change in time
for 1.0 at this point. I'm happy to continue the discussion on the list
for possible inclusion in a future version, but realistically with the
proposed 1.0 timeframe being like a week away (or even if it was a month
away!) this kind of a change is not an option at this time.

Sanjiva.


Mime
View raw message