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
