In association with heise online

Differences

Despite the many similarities, there are also various notable differences. The products differ most discernibly in terms of the available connectors and DSLs. The following section will, therefore, focus on these two areas. As a code example, we will implement the "content-based router" EIP, which forwards messages to different destinations depending on their content, in all three frameworks. The process involves reading orders from a file directory and processing individual order items accordingly. DVDs will be copied to another directory, video games will be added to a JMS queue, and other items will only be logged (temporarily). Any other technology – for instance FTP, Mail, MongoDB, Amazon SQS, RMI (Remote Method Invocation) or around 100 others – could be handled in the same way.

Spring Integration

Spring logo The framework is based on the Spring portfolio and extends its programming model to include integration aspects. Familiar Spring features such as dependency injection, transactions and security can be used in the normal way. Spring Integration is particularly suitable if the rest of the application is also based on Spring. Interactions are simple, and experienced Spring developers can use this framework with virtually no extra learning effort.

Spring Integration mainly supports various technologies that are widely used in Java environments, for example file, FTP, JMS, TCP, HTTP and web services. Mule and Camel, on the other hand, offer a considerably larger number of connectors. Although custom connectors can be created in Spring Integration, the process is undocumented and therefore awkward and time-consuming.

Developers implement their integrations as XML source code without a dedicated DSL:

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

<payload-type-router input-channel="incomingOrders">
<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"/>

In recent Spring versions, annotations have allowed much logic to be implemented in Java code; however, the integration logic itself must be implemented in XML. While XML is very suitable for configuration tasks, this is only partially true for the integration logic. With complex and involved integration tasks, a DSL that offers good readability is a tremendous help for developers. Consequently, complex Spring Integration examples are far more difficult to understand than those of its competitors. It is, therefore, welcome news that Scala- and Groovy-based DSLs are currently in their early development stages.

The Integration Graph visual tool that is part of Eclipse does work, but it is less intuitive than the tools that are available with the other two frameworks. There is currently no documentation whatsoever, nor are there any extra features such as the live monitoring or performance analysis mentioned above.

Mule ESB

MuleSoft logo As its name implies, Mule ESB is not only an integration framework, it is also an ESB that offers additional features. Nevertheless, Mule can be used as an integration framework by embedding only the required libraries into the applications as one would with Camel or Spring Integration. This article will, therefore, omit ESB features such as monitoring or Business Process Management (BPM).

Unfortunately, Mule only offers one XML DSL for integration, although the Mule Studio development environment does include a good and intuitive visual designer. The following code snippet demonstrates how our example can be implemented in Mule. Compared to the Spring Integration example, the DSL code is significantly more readable, which is particularly relevant for complex integration logic:

<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>

Mule's biggest advantage lies in its numerous connectors to important proprietary interfaces, such as SAP, Tibco Rendezvous, Oracle's Siebel CRM and IBM's CICS Transaction Gateway. If the integration project requires one of the proprietary connectors, Mule is the framework to use. If no connector exists, a custom one is easy to create. For this purpose, a Maven archetype creates the basic framework, and the developer only needs to add a custom logic to integrate the required technology. However, a disadvantage for some projects is that Mule doesn't support OSGi, and there are no plans to add this support in the future.

Apache Camel

Apache Camel logo Camel is virtually identical to Mule in many respects. It offers connectors for almost any conceivable technology, and custom connectors are easy to create. Camel also strongly integrates with the Spring framework. The following example shows the Spring-based 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>

The DSL is almost identical to that of Mule and much more readable than the Spring Integration code. What's more, FuseSource offers the commercial – Eclipse-based – graphical Fuse IDE designer that generates XML DSL source code.

Nevertheless, a lot of XML code must ultimately be generated and maintained. Unlike its competitors, Camel offers an extra feature for this purpose: programmatic DSLs for Java, Groovy and Scala. A DSL for Kotlin, a newcomer among the JVM languages, is already in development.

The following code snippet shows the Java DSL:

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 ");

This allows developers to avoid XML completely. The flowing DSL is much more readable and offers familiar development environment features such as code auto-completion and refactoring. Incidentally, Talend offers a visual tool that generates a Java DSL; however, unlike the Fuse IDE, it still generates much redundant boilerplate code. This code can't be modified because there is no option to edit the generated source code. As Talend's product suite offers a "zero coding" approach, however, editing isn't usually required.

It is also possible to use multiple DSLs. In practice, a programmatic DSL is often used for the integration logic, while XML is chosen for configuration tasks – for example when specifying JMS connection factories or JDBC properties.

Having introduced the integration frameworks, we will now consider which projects it makes sense to use them in, instead of a more powerful, but also more complex, ESB.

Next: Enterprise Service Bus

Print Version | Permalink: http://h-online.com/-1672712
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit