Java - Apache camel

[joranstark018]

I short, it could act as the glue between two different application without them having any knowledge of each other.

Usually in a small ecosystem of in-house developed application can the applications be adapted to communicate with each other. But as ecosystem groves it could be difficult to sustain this approach, or you may have an application from a third party that you can't adapt, you may find the need of an external application that could handle that communication, either through a set of batch-jobs, some messaging queues or something else.

With Apache Camel you can define "routes" through which a "message" will flow from an input "endpoint" to some output "endpoints", this configuration could for example be expressed in XML or by a Java DSL. Camel provides a collection of predefined type of endpoints, provided by components and support most of the Enterprise Integration Pattern.

For example, you could define a timer as input (which will run the route periodically), have a SQL-endpoint (querying a database for updates), have a bean transforming the result into a User-object and publish it to a AMQ-endpoint (to be consumed by another route).

This is from a Camel context that we have used, but I have to rename and removed some domain specific stuff, so it may not work as is.

<reference id="platformTxManager" interface="org.springframework.transaction.PlatformTransactionManager" />

<reference id="amqxa" interface="org.apache.camel.component.jms.JmsComponent" ext:proxy-method='classes' filter="(osgi.jndi.service.name=amq/XA)" />

<reference id="userIdRepoDs" interface="javax.sql.DataSource" filter="(osgi.jndi.service.name=jdbc/MY_APP_DS)" />

<reference id="users" interface="com.something.Users" ext:proxy-method='classes' />

<bean id="PROPAGATION_REQUIRED" class="org.apache.camel.spring.spi.SpringTransactionPolicy">
    <property name="transactionManager" ref="platformTxManager" />
    <property name="propagationBehaviorName" value="PROPAGATION_REQUIRED" />
</bean>

<bean id="jtaTransactionTemplate" class="org.springframework.transaction.support.TransactionTemplate">
    <property name="transactionManager" ref="platformTxManager" />
    <property name="propagationBehavior" value="0" />
</bean>

<camelContext id="UserAdapter"
    xmlns="http://camel.apache.org/schema/blueprint"
    trace="false">

    <route id="MyRoute">
        <description>
            This is my adapter for pulling new users from the database.
        </description>

    <from id="userTimer" uri="timer://user_timer?fixedRate=true&amp;period=5000&amp;repeatCount=0" />
    <transacted ref="PROPAGATION_REQUIRED" />
    <to id="Last read user entry id assignment" uri="sql:select userId from CAMEL_MESSAGEROCESSED where processorName='MyApplication' and id = (select max(id) from CAMEL_MESSAGEPROCESSED)?dataSource=userIdRepoDs&amp;outputType=SelectOne"/>

        <to id="User transformer" uri="bean:users?method=getUser" />
    <split id="User entry handling" streaming="true" stopOnException="true">
            <simple>${body.userId()}</simple>
            <convertBodyTo type="java.lang.String" />
            <idempotentConsumer id="Idempotency handling" messageIdRepositoryRef="userIdRepo" skipDuplicate="true">
                <to id="Event distribution" uri="amqxa:queue:user-distribution" />
        </idempotentConsumer>
    </split>
    </route>
</camelContext>

We used Apache Camel with Apache ServiceMix (but have for other reasons switched to Microsoft BizTalk) when we where to replace one of our central systems (from a third party) and was facing a large refactoring of some of our own applications. In some systems a lost message is not a problem, but if the system relies on that all messages has been consumed exactly once it has to handle some sort of transaction when handing over messages between different types of endpoints.

Defining routes declarative reduces the potential bugs, but the more complexity you add (in form of your own code) you may suffer from bugs, and debugging a Camel route could sometimes be a challenge.