About Kai Waehner

Kai Waehner works as consultant. His main area of expertise lies within the fields of Java EE, SOA, Cloud Computing, BPM, Big Data, and Enterprise Architecture Management. He is speaker at international IT conferences such as JavaOne, ApacheCon or OOP, writes articles for professional journals, and shares his experiences with new technologies on his blog.

Integration Framework Comparison – Spring Integration, Mule ESB or Apache Camel

Data exchanges between companies increase a lot. The number of applications which must be integrated increases, too. The interfaces use different technologies, protocols and data formats. Nevertheless, the integration of these applications shall be modeled in a standardized way, realized efficiently and supported by automatic tests.

Three integration frameworks are available in the JVM environment, which fulfil these requirements: Spring Integration, Mule ESB and Apache Camel. They implement the well-known Enteprise Integration Patterns (EIP, http://www.eaipatterns.com) and therefore offer a standardized, domain-specific language to integrate applications.

These integration frameworks can be used in almost every integration project within the JVM environment – no matter which technologies, transport protocols or data formats are used. All integration projects can be realized in a consistent way without redundant boilerplate code.
This article compares all three alternatives and discusses their pros and cons. If you want to know, when to use a more powerful Enterprise Service Bus (ESB) instead of one of these lightweight integration frameworks, then you should read this blog post: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ (it explains when to use Apache Camel, but the title could also be „When to use a lightweight integration framework“).

Comparison Criteria

Several criteria can be used to compare these three integration frameworks:

  • Open source
  • Basic concepts / architecture
  • Testability
  • Deployment
  • Popularity
  • Commercial support
  • IDE-Support
  • Errorhandling
  • Monitoring
  • Enterprise readiness
  • Domain specific language (DSL)
  • Number of components for interfaces, technologies and protocols
  • Expandability

Similarities

All three frameworks have many similarities. Therefore, many of the above comparison criteria are even! All implement the EIPs and offer a consistent model and messaging architecture to integrate several technologies. No matter which technologies you have to use, you always do it the same way, i.e. same syntax, same API, same automatic tests. The only difference is the the configuration of each endpoint (e.g. JMS needs a queue name while JDBC needs a database connection url). IMO, this is the most significant feature. Each framework uses different names, but the idea is the same. For instance, „Camel routes“ are equivalent to „Mule flows“, „Camel components“ are called „adapters“ in Spring Integration.
Besides, several other similarities exists, which differ from heavyweight ESBs. You just have to add some libraries to your classpath. Therefore, you can use each framework everywhere in the JVM environment. No matter if your project is a Java SE standalone application, or if you want to deploy it to a web container (e.g. Tomcat), JEE application server (e.g. Glassfish), OSGi container or even to the cloud. Just add the libraries, do some simple configuration, and you are done. Then you can start implementing your integration stuff (routing, transformation, and so on).

All three frameworks are open source and offer familiar, public features such as source code, forums, mailing lists, issue tracking and voting for new features. Good communities write documentation, blogs and tutorials (IMO Apache Camel has the most noticeable community). Only the number of released books could be better for all three. Commercial support is available via different vendors:

IDE support is very good, even visual designers are available for all three alternatives to model integration problems (and let them generate the code). Each of the frameworks is enterprise ready, because all offer required features such as error handling, automatic testing, transactions, multithreading, scalability and monitoring.

Differences

If you know one of these frameworks, you can learn the others very easily due to their same concepts and many other similarities. Next, let’s discuss their differences to be able to decide when to use which one. The two most important differences are the number of supported technologies and the used DSL(s). Thus, I will concentrate especially on these two criteria in the following. I will use code snippets implementing the well-known EIP „Content-based Router“ in all examples. Judge for yourself, which one you prefer.

Spring Integration

Spring Integration is based on the well-known Spring project and extends the programming model with integration support. You can use Spring features such as dependency injection, transactions or security as you do in other Spring projects.

Spring Integration is awesome, if you already have got a Spring project and need to add some integration stuff. It is almost no effort to learn Spring Integration if you know Spring itself. Nevertheless, Spring Integration only offers very rudimenary support for technologies – just „basic stuff“ such as File, FTP, JMS, TCP, HTTP or Web Services. Mule and Apache Camel offer many, many further components!
Integrations are implemented by writing a lot of XML code (without a real DSL), as you can see in the following code snippet:

<file:inbound-channel-adapter
            id=”incomingOrders”
            directory=”file:incomingOrders”/>

<payload-type-router input-channel=”incomingOrders”>
            <mapping type=”com.kw.DvdOrder” channel=”dvdOrders” />
            <mapping type=”com.kw.VideogameOrder”
                                channel=”videogameOrders” />
            <mapping type=”com.kw.OtherOrder” channel=”otherOrders” />

</payload-type-router>

<file:outbound-channel-adapter
               id=”dvdOrders”
               directory=”dvdOrders”/>

<jms:outbound-channel-adapter
               id=”videogamesOrders”
               destination=”videogameOrdersQueue”
               channel=”videogamesOrders”/>

<logging-channel-adapter id=”otherOrders” level=”INFO”/>

You can also use Java code and annotations for some stuff, but in the end, you need a lot of XML. Honestly, I do not like too much XML declaration. It is fine for configuration (such as JMS connection factories), but not for complex integration logic. At least, it should be a DSL with better readability, but more complex Spring Integration examples are really tough to read.
Besides, the visual designer for Eclipse (called integration graph) is ok, but not as good and intuitive as its competitors. Therefore, I would only use Spring Integration if I already have got an existing Spring project and must just add some integration logic requiring only „basic technologies“ such as File, FTP, JMS or JDBC.

Mule ESB

Mule ESB is – as the name suggests – a full ESB including several additional features instead of just an integration framework (you can compare it to Apache ServiceMix which is an ESB based on Apache Camel). Nevertheless, Mule can be use as lightweight integration framework, too – by just not adding and using any additional features besides the EIP integration stuff. As Spring Integration, Mule only offers a XML DSL. At least, it is much easier to read than Spring Integration, in my opinion. Mule Studio offers a very good and intuitive visual designer. Compare the following code snippet to the Spring integration code from above. It is more like a DSL than Spring Integration. This matters if the integration logic is more complex.

<flow name=”muleFlow”>
        <file:inbound-endpoint path=”incomingOrders”/>
        <choice>
            <when expression=”payload instanceof com.kw.DvdOrder”
                         evaluator=”groovy”>
                        <file:outbound-endpoint path=”incoming/dvdOrders”/>
            </when>
            <when expression=”payload instanceof com.kw.DvdOrder”
                          evaluator=”groovy”>
                          <jms:outbound-endpoint
                          queue=”videogameOrdersQueue”/>
            </when>
            <otherwise>
                                <logger level=”INFO”/>
            </otherwise>
        </choice>
</flow>

The major advantage of Mule is some very interesting connectors to important proprietary interfaces such as SAP, Tibco Rendevous, Oracle Siebel CRM, Paypal or IBM’s CICS Transaction Gateway. If your integration project requires some of these connectors, then I would probably choose Mule!

A disadvantage for some projects might be that Mule says no to OSGi: http://blogs.mulesoft.org/osgi-no-thanks/

Apache Camel

Apache Camel is almost identical to Mule. It offers many, many components (even more than Mule) for almost every technology you could think of. If there is no component available, you can create your own component very easily starting with a Maven archetype! If you are a Spring guy: Camel has awesome Spring integration, too. As the other two, it offers a XML DSL:

<route>
        <from uri=”file:incomingOrders”/>
        <choice>
            <when>
                <simple>${in.header.type} is ‘com.kw.DvdOrder’</simple>
                            <to uri=”file:incoming/dvdOrders”/>
            </when>
            <when>
                <simple>${in.header.type} is ‘com.kw.VideogameOrder’
               </simple>
                            <to uri=”jms:videogameOrdersQueue”/>
            </when>
            <otherwise>
                <to uri=”log:OtherOrders”/>
            </otherwise>
        </choice>
    </route>

Readability is better than Spring Integration and almost identical to Mule. Besides, a very good (but commercial) visual designer called Fuse IDE is available by FuseSource – generating XML DSL code. Nevertheless, it is a lot of XML, no matter if you use a visual designer or just your xml editor. Personally, I do not like this.

Therefore, let’s show you another awesome feature: Apache Camel also offers DSLs for Java, Groovy and Scala. You do not have to write so much ugly XML. Personally, I prefer using one of these fluent DSLs instead XML for integration logic. I only do configuration stuff such as JMS connection factories or JDBC properties using XML. Here you can see the same example using a Java DSL code snippet:

from(“file:incomingOrders “)
       .choice()
                .when(body().isInstanceOf(com.kw.DvdOrder.class))
                                .to(“file:incoming/dvdOrders”)
                .when(body().isInstanceOf(com.kw.VideogameOrder.class))
                                .to(“jms:videogameOrdersQueue “)
                .otherwise()
                                .to(“mock:OtherOrders “);

The fluent programming DSLs are very easy to read (even in more complex examples). Besides, these programming DSLs have better IDE support than XML (code completion, refactoring, etc.). Due to these awesome fluent DSLs, I would always use Apache Camel, if I do not need some of Mule’s excellent connectors to proprietary products. Due to its very good integration to Spring, I would even prefer Apache Camel to Spring Integration in most use cases.

By the way: Talend offers a visual designer generating Java DSL code, but it generates a lot of boilerplate code and does not allow vice-versa editing (i.e. you cannot edit the generated code). This is a no-go criteria and has to be fixed soon (hopefully)!

And the winner is…

… all three integration frameworks, because they are all lightweight and easy to use – even for complex integration projects. It is awesome to integrate several different technologies by always using the same syntax and concepts – including very good testing support.

My personal favorite is Apache Camel due to its awesome Java, Groovy and Scala DSLs, combined with many supported technologies. I would only use Mule if I need some of its unique connectors to proprietary products. I would only use Spring Integration in an existing Spring project and if I only need to integrate „basic technologies“ such as FTP or JMS. Nevertheless: No matter which of these lightweight integration frameworks you choose, you will have much fun realizing complex integration projects easily with low efforts. Remember: Often, a fat ESB has too much functionality, and therefore too much, unnecessary complexity and efforts. Use the right tool for the right job!

Reference: Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel? from our JCG partner Kai Wahner at the Blog about Java EE / SOA / Cloud Computing blog.

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

5 Responses to "Integration Framework Comparison – Spring Integration, Mule ESB or Apache Camel"

  1. Zygo Vox says:

    I have used all 3, but they are not truly comparable. Mule is a full blown ESB, but Camel is a routing and mediation engine. You can use Camel inside your traditional web/enterprise app for defining routing flows of data between components (the same could be said for Mule/Spring Integration as well). Camel’s functionality stops there, if you want an apples to apples comparison Mule ESB should be pitted against Apache Service Mix (with Camel).

  2. Ross Mason says:

    Good write up, thanks for sharing your perspective.  Disclaimer,  am the founder of Mule.

    There are a couple of things I would like to add on the Mule side of things:

    Mule XML is based on Spring and behaves as a Spring container.  This means, anything you can do in Spring can be done in Mule using the ‘spring’ namespace, we love the power of String, but the XML DSL approach is a nice way to make things readable and discoverable.

    Mule Cloud Connect now has over 50 connectors for talking with SaaS, Social Media and infrastructure APIs including Salesforce, PayPal, NetSuite, Magento, FreshBooks, Facebook, Twitter, LinkedIn, AWS, MongoHQ, PubNub, etc.   http://www.mulesoft.org/muleforge/connectors

    You already mentioned our strong support for Enterprise connectivity, thanks for that!

    We also have a cloud platform called iON that allows you to create cloud integration apps and run them with one-click from Mule Studio. iON is multi-tenanted, elastic and is super easy to work with.  the nice thing is that the same code that runs on the cloud also runs on local Mule instances. http://muleion.com

    You mentioned Monitoring as an evaluation criteria, Mule has enterprise grade management capabilities for managing server groups, deployments, performance analysis, monitoring/alerting.  Another point is we also have business event tracking so that we can track transactions across systems. http://www.mulesoft.com/management-console-mule-esb

    Also, FWIW there are two new Mule books in development at the moment, we should see them both published this year

  3. Ross Mason says:

    @google-8e52e8aa36f4a18a0ca214730c688c2b:disqus I think the auors point is MUle’s core engine is just as embeddable as Spring of Camel, the difference is that we also supply an enterprise grade container, management capabilities and enterprise and cloud connectivity

    • Kai Waehner says:

      Ross, you are absolutely right. As mentioned in the article, I think Mule ESB is comparable to Camel and Spring Integration as lightweight, embeddable integration framework. You can also use Mule ESB (as its name states) as full ESB, then you have to compare it to other ESBs such as Apache ServiceMix (again, I mentioned this in the article).

      By the way: Spring Integration is also adding a Scala DSL. So, I hope Mule will get a programming language DSL soon, too :-)

      Best regards,
      Kai Wähner (Twitter: @KaiWaehner)

  4. Halil Duygulu says:

    at mule sample code second full class name should be “com.kw.VideogameOrder”

Leave a Reply


× 5 = thirty five



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.