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 Re: [Axis2] How to Handle faults
Date Wed, 17 Aug 2005 11:36:00 GMT
Hi Dims,
I guess we are taking the first solution then. So we need to have a handler 
in the in-flow so we can switch the flows. (inspecting the headers need to 
be done inside a flow, in this case the in-flow).
BTW Do we need to add another method to the message receiver interface ?

On 8/17/05, Davanum Srinivas <davanum@gmail.com> wrote:
> 
> 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 <ajith.ranabahu@gmail.com> 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
> 



-- 
Ajith Ranabahu
Mime
View raw message