camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <r...@evosent.com>
Subject Re: Camel vs BPEL
Date Sun, 16 Sep 2012 17:44:50 GMT
In a typical enterprise architecture, you've got a) the need to orchestrate
services to compose business processes which, b) rely on neutrally-exposed,
proxied and mediated services that may perform lightweight orchestration and
routing.

Whether you end up using Camel for a) or not (I'm assuming that you are
using Camel for b - as it's the best fit ;)), you should really
differentiate between those two layers at least. Camel is definitely a great
fit for both, but there are tradeoffs.

Camel's support for so many Enterprise Integration Patterns makes it good
for implementing orchestration flows, and its error handling/compensation
features are on par with BPEL. 

A good point about BPEL is that the data transformation/assignment rules can
be expressed inside the BPEL process. But they are essentially limited to
XPath, XQuery and XSLT. With Camel, you have more than 20 transformation
technologies at your fingertips, and the payload doesn't need to be XML.

When it comes to connectivity, you must be already aware that BPEL is
WS-centric. Camel has 80+ components to interact with practically any
protocol, technology or resource out there.

I hope this helps a bit.

Regards,
Raúl.

--- 
Raúl Kripalani (raul@evosent.com)
Enterprise Architect, Program Manager, Open Source Integration specialist 
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk 



--
View this message in context: http://camel.465427.n5.nabble.com/Camel-vs-BPEL-tp5719214p5719439.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Mime
View raw message