You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2008/04/17 06:47:28 UTC
Are faults errors?
Hi,
We had an issue in camel (see end of nabble thread here: http://www.nabble.com/in-out-fault-messages-discussion-td14170013i20.html)
and we'd highly appreciate your input on this.
In brief, there is a proposal to get rid of faults. Most of the
protocols do not distinguish between faults and exceptions, but jbi,
jsr181, wsdl to. Should we remove faults from the model? And if we
do so should faults be more like outputs or more like errors?
Thanks
Hadrian
Re: Are faults errors?
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I think it's better to continue this discussion on the camel-dev list
(please don't Reply All). Thanks to the cxf community for the input.
Hadrian
On Apr 30, 2008, at 1:42 PM, Guillaume Nodet wrote:
> That's a bit of the problem. Should faults be considered as
> exceptions and interrupt the normal flow or should they considered as
> messages ? I guess removing them will remove this ambiguity as well,
> because one will have to either use a out message or an error.
>
> As I replied on the other thread, we could also go further and remove
> the exchange, especially if it can not be linked to an invocation
> (like in the wsdl2 model). For example, if there are multiple outs,
> it may be even easier to just have a Message, with a getter to
> retrieve a Context, and a property to link to the previous message (be
> it the in messge, or anything else related to this message).
>
> On Wed, Apr 30, 2008 at 7:14 PM, Hadrian Zbarcea
> <hz...@gmail.com> wrote:
>> Hi Bruce,
>>
>> +1 to Hiram's proposal.
>>
>> I cannot speak about the original intentions, but since the idea of
>> fault
>> is only specific to just a few of the technologies camel supports,
>> I think
>> having a fault in an exchange could be quite confusing for other
>> components.
>> I think it should be up to a component to decide what to do with
>> the faults,
>> camel-cxf in this case.
>>
>> Some expressed the point of view that faults *are* exceptions. I
>> am not
>> sure if that meant that they should be of an Exception type, or
>> that they
>> should be handled as exceptions by the middleware infrastructure.
>> I later
>> thought they probably meant the former, which is fine. The out in
>> the
>> exchange could hold an Exception which may or may not be handled by
>> camel
>> depending on how the route is defined.
>>
>> My $0.02
>> Hadrian
>>
>>
>>
>> On Apr 30, 2008, at 12:28 PM, Bruce Snyder wrote:
>>
>>
>>> On Wed, Apr 30, 2008 at 9:56 AM, Hiram Chirino <hiram@hiramchirino.com
>>> >
>> wrote:
>>>
>>>> When I think faults I always think soap faults. And I think that
>>>> was
>>>> the main use case behind adding the the fault message in the
>>>> exchange.
>>>> But the fact is that a fault is just the out message from soap. A
>>>> soap processor could inspect that out message and notice it's of a
>>>> fault variety. So my vote is to eliminate the fault message and
>>>> store
>>>> faults in the out message.
>>>>
>>>> IMO, exceptions thrown by camel processors should be due to
>>>> internal
>>>> camel errors due to things like not having connectivity or invalid
>>>> configuration etc. etc. Accessing a soap service which returns a
>>>> fault
>>>> message should not be an exception, it's just a error response that
>>>> needs to get routed.
>>>>
>>>
>>> This discussion immediately makes me think of the fault propagation
>>> rules in WSDL 2.0 which are used to specify the recipient of the
>>> fault
>>> message. There are three rules in WSDL 2.0:
>>>
>>> 1) Fault replaces message - fault might not be sent to the message
>> originator
>>> 2) Message triggers fault - fault must be sent to the message
>>> originator
>>> 3) No faults - faults are discarded
>>>
>>> Was there any intention when originally putting faults into Camel to
>>> cover these rules at all? Or is this not a concern at all?
>>>
>>> Bruce
>>> --
>>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>> );'
>>>
>>> Apache ActiveMQ - http://activemq.org/
>>> Apache Camel - http://activemq.org/camel/
>>> Apache ServiceMix - http://servicemix.org/
>>> Apache Geronimo - http://geronimo.apache.org/
>>>
>>> Blog: http://bruceblog.org/
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
Re: Are faults errors?
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I think it's better to continue this discussion on the camel-dev list
(please don't Reply All). Thanks to the cxf community for the input.
Hadrian
On Apr 30, 2008, at 1:42 PM, Guillaume Nodet wrote:
> That's a bit of the problem. Should faults be considered as
> exceptions and interrupt the normal flow or should they considered as
> messages ? I guess removing them will remove this ambiguity as well,
> because one will have to either use a out message or an error.
>
> As I replied on the other thread, we could also go further and remove
> the exchange, especially if it can not be linked to an invocation
> (like in the wsdl2 model). For example, if there are multiple outs,
> it may be even easier to just have a Message, with a getter to
> retrieve a Context, and a property to link to the previous message (be
> it the in messge, or anything else related to this message).
>
> On Wed, Apr 30, 2008 at 7:14 PM, Hadrian Zbarcea
> <hz...@gmail.com> wrote:
>> Hi Bruce,
>>
>> +1 to Hiram's proposal.
>>
>> I cannot speak about the original intentions, but since the idea of
>> fault
>> is only specific to just a few of the technologies camel supports,
>> I think
>> having a fault in an exchange could be quite confusing for other
>> components.
>> I think it should be up to a component to decide what to do with
>> the faults,
>> camel-cxf in this case.
>>
>> Some expressed the point of view that faults *are* exceptions. I
>> am not
>> sure if that meant that they should be of an Exception type, or
>> that they
>> should be handled as exceptions by the middleware infrastructure.
>> I later
>> thought they probably meant the former, which is fine. The out in
>> the
>> exchange could hold an Exception which may or may not be handled by
>> camel
>> depending on how the route is defined.
>>
>> My $0.02
>> Hadrian
>>
>>
>>
>> On Apr 30, 2008, at 12:28 PM, Bruce Snyder wrote:
>>
>>
>>> On Wed, Apr 30, 2008 at 9:56 AM, Hiram Chirino <hiram@hiramchirino.com
>>> >
>> wrote:
>>>
>>>> When I think faults I always think soap faults. And I think that
>>>> was
>>>> the main use case behind adding the the fault message in the
>>>> exchange.
>>>> But the fact is that a fault is just the out message from soap. A
>>>> soap processor could inspect that out message and notice it's of a
>>>> fault variety. So my vote is to eliminate the fault message and
>>>> store
>>>> faults in the out message.
>>>>
>>>> IMO, exceptions thrown by camel processors should be due to
>>>> internal
>>>> camel errors due to things like not having connectivity or invalid
>>>> configuration etc. etc. Accessing a soap service which returns a
>>>> fault
>>>> message should not be an exception, it's just a error response that
>>>> needs to get routed.
>>>>
>>>
>>> This discussion immediately makes me think of the fault propagation
>>> rules in WSDL 2.0 which are used to specify the recipient of the
>>> fault
>>> message. There are three rules in WSDL 2.0:
>>>
>>> 1) Fault replaces message - fault might not be sent to the message
>> originator
>>> 2) Message triggers fault - fault must be sent to the message
>>> originator
>>> 3) No faults - faults are discarded
>>>
>>> Was there any intention when originally putting faults into Camel to
>>> cover these rules at all? Or is this not a concern at all?
>>>
>>> Bruce
>>> --
>>> perl -e 'print
>> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
>>> );'
>>>
>>> Apache ActiveMQ - http://activemq.org/
>>> Apache Camel - http://activemq.org/camel/
>>> Apache ServiceMix - http://servicemix.org/
>>> Apache Geronimo - http://geronimo.apache.org/
>>>
>>> Blog: http://bruceblog.org/
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
Re: Are faults errors?
Posted by Guillaume Nodet <gn...@gmail.com>.
That's a bit of the problem. Should faults be considered as
exceptions and interrupt the normal flow or should they considered as
messages ? I guess removing them will remove this ambiguity as well,
because one will have to either use a out message or an error.
As I replied on the other thread, we could also go further and remove
the exchange, especially if it can not be linked to an invocation
(like in the wsdl2 model). For example, if there are multiple outs,
it may be even easier to just have a Message, with a getter to
retrieve a Context, and a property to link to the previous message (be
it the in messge, or anything else related to this message).
On Wed, Apr 30, 2008 at 7:14 PM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Hi Bruce,
>
> +1 to Hiram's proposal.
>
> I cannot speak about the original intentions, but since the idea of fault
> is only specific to just a few of the technologies camel supports, I think
> having a fault in an exchange could be quite confusing for other components.
> I think it should be up to a component to decide what to do with the faults,
> camel-cxf in this case.
>
> Some expressed the point of view that faults *are* exceptions. I am not
> sure if that meant that they should be of an Exception type, or that they
> should be handled as exceptions by the middleware infrastructure. I later
> thought they probably meant the former, which is fine. The out in the
> exchange could hold an Exception which may or may not be handled by camel
> depending on how the route is defined.
>
> My $0.02
> Hadrian
>
>
>
> On Apr 30, 2008, at 12:28 PM, Bruce Snyder wrote:
>
>
> > On Wed, Apr 30, 2008 at 9:56 AM, Hiram Chirino <hi...@hiramchirino.com>
> wrote:
> >
> > > When I think faults I always think soap faults. And I think that was
> > > the main use case behind adding the the fault message in the exchange.
> > > But the fact is that a fault is just the out message from soap. A
> > > soap processor could inspect that out message and notice it's of a
> > > fault variety. So my vote is to eliminate the fault message and store
> > > faults in the out message.
> > >
> > > IMO, exceptions thrown by camel processors should be due to internal
> > > camel errors due to things like not having connectivity or invalid
> > > configuration etc. etc. Accessing a soap service which returns a fault
> > > message should not be an exception, it's just a error response that
> > > needs to get routed.
> > >
> >
> > This discussion immediately makes me think of the fault propagation
> > rules in WSDL 2.0 which are used to specify the recipient of the fault
> > message. There are three rules in WSDL 2.0:
> >
> > 1) Fault replaces message - fault might not be sent to the message
> originator
> > 2) Message triggers fault - fault must be sent to the message originator
> > 3) No faults - faults are discarded
> >
> > Was there any intention when originally putting faults into Camel to
> > cover these rules at all? Or is this not a concern at all?
> >
> > Bruce
> > --
> > perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > );'
> >
> > Apache ActiveMQ - http://activemq.org/
> > Apache Camel - http://activemq.org/camel/
> > Apache ServiceMix - http://servicemix.org/
> > Apache Geronimo - http://geronimo.apache.org/
> >
> > Blog: http://bruceblog.org/
> >
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Are faults errors?
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi Bruce,
+1 to Hiram's proposal.
I cannot speak about the original intentions, but since the idea of
fault is only specific to just a few of the technologies camel
supports, I think having a fault in an exchange could be quite
confusing for other components. I think it should be up to a
component to decide what to do with the faults, camel-cxf in this case.
Some expressed the point of view that faults *are* exceptions. I am
not sure if that meant that they should be of an Exception type, or
that they should be handled as exceptions by the middleware
infrastructure. I later thought they probably meant the former, which
is fine. The out in the exchange could hold an Exception which may or
may not be handled by camel depending on how the route is defined.
My $0.02
Hadrian
On Apr 30, 2008, at 12:28 PM, Bruce Snyder wrote:
> On Wed, Apr 30, 2008 at 9:56 AM, Hiram Chirino
> <hi...@hiramchirino.com> wrote:
>> When I think faults I always think soap faults. And I think that was
>> the main use case behind adding the the fault message in the
>> exchange.
>> But the fact is that a fault is just the out message from soap. A
>> soap processor could inspect that out message and notice it's of a
>> fault variety. So my vote is to eliminate the fault message and
>> store
>> faults in the out message.
>>
>> IMO, exceptions thrown by camel processors should be due to internal
>> camel errors due to things like not having connectivity or invalid
>> configuration etc. etc. Accessing a soap service which returns a
>> fault
>> message should not be an exception, it's just a error response that
>> needs to get routed.
>
> This discussion immediately makes me think of the fault propagation
> rules in WSDL 2.0 which are used to specify the recipient of the fault
> message. There are three rules in WSDL 2.0:
>
> 1) Fault replaces message - fault might not be sent to the message
> originator
> 2) Message triggers fault - fault must be sent to the message
> originator
> 3) No faults - faults are discarded
>
> Was there any intention when originally putting faults into Camel to
> cover these rules at all? Or is this not a concern at all?
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!
> G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache Camel - http://activemq.org/camel/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
>
> Blog: http://bruceblog.org/
Re: Are faults errors?
Posted by Bruce Snyder <br...@gmail.com>.
On Wed, Apr 30, 2008 at 9:56 AM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> When I think faults I always think soap faults. And I think that was
> the main use case behind adding the the fault message in the exchange.
> But the fact is that a fault is just the out message from soap. A
> soap processor could inspect that out message and notice it's of a
> fault variety. So my vote is to eliminate the fault message and store
> faults in the out message.
>
> IMO, exceptions thrown by camel processors should be due to internal
> camel errors due to things like not having connectivity or invalid
> configuration etc. etc. Accessing a soap service which returns a fault
> message should not be an exception, it's just a error response that
> needs to get routed.
This discussion immediately makes me think of the fault propagation
rules in WSDL 2.0 which are used to specify the recipient of the fault
message. There are three rules in WSDL 2.0:
1) Fault replaces message - fault might not be sent to the message originator
2) Message triggers fault - fault must be sent to the message originator
3) No faults - faults are discarded
Was there any intention when originally putting faults into Camel to
cover these rules at all? Or is this not a concern at all?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Blog: http://bruceblog.org/
Re: Are faults errors?
Posted by Hiram Chirino <hi...@hiramchirino.com>.
When I think faults I always think soap faults. And I think that was
the main use case behind adding the the fault message in the exchange.
But the fact is that a fault is just the out message from soap. A
soap processor could inspect that out message and notice it's of a
fault variety. So my vote is to eliminate the fault message and store
faults in the out message.
IMO, exceptions thrown by camel processors should be due to internal
camel errors due to things like not having connectivity or invalid
configuration etc. etc. Accessing a soap service which returns a fault
message should not be an exception, it's just a error response that
needs to get routed.
Regards,
Hiram
On Thu, Apr 17, 2008 at 12:47 AM, Hadrian Zbarcea <hz...@gmail.com> wrote:
> Hi,
>
> We had an issue in camel (see end of nabble thread here:
> http://www.nabble.com/in-out-fault-messages-discussion-td14170013i20.html)
> and we'd highly appreciate your input on this.
>
> In brief, there is a proposal to get rid of faults. Most of the protocols
> do not distinguish between faults and exceptions, but jbi, jsr181, wsdl to.
> Should we remove faults from the model? And if we do so should faults be
> more like outputs or more like errors?
>
> Thanks
> Hadrian
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com