Hi dims;
Lets say that we have the fault information in the soap header (addressing)
. In the current implementation what it does is when a message is received ,
takes the inflow (inflow handles ) and give it to the engine and call
engine.receive(msgContx) ,
addressing handler is in that chain , so we do need to go throgh the inflow
upto addressing handler to read the addressing headers to know the fault ,
and then we can call engine.receiveFault();
so we have to start the in-fault-flow invocation in the middle of in-flow;
is that ok?
thought ......
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Davanum Srinivas" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, August 17, 2005 5:03 PM
Subject: Re: [Axis2] How to Handle faults
Ajith,
Let us keep the fault-in-flow concept. We can key it off by inspecting
the soap headers (specifically the addressing headers' action) in
addition to the HTTP 500. worst case the fault will reach the
"in-flow". will this be enough?
thanks,
dims
On 8/17/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
Hi all,
We have discussed the handling of the SOAP fault using the fault-in-flow
in the last f2f but there seems to be some unseen issues. So I'm
explaining the concepts and problems from ground up for the benefit of
the people who were not in the f2f.
Concepts
In axis2 we've decided there would be 4 types of flows. The in-flow and
the out-flow are two of the most obvious. Similarly there are two more
flows, the fault-in-flow and the fault-out-flow. The idea is that when a
message is received, if it's a Normal SOAP message, it should be
processed with the in-flow and if the message is a SOAP fault then it
should be processed with the fault-in-flow. Similarly if a message needs
to be sent out it would be processed through the out-flow and if a fault
needs to be sent out it would be processed through the fault-out-flow.
This is the conceptual idea of the flows we came across in the summit.
Problems
The outflows (both out-flow and the fault-out-flow) poses no problems.
When an exception is caught by the engine, the fault-out-flow is invoked.
The problem is when a fault is received. Obviously the invocation of the
in-flows should happen at the transport and there are some cases where
such decisions cannot possibly be taken at the transport level. Consider
the following table that list out scenarios.
Protocol
Scenario
Possibility of invoking the fault flow at transport
Reason
HTTP
A fault is received as the result of a synchronous web service call
Yes
Both SOAP 1.1 and SOAP 1.2 require the SOAP fault to have the HTTP 500
error code.
HTTP
A fault is received as the result of a asynchronous web service call
No
No information is present for the receiver to take a decision about the
message!
SMTP/POP
A fault is received. (Since this is a single channel transport, there's
no concept of a 'synchronous response'.)
No
SOAP does not define any binding to SMTP/POP. There's no transport
information what-so-ever in the mail message that says about the SOAP
content
It should be clear by now that selecting the fault flow based on the
transport information is not possible in all instances.
One can ask at this point whether it would be possible to handle this by
putting a handler that looks at the SOAP body and determines whether it's
a fault or not. Well, not in all cases. The message can be encrypted
hence the security handler should run first if the body needs to be
inspected.
Again there's the vague area of where the fault-in-flow should lead to.
Obviously it should end at the Message receiver. However the message
receiver should somehow be informed that this is a fault, perhaps through
a different method in the message receiver interface (Currently the
message receiver interface has only one method, receive(…). Perhaps we
can put a receiveFault(…) method for the fault-in-flow to call)
Solutions
These are the possible solutions
Have a switching handler in the middle of the inflow. This handler
(referred to as the switching handler afterwards) has to run after
some of the essential handlers. In more technical words, it should
be resolvable to a fault or not at the switching handler. The fault
flow ends at the message receiver that may invoke a separate
method in the MR or just inject the message context which has a flag
saying it's a fault.
Drop the concept of fault-in-flow completely. Necessary handlers can
implement fall through mechanisms to handle an incoming fault.
As you can see, this problem is more of the conceptual nature. All are
welcome to express their opinions.
--
Ajith Ranabahu
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
