Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Importance: Normal
Subject: Re: [Architecture Improvement] Handler lifecycle events and undo()
To: axis-dev@xml.apache.org
Message-ID: <OFE82AFB3C.690EE621-ON85256B25.005CE85E@raleigh.ibm.com >
From: "Doug Davis" <dug@us.ibm.com>
Date: Mon, 17 Dec 2001 12:09:28 -0500
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


Glyn,
>>     2 - before a chain(service?) a handler is in is invoked
>>         - this is when init() was supposed to be called
>>         - could be for stuff like init'ing DB transactions
>What about handlers which are not in chains? Would init be driven
>just before invoke? Seems a little superfluous.

Handlers not in chains? Do you mean instead of invoking a
chain we invoke a single handler?  No difference, chains are
handlers.  A handler can be created long before it is ever used.
It is possible to have a configuration manager that doesn't just
populate a hashtable of handler names but rather loads/creates
instances of them at startup (much like "load on startup" for
servlets).  The point is that you can't assume that a handler
is created and used at the same time (or in the same engine
invocation).  The most common use-case we talked about in the
past was the creation of a pool of DB connections.

>>     4 - after a chain(service?) a handler is in is invoked
>>         - complement to the init()
>>         - could be for closing down stuff like DB transactions
>Again, what about handlers which are not in chains?

See above.

>>     5 - after the response message is done being read
>>         - this is important for cleaning up stuff that was created
>>           but still needed until the entire response message is
>>           read.  For example, temporary attachment files.
>I don't understand this. It seems to assume a single request response
>message pattern. Or what if the response message is read in a different
JVM
>to the chain being considered?

Perhaps I should have said, after all of the Messages have been
processed.  This would including the reading of the request
message (think HTTPSender reading the Message while trying to
send to the server), and reading any possible response.  I can
see this needing to be split into two, but that can be worked out
once we agree on the concept.  As for two JVMs - I don't follow,
the engine is running withing a single JVM, I don't think we support
the reading of a possible response on a different JVM but still
in the same engine.  That would be a different engine - and in
that case there would be no response message for the 1st engine
to process - which is fine.

>>     6 - when a error happens
>>         - allow a handler that was previously invoked() to
>>           perfom some action when another handler, later on,
>>           faults.  Whether this is as complex as rollback()
>>           or simply a logError() type of thing is up to it.
>I don't understand the scope here. What if a client node A calls an
>intermediary node B which forwards the request to a server node C and then
>the response flows back to B and then back to A and then a fault occurs.
>Which handlers would get notified? All those in A, B, and C which had
>already run or just those in A which had already run?

All we care about is what happens within a single SOAP engine
and we don't mandate what happens within each handler.  You
need to distinguish between a fault on "this" node and a fault
on the "next" node.  A fault on the next node would not cause any
fault chains on this node to be invoked (it is an option I guess
but we never talked about it), rather a response handler is responsible
for processing the response message - which would include examining
it to see if it is a fault or not and do something if it wants.
A fault on "this" node is different - from an Axis' point of view
the entire chain (or set of chains) makes up "this" node and when
something causes a fault in "this" node, "this node (ie. the handlers)"
needs to be notified.

-Dug