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
