Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of roman.kalukiewicz@gmail.com
 designates 72.14.204.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=K0WFnV2p2AlbPeOgL6eL3VnRIj7C93nefkpzs4v6BShIC5q40p7kf9qf9sfhS7YiF/jOTcOJrclfX9kJb83s68Ld48FA2WI0EcCf4YcW07A+xpDSkEr95JDipzknnk0LSFsje7FlqU7Klk6+M6cDmPcs9SI8SN8nsgjcdac5mIA=
Message-ID: <f1c427510801301052s26fd9441l1f51f77eb282812f@mail.gmail.com>
Date: Wed, 30 Jan 2008 19:52:20 +0100
From: "Roman Kalukiewicz" <roman.kalukiewicz@gmail.com>
To: camel-user@activemq.apache.org
Subject: Re: in/out/fault messages discussion
In-Reply-To: <EBFEEEDA-E7B7-495C-803A-C1E169708DBE@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <f1c427510712050335j22a73fb1u619bbd258a06b30c@mail.gmail.com>
	 <1D64AF3E-A69A-44DE-9DAB-F0EB238A8326@intalgent.com>
	 <EBFEEEDA-E7B7-495C-803A-C1E169708DBE@gmail.com>

> > 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