27
12
|
Hey,
If we have Apache Camel why to use other solutions like Apache ServiceMix and Mule? Is there something Apache Camel can't do comparing to these products? When to use Mule/ServiceMix and when to use Camel?
| ||||
|
33
|
Apache Camel is a library that implements enterprise integration patterns (EIP). While it can use Spring as its IOC framework, it is not even dependent upon Spring, so it is completely platform independent. It is "just" a library. So you can run it any JVM environment, e.g. simple jvm, servlet, ejb, osgi. It does not bring with any of the benefits (or the overhead) of a container such Mule. It has, in my opinion, cleaner separation of concerns in this area.
Mule can also be embedded in different environments, but I think Mule has both the advantages and disadvantages of coupling their EIP library to their container. When you deploy Mule inside a servlet or ejb environment, do you really want to carry all of that baggage of the Mule container? I am not a Mule expert, and I think you can probably spend a relatively modest amount of effort and clean out some of the redundant capability. (Note this is not bad capability in all cases, it is just redundant if you are running embedded inside another container.)
Apache ServiceMix is an OSGI container that uses Camel to implement EIP as the basis of an ESB. Although ServiceMix historically started with its roots in JBI, it has moved away from JBI and has evolved into (IMO) a nice layered architecture combining best of breed Apache CXF, Camel, and ActiveMQ in an OSGI container. The main value here is not really ServiceMix and its JBI support, but the underlying OSGI container standard coupled to proven Apache transports like CXF for web services and ActiveMQ for JMS. OSGI is a mature standard that offers a container that addresses the same types of "DLL" hell that plagued Microsoft before the advent of .NET. While neither .NET nor OSGI solves the essential complexity of the underlying problem, they at least provide a means for addressing it. OSGI has other benefits as well, but from a product selection perspective the standards based container is primary, and its essential feature that Mule (and Java in general) does not address is dependency management.
Some important things to note in comparing Mule with Apache communities. Mule is like Redhat in the sense that although it is an open source license it is not really in my opinion an open community. Anyone can participate in Apache whereas MuleSoft owns the Mule community and the final roadmap. Second, although the Mule community is arguably pretty active, I think the Apache community is much larger (and naturally so since it is not a gated community). Both approaches have both plusses and minuses. One positive to the Apache approach is that there are multiple vendors for ESB's based on Camel, CXF, ActiveMQ, and OSGI. For example, Talend offers an ESB on the same core technologies without the ServiceMix JBI history. This has both plusses and minuses within the Apache community, but the real point is to highlight the difference between Apache and Mule. You won't find multilple vendors in the Mule community. So IMO an Apache ESB like Talend or ServiceMix is a broader and more inclusive, and ultimately competitive community than a closed community like Mule.
Ed Ost
| ||
| add comment |
9
|
If you compare Camel and Mule, you'll see that they are built on similar concepts (enterprise integration patterns, possibility to use SEDA queues...).
A key differentiator is the number of available transports (Camel vs. Mule). Moreover, Mule can run embedded (like Camel) or as a standalone integration broker, with support for application hot deployment. On top of that, Mule's Enterprise Edition offers an advanced management console that can make a difference in production.
| ||||||||||||||||||||
|
3
|
Camel is a mediation engine while Mule is a light-weight integration platform. The difference is that that Mule offers all the capabilities of an ESB including a container for deploying applications, REST and Web Services. Mule can be embedded in the same way Camel to allow application developers to embed there application code with their integration code. Both integrate tightly with Spring.
Mule does not use JBI for good reasons and now that the JBI spec has been disbanded (no working group, owned by Oracle who passed on the JBI spec originally) there is no good professional or technical reason to use JBI.
| ||
| add comment |
