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 nodes and edges. Each node is an endpoint on the route (can consume/produce messages). Each edge is a route between two different endpoints (1 producer and 1 consumer).

Assuming that's correct, I have a practical question: what do best practices dictate about deploying your application's ESB/Camel Route? Should I package it up as its own JAR, or is it worthy of being its own EAR full of EJBs, Web Services and other JARs?

I guess I'm asking how a Camel Route or ESB should be deployed/architected, like:

my-esb.ear/
    ejb1.jar/
        MyEJB_1.class
    ejb2.jar/
        MyEJB_2.class
    webservice.war/
        MyWebService.class

Or...

my-esb.jar/
    MyEJB_1.class
    MyEJB_2.class
    MyWebService.class

Answer 1

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.

Answer 2

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