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 03:06:25 GMT
Mostly a social issue, but I totally agree.

Also keep in mind when you compare options that Camel is a framework, 
not a product and BPEL in this context actually means not the spec, but 
a specific box-wrapped interpretation of it sold as a product.

$0.02 + tax

On 09/14/2012 09:55 AM, Donald Whytock wrote:
> Something that's gelled from conversations I've had at my workplace is
> that there's a perception difference between commercial software and
> FOSS.  Yes, I was one of those that, in this very thread, said
> "Camel's a lot cheaper".  But that's at least partly because I for one
> use it in personal hobbies and would avoid buying something
> commercial.
> In the corporate world, though, free software isn't free.  It requires
> paying people to understand it, implement it, maintain it, etc.  These
> costs can be estimated, but estimates are estimates; there's nothing
> guaranteed.
> Commercial vendors, on the other hand, don't offer estimates.  They
> offer invoices.  You can literally buy a box of Oracle, off the shelf
> in better neighborhoods.  How much Oracle do you want?  Okay, that'll
> be $X.99 plus tax.  It's a nice, simple answer that a vendor in a suit
> can present to a manager and have the manager understand it.
> Microsoft does that too.  I believe that's the reason a company that
> already uses Java might find itself trending toward .NET.
> Yes, POC might help, especially in the form of working in-use
> applications.  But if you don't have that already, someone might go
> buy a box of BPEL while you're building it.
> Good luck.
> Don
> On Fri, Sep 14, 2012 at 9:11 AM, Henryk Konsek <> wrote:
>>> 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