axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajith Ranabahu <ajith.ranab...@gmail.com>
Subject [Axis2] How to Handle faults
Date Wed, 17 Aug 2005 08:17:45 GMT
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

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


   1. 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
Mime
View raw message