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.
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.
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.
5 comments:
We are beginning to use JCAPS 513 in a linux environment. I like you review of the product - it's an easy read. Have you ever run into a problem whereby a running Enterprise Manager will "lock Out" a second running Enterprise Manager that is trying to add servers (domains)? Is there a way to only allow one running Enterprise Manager? There are several of us who will be administering JCAPS and we all log in with the Admin account.
Hi, I'm glad you enjoyed the post! I haven't had a chance to look at JCAPS 5.1.3. I'm actually waiting for the next major release 6.0 to see how Sun changes the product as it converges with OpenESB. Unfortunately, I haven't run into the problem with Enterprise Manager only because I haven't tried running multiple Enterprise Managers to administer a domain.
Hi. I tried to use eManager to upload files to the repository but the exception `invalid distance code` appers while uploading logicalhost-win32.sar. Do you know what is the problem ? Or know where i can get the solution ? Thanks!
If my memory serves me correctly, all .sar files should be uploaded to the Repository (e.g. http://localhost:12000/). Enterprise Manager is a web application to administer the logical hosts. Hope this helps.
The decision that you can use only one eManager per environment is by design and for good safety reasons. Basically one Logicalhost instance can be monitored by only one eManager instance, to avoid undesired concurrency.
Post a Comment