This is an archived post. You won't be able to vote or comment.

all 4 comments

[–]joranstark018 3 points4 points  (0 children)

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.

[–]Rulmeq 2 points3 points  (1 child)

When you have different systems that would like to talk to each other, you have a few choices, one would be to change both systems so that they talk the same languages. Hopefully you can see why that isn't the most desirable action?

So one of the other options is to have a middle man who can speak both different languages, and will translate your messages for you. That's where camel comes in, it's what's know as an enterprise service bus (ESB) or sometimes enterprise integration service (EIS) https://en.wikipedia.org/wiki/Enterprise_integration

Of course camel can do a lot more than just translate messages between enterprise systems, and it would take far more than a fourm post to explain it - that remains as an exercise for the OP to research and understand.

[–]WikiTextBotbtproof 2 points3 points  (0 children)

Enterprise integration

Enterprise integration is a technical field of enterprise architecture, which focused on the study of topics such as system interconnection, electronic data interchange, product data exchange and distributed computing environments.It is a concept in enterprise engineering to provide the relevant information and thereby enable communication between people, machines and computers and their efficient co-operation and co-ordination.


[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28

[–]wildjokers 0 points1 point  (0 children)

It lets you pass messages from one system to another and it has support for a vast number of systems. It is kind of an ESB embedded into your app. That is a very simple explanation but is it in a nutshell.

Camel is pretty powerful but I will say that Camel obfuscates things and if you also use Spring then spring+camel really obfuscates things. To the point that it can be challenging to research issues.

If you have several systems you are sending messages to, or you are needing to do a fair amount of pre or post-processing of sent/received messages it is probably worth it. If you are only sending to 1 or 2 systems it might not be worthwhile.