Data exchanges between companies are increasing a lot. The number of applications that must be integrated is increasing, too. The interfaces use different technologies, protocols and data formats. Nevertheless, the integration of these applications must 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 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. learn more from Mulesoft Training
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.
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. Get more skills from Mulesoft Certification
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
- Mule ESB
- Apache Camel
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. Learn additional skills from Mulesoft Training and Certification
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. Get more details From Mulesoft Course
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>
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.
To get in-depth knowledge, enroll for a live free demo on Mulesoft Online Training
Mulesoft Online Learning 