Return-Path: Delivered-To: apmail-activemq-camel-user-archive@locus.apache.org Received: (qmail 55049 invoked from network); 21 Jan 2008 16:19:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Jan 2008 16:19:37 -0000 Received: (qmail 9219 invoked by uid 500); 21 Jan 2008 16:19:27 -0000 Delivered-To: apmail-activemq-camel-user-archive@activemq.apache.org Received: (qmail 9203 invoked by uid 500); 21 Jan 2008 16:19:27 -0000 Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: camel-user@activemq.apache.org Delivered-To: mailing list camel-user@activemq.apache.org Received: (qmail 9193 invoked by uid 99); 21 Jan 2008 16:19:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jan 2008 08:19:27 -0800 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=DNS_FROM_OPENWHOIS,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; Mon, 21 Jan 2008 16:19:13 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JGzMX-0002Pj-8Y for camel-user@activemq.apache.org; Mon, 21 Jan 2008 08:19:05 -0800 Message-ID: <15000862.post@talk.nabble.com> Date: Mon, 21 Jan 2008 08:19:05 -0800 (PST) From: Wilson To: camel-user@activemq.apache.org Subject: Re: About JIRA issue CAMEL-180 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: wilson.lists@gmail.com References: <50174d00801081653sa2ee96bld92019af6c809387@mail.gmail.com> <478439C4.4000108@gmail.com> <14711292.post@talk.nabble.com> <4784D41D.8060407@gmail.com> <14720958.post@talk.nabble.com> <47858FD5.5040504@gmail.com> <14731161.post@talk.nabble.com> <14753660.post@talk.nabble.com> <47877AA2.4040104@gmail.com> <14760729.post@talk.nabble.com> <47886A05.9020604@gmail.com> <14806628.post@talk.nabble.com> <478C78E1.2050508@gmail.com> <14839833.post@talk.nabble.com> <478DA890.3060209@gmail.com> <14996491.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org Hi, Well, I am new to ESB approach so maybe I am not thinking the right way to meet the requirements. I will try to list my requirements for the project I am working on: --------------------------------------------- - The same system will be installed in several nodes in distinct networks. The nodes are connected using the Internet. - Each node needs to exchange information with each other. I think that HTTP is the obvious choice for the message exchange. The bigger part of the exchanges can be inOnly and asynchronous but I need to make sure the message will be received by the target node. - The nodes need to send messages to third party web services. If these web services are down or slow the nodes must keep sending the inOnly messages normally. The ESB must hide any problems related to the third party web services. Message lost is not allowed. - The message exchanges must be secure so I want to use HTTPS. --------------------------------------------- I am planning to use an ESB server running Camel or Servicemix or both. The ESB server will control all message exchanging. My idea is to put queues in front of the web services. When a node send a message (via SOAP), the ESB will put it in a JMS queue and send acknowledge back to the sender. Another endpoint will consume from the JMS queue and send the SOAP request to the third party web service. This way if the third party web service is down or slow the client can keep sending messages. Is there another way to achieve this? Thank you, Wilson James.Strachan wrote: > > On 21/01/2008, Wilson wrote: >> >> Hi Willem >> >> Unfortunately I need this feature and I can't wait until Camel provides a >> stable implementation. >> I tested the Servicemix cxf-bc component and it works using an activemq >> queue between the HTTP endponts. In my opiniou Camel is easier and >> cleaner >> than pure JBI, but I think I am forced to use Servicemix this time. > > Just out of interest I wonder if you could explain your use case so we > can see where the camel approach breaks down? > > Are you connecting 2 HTTP endpoints together using a JMS queue in > between? Or just exposing an existing SOAP/HTTP endpoint over > SOAP/JMS? I've been getting a bit confused in this thread with the > exact scenario folks are talking about :) > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > > -- View this message in context: http://www.nabble.com/About-JIRA-issue-CAMEL-180-tp14702992s22882p15000862.html Sent from the Camel - Users mailing list archive at Nabble.com.