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
