Open ESB & GlassFish: JMS messaging (part 2)

The long awaited follow-up to Open ESB & GlassFish: JMS messaging (part 1) is finally here...well, long awaited for me that is :) I've been waiting since March to get back to OpenESB and GlassFish to implement our business use case. My hope for this post was to have GlassFish working with ActiveMQ embedded in Geronimo but I'm not quite there yet. However, I feel confident that I have a solution that will work.

First a quick review on what I was trying to do in part 1. My initial approach to integrating ActiveMQ embedded in Geronimo, was to configure ActiveMQ's resource adapter in GlassFish in order for my business processes to use a set of queues in Geronimo. One thing I realized is that the configuration for my initial approach was taking me down a path of using ActiveMQ in Geronimo for all queuing which was not what I wanted to do. I just wanted to access a set of queues in Geronimo from business processes deployed in GlassFish and use the embedded queuing support in GlassFish for other JMS activity. So I had to start again with my trusty pal Google and it turned up Ramesh Parthasarathy's Blog GlassFish V2 and ActiveMQ 4.1.

Remesh's post describes how to use the generic JMS resource adapter available in GlassFish make ActiveMQ queues available to components deployed in GlassFish. When you get it working your component (MDB) references the ActiveMQ queue through a typical resource reference as you would for a Datasource or other EJBs. The generic resource adapter provides a "bridge" by using JNDI. Some observations about the generic ra support in GlassFish:

What I like:

• The concept of accessing remote queues as resource references. This is something all J2EE developers understand and can use.
• No coding...this is all configuration based. You do have to code up and configure an MDB to access a remote queue.
  

What I don't like:

• Lots of configuration. I can't pin this on GlassFish, J2EE applications in general have a lot of configuration which lends themselves to delicate deployments. Java EE 5 has made it a lot easier with annotations and dependency injection. However, because of limitations with annotations (i.e. not being able to specify what resource adapter you want to use) I have to use J2EE 1.4.
• The use of com.sun.jndi.fscontext.RefFSContextFactory. This file system-based context factory works fine. However, you need to create and maintain the .bindings file for the generic ra. For example, this means if you create a new queue in ActiveMQ or change a queue name you have to update the .bindings file. I hope to experiment with other context factories within Geronimo but for now I'll continue with the FS context factory.

What concerns me:

• Stability and availability. I've experienced some issues with GlassFish not recovering when ActiveMQ is not available and becomes available again.
• Transactional oddities...I'm currently dealing with some odd container-managed transactional exceptions with my MDB using the ActiveMQ queues that I cannot reproduce. Hopefully this is just a configuration problem.

What is next for me is to work through the transaction exceptions and then test the solution with Geronimo. Initial tests are encouraging which should not be a surprise because ActiveMQ is embedded in Geronimo. After that it's onto building the BPEL processes and supporting components.

Milestone 1: Use Case Implemented in Sun JavaCAPS

Well it's been a long road and I'm happy to announce that we've reach our first milestone in the SOA Lab of an implemented use case using our Virtual Enterprise. Steve Smith and I decided back in late April to combine our efforts and work collaboratively with JavaCAPS to complete the work. This post will focus on my hands on experience with Sun JavaCAPS 5.1.2 and overall impressions with the product.

Impressions of the Sun JavaCAPS tools

Architecture

Java CAPS has been around since the late 1990's and evolved from a traditional hub/spoke architecture to an early ESB architecture consisting of multiple JVMs for each integration point to avoid single point of failure and increase availability. Now the architecture has evolved once again to J2EE utilizing JCA, MDBs, session and entity EJBs, JMS, etc. At the core of Java CAPS is eGate Integrator. The purpose of the eGate system is to translate, transform, and route data between multiple external systems, and translate that data from one to many formats. Some of the key components of eGate are:

• J2EE compliant middleware services (e.g. Sun SeeBeyond Integration Server aka "Logical Host")
• A messaging server (JMS) - deployed in the Logical Host
  
• Repository server - The Repository server stores the setup, components, and configuration information for the elements of an eGate Project (Enterprise Designer Project). It also stores the product binary files that are required at run time by the Logical Hosts.
• Java Composite Application Platform Suite Installer - A Web-enabled application used for uploading Composite Application Platform Suite products into the Repository, and then downloading and installing the products from the Repository onto a system.
• Enterprise Manager - web-based application to manage multiple logical hosts.
• Enterprise Designer GUI - development IDE, which is a number of plugins deployed in NetBeans 3.4.

The Enterprise Designer must be deployed on windows. Apparently some of the plugins only work on windows even though NetBeans is cross platform. To develop in Java CAPS you first need to setup a repository. This repository appears to run in a separate instance of the SeeBeyond Integration Server. It is quite "heavy" so it should be deployed on a powerful machine. The Enterprise Designer appears to have a lot of communication with the repository. If the repository is on a slow box and/or network the instances of Enterprise Designer attached to it will have poor performance. The Enterprise Manager is a web-based application that runs in a web container that is based on tomcat. This application does an adequate job of allowing administrators to attach and administer several integration servers.

Installation/Configuration

Overall the installation and configuration went pretty well, I'd give it a B+. It was disappointing that the Enterprise Designer could not be installed on a non-windows OS. It was a little concerning to hear that the RedHat linux distribution of the integration server was EOL (End Of Life). I guess they're more concerned about Windows at this point. If you stay completely on a Windows platform the installation and configuration is typical of what you'd expect from a windows install (i.e. GUI wizard-like installer).

In our lab we installed the Repository on a CentOS VMWare VM. A couple of small things had to be done to get it to work like:

• linux installation did not pick up a jre embedded in the installation directory therefore I had to modify the install.sh script to use my jre.
• had to modify the startserver.sh and stopserver.sh to comment out the JAVA_HOME hard coded path because it was wrong. I opted to use my jdk1.5 JAVA_HOME.

Other than that the repository seems to run well on linux.

Development & Debugging

For the most part, the Enterprise Designer seems stable and is easy to use. The repository must be available and accessible in order to use the designer, which is limiting. The communications with the repository introduces latency when creating, modifying and deleting objects, even when the repository is installed on the local machine. The repository has a built in source code control system that locks files, which makes concurrent development difficult if not impossible. The "locking" that happens requires that the user "check out" a business process (BPEL) in order graphically see the process or even look at the properties. There is no support for a 3rd party source code systems (e.g. SVN, CVS, etc). This limitation can certainly become an issue when introducing Java CAPS to an enterprise that has already standardized on a source code control system. Debugging support for Java Collection Definitions is ok. I expected it to be more robust as it is in the NetBeans IDE. I did not try the debugging support for BPEL.

Deployment & Troubleshooting

Building and deploying business processes is heavy. Since Java CAPS deploys a to a J2EE application server, when you build a project you are building a .ear. The most basic business process results in an ear file that is ~5mb in size. Business processes that are built in BPEL are typically ~10mb in size. The process for building the business process is easy and straight forward. I did run into issues with binaries that were not cleaned up that resulted in deployments with unwanted code. This only happened a few times. The Sun SeeBeyond integration server does have pretty good logging to help troubleshoot problems.

Comments

If I had to give Java CAPS a grade based on what I've learned and used it would be a B. (NOTE: I have to mention that I did have quite a bit of training on Java CAPS from Sun and without it my experience with the tools would have been much different.) The development and administrative tools seem pretty good. I'm not that impressed with the heaviness of J2EE, large deployment binaries, lack of support for 3rd party source code control systems, tight coupling between the designer and the repository and the lack of support for open source technology (e.g. Geronimo, ActiveMQ, etc.). We ran into challenges with correlation (see BPEL Correlations introduced using Sun CAPS and BPEL Correlations...as easy as it sounds?). That took us a week or more to get resolved.

Bottom line, building composite applications can be difficult. It's not difficult in the sense of the concepts and tools (once you know them). It's difficult to setup a "complete" development environment (this is where our SOA Lab is real beneficial). This type of development takes a lot more time than it seems it would, we found this out first hand. There are a lot of parts (servers, clients, GUIs, etc.) that have to eventually work together. Depending on how complex your business process is you could be spending a large amount of time just mocking up environments for unit and integration testing. After implementing a fairly straightforward use case I have an appreciation for the term "governance" as it applies to implementing an SOA. Our straightforward use case resulted in 8 business processes (BPEL processes), 2 JCDs (Java Collaboration Definitions) and numerous Java CAPS objects. Ok, now imagine having multiple projects going on at the same time and trying to manage reuse of these objects not to mention the operational support required to keep an eye on everything in production.

What's Next?...

Well, we still have a little clean up to do with the Java CAPS use case implementation. After that then it's back onto either ServiceMix or OpenESB for me. I'm looking forward to comparing a commercial product to an open source project.

First taste of ServiceMix

It's been just over a month since my last post and that's fair too long. So, you might ask, what's going on? Well I had a slight diversion from Java CAPS to take a closer look at ServiceMix. I only spent a little over week looking into ServiceMix so that doesn't justify any kind of experience let alone blog about it. However, for those who are curious but may not have the time to look at ServiceMix, I've decided to share my first impressions.

I started out by installing LogicBlaze FUSE on a CentOS linux VM along with the FUSE Development Environment, which is Eclipse with some plugins. Now why FUSE you might ask? Well FUSE is interesting because it is marketed as a "runtime environment for SOA" that is based on best-of-bread open source projects. Since I was asked to look at the viability of using ServiceMix at an enterprise level, I felt that a platformed based on ServiceMix may have more to offer verses just an ESB. Anyway, back to the fun :) Ok, so now I have FUSE installed and the Development Environment on a linux distro. I start up the IDE and click on the area for a tutorial on the first screen and eclipse crashes! Ok, not a very good start. It seems like most of the SOA products are "happier" on Windows so I switched platforms to a Windows XP VM. Things seemed a little more stable from then on. In the interest of time, my colleague Tom Purcell then took the "ball" with the FUSE stuff and I turned my focus on ServiceMix.

I installed ServiceMix 3.1 stand-alone on my Windows XP VM and started looking at the canned examples (i.e. File Binding and loan-broker). A couple things really impressed me:

• Ease of Service Assembly deployment - Very similar to deploying a web app (.war file) in Tomcat, just copy your service assembly archive (e.g. loan-broker-sa.zip) into the deploy directory of the ServiceMix installation home. ServiceMix will then try to load the assembly and tell you if you need anything.
  
• Ease of JBI component installation - wow, it can't get much simpler than this. The loan-broker example require some JBI components that were not installed in my instance of ServiceMix. So, how did I know...well ServiceMix was kind enough to tell me exactly what JBI components I needed in the server log. Here's an example from the log:
  
  

  10:14:12,571 | WARN  | Timer-4    | AutoDeploymentService    | ramework.AutoDeploymentService  341 |
  Components servicemix-lwcontainer are not installed yet: the service 
  assembly loanbroker deployment
  is suspended and will be resumed 
  once the listed components are installed
  
  
  10:14:12,883 | INFO  | Timer-4    | AutoDeploymentService    | ramework.AutoDeploymentService  646 |
  Directory: deploy: Finished installation 
  of archive:  loanbroker-sa.zip
  

  
  What is also very nice is that ServiceMix suspended my assembly until the dependencies were resolved! In this case I need to find the "loanbroker-sa.zip", as the log told me" and copy it into install directory.
  

The File Binding example is a very good example of declarative programming in ServiceMix. It's not a robust example but it does give you a sense of the benefits for developing JBI compliant assemblies.

Ok, with the good there's always some bad. The bad in this case is lack of documentation and current documentation. For example, I was trying to do a little work with XSQL in ServiceMix and I found a page on the ServiceMix website about it. The problem is that the code snippets and configuration were missing. After plenty of searches, a couple emails to a user group and even pulling down the latest source from subversion I found that the XSQL support was moved to a "sandbox" area. I was encouraged to use a non-JBI compliant JDBC component instead. It's still not clear what the future is for XSQL in ServiceMix. That is just one of many examples where the documentation is lacking. Obviously, this plays a role in an evaluation of any product or project.

Overall I'm very encouraged with what I've seen in a short period of time with ServiceMix. I'm back working with Java CAPS to finish up what I started with our use case in the lab. However, I'm really curious to continue looking at ServiceMix and how it compares to another JBI compliant ESB OpenESB.

Open ESB & GlassFish: JMS messaging (part 1)

In my last post Open ESB & GlassFish: Getting Started I provided information on our SOA Lab as well as history behind why we selected Open ESB & GlassFish to test in the lab. This post I describe my experience with trying to implement the first step in our use case, JMS messaging between a Alert System running in a Geronimo application server and a BPEL process running in GlassFish.

My goal is to build a BPEL process that can send and receive JMS messages with the Alert System running in a separate and different application server. Sounds pretty straight forward and nothing new for even the "greenest" of SOA products. However, there one little detail that doesn't make this so simple...the message queue implementation is ActiveMQ running in Geronimo.

So I figured I'd first "ease" my pain with this implementation by walking through a tutorial "Step by Step toward a jms sample in NetBeans and yes GlassFish" on Masoud Kalali's Blog...and to no one's surprise, it worked. In all fairness, it turned out to be a good and informational tutorial. Masoud's approach was to:

1. Configure the internal GlassFish JMS implementation
2. Develop a Message-Driven Bean (MDB) to pop messages off a queue
3. Develop a web-based JMS client application that would put messages on a queue

The sample was quite simple and easy to build, deploy and test. However, remember my first blog post (Let the Journey Begin), I mentioned that "...we are not satisfied with just stepping through scripted tutorials of basic examples that the SOA product vendors offer." This is a good example. Masoud's sample works very nicely however, it's using GlassFish JMS implementation, the MDB is deployed in the same GlassFish application server and the web-based JMS client application is (yet again) deployed in the same GlassFish application server.

Ok, at this point I feel I'm ready to implement the first step in the use case. I have the VE (Virtual Enterprise) running in a Geronimo application server that uses ActiveMQ. The Alert System running in Geronimo is placing messages on an ActiveMQ queue. After doing some research and talking with my colleague Steve Smith (who is working with CapeClear on implementing the same use case), I came up with the following approach:

1. Configure a ActiveMQ resource adapter in GlassFish. I referenced the steps in the Sun Java System Application Server docs for Foreign JMS Providers
2. Change the MDB annotations to map to the remote ActiveMQ queue
3. Test with the Alert System running in Geronimo

Well I was able to successfully configure the ActiveMQ resource adapter in GlassFish. The MDB deployed just fine with the changes to the annotations to map to the remote ActiveMQ queue however, messages are not being pop off the ActiveMQ queue. Interestingly enough, I can use the web-based JMS client deployed in GlassFish to put messages on the remote ActiveMQ through the resource adapter in GlassFish. So, I believe the resource adapter is configured properly but my MDB is still having "issues."

I'm real close but not there yet. To top it off, I've had to temporarily "shelf" the Open ESB & GlassFish project and focus on Sun Java CAPS. We were fortunate enough to get some Sun training on Java CAPS and we've decided to implement the use case in the SOA lab since Java CAPS is still fresh in our minds. As much as I hate to leave a problem unresolved, I have to in this case but I WILL come back to it.

...my next post will be on the Sun Java CAPS SOA product tools in our lab.

Open ESB & GlassFish: Getting Started

The SOA Lab
Before I start talking about my experience so far with Open ESB & GlassFish let me set the stage by introducing the SOA Lab. First a special thanks to my colleague Steve Smith for blogging about a key piece of the SOA Lab and that is The Virtual Enterprise...less work for me :-). I recommend reading The Virtual Enterprise post first to get a better understanding of systems/applications that make up the VE and their interfaces. The SOA Lab is a reference architecture with the VE representing business systems and at its core is a "pluggable" component for swapping in SOA products. This provides us with an environment for evaluating SOA products, learning and performing proof-of-concepts. Ok, now that you have at least a high-level understanding of the lab lets move on.

Open ESB & GlassFish - Why?
We recently starting looking at Open ESB & GlassFish after a potential client inquired about our knowledge and experience with the products. We had identified the need to evaluate an open source SOA project but didn't select one right away. We thought that it would either ServiceMix or Mule (which we already had experience with and is a key component of the VE). Both ServiceMix and Mule are on the radar for the lab but not in our current iteration. So, knowing very little about Open ESB & GlassFish I started my research.

After spending some time on the GlassFish community website (https://glassfish.dev.java.net/) things started coming together for me. GlassFish is a Java EE 5 application server that is "...based on the source code for Sun Java System Application Server PE 9 donated by Sun Microsystems and TopLink persistence code donated by Oracle." The project is getting plenty of support from Sun and Oracle, not to mention, more than 100 contributers in the community. So, it appears that we have a mature and robust application server with good support.

Ok, so what is Open ESB? A quick google turned up its community website (https://open-esb.dev.java.net/). After spending some time on the website I'm coming to the understanding that Open ESB is a service bus based on Java Business Integration (JBI). What is very interesting is that Java EE 5 SDK now includes a subset of functionality (JBI runtime, a BPEL 2.0 Service Engine, and a SOAP binding component) from Open ESB.

So far I like what I'm reading, however, as my colleague Tom would say..."the devil is in the details." My next question is what tools do I use to build Open ESB composite application? Well good news for NetBeans IDE fans, there is a NetBeans Enterprise Pack for NetBeans 5.5 that includes nice tooling for creating BPEL processes graphically. I haven't spent a whole lot of time with the tools, but they do seem to be pretty good. The downside is that if you're IDE of choice is not NetBeans then you're out of luck. I'm not aware of Open ESB support any other IDE...after all this is a Sun supported project :)

Ok, I've liked what I've read so far and even though I haven't used NetBeans for a while I'm open to other IDEs so that doesn't bother me. It's settled, we've decided to select Open ESB & GlassFish as our first open source SOA project to evaluate in the SOA Lab.

...the next post I'll discuss my experience with JMS support in GlassFish to integrate with the Alert System in our VE, which is the first step in our business use case.

Let the Journey Begin

The "Journey" I'm referring to is a path to a better understanding of SOA (Service Oriented Architecture) and the tools that enable an organization to achieve it. My name is Rod Biresch and I'm part of a team of Enterprise Architects that include Steve Smith and Tom Purcell at Chariot Solutions who are taking a real world "hands on" practical approach to SOA. So why are we doing this? The answer is pretty simple, we are not satisfied with just stepping through scripted tutorials of basic examples that the SOA product vendors offer. Moreover, these tutorials just happen to work very nicely on a single machine in the same product suite. We've took it upon ourselves to find out what these tools can do in "real world" situations with various applications on disparate platforms. Ok, hopefully I have your interest by now. As much as I'd like to jump right in and explain what we're doing I have to take a step back.

So lets start at the beginning, what is SOA? Today, it has so many meanings and formal definitions that seems to vary depending on which expert you talk to. As my colleague Steve Smith blogged in The Beginning, there seems to be no single or "correct" definition to SOA (Service Oriented Architecture). As for opinions, there are plenty...some people coin it as "marketecture" an others don't see the big deal..."we've been integrating systems and service-enabling applications for long time now!?" Quite frankly, I believe there's truth in both of these. But anyway, I like to think of SOA in business terms as a goal rather than a framework or architectural component. Those pieces are "enablers" of an SOA. Now I'm not going explain why businesses are considering SOA or attempt to formalize it, that's not the point of this blog. Besides, we have plenty of qualified experts out there, not to mention, resources on the web for that, e.g. Wikipedia on "SOA". The fact is that SOA has a lot of momentum in the market and product vendors like IBM, Oracle, Sun Microsystems, BEA, etc. have made huge investments in SOA. Corporations are taking a closer look at SOA and trying to figure out what it means to their business. So practically speaking, SOA is here today and indications are that it continues to quickly gain momentum. However, this fast growth brings plenty of confusion and a need for knowledge, as we found out.

The work we are doing in our lab is very exciting. The knowledge and experience our team has gained through the lab is invaluable and I plan on sharing my findings on this blog. In subsequent posts I'll be discussing my experience with a commercial SOA product (Sun Java CAPS) and an open source ESB (Open ESB on GlassFish). My goal with this blog is to pass along information from a non-biased view on implementing a real world business scenarios with these tools.

Rod Biresch
Enterprise Architect
Chariot Solutions