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 (r...@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.
