Wednesday, September 19, 2007

JBI Deployment Options

Recently, I have had multiple discussions with different individuals concerning possible JBI deployment options for their projects. Is Glassfish required? Do I need a JavaEE container? Do I need Netbeans? Is it packaged as a WAR? How big is the runtime footprint? If I am already using JBoss, how can I take advantage of JBI? Why is the OpenESB installer so large? Even with every project having its own specific needs, JBI has an array of potential solutions for each one. So if you are new to JBI or just curious how to use it, please contiue to read while I describe the various options.

First, I have fortunately had the pleasure of extensively using two of the most popular JBI containers currently available: Apache ServiceMix and Sun's OpenESB. The following is the landscape as I see it based off my experience.

Apache ServiceMix Options

  • Can run as a standard J2SE application. To use this version download the container from here:
  • Bundled as a WAR, making it deployable to your existing JavaEE container. The WAR is also available for download from the same address above.
Sun's OpenESB Options
  • Can run as a standard J2SE application. Although it's a little more untested than it's other options. Go here for a How-To Guide on where to download the container and run it.
  • Comes bundled in an All-In-One install that includes the latest Glassfish, OpenESB, and Netbeans 6.0 for tooling support. Go here to download this version. Before you flip out on the download size (300+MB), let me provide an explanation as to the size because this seems to be the version receiving the most attention by Sun; and it's actually the version my team uses. Along with the items mentioned above, this bundle also includes all the Sun components and the latest Community Partner components. I believe the main benefit to having an All-In-One install is previously we had to download each project individually and usually the different versions where incompatible (the BPEL tooling support in Netbeans didn't match the BPEL Service Engine capabilities downloaded with OpenESB). It's important to note that with this option Netbeans is only required to compose Composite Applications and not to run OpenESB. Finally, the Glassfish and OpenESB combo is a little deceiving in that it's not like starting two applications. OpenESB is basically exploded out in one of the Glassfish domains, much like a WAR would be. So when you start a Glassfish domain, it handles starting OpenESB.
  • There exists a WAR file for IBM Websphere located here and work has been done to integrate with JBoss (read here for more information).
Which one is right for you?

Most projects fall into two categories: one that already has a JavaEE container and ones that don't. If you already have a JavaEE container, then you can use the ServiceMix WAR or run the J2SE standalone version of OpenESB. If you don't have one, then obviously you can choose among all the options. If I was forced to give a personal recommendation, I would recommend when possible using the Glassfish/OpenESB package. This gives you complete capability of building Composite Applications consisting of Web Services running in Glassfish and orchestrating them using OpenESB and the BPEL Service Engine and then integrating with other protocols such as RSS, SIP, UDDI, and XMPP. And the tooling support in Netbeans is well worth it.

For further questions please visit the FAQ on or feel free to drop me a comment. You can also subscribe to my shared JBI RSS Feed.


Bruce Snyder said...

Apache ServiceMix can certainly be used to build composite applications that are a combination of web services running external to the JBI container and the Apache Ode BPEL Service Engine to orchestrate it all, including additional integration with the other protocols you mentioned. ServiceMix provides all the necessary features to achieve exactly this type of task.

Is there something preventing you from using ServiceMix to achieve this goal?

jlorenzen said...

Hey Bruce, thanks for the feedback. I apologize for being misleading. My intent was not to portray SM as not being able to compose CompositeApps. But after some sleep and rereading my post I can see how you got that impression.
Is there anything from preventing me from achieving this goal? Not really, except time. My experience using SM started around version 2 and continues with 3.1.x. We regulary used the HTTP BC, EIP SE, JSR181, JMS, etc. However, I think there are significant differences between how SM and OESB create CompositeApps. I never got the chance to use the Ode BPEL SE.
The only other thing preventing this goal, was at the time a lack of tooling. Perhaps it's better now, but to my knowledge there only existed maven-archetypes. I think now there is eclipse plugin support but I am unfamiliar with it. However, I have grown fond of the BPEL tooling support in Netbeans.

Bruce Snyder said...

What differences are your referring to between SMX and OpenESB regarding the creation of composite applications?

If you're interested in Eclipse tooling, my company (IONA Technologies) offers the Fuse Eclipse IDE but there is no BPEL support included as BPEL is an huge animal all its own and we don't claim to be BPEL experts.

Anonymous said...

Hello Bruse,

We are currently having typical J2EE web application and planning to port it to SM?

Can we do it with out touching code in the war file?and can you mention the steps which briefly explains the
procedure to port an Web application to SM??

Fred Aabedi said...

Hi, If you need any support related to OpenESB please contact us for free one month development support.
Please look at the url for OpenESB support