Return-Path: Delivered-To: apmail-activemq-camel-user-archive@locus.apache.org Received: (qmail 94160 invoked from network); 17 Oct 2007 13:38:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Oct 2007 13:38:10 -0000 Received: (qmail 16938 invoked by uid 500); 17 Oct 2007 13:35:26 -0000 Delivered-To: apmail-activemq-camel-user-archive@activemq.apache.org Received: (qmail 16924 invoked by uid 500); 17 Oct 2007 13:35:26 -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 16913 invoked by uid 99); 17 Oct 2007 13:35:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 06:35:26 -0700 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of james.strachan@gmail.com designates 66.249.82.231 as permitted sender) Received: from [66.249.82.231] (HELO wx-out-0506.google.com) (66.249.82.231) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 13:35:27 +0000 Received: by wx-out-0506.google.com with SMTP id s14so2751406wxc for ; Wed, 17 Oct 2007 06:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=iKs4pwSdZt6AjndxYkVj+uI8WX/3ynJrIap6Ovevtzw=; b=fdVFabiQzFMpEa3th5+Y2+0Su2R1l8w5+V4QipFswhr1ZNt2bIoLiwsOoBs7HKmd0gjXIcbpk4BQrfjINNad9/jGZ8eogDSD6FD03XEvZC6Hn2eI9JpavIW0X/dtFTFsAn7rrfxXhA0Q8gDZjZcVJQ7xWOkvGEBKe2XGcum0ldg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oReEZK85rp6NvadIkB1B//+7NLrbnY5BFmqdOWWhym6RwnEZbVtJ7XvY7vN/tAkAjbS2gmvsyBBbA6wjUz4D9PtMqaXMmZznmYsEDQpFkQ6VKxkRouCiArk2A9237LHGRaFMjpGINZLlxCcXV/QNL0g03UuvyF3hVEdBxbdVr5E= Received: by 10.90.56.11 with SMTP id e11mr12663024aga.1192628105994; Wed, 17 Oct 2007 06:35:05 -0700 (PDT) Received: by 10.90.67.7 with HTTP; Wed, 17 Oct 2007 06:35:05 -0700 (PDT) Message-ID: Date: Wed, 17 Oct 2007 14:35:05 +0100 From: "James Strachan" To: camel-user@activemq.apache.org Subject: Re: Camel based workflow In-Reply-To: <13247738.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <13247738.post@talk.nabble.com> X-Virus-Checked: Checked by ClamAV on apache.org On 17/10/2007, dmd wrote: > Hi all, > > I saw someone comment on the upcoming integration of Camel into ServiceMix, > http://www.nabble.com/Camel-and-ServiceMix-tf4443716s22882.html. I am > curious how Camel compares to Apache ODE (if at all). >From a high level, ODE is an orchestration engine; using a persistent model of business processes with steps and state. Camel is primarily a routing and integration engine; integrating endpoints together using routing rules with different transports... http://activemq.apache.org/camel/components.html to implement different enterprise integration patterns... http://activemq.apache.org/camel/enterprise-integration-patterns.html So they have kinda different focusses; ODE focusses on creating an executable stateful business model; Camel focusses on integrating anything to anything in a frequently stateless way using EIP. Both could be used together; e.g. Camel could route different transports together and feed them into an ODE business process. > For some background, here's the problem I need to solve. I am building an > order execution system, which receives some kind of complex (financial) > transaction from a user, and then must talk to several endpoints (such as > several exchanges) in order to execute it. The workflow is asynchronous, > can have exception cases, etc. And of course it must be fault tolerant, in > the sense that if the execution engine, or an exchange gateway, crashes, it > must be able to restart and retrieve it's state from some durable > transactional store (e.g. RDBMS) and get back on track. > ODE seems to be able to do what I need. If you were to use ODE then you'd probably write services & WSDLs then write a BPEL to describe the orchestration; of how messages flow from the endpoints to the process etc. Camel tends to focus on binding endpoints (like transports) to beans & components; so each service in the process would just be a POJO thats bound to some JMS endpoint or whatever. In the Camel approach its up to a specific bean to do whatever state management it wants; rather than there being a central, generic business process model. More detail of how Camel binds to beans here... http://activemq.apache.org/camel/bean-integration.html You could use either approach really; whatever seems most natural to you. What I would say is that these days, middleware and infrastructure should be mostly invisible apart from maybe a few annotations here and there. i.e. I'd recommend you write most of your services as just POJOs then bind them to whatever middleware you're using (say web services or using Camel to bind JMS messages to bean methods or whatever). > However, I am looking into Camel > because it's nicely integrated with ActiveMQ, which is being used as the > transport between my services, and it seems more lightweight. However, I > can't tell if it's powerful enough, or expressive enough to solve this > problem with. In Camel for example, you could write a bean to represent your business logic, then create proxies for services for remote services that are bound to a JMS queue; then your logic and code is just regular Java I guess the place to start is - how do you want to design and implement your business process? In BPEL - if so ODE's what you want. If its POJOs bound to message queues (maybe with some content based routing or transformation) then Camel might be better. > I did look at the BAM example, > http://activemq.apache.org/camel/bam-example.html, but so far the bulb has > not lit up. :) So the BAM stuff is more like the inverse of ODE. Imagine you have a bunch of systems in your company that are already integrated together. So system A generates events that are sent via some transport to system B which also has some kind of output. BAM is all about monitoring an existing process - something which already exists in some form which might be Java code, BPEL, duct tape, carrier pigeons, humans dual-typing - whatever. The basic concept is rather like having probes you add into an existing electricity circuit in a building; to check things are still flowing as they should. Its not really meant to be the flow - its more to monitor an existing flow to check its working as expected. So BAM kinda reverse engineers an existing business process by monitoring messages and correlating them together - by being outside of the flow but just monitoring business events. ODE / BPEL are the other way around - they are for creating new business process where they are the real business process in the middle of the flow. If you are using ODE/BPEL then you'd probably use your ODE/BPEL engine to monitor processes. However if they are legacy systems wired together somehow; then BAM comes in. > Lastly, is it the case that the payload of messages must be XML in order to > be interpretable by Camel rules, or could I send serialized Java objects > and/or FIX messages? It can be any POJO for the payloads. Indeed we support Artix Data Services for the payloads; so you can use a commercial FIX/SWIFT/FpML/FixML handling library for marshalling and unmarshalling messages, transforming between data formats and doing XQuery routing on POJOs etc. http://activemq.apache.org/camel/artix-data-services.html -- James ------- http://macstrac.blogspot.com/ Open Source SOA http://open.iona.com