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.