camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Chekan <>
Subject Re: Camel 2.0 - FAULT message, do we need it?
Date Sun, 14 Sep 2008 21:23:38 GMT
I even didn't know about FAULT :(
Does it mean that all my processors are buggy because I do not check fault?

My understanding of Fault in SOAP is that *it is* an exception. WS 
frameworks generate proxy classes which check fault and throw exception. 
The reason Soap use fault is that it is the only way you can serialize 
an exception.
The same approach on server side: any business exception is caught by WS 
handler, wrapped into fault code and sent back.
So distinguishing fault and exception in Camel is senseless. There is no 
difference between two.
Fault code is nothing else but serialized exception.

I'm afraid I can't agree with Hadrian:

 > Outputs provide a response after
 > successful processing.  Faults are responses that indicate to the
 > client that the expected goal was not achieved, and they usually
 > provide a reason.  Faults are messages that tell a client that the
 > server did receive the request and successfully processed it, but not
 > in the way intended and the client may need to take further action

What "not in the way intended" mean? What should Camel do if something 
went not in the way intended? The answer is: nothing. Camel knows 
nothing about application business stuff. From Camel perspective message 
is either processed or not. Period. It is application which should know 
that certain component can return two types of responses and act 
accordingly. From Camel perspective it is a perfectly valid response 
which is indistinguishable from Out.

Now, lets talk use cases. Lets say we have a batch to process. Like any 
programmer I'm all about ACID so I design my system to rollback and fail 
the whole batch if any item failed.
But my users are unhappy. They come to me and say that if I just create 
a list of errors and keep batch executing they would rather fix errors 
manually instead of cleaning source data and re-running the batch.
So now I'm facing dilemma. If before knew that if no exception happen 
then batch succeeded but now I have a "failed" response with list of 
failed items. So I can not throw exception anymore. I need to process 
this "failed" list by publishing it.
But it is very important to understand that from service design point of 
view there was no errors! I got a response with a list of items which 
need to be published. Sounds like typical workflow. It is error only 
from customer perspective, not from the Camel or even application 

I provided this long example because I suspect that this "fault" 
conception is interpretation of application-level faults. I want to show 
that there exist no "fault" message as opposite to exception. If you 
have a use case which demonstrates "fault" message, lets discuss.

I must admit I had some confusion grasping "exchange" conception. The 
word exchange assumes that there is 2-directional flow between 2 
entities. But Filter has only one direction: from one component to 
another. So exchange between what and what is happening?
In/Out is perspective of component. The component is given In message 
and must provide the Out message. But it is not "exchange" it is rather 
replacing In with Out.
Now, on practical side, there is no need to provide both In and Out at 
the same time. We can assume that component will return its answer in 
the same object. But I'm failing to see any practical benefits. IMHO it 
is the same, just matter of variable allocation.
I think Roman's (and mine) frustration comes not from the fact that 
there are in/out but from the fact that they are too relaxed and it is 
not clear when In is Out :) So stricter rules should address this concern.

I have implemented  a small message routing system for internal needs at 
works and I used Soap idea of Envelope with properties and payload - 
body. So I have no Exchange entity as such. All service information, 
like number of faults, etc is in the envelope header. The processor 
function itself is an exchange:
"public MessageEnvelope Process(MessageEnvelope env);"
Later I faced a need to implement a splitter which produces more then 
one message so I modified interface to return array of messages:
"public MessageEnvelope[] Process(MessageEnvelope env);"
In Camel there is a special type of processor to handle this. In my 
design any component can do broadcast by returning multiple messages.

You can do all the things you do in camel in/out exchange.
You can return null which would mean "no outputs, stop processing"; you 
can return exact the same object you received for logging for example; 
you can create a copy of object, modify it and return; you can create a 
bunch of new messages and return then.

In/Out notation is pretty much the same as described above but ability 
to modify In message and leave Out null brings uncertainty. Should I 
modify In or create Out? Why the heck In work as Out? Does componentX 
use In or Out? etc.
I would think about making rules more strict: result is always in Out. 
Providing many ways of doing the same thing without benefits is a bad 
idea. You'll spend infinite amount of time explaining newbies what 
in/out thing is. Principle of the least surprise :)

Another note about HTTP request/response.
I think it has nothing to do with Camel. Camel In/Out implements 
conception of filter. You have a message asking to convert X $USD to 
EUR. Your component use http to do it. So what the output of your 
component is, http response? I doubt it. It is a message with EUR 
amount. The whole http request-response is internal business of 
component. Http request-response in an Exchange, when Camel Filter is not.

So my opinion is:
1. Faults must be removed and exceptions used instead like any WS 
framework does.
2. "In" must be In and Out must be Out, meaning In can not be modified 
and Out *must* be set; no tricks "if out is null then interpret In as 
Out". We should agree what to do with "null" out. Is it an error or it 
means "no messages to process, stop the pipe"?


P.S. Great discussion btw.

Claus Ibsen wrote:
> Hi
> Just a quick mail to get the discussion rolling.
> I think we should @deprecated exchange.fault in Camel 1.5 and remove it in Camel 2.0.
> It is a confusing concept that isn't used much, and many components doesn't handle the
FAULT message. For instance it was missing in camel-jms a very central component.
> Med venlig hilsen
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web:

View raw message