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
perspective!
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.
In/Out
==============
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"?
Vadim.
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: www.silverbullet.dk
