How should an ESB be packaged/deployed?

Question

I am trying to wrap my head around Apache Camel, which appears to be a lightweight ESB. If I understand Camel/ESBs correctly, then you can think of a Camel Route as a graph of n

Answer 1

That depends on YOUR needs. There is no single truth answer that is better.

Camel can adapt to your existing infrastructure and runtime platform. So package your applications with Camel embedded the way this platform can do it, and the way you want it.

For example to use Camel in a web application (WAR) you can see this link: http://camel.apache.org/tutorial-on-using-camel-in-a-web-application.html

Answer 2

You are considering .ear embedding, I see.

I would recommend you to think twice about embedding Camel to tight inside a full featured Java EE server. It is certainly doable, but you will get some work to connect them (with commonJ, WorkManagers, JNDI references etc). Specifically, letting Camel handle the threading is a large plus.

Embedding Camel inside a spring web-app (.WAR) i my personal favourite for deployment in Jetty or Tomcat. Then you get access to a decent servlet container, a runtime that can do some things, etc.

Actually, I've used the standard download of ActiveMQ in some production environments with the embedded Camel, more for adapter purposes and not so much ESB, but still, it might be a valid choice if ActiveMQ is the messaging backbone of your ESB.

Answer 3

Let me Answer your Questions One by One:

Provides a descriptive, non-vague list of general factors that should be used to determine how to best deploy an ESB (either as a single EAR with each endpoint being an embedded JAR or as a single "monolithic" JAR);

Embeded or Monolithic jar doesn't matter. Which matters is Bundled or war deployment. In case of a Standalone bundle you might end-up with a very fat deployment archive having lots of jars to for dependency resolution.

Fully explains why Camel might not play nicely with Java EE app servers like JBoss or GlassFish

1. Thread/Resource/Port Management of App-Server/Container may impose restriction.

2. Conflict of commonly used Library Version

3. Conflict on ClassLoading mechanism

Logically, if your container supports OSGi then Camel should not face any problem.

1. As Apache Camel is a very lightweight Message Router, So you can definitely you can package it in your ear along with your web application as a war file. If you are using maven/Ivy and your web container supports osgi, then Bingo! Life will be much more easier.
2. Second option is to deploy your application as a bundle
3. and another is stand-alone Java SE jar.

Follow the links below[Though, Outdated enough], those will give you step-by-step direction on packaging, at-least clarity on the packaging mechanism:

Camel Step By Step

Camel in a Web Application

Camel Real Life Packaging & Deployment in OSGi environment

Answer 4

Like in the other answers, it depends on your needs but an ESB is usually a combination of different integration processes that do not necessarily share the same lifecycle.

If this is the case for you I suggest using a jar per integration process approach. That way you can have different development lifecycles for each of the different jar's and you can assure your client that you have not touched any of the code except the one in that jar.

This does not mean you have to go with the ear solution. You can perfectly package the code for your different processes in a war file without the ear overhead.

Answer 5

From my understanding there is a couple of ways you can run Camel.

1. Embedded in a Java Application: You can embed Camel in a stand alone Java application. In this scenario you would start a Camel Context inside your application which will start the routes etc. This is great when your application needs to communicate with services etc. For this to work you would need to deploy the Camel and third party jars for components to the classpath.

2. Embedded in a Web Application: As people has already pointed out this seems the a popular option. The Camel jars and third party jars are wrapped in a WAR file and essentially deployed to a web container such as Tomcat to host the Camel services.

3. Embedded in a application server: I have read some article on how to deploy Camel to a Application server such as JBoss and I have even read about people deploying to Glassfish. This seems very similar in how you deploy to Tomcat. JBoss has some class loading issues that you would need to address which makes it tricky. So yes you can deploy to a application server by going the WAR route.

4. Deploy to OSGi: You can make your Camel jar a OSGi bundle relatively quickly and deploy to a OSGi framework such as Apache Felix. It is relatively simple to convert the jar to a proper OSGi bundle and then deploy. The one big problem here is that some third party might not have OSGi compatible bundles for you to deploy.

My personal preference is the OSGi route. It is easy and lightweight and allows me to host my camel routes as persistent services (i.e. Window service, Unix Deamon) with a very small foot print.

The thing that you should realise now is that Apache Camel can be deployed in several ways and it is really up to you to decide on how you want to do it. It took me a while to understand how to deploy Camel as I had to play with the different deployment models to get a good feel for it. The only one I have not touched was deploying to a Application Server as I felt most of these Servers are heavy enough.

As far as architecture is concerned I like to keep my different routes/applications in different jars. Since I am using OSGi I like to be able to update a specific route and deploy it without having to redeploy everything. If you deployed everything in one jar you would need to take down the world rebuild and redeploy the jar. However this is personal preference and your mileage might vary

Hope this helps a bit.