Never forget that with a BPEL engine, all the steps (= status change ) defined in a Process must be saved in a DB. With Camel a process could be a camel route or a collection of camel routes and one camel exchange (= message) can pass though a collection of processors (= steps defined in a BPEL workflow). That will simplify your architecture as we can group steps in a camel route or split them through a collection of camel routes. If persistence is required to avoid to loose information carried by camel exchanges, then you can use one of the camel persistence component supported (JMS, JDBC, JPA, SQL, iBaitis, myIbatis, Hibernate, ...)
On Fri, Sep 14, 2012 at 12:40 AM, Christian Müller < christian.muel...@gmail.com> wrote: > it's cheaper (Camel is for free) > it's simpler (the Camel DSL is much more readable and understandable) > it's more flexible (it works with any kind of payload) > it supports more protocols (more than 120 at present) > it's more open (you can extend Camel yourself and add new components) > it has a very good community which helps other users (Red Hat CEO Jim > Whitehurst says: In the ESB case, that leading community is the Apache > Camel project: http://tinyurl.com/bphnwfm) > > Best, > Christian > > On Wed, Sep 12, 2012 at 8:05 PM, mfcplus <mfcp...@yahoo.com> wrote: > > > Hi, can anyone give some really good convincing stuff that why should we > > use > > camel over BPEL? I'm trying to convince somebody here to use camel > instead > > of oracle SOA 11g that has BPEL engine as so called 'orchestrator'. any > > references, materials are good, and especially like to have some input > from > > the gurus > > > > many thanks > > > > > > > > -- > > View this message in context: > > http://camel.465427.n5.nabble.com/oracle-BPEL-vs-camel-tp5719204.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > > > -- > -- Charles Moulliard Apache Committer / Sr. Pr. Consultant at FuseSource.com Twitter : @cmoulliard Blog : http://cmoulliard.blogspot.com
