camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: Camel vs BPEL
Date Wed, 19 Sep 2012 02:59:59 GMT
Finally somebody who pointed out the real difference. Thanks Bruno.

Camel is stateless, WS-BPEL is stateful! If you need to deal with state, 
which is usually the case, Camel will only partially help. You'll have 
to deal with persistence and correlation yourself. For simple projects, 
it's next to trivial, for larger ones, not so much.

OTOH, BPEL only knows/cares of WS, using it together with Camel extends 
the reach of your business process orders of magnitude. So in some cases 
Camel can substitute BPEL, in most others it complements it really well.


On 09/14/2012 01:55 PM, Bruno Borges wrote:
> 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
> **
> On Fri, Sep 14, 2012 at 2:45 PM, Omar Atia <> 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 []
>> Sent: Friday, September 14, 2012 4:12 PM
>> To:
>> 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

View raw message