How my Camel app is related to the apps I want to integrate?

Question

I've been studying Camel and EIPs for a few days, but there are a few things that I don't really understand ( yet :) ). For instance, let's say I have 5 applications and they exchange data with each other using several technologies (REST WS, JMS, database, etc). - Where should I put my Camel routes? - Should I change the code of each individual application and declare the specific routes on them? - Should I create a new Web application (or OSGi bundle) and make it work as a central provider to process the routes? I mean, change the code of the other apps to point to Camel endpoints defined in this app? - Using Camel implies in changing the code of every existing application in my integration set? I mean, how does Camel work in a real world scenario? Is it more like a central web app that intercepts stuff, process it and then sends somewhere else? Is it something inside my app (that lives in the same place as the business rules) and then pools/intercepts/listens stuff and processes it? I know these are all dummy questions, but I could not sleep well yesterday thinking about them. Any help would be really appreciated :)

Answer 1

Here's the approach we used.

Firstly, ask yourself the question, are you using camel to facilitate communication between applications / services that run independently? If this is the case then you can write a new application containing your camel routes, it essentially wires up all the other components to talk together, and you make minimal changes to existing apps.

On the other hand, maybe you want to use camel as an architectural standard for services that already talk to each other? In this case you want to go in to each existing application and rewrite the code for inter-service communication (and everything related to it, like configuration and error handling) as camel routes. You will likely keep business logic as-is and remove / rewrie a lot of code for doing things like web service calls, jms, etc.

A mid sized camel route can easily replace a few hundred lines of boilerplate code and be much more readable, plus you get all the EIPs and components (quartz, hazelcast, etc) for free.

For information, i use JBoss Fuse as the ESB (using Apache Camel) and it has worked superbly well for enterprise level integration.

Answer 2

Great answer from vikingsteve.

We use Camel to integrate legacy applications so the Camel routes are external. We are using ActiveMQ as the message bus and tomcat6 as the container. If we started now we would use JBoss Fuse (Karaf).

Each end system gets a Camel route set (in our system a war) which acts as an adaptor for that system to the message bus.

Integrations get a Camel route set.

The idea is that as we add more and more integrations we evolve each application into a set of services on its data and one day, end up with a service oriented architecture.

In an ideal world, the end system route sets would run on the same servers as the end systems and the integration route sets would run centrally. In practice we run all the route sets centrally. That is a matter of SLAs and hosting aggreements on the end systems.

It sounds like you have a more vertically integrated environment so you should be able to implement canonical solutions more cleanly than we can.

if you do end up with Camel instances distributed around the network, Fusesource were working on a management tool for that called Fuse Fabric. I don't know how far Redhat have got with that since they acquired it.