Re: Camel vs. Synapse vs. ServiceMix

[James Strachan <ja...@gmail.com>]

Great mail BTW; sorry for the delay responding, am just back from vacation

On 5/30/07, Jerome Banks <je...@gmail.com> wrote:
> There seem to be a lot emerging open-source ESB/Message routing frameworks
> developing these days.

:)


> This is a somewhat open-ended question, but what are
> the relative strengths and weaknesses of Camel, Synapse, and ServiceMix.
> They all seem to be Apache ESB-like projects with some overlap, but they
> must complement each other in some way.

Great question :)


>  Which use-cases are best handled by which projects? In particular, which
> use-cases are best handled by Camel?

So Synapse is a mediation engine for Axis2; so if you're using Axis2
and want to mediate, Synapse is worth a look.

ServiceMix is a JBI based ESB which provides a JBI container and
component suite. The big win of JBI is that its a standard that many
vendors support which allows integration components to interoperate
across ESBs

Camel is a routing and mediation engine which can be deployed inside
ServiceMix as a JBI component, used with ActiveMQ, CXF or MINA or used
stand alone. Camel focusses on implementing the Enterprise Integration
Patterns using a neat Java language to minimse the amount of XML
required to configure routing and mediation rules. So you can view
Camel as a reusable framework which can be used in your web services
stack, your ESB or message broker etc.


> Also, this might be flame-bait, but is Camel a pun on "Mule"?

LOL. Well, a Camel can carry 4 times as much load as other beasts of burden :)
http://activemq.apache.org/camel/why-the-name-camel.html


> How does
> Camel compare the the Mule ESB project?

I guess from 30,000 feet they're kinda similar beasts; they're both
kinds of routing/mediation engines. The main differences are as
follows (warning, I'm kinda biased :)


* Camel uses a Java DSL in addition to Spring XML for configuring the
routing rules and providing  EIP implementations
http://activemq.apache.org/camel/enterprise-integration-patterns.html

* Camel's API is smaller & cleaner (IMHO) and is closely aligned with
the APIs of JBI, CXF Bus API and JMS; based around message exchanges
(with in and optional out messages) which more closely maps to REST,
WS, WSDL & JBI than the UMO model Mule is based on

* Camel allows the underlying transport details to be easily exposed
(e.g. the JmsExchange, JbiExchange, HttpExchange objects expose all
the underlying transport information & behaviour if its required)
http://activemq.apache.org/camel/how-does-the-camel-api-compare-to.html

* Camel supports implicit type coercion from the core API to make it
simpler to connect components together requiring different types of
payload & headers
http://activemq.apache.org/camel/type-converter.html

* Camel uses the Apache 2 License rather than Mule's restrictive
commercial license

I hope that helps clear things up a bit; I admit all this SOA/ESB
stuff can be a bit confusing

-- 
James
-------
http://macstrac.blogspot.com/