IMHO, BPEL is about Business Process, and Camel is about Message Processing, although both can be used for the same thing (business or message).
But what about human tasks in the middle? Persistence is important because your process may not be atomic. So if you go for Camel or any other product (MuleESB comes to mind), you will have to implement all these business process control and persistence on your own. jm2c *Bruno Borges* (11) 99564-9058 *www.brunoborges.com* On Fri, Sep 14, 2012 at 2:45 PM, Omar Atia <omar.a...@its.ws> wrote: > Adding to this BPEL is slow in performance for heavy load activities. > > Camel is the best solution you go for , even spring DSL configuration you > can do the same. > > -----Original Message----- > From: Henryk Konsek [mailto:hekon...@gmail.com] > Sent: Friday, September 14, 2012 4:12 PM > To: users@camel.apache.org > Subject: Re: Camel vs BPEL > > > Hi, can anyone give some really good convincing stuff that why should > > we use camel over BPEL? > > Call me stupid, but BPEL is too complex for me. :) > > If I want to orchestrate two WS endpoints and perform some transformation > on the data, I would like to express this with a few lines of DSL. > > I'm technical guy and one of the things I'm paid for is to estimate the > cost of deploying given technical solution. In my opinion investing into > the BPEL is expensive. BPEL is complicated and inflexible. Only abusive > volume of legacy BPEL code will convince me to suggest somebody to stick to > the BPEL. > > I don't see any value in the BPEL complexity. > > -- > Henryk Konsek > http://henryk-konsek.blogspot.com >
