camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: in/out/fault messages discussion
Date Wed, 30 Jan 2008 19:23:10 GMT
Hi Roman,

But it already is like that, sort of.  If you like, imagine that your  
message has a tag (out/fault) that tells us how that message got  
there, that we also keep the previous message around (in).


On Jan 30, 2008, at 1:52 PM, Roman Kalukiewicz wrote:

>>> As I understand it the whole reason Exchange exists is to model the
>>> correlation between the in/out/fault messages, not their format.
>>> Maybe the abstraction is too leaky to hide, but I thought that's
>>> what Camel was trying to do.  If you remove the distinction from
>>> Camel's API, it then becomes the responsibility of the players
>>> involved in the to keep track of the correlation.  That, to me
>>> anyway, sounds like it makes life more difficult for users of Camel,
>>> or at the least, anyone implementing a Camel component.
>>> As Hadrian said, I think a number of your concerns can be address by
>>> revisiting Pipeline and a few of the core routing mechanisms.  The
>>> in/out/fault distinction may not be clear or consistent throughout
>>> Camel, and rmaking it so is not a simple task,
>> I don't think it's a major effort either.  For the most part Camel
>> *does* things right.
> Maybe I should state it clearly -- I really believe that Cames *does*
> things right, and it is not a huge effort to correct things that are
> not working right in current model.
> On the other hand the whole discussion starts with my feeling that in
> Camel we have some flow, and the message that flows through the flow.
> _One message that simply flows through some number of steps_. This is
> the simplest possible model of the flow in Camel.
> The basic question is if this simple model is strong enough to
> describe everything we need. I believe, that it is, and I was trying
> to prove it with the patch I shown.
>>> For example, as you point out, the in/out distinction is clunky to
>>> processors that only want to modify a message or pass it along.  The
>>> convention or shortcut that's come about for these cases is merely
>>> modifying/using the In message, and having Pipeline forward it
>>> along.  Perhaps some benefit could come from further utilizing
>>> ExchangePattern, or generating better default wrappers from the DSL.
> Current model (even if it requires some fixes) with in/out/fault works
> and maybe it is even easier for someone using SOAP or JBI, but (I
> think) Camel shouldn't try to model SOAP, JBI, Java or something else.
> It is about patterns, and messages. If I think about messages flowing
> through my flow, what is the difference between body(), outBody() and
> faultBody()? It is the body of the message, period.
> Maybe it is my problem that I see those flows, as flow of a message?
> My perception is like "read the message from here, then process it
> this and this and that way and send it somewhere else". I think about
> it as a one message. Maybe majority of people see it as a set of
> exchanges between different processors or in some other way?
> If this is my perception of those flows, then I would like to see it
> in DSL and in APIs, because Camel tries very hard to match my
> perception of the flow. This is the biggest strength of Camel.
> Just by the way I think, that it could solve some of our problems, but
> it is not the core of my concerns.
> BTW Thanks for all your $0.02 ;)
> Roman

View raw message