Spoilt for Choice: Which Integration Framework to use – 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: https://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:

• Spring Integration: SpringSource (http://www.springsource.com)
• Mule ESB: MuleSoft (http://www.mulesoft.org)
• Apache Camel: FuseSource (http://fusesource.com) and Talend (http://www.talend.com)

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!

 

Best regards,

Kai Wähner (Twitter: @KaiWaehner)