Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: domain of nagy@watson.ibm.com designates
 129.34.20.6 as permitted sender)
Subject: Re: [Axis2] Proposal: Extending the handler invocation pattern
From: Bill Nagy <nagy@watson.ibm.com>
To: axis-dev@ws.apache.org
In-Reply-To: <1145121846.30233.24.camel@localhost.localdomain>
References: <1145040785.7710.3.camel@scylla.watson.ibm.com>
	 <19e0530f0604141213o314b42aq1810546fce3a519b@mail.gmail.com>
	 <1145059635.7710.18.camel@scylla.watson.ibm.com>
	 <1145121846.30233.24.camel@localhost.localdomain>
Content-Type: text/plain
Date: Sun, 16 Apr 2006 22:19:39 -0400
Message-Id: <1145240379.19954.32.camel@scylla.watson.ibm.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi Sanjiva,

On Sat, 2006-04-15 at 23:24 +0600, Sanjiva Weerawarana wrote: 
> 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.

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

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

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.    

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

Sorry that I wasn't clear.  The only thing that I meant was that if you
rely upon outbound handlers to "clean up", you may get different
behavior depending upon whether or not the response is the final piece
of work being done.  Take my Tx scenario for example: If an outbound
handler is used to commit the transaction, then in one case (where the
response is sent when the artifact returns control to the message
receiver,) all of the processing for the operation will occur under the
scope of the transaction, while in the other case (if the response is
explicit) some amount of the work will not be scoped under the
transaction.      

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

Actually that's not completely true; you can force the response to
commit via ServletResponse.flushBuffer().  I'm not sure that I quite
understand where the chicken and egg problem is.

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

If no one has problems with extending the Handler interface (i.e.
changing the interface) after 1.0, I don't see any need to make the
changes now either.  (If there is a desire to keep the interface stable
after 1.0, I would still only suggest modifying the interface and
putting a comment in saying that the method will not be invoked in this
version.)  

> 
> Sanjiva.