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
Hadrian

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 <hekon...@gmail.com> 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
http://henryk-konsek.blogspot.com

Reply via email to