axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: Life after service response?
Date Thu, 13 Dec 2001 18:56:24 GMT
What a handler does during its fault processing is
pretty much undefined and I would think it should probably
stay that way - much like what a handler does in "invoke()"
is undefined.  As for no one implementing anything it in
yet,well, I know some people who want to but since I don't
believe the fault processing in Axis is complete yet I've
been telling people to avoid it, for now.  Much like I'm not
100% sure the init() method is called correctly.  We need
to work through the details of all this.

Glyn Normington/UK/IBM@IBMGB on 12/13/2001 11:52:27 AM

Please respond to

Subject:  Re: Life after service response?


Ok, but what should a handler be allowed to do when a fault is occurs? For
instance, you could invent requirements for a handler to:

1. Adopt a different strategy and retry the remainder of the chain.
2. Add some kind of block to the response to coordinate with a
corresponding handler on the client side.
3. Clean up its own state.
4. Report diagnostics if it thinks it is the cause of the fault.
5. etc.

1 & 2 would require faults to be delivered in (reverse) chain sequence
whereas 3 & 4 could just be done by handlers 'subscribing' to faults and
Axis 'publishing' faults to them in an essential random handler order.

But practically speaking, so far, I haven't found any handlers that
implement undo() with real function. Is this function which is just missing
or is there no requirement for fault processing in most handlers?

Clarification of the requirements and what function is currently missing
would help steer the discussion.



                    Davis/Raleigh/       To:
                    IBM@IBMUS            cc:
                                         Subject:     Re: Life after
service response?
                    13/12/01 15:56
                    Please respond
                    to axis-dev

That's not the point of "undo".  I've now realized that "undo"
is just a bad choice for a name - perhaps something like
"handleFault" would be better.  All it's supposed to do it
give each handler that was invoke()'d a chance to do some
processing in the event of a fault - that's it.  If someone wants
to use it for some sort of transactional stuff that's up to them
Axis is just providing a framework from which people can do
whatever they want.  Please do not remove it - instead, if
you're looking for something to do you could work on the
fault processing logic - I believe it still needs to completed.  :-)

Glyn Normington/UK/IBM@IBMGB on 12/13/2001 10:38:22 AM

Please respond to

Subject:  Re: Life after service response?

I've been trying to understand the abstractions surrounding handlers and
the engine and cannot understand the basis for introducing undo(). I was
pleased to find that Sanjiva wrote:

>I'd like to see undo() taken out totally. The semantics of
>undo() in the context of chains of handlers is pretty flaky.

I think Axis should avoid getting into 'compensation management' which
starts to appear in embrionic form in

For example I suspect Axis does not want to get into 'recovery', but the
requirement for compensation after a system crash could easily arise from
handlers which deal with persistent state and which depend on undo to
perform properly.

I'll happily strip out undo if no-one else wants to.


View raw message