Hello!
I have few fundamental questions about in/out/fault messages inside Camel.
My impression is that they were introduced because of the model that
exist in JBI where this distinction is in JBI spec. On the other hand
by belief is that this separation of in/out/fault messages makes more
problems that it solves. Another question is if it solves anything -
if I cannot see it then let me know.
Everything is based on behavior of pipeline element that:
* if there is some step of pipeline that returns out message, then it
takes it and copies it into in message of the next exchange
* if there is no out message then it copies this in message into in
message of next exchange.
It is natural behavior. But what happens with fault messages? I could
check it in the code easily but what is the natural behavior? If there
is exception then we already know what happens - it is handled by
exception() clause or is catched by catch() clause - anyway exceptions
are thrown and behavior of the flow reflects it. But what with
faults??
My examples are based on DSL notation as I don't use XML at all.
what this code does?
from("jms:inQueue").setBody(constant("abc")).setHeader("bar",
constant("foo")).to("jms:outQueue");
it takes the message from inQueue, sets body to abc, sets bar header
to foo and sends jms message with bar property set and 'abc' body -
moreover it propagates every property of the original message to
outgoing message.
what this code does?
from("jms:inQueue").setOutBody(constant("abc")).setOutHeader("bar",
constant("foo")).to("jms:outQueue");
basically it sends EMPTY JMS message with "bar" property set. It
doesn't have any body as it is dropped by underlying pipeline when
setOutHeader() sets a header on out message while in message contains
"abc" (it is in message as it was copied by pipeline from previous
out)
if we change the order of setOutHeader() and setOutBody() we will have
"abc" text message without any headers.
how to remove all headers from your message now? it is easy:
setOutBody(body()) - we don't have removeAllHeaders() processor (but
it is easy to add anyway - it is not a problem)
all those examples show that the notation becomes VERY unnatural if
you use out messages. What when some processor sets faults? How to
handle this scenario in your flows? Faults are business faults and
they should flow through the flow - they are not exceptions.
if someone will argue that in and out messages are important, because
we want to have an access to in message while we create out message
then the answer is simple. The only place you could use it is in your
processor (because in message is lost at pipeline). Then the answer is
local variable that could hold the original value.
If you want to distinguish fault messages somehow - do it with headers
like 'http.responseCode' header - BTW if response code is not 200
should the response be in out or fault message?
I'm wondering why Camel doesn't have this structure:
* exchange with properties that are used for application specific data
- those things should be propagated via all endpoints as it happens
now
* only one message where body represents the payload we actually use -
this is used as in message as it reaches an endpoint/processor and is
used as out message when it leaves the endpoint
* message contains headers that are protocol specific - are used to
store JMS properties, HTTP headers, whatever else. they are sometimes
propagated through a processor (like setBody() or setHeader()) or
replaced in other cases (like jms endpoint invocation when headers are
replaced with properties on incoming JMS message)
This way we don't have any problem with strange behavior of pipelines,
we don't care about exchange.getOut() (when you accidentally
lazy-create out message that gets propagated), and we don't have
faults that are not really used in many points (I haven't seen them so
far).
The mail is pretty long so if you reached this point - thank you! ;)
If I'm mistaken in some points - let me know. If you like
in/out/faults or know the reason we need them/they help us - let me
know.
I don't really know if those ideas could be implemented in camel - I
know that it touches the very core architecture of the framework. I
just wanted to share my thoughts.
Thanks for great framework anyway! ;)
Roman
