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.