Return-Path: Delivered-To: apmail-camel-users-archive@www.apache.org Received: (qmail 82068 invoked from network); 27 Mar 2009 04:03:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 27 Mar 2009 04:03:53 -0000 Received: (qmail 79270 invoked by uid 500); 27 Mar 2009 04:03:52 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 79209 invoked by uid 500); 27 Mar 2009 04:03:52 -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 79199 invoked by uid 99); 27 Mar 2009 04:03:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Mar 2009 04:03:52 +0000 X-ASF-Spam-Status: No, hits=4.0 required=10.0 tests=DNS_FROM_OPENWHOIS,FORGED_YAHOO_RCVD,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Mar 2009 04:03:43 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Ln3Hu-0001o6-B2 for users@camel.apache.org; Thu, 26 Mar 2009 21:03:22 -0700 Message-ID: <22735782.post@talk.nabble.com> Date: Thu, 26 Mar 2009 21:03:22 -0700 (PDT) From: ychawla To: users@camel.apache.org Subject: Re: CXF Guidance In-Reply-To: <49CC4967.9030008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: premiergeneration@yahoo.com References: <22735251.post@talk.nabble.com> <49CC4967.9030008@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Hi Willem, Thanks for the response. Fortunately the web service only drops off a message and returns a unique message id to the invoker. This can be viewed as a synchronous request / response cycle. In parallel with sending the user this confirmation, the message is multicast into the workflow queues, and then there is another web service on the other side to allow a user to pick it up after Camel has had its way with it :-) The part of my app that I am concerned about is the drop off request / response cycle. I am starting out at the CXF component page: http://camel.apache.org/cxf.html Is there a simple camel example that will consume a CXF web service, run the payload through a camel route, and then create/return a web service response. I have the Camel route all setup and now I just want to integrate with the CXF web service that has a few interceptors. I am at home now, but I will post the routes I have setup tomorrow. Cheers, Yogesh PS. Love the article about SABRE. What a great achievement for Camel and FUSE. willem.jiang wrote: > > Hi, > > Maybe you should take a look at the LoanBroker example[1] of Camel. > There are two versions of Loan Service which look like your application. > > It is not easy to adapter an asynchronized JMS message system with the > Request/Response WebService message model effectively. Maybe you need to > do some modification on your routing rule. > > [1] http://cwiki.apache.org/CAMEL/loan-broker-example.html > > > Willem > > ychawla wrote: >> Hello Fellow Camel Riders, >> I have an application that is using camel for routing and it working >> quite >> nicely. There are two allowed input paths for a message, one is a web >> service and the other is direct file system access. >> >> When a user drops a file onto the file system, it is processed by the >> file >> component, validated, assigned a message ID, routed to workflows (JMS >> queues) and a confirmation or error is sent to a folder for the end user >> to >> inspect. >> >> Our current strategy with the web service is to extract a message payload >> and write it to the file system folder that is polled by the file >> component. >> The web service will then poll a confirmation or error folder and then >> reads >> the confirmation or error and uses that to create a web service response. >> >> The polling done by the web service is making me increasingly nervous >> because it is a recipe for performance problems. Seems like way too much >> unnecessary file I/O. >> >> The web service is written in CXF and the Camel Routes are already setup. >> It seems like we just need to wire the CXF web service to the routes we >> already have. We also want to wire the web service response to either >> the >> confirmation or error rather than writing it to the file system and then >> reading it from there. >> >> I am assuming this is all possible through the CXF component, but I want >> to >> confirm that I am interpreting the functionality of the CXF component >> properly. Will this work? Where should I get started? >> >> Cheers, >> Yogesh > > > -- View this message in context: http://www.nabble.com/CXF-Guidance-tp22735251p22735782.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.