Return-Path: Delivered-To: apmail-camel-users-archive@www.apache.org Received: (qmail 72334 invoked from network); 25 Sep 2010 11:38:10 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 25 Sep 2010 11:38:10 -0000 Received: (qmail 54233 invoked by uid 500); 25 Sep 2010 11:38:09 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 53920 invoked by uid 500); 25 Sep 2010 11:38:06 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 53912 invoked by uid 99); 25 Sep 2010 11:38:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Sep 2010 11:38:04 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of claus.ibsen@gmail.com designates 209.85.216.180 as permitted sender) Received: from [209.85.216.180] (HELO mail-qy0-f180.google.com) (209.85.216.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 25 Sep 2010 11:38:00 +0000 Received: by qyk5 with SMTP id 5so5231763qyk.11 for ; Sat, 25 Sep 2010 04:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=GrGmhqrpjBIKeQJv8bBlfbsp+4zTodLM1djiC9dBueM=; b=N1MVfDtZGf+WMFfbzj4lgbkIdQE2f5TPqxuE6Nj3XRBf6QHleYeRyhZz87+WoqcKV8 8ewNigDBWZXafj7pUDX6PRBSys3eZeI9gMIP5PB8jxkeMl7wvnwBEYKqhdpus4ixRiwz 3lYhLyqloZ9pV02T6wswG/26BfJQXs8ZHKZwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=pNSMoua/kw/fRRMDvTnJ/N45ElIjknMFzI++Y8olCvEryuE7rcOKNw5AsY1aS8EWPj 6yIEO9iMZXPFd6sqNm4LFfaJFh/2tLtDGlnLLOLT5CCdqrC/c6drdCHfklb56E50Em9L aWKa9uUyGXs8N/+WbAAfo0lH+yjhZngT3n+WA= Received: by 10.229.246.194 with SMTP id lz2mr3496557qcb.216.1285414659224; Sat, 25 Sep 2010 04:37:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.11.22 with HTTP; Sat, 25 Sep 2010 04:37:18 -0700 (PDT) In-Reply-To: <469FCFF1-CDE9-4B25-8646-E3CAC9D51291@gmail.com> References: <1284301625054-2836790.post@n5.nabble.com> <1284368604504-2837443.post@n5.nabble.com> <24732_1285332243_4C9C9D13_24732_12726_1_9A0AC53E58D55946ADB5B1AA8AB75D7C3F1221B980@PUEXCB2C.nanterre.francetelecom.fr> <469FCFF1-CDE9-4B25-8646-E3CAC9D51291@gmail.com> From: Claus Ibsen Date: Sat, 25 Sep 2010 13:37:18 +0200 Message-ID: Subject: Re: Camel Exchange Patters To: users@camel.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. S= o it's really not jbi not even wsdl, but the same model, that's mostly rela= ted 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. http://download.oracle.com/javase/6/docs/api/javax/xml/ws/package-summary.h= tml 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. http://camel.apache.org/maven/camel-2.2.0/camel-core/apidocs/org/apache/cam= el/ExchangePattern.html > 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 p= roposing 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 discussio= n again. Otherwise it's just a useless statement, that would bring more con= fusion 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 https://issues.apache.org/activemq/browse/CAMEL-3157 > 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 wr= ote: >>> Let's not get there (again). The community agreed already at least twic= e that this api is a good abstraction of what we try to do. As any abstract= ion it has to be properly documented. If it's not clear enough, that's wher= e 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 specifi= cation. >> >> 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, =A0 wrote: >>>>>> "But the Camel routing engine will automatic handle using IN if ther= e >>>>>> 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 c= onfusing 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. >>>> =A0 =A0getMessage() >>>> >>>> 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 > > --=20 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