camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Camel Exchange Patters
Date Sat, 25 Sep 2010 11:37:18 GMT
On Fri, Sep 24, 2010 at 4:08 PM, Hadrian Zbarcea <> wrote:
> But see, that's the thing, the model and api is not based on jbi, and we should correct
that in the wiki as well. Web services use the same model. So it's really not jbi not even
wsdl, but the same model, that's mostly related to the integration space than a spec in particular.

I think I should emphasize that I am talking about the confusing when
to use the getIn or getOut method on the Exchange. That part of the
API came from Apache ServiceMix when Camel was created. Other
frameworks, which are in the integration space as you put it, do not
have such methods. They simply have a single method named getMessage
(or something similar).

If you look in the WS API which comes out of the box with the JDK 1.6
onwards. You will not find the notion of a getIn or getOut methods to
retrieve a Message.
At least I could not find it when looking and I dont recall having
used it when using WS from the JDK.

Of couse messaging has the concept of the MEPs. It may be named
something else such as: one-way, fire-and-forget, request-reply,
request-response or as in the EIP book: event message and request
reply pattern. That part of the Exchange API is good.

Albeit the ExchangePattern enum used the WSDL standard names such as:
InOnly, InOut and then many others which are hardly know and used by
end users.

> I personally think jbi is pretty much dead, yet it does not affect Camel even a tiny
bit. There are many other innovations Camel brings such as the independence on xml payloads,
eips and a bunch of other goodies.

Yeah here we agree about the JBI being on the downslope and it will
become another dying spec.

> Please continue to express your personal views, we highly value them, and I encourage
everybody in the community to do so. However, if you are not proposing a change (you seem
to think that's better to leave it as is), why make the comment? If you however want to bring
it up again, especially with camel 3.0 on the horizon, please be blunt about it and start
the discussion again. Otherwise it's just a useless statement, that would bring more confusion
to users than help anything. Or make such statement on the dev@ list rather than user@ (which
is what I should have too).

Hadrian let's not go down this path, it may just be mistaken and
perceived as personal.

No I am not starting a debat about API changes for Camel 3.0. We have
debated this before and I think its best to keep the development cycle
of Camel 3 short and keep the API compatible with 2.x so people can
have a smooth transition. In fact we should start a thread about the
Camel 3.0 on the @dev forum shortly.

Therefore if we can improve the javadoc documentation and FAQ entries
then that would be good. Here is a JIRA ticket about this work

> My $0.02,
> Hadrian
> On Sep 24, 2010, at 9:30 AM, Claus Ibsen wrote:
>> On Fri, Sep 24, 2010 at 3:22 PM, Hadrian Zbarcea <> wrote:
>>> Let's not get there (again). The community agreed already at least twice that
this api is a good abstraction of what we try to do. As any abstraction it has to be properly
documented. If it's not clear enough, that's where I would focus.
>> I can't recall we agreed this twice or more (since you say at least).
>> There was a heated debate about the API. And yes I think we should
>> leave it as it.
>> On the other hand I am entitled to express my personal view on the API.
>> And it may be interesting for people in the community to hear from a
>> committer who was worked 30+ months on Camel, his though of the
>> Exchange API.
>> There has been many Camel users who got started with Camel that got
>> confused / very confused about the API.
>> So its definitely not good, despite its nature back from the JBI specification.
>> Competing integration frameworks such as Mule and Spring Integration
>> has a simpler Exchange API in this area.
>> And the future of JBI is also dubios. So you may questions where if
>> someone creates a new integration framework, whether
>> he/she will go down the path of JBI and chose to have a getIn and
>> getOut methods on his/her's "Exchange" type.
>>> Hadrian
>>> On Sep 24, 2010, at 8:53 AM, Claus Ibsen wrote:
>>>> On Fri, Sep 24, 2010 at 2:51 PM,  <>
>>>>>> "But the Camel routing engine will automatic handle using IN if there
>>>>>> is no OUT message."
>>>>> So this is the magic behind! :-)
>>>>> I don't remember reading this anywhere previously and I was wondering
how data was flowing from in to out messages.
>>>>>> Working on IN is just much easier to explain and use for end users.
>>>>> Honestly it was confusing to me.
>>>>> Writing something to an "in" message to make it go "out" was really confusing
to me.
>>>> Yeah the API is not optimal there. We have debated this many times on
>>>> the dev forums.
>>>> I personally would remove the IN and OUT and only keen one message.
>>>>    getMessage()
>>>> But the current API is kinda stuck due it been there since 1.0 and the
>>>> old legacy from JBI and whatnot.
>>>>> *********************************
>>>>> This message and any attachments (the "message") are confidential and
intended solely for the addressees.
>>>>> Any unauthorised use or dissemination is prohibited.
>>>>> Messages are susceptible to alteration.
>>>>> France Telecom Group shall not be liable for the message if altered,
changed or falsified.
>>>>> If you are not the intended addressee of this message, please cancel
it immediately and inform the sender.
>>>>> ********************************
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>> Author of Camel in Action:
>>>> Open Source Integration:
>>>> Blog:
>>>> Twitter:
>> --
>> Claus Ibsen
>> Apache Camel Committer
>> Author of Camel in Action:
>> Open Source Integration:
>> Blog:
>> Twitter:

Claus Ibsen
Apache Camel Committer

Author of Camel in Action:
Open Source Integration:

View raw message