You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Ajith Ranabahu <aj...@gmail.com> on 2005/08/17 10:17:45 UTC
[Axis2] How to Handle faults
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
[Axis2] DoS concersn and fautl handling [some thoughts] [ Re: [Axis2]
How to Handle faults
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Srinath Perera wrote:
>Well, IMO the idea of the infault flow is as high level as the inflow
>.. I belive the wsdl makes it so. One can have a dispatcher to do the
>check for a fault .. (he should not/ can not do the service disptah if
>it is a fault. ) Then it is we calling the infualt flow with in the
>in-flow.
>
>But we are running in to this chicken and egg problem too often
>.somehting is encrypted ...ect ..ect ... may be the pre diapatch
>pahses are common to all in* flows ..and we should redefine them so.
>
>Just thinking aloud .. what you guys think?
>
>
IMHO decryption and signature verification should happen in an early
inflow handlers (as early as possible) and encryption and signing in one
of the last outflow handlers (if not the last one) - if not then there
is plenty of problems to preserve infoset through handlers.
addressing handler should be after decryption in-flow and definitely
before encryption out-flow (ws-rx/rm may sit between ws-addressign and
WSS handlers).
if there is fault before decryption then there are only limited options
how to handle this - you may not even know whhich target service was
called ...
if there is fault it may still need be encrypted -right?
so what really is the problem? if there is in-flow fault before
addressing handler is reached then no addressing should be used to send
fault as it was not yet reached and problem is in a layer that is
possibly below (like transport or security ...) - right?
if you use addressing FaultTo for invalid message to send fault (such as
wrong signature) you expose a possible denial-of-service (DoS) attack
capability for any axis2 enabled service (send invalid messages to axis2
service that acts as a "zombie" and sends fault message to DoS target
host ...) - there is no easy solution for it AFAIK if no security or
policy is used.
using Basic Authorization / WSS and/or policy on allowed values
FaultTo/ReplyTo should help but it would be no good if security can be
overridden and DoS executed even when service is supposedly using WSS
encryption and signature verification ...
i think maybe there is need for some use cases ...
best,
alek
>On 8/17/05, Ajith Ranabahu <aj...@gmail.com> wrote:
>
>
>>Ahum..
>>In my personal opinion I see the invokeFault(..) [or whatever it will be
>>called] as an elegant way of handling the error.So I don't think it's
>>complicating things. it's actually a better way of dealing with the
>>complication :)
>>The very reason why we need a fault flow is to avoid such fall through code
>>in the handlers :)
>>
>>
>>On 8/17/05, Eran Chinthaka < chinthakae@gmail.com> wrote:
>>
>>
>>>Ok, can I know the things you are thinking of doing in the IN fault
>>>flow, which you don't wanna do in the normal in flow (of course
>>>something other than logging :) )
>>>
>>>
>>>
>>>
>>>>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?
>>>>
>>>>
>>>Isn't this complicating the things ???
>>>Without doing the way you propose, you can achieve the samething like
>>>
>>>
>>this.
>>
>>
>>>1. Handler which handlers everything
>>>
>>>invoke (msgctx){
>>> if( env.getBody().hasFault()){
>>> // do your fault stuff
>>> }else{
>>> // do normal stuff
>>> }
>>>}
>>>
>>>2. Fault Handler (any use cases ??)
>>>
>>>invoke (msgctx){
>>> if(env.getBody().hasFault()){
>>> // do your fault stuff
>>> }
>>>}
>>>
>>>3. No Difference on faults handler
>>>
>>>invoke (msgctx){
>>> // act on msgctx. No difference
>>>}
>>>
>>>
>>>See my point ??
>>>
>>>-- Chinthaka
>>>
>>>
>>>
>>
>>--
>>Ajith Ranabahu
>>
>>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] How to Handle faults
Posted by Srinath Perera <he...@gmail.com>.
Well, IMO the idea of the infault flow is as high level as the inflow
.. I belive the wsdl makes it so. One can have a dispatcher to do the
check for a fault .. (he should not/ can not do the service disptah if
it is a fault. ) Then it is we calling the infualt flow with in the
in-flow.
But we are running in to this chicken and egg problem too often
.somehting is encrypted ...ect ..ect ... may be the pre diapatch
pahses are common to all in* flows ..and we should redefine them so.
Just thinking aloud .. what you guys think?
On 8/17/05, Ajith Ranabahu <aj...@gmail.com> wrote:
> Ahum..
> In my personal opinion I see the invokeFault(..) [or whatever it will be
> called] as an elegant way of handling the error.So I don't think it's
> complicating things. it's actually a better way of dealing with the
> complication :)
> The very reason why we need a fault flow is to avoid such fall through code
> in the handlers :)
>
>
> On 8/17/05, Eran Chinthaka < chinthakae@gmail.com> wrote:
> > Ok, can I know the things you are thinking of doing in the IN fault
> > flow, which you don't wanna do in the normal in flow (of course
> > something other than logging :) )
> >
> >
> > > 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?
> >
> > Isn't this complicating the things ???
> > Without doing the way you propose, you can achieve the samething like
> this.
> >
> > 1. Handler which handlers everything
> >
> > invoke (msgctx){
> > if( env.getBody().hasFault()){
> > // do your fault stuff
> > }else{
> > // do normal stuff
> > }
> > }
> >
> > 2. Fault Handler (any use cases ??)
> >
> > invoke (msgctx){
> > if(env.getBody().hasFault()){
> > // do your fault stuff
> > }
> > }
> >
> > 3. No Difference on faults handler
> >
> > invoke (msgctx){
> > // act on msgctx. No difference
> > }
> >
> >
> > See my point ??
> >
> > -- Chinthaka
> >
>
>
>
> --
> Ajith Ranabahu
Re: [Axis2] How to Handle faults
Posted by Ajith Ranabahu <aj...@gmail.com>.
Ahum..
In my personal opinion I see the invokeFault(..) [or whatever it will be
called] as an elegant way of handling the error.So I don't think it's
complicating things. it's actually a better way of dealing with the
complication :)
The very reason why we need a fault flow is to avoid such fall through code
in the handlers :)
On 8/17/05, Eran Chinthaka <ch...@gmail.com> wrote:
>
> Ok, can I know the things you are thinking of doing in the IN fault
> flow, which you don't wanna do in the normal in flow (of course
> something other than logging :) )
>
>
> > 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?
>
> Isn't this complicating the things ???
> Without doing the way you propose, you can achieve the samething like
> this.
>
> 1. Handler which handlers everything
>
> invoke (msgctx){
> if(env.getBody().hasFault()){
> // do your fault stuff
> }else{
> // do normal stuff
> }
> }
>
> 2. Fault Handler (any use cases ??)
>
> invoke (msgctx){
> if(env.getBody().hasFault()){
> // do your fault stuff
> }
> }
>
> 3. No Difference on faults handler
>
> invoke (msgctx){
> // act on msgctx. No difference
> }
>
>
> See my point ??
>
> -- Chinthaka
>
--
Ajith Ranabahu
Re: [Axis2] How to Handle faults
Posted by Eran Chinthaka <ch...@gmail.com>.
Ok, can I know the things you are thinking of doing in the IN fault
flow, which you don't wanna do in the normal in flow (of course
something other than logging :) )
> 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?
Isn't this complicating the things ???
Without doing the way you propose, you can achieve the samething like this.
1. Handler which handlers everything
invoke (msgctx){
if(env.getBody().hasFault()){
// do your fault stuff
}else{
// do normal stuff
}
}
2. Fault Handler (any use cases ??)
invoke (msgctx){
if(env.getBody().hasFault()){
// do your fault stuff
}
}
3. No Difference on faults handler
invoke (msgctx){
// act on msgctx. No difference
}
See my point ??
-- Chinthaka
Re: [Axis2] How to Handle faults
Posted by Deepal Jayasinghe <de...@opensource.lk>.
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" <da...@gmail.com>
To: <ax...@ws.apache.org>
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 <aj...@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
>
Re: [Axis2] How to Handle faults
Posted by Ajith Ranabahu <aj...@gmail.com>.
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 <da...@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 <aj...@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
Re: [Axis2] How to Handle faults
Posted by Davanum Srinivas <da...@gmail.com>.
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 <aj...@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
Re: [Axis2] How to Handle faults
Posted by Eran Chinthaka <ch...@gmail.com>.
Hi Ajith and all,
> 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)
Why does the message receiver be notified *explicitly* about a fault,
with this much of pain. MR can simply do a small check on the msgctx
and switch, if required.
(msgctx.getSOAPEnvelope().getBody().hasFault() ).
>
> 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.
+1.
I don't think we have a necessity to incorporate the fault handling
mechanism to the main control flow. You have a good and acceptable way
to do the samething. And if we do option #1 you are unnecessarily
complicating the common case. Anyway, I don't think there are that
much of use cases that have services which *expects* faults as IN
messages.
What I suggest is don't have this in the main control flow. Let the
user put the required logic in handlers and in MR.
Regards,
Chinthaka