Spoilt for Choice: Which Integration Framework to use – Spring Integration, Mule ESB or Apache Camel?

  • 8 minute read
Three lightweight integration frameworks are available in the JVM environment: 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.
Total
0
Shares
0
0
0
Share
0 people shared the story
0
0
0
0

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:

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)

Total
0
Shares
Share 0
Tweet 0
Pin it 0

Dont‘ miss my next post. Subscribe!

We don’t spam! Read our privacy policy for more info.
If you have issues with the registration, please try a private browser tab / incognito mode. If it doesn't help, write me: kontakt@kai-waehner.de

Related Tags

builds cloud-native event streaming infrastructures for real-time data processing and analytics

44 comments

  1. Nice write up Kai, there are indeed plenty of options available nowadays. I think it is also worth noting that it’s possible to interconnect some (or all) of the above frameworks when there’s a need to do so. For example in case you’re using Camel and you need a Mule connector it worth considering to use the MuleClient from within you Camel route. Or you may chose to put e.g. ActiveMQ between the two. The same applies to Spring Integration, Camel even ships with a SI component out of the box.

  2. Richard, I agree with you.

    Though, I think this will bring additional complexity. It makes sense if you have to integrate a complex connector such as SAP or Tibco Rendevous.

    If you need just a “simple connector” from another framework, I would prefer to build my own component (very easy with a Camel archetype) or by simply using REST interfaces (if available). For instance, instead of using Mule’s Paypal connector in Camel, I would use the Paypal REST API directly or build a wrapper Camel component using the REST API.

  5. Disclaimer: I am Spring Integration committer

    Now to the point.
    Although I do like the overall tone of the article, i do believe that some corrections are in order. For example, you say: “just „basic stuff“ such as File, FTP, JMS, TCP, HTTP or Web Services…” First I would not call it “just „basic stuff”. If you were to compare the adapters you have listed with the same of Camel or Mule, you’d quickly realize that they are just as feature-full  if not more. But you also failing to list all of the adapters and protocols we currently support, so here is the full list: AMQP, Spring Application Events, Feeds (e.g, RSS/ATOM), File, FTP, FTPS, SFTP, Gemfire, Groovy, HTTP (REST), TCP/IP, JDBC, JMS, JMX, Mail (IMAP/IDLE/POP3), MongoDB, Redis, RMI, Twitter, Web Services (SOAP), XMPP.
    Also, it would be nice to point out in how frameworks such as Camel decided to list their components which create an appearance of the large number. For example. If you go to this website http://camel.apache.org/components.html you quickly see that Camel advertises gmail, imap, mail, pop, smtp etc. That is 5 components which handle exactly what SI Mail module does. . .
    Anyway, as I said, not a bad article overall.
    Cheers
    Oleg 

     

  6. Disclaimer: I am an Apache Camel committer.

    In terms of the number of Camel components, then there is a lot. And still growing. Oleg mention the Camel component overview on the website shows multiple entries for mail. That is by intention as this overview is per technology, so if people is looking for a smtp, imap, etc they can find it.

    That said the source code could be used to indicate number of different components, where the mail component will be only counted as one.

    For example in the latest Camel 2.9, there is 110 components.
    davsclaus:camel-2.9/components$ ls | wc -l
    110

    So why is there so many components with Camel? That is because of a very active and engaged community, which develop Camel components, that we accept and include in the distribution. For the upcoming 2.10 release, we have already a new websocket, twitter, and ssh and mongodb is in the works. 

     

  7. Kai, 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 

  11. Does the comparison actually make sense? Mule is an ESB while Camel and SI are just lightweight integration/mediator engines, though quite powerful.

    It makes sense compare Mule and ServiceMix, for instance, but not Mule vs SI.

    and yeah, Camel FTW!  :]

  12. You are in a way opening up a whole new can of warms with this one 😉 Basically you are correct in a way that may be the first thing to answer is “To ESB or not to ESB”. Ross Mason tried it in 2009 – http://blogs.mulesoft.org/to-esb-or-not-to-esb/. There is even a check list there. I personally disagree with every conclusion there, but don’t forget I am bias after all, so you decide. 

  13. @Anton: The article explains why I think that it is worthy to include Mule, too. You can use it as simple lightweight, embedded, developer-oriented integration framework as you do with Camel or Spring Integration.

  14. I asked this question in a different blog entry, but I think this entry is more appropriate to ask this question. Do you consider MuleESB as an Integration Framework or an ESB? The reason I ask, you mentioned that a typical ESB should offer features like BPM/BAM/Registry/Repository/Rules Engine etc, which in my understanding MuleESB does not provide support for out of the box. Feel free to correct me if my understanding is not correct.

  15. Hi Murthy, Mule does offer BPM, BAM and Rules Engine out of the box:

    BPM: Mule includes jBPM OOTB and tight integration with Activiti:
    http://www.mulesoft.org/documentation/display/MULE3USER/BPM+Module+Reference
    http://www.mulesoft.org/activiti-bpm

    Rules Engine: 
    http://www.mulesoft.org/documentation/display/MULE3USER/Drools+Module+Reference

    BAM: Mule Enterprise allows you to track business level events across all your Mule instances, capture specific KPIs, store a historical log of transactions and integration with 3rd party Busines Intelligence (BI) platforms like Jasper: http://www.mulesoft.org/documentation/display/mmc/Analyzing+Business+Events

     

  16. @Murphy: Mule ESB is a full ESB (however remember there is no real definition of an ESB). You should compare it to Apache ServiceMix or WSO2 (open source) or commercial products from WebSphere, Oracle, etc.
    This comparison was only about the integration support, so if you need just integration, an integration framework (i.e. Apache Camel, Spring Integration, or the integration part of Mule ESB) is sufficient.

  18. Hi Kai…That definitely address my confusion around why Mule is being compared against other Integration Frameworks if it is considered as a full blown ESB. Thanks for your response.

    Do you have an entry that compares ESBs as you did for the Integration Frameworks? 

  20. @Kai..Not a problem. I recently stumbled across your blog and you really have some exceptional entries on Integration. I am an Integration architect by profession specializing in Oracle Fusion Middleware and am passionate about open-source alternatives. Thanks for all your responses and a great entry.

  23. Good Article. We have done the similar comparision in our company. How about adding WSO2 in your comparision. WSO2 gives lot of open source products including governance one. The Webservices stack is based on AXIS.  We went ahead with ServiceMix as it is having good acceptence, userbase, active community and Spring Based configuration.

  25. Hi Kai,

    Really nice article. makes things clear.

    But I would like to ask you about additional aspectד in your בomparisons:

    1. Latency
    2. Performance.

    We are creating a system with a low latency demand.
    which of the three is excellent in those aspects?

    thanks,
    Idan. 

  26. Idan,
    this question cannot be answered in general. For example, if you use JMS, then you have to do some performance tests with the JMS connectors of the frameworks.
    In projects I have seen, performance / latency was sufficient, always. However, you should probably do a proof of concept to verify this.

  27. Hi Kai,
    According to your response, Yes –  I am using JMS.
    And ill do latency tests for sure.

    I was just curious in your experience with the different frameworks concern these aspects.

    Thanks. 

  28. Hi, 
     
    It would have been interesting to measure the frameworks by two more criteria:
    1. Documentation.
    2. The aggressiveness of the companies to push you towards “enterprise” versions, if there are such.
    I must say I had a very mixed experience with Mule (to be polite). And I am focusing on Mule because it is a recent experience.
    Everything seems to be blurred in the community version. The documentation is sometimes hilarious, they seem to be experts in making things unclear. Or they do not explain the semantics, only explain the obvious in different wording. 
    You receive almost daily emails and you feel hunted. And don’t get me started on what they would charge for 3 days of training. 
    The product itself is made to appear as unreliable in the community version. The most interesting connectors and behaviours are reserved, of course, to the enterprise version.
    A very interesting point: the whole Mule thing seems to be made artificially complicated as to require special training and explanations. It seems very much geared towards making (lots) of money.
    You don’t know wether you are allowed to use MuleStudio in production, they always use the word “evaluation”.
    You have no idea what a subscription would cost and there is no way of finding unless you go through the antiquated mechanism of “call us, establish a meeting, discuss…” blah blah blah. In the 21st century???
    No thank you. 
    So for me it is a question of choosing between Spring and Camel.

  29. Ken,
    Well, the problem of Mule is that it is a open source framework and the MuleSoft product “all in one”. Apache Camel and Spring integration are independent of tooling on top of it. So, I think that both, Spring Integration and Apache Camel, do not have these problems.You can just use the full framework without any specific tooling from a vendor.
    I can talk especially about Camel and Talend tooling (be aware that I work for Talend). There is just one documentation (www.help.talend.com).
    All connectors are also included within the open source version, even B2B connectors such as SAP or Salesforce.
    Code base is the same for open source and enterprise version. Open source version is  even released before enterprise version.
    IMO, Apache Camel is the right choice in most use cases. Tooling from Talend or JBoss (former FuseSource) on top of it reduces efforts a lot.

  30. Great article, Kai!
    It gave me a comprehensive image that how good an integration framework should be, and what features it should include.
    So far as I learned, I think Apache Camel is the best choice for my project. Of course, I would do the POC later.
    Thanks for your sharing!
    Karl

  31. Nice article.
    I am wondering if there are any performance comparisons between Camel and SI? Can this become a major factor when we want to choose one of these frameworks.
    I personally felt that Camel documentation was not great.

  32. Usha,
    in most use cases, performance is not an issue regarding this comparison. It depends on the underlying technologies you use, e.g. HTTP, FTP or JMS. Both frameworks do not have much overhead.
    IMO, Camel documentation is very good. It contains details descriptions and examples for all connectors and EIPs. Though, it might be a little bit unstructured in some cases. I usually use Google to find answers. This way, I always find the best links to Camel documentation.
    Kai

  33. Hi Kai,
    Nice Article.
    there´s a Framework named Smooks – Data Integration. For me it looks like the same as Apache Camel. What´s the difference between this two Frameworks? I know that Smooks can be used together with Camel when Smooks acts as an component?
     
    Holger

  35. Holger,
    Smooks is “just” for doing complex transformations (XML and non-XML such as CSV or EDI). Camel is much more: It is about routing, enterprise integration patterns, automatic conversions, endpoints, web services, etc.
    Use Smooks when you want to do some transformations, use Camel for all other stuff. Both are complementary, by the way.
    Kai

  36. Kai,
    Its an interesting blog that helps me to understand all three technologies with ease comparison.
    As my need is to extract data from multiple sources say Salesforce, SAP, RDBMS etc and put into Hadoop file system for analysis. In this case, should I still go with Apache Camel? Please advise.
    Thanks.

  37. Amalan, yes, Camel is perfect for this use case. However, with Camel, you still have to do a lot of manual coding by yourself. Data integration tools help a lot here. For example, Talend Open Studio for Big Data is an open source tool under Apache license which will reduce your efforts a lot. See http://en.talend.com/products/big-data. By the way: Talend ESB also uses Camel under the hood 🙂 But for your use case, Talend Open Studio for Big Data is easier to use than Talend Open Studio for ESB. Best regards, Kai

  38. Thanks Kai. I have to deliver this use case as an offering project so that they can extend this later.
    I started with TOS_BD and Mule ESB but later I feel this creates an utility kind of project and may not be considered to be an extensible project. Please correct me if am not correct.
    Thanks.

  39. Amalan,
    I can speak especially about Talend (the company I work for), not so much about Mule ESB (but I think it is the same)… It really depends on what you mean with “extensible”. You can extend Talend almost everywhere: You can build your own custom connectors, you can add Java (and other) code in expressions, you can add own Java classes and JAR libraries. That’s all very easy and supported implicitly within Talend’s Studio. Nevertheless, you still have very cool graphical tooling which reduces efforts a lot for development and maintenance.
    If you do not want to use graphical tooling, but just coding within an IDE, then Apache Camel is the way to go!
    Kai

  40. Hi Kai,
    thanks for this post.
    Please, can you present, an example, how to connect to alfresco with Spring integration (EIP)? which connector to use , and the property to add in the config?
    Thanks in advance.

  43. Very informative article and also very intellegent comments.

    Quick question ..

    Does these frameworks offer transactional support ? For example, in Webpshere message broker, if I run into an exception in a message flow, the broker supports roll back of the message to the input queue and on the input queue I can set backout count and backout queue to control retries and backout. Is something like this available in the frameworks discussed here ?

    Thanks
    Sharathbabu

Leave a Reply
You May Also Like
Read More
  • 19.9K views
  • 3 minute read

Apache Kafka vs. Middleware (MQ, ETL, ESB) – Slides + Video

This post shares a slide deck and video recording of the differences between an event-driven streaming platform like Apache Kafka and middleware like Message Queues (MQ), Extract-Transform-Load (ETL) and Enterprise Service Bus (ESB).
Read More
0
0
0