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 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. 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). 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 <hzbar...@gmail.com> 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, <patrice.god...@orange-ftgroup.com> wrote: >>>>> "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: http://www.manning.com/ibsen/ >>> Open Source Integration: http://fusesource.com >>> Blog: http://davsclaus.blogspot.com/ >>> Twitter: http://twitter.com/davsclaus >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus
