Geronimo is young; JBoss is not

You might have come here to read about Geronimo, or you might have come here to read about JBoss. Each of these two camps has been around for a couple of years now. The Geronimo camp has just reached the version 1.1.1 release in September of this year; JBoss is quite mature, with four major releases behind it. There seems to be a trend lately toward porting JBoss applications over to Geronimo. This article provides technical information on issues you may encounter in getting the job done and gives you a peek at features that have been added to the Geronimo 1.0 release to make this transition smoother in the future. In short, it surveys the landscape.

Licensing

Apache Geronimo, released under the business-friendly Apache 2.0 license, has been in development since the fall of 2003. Geronimo has reached the version 1.1.1 release, but it would be impossible for me to list all the features that have been added in the prior year since the last pre-1.0 release without taking up all of my article space.

JBoss is released under the Lesser General Public License (LGPL). While the LGPL is generally a friendly license for business, occasions arise in which you need to make changes to the JBoss source code to support your particular application, and that precipitates the need to donate those changes back to the JBoss source base as a patch. The latest version of JBoss Application Server is 4.0, and it has support for a large number of useful and forward-looking plug-ins.

J2EE 1.4 certification

To make the comparison a little more relevant we have to go back in time and compare pre-1.0 JBoss to pre-1.0 Geronimo. I only became aware of JBoss when it was in its 2.0 phase of development, so I'll give JBoss a head start. The main comparison I can draw here that's factual (instead of based on gut feeling) is that when Geronimo was pre-1.0 it was already J2EE 1.4 certified. JBoss wasn't certified until it was into its 4.0 release, and that was after a great deal of controversy and rumblings of incomplete compliance and unreasonable fees flying in various directions. That was only a little over a year ago.

The Geronimo team, on the other hand, seems to have sailed through the certification process with much fanfare. I think this says a lot about the dedication of the Geronimo team with regard to adherence to standards. I think it also says a lot about the relative maturity of the project.

Architecture is everything

JBoss Application Server, Version 4.0 is built entirely on a Java Management Extensions (JMX) architecture. JMX is an API developed by Sun Microsystems (see Resources for a link) that allows a standard naming and lookup mechanism to find JMX components easily and a standard calling mechanism so that JMX components can be used within other code. I have used JMX and JBoss extensively in the past to create new components, such as a modem pool JMX service for supporting old serial line calls from remote devices, and found the JMX architecture to have one particularly annoying problem. I ended up peppering my code with JMX API calls every time I wanted to use my JMX service. While this is easy to encapsulate, it's still a portability barrier because it requires you to rewrite your lookup and calling code, effectively tying your application to the JBoss platform.

Basically, it's dangerous to use platform-specific features within an application, regardless of the power of the respective APIs, unless you're willing to tie your application to that platform permanently. One case of such an API is the JBossAOP feature of recent JBoss application servers, usage of which would closely bind your application to JBoss and reduce its portability to other J2EE platforms.

The Geronimo application server, on the other hand, is architected as lightweight components called GBeans. The primary difference between Geronimo and JBoss that I can discern after reading through some of the Geronimo kernel code is that the GBean architecture is a component abstraction that is richer than JMX. What really makes the architecture special is its heavy internal use of a concept called Inversion of Control (IOC). The article "Geronimo GBean Architecture" (see Resources for a link) details how the GBean architecture works. Dependencies between GBeans and references to other GBeans are managed automatically by the Geronimo kernel. The kernel provides for the needs of each GBean at run time, looking at what each GBean says it needs and injecting the appropriate references. This frees the developer from having to constantly write meaningless registry lookup code, such as that enforced by the JMX API.

So, what does this mean? It means that Geronimo's architecture frees developers from meaningless code clutter introduced by APIs like JMX. The main building block of Geronimo is the GBean, which provides a straightforward method of providing information about the needs of each GBean, such as how to construct a GBean at run time and provide what it needs to run. Another refreshing feature of this architecture: There's no XML involved in creating a GBean -- just a few lines of actual source code. What's more, the information contained in a GBean can easily be converted to the information required for JMX, so it can be thought of as a superset of JMX and, therefore, more flexible in the long term.

In the interest of fairness, JBoss is undergoing a change to a more modular architecture for the 5.0 version of the application server. But in attempting to obtain information about this new architecture by reading the provided documentation, many references to the phrase is subject to change without notice lead me to believe that the current ideas on the microkernel architecture are not fully fleshed out. I found many references to Aspect-Oriented Programming (AOP) and Reflection Caching in the documentation, which suggest this may be an IoC architecture. I've also found later references to supply and demand in describing a component that supports this hypothesis. However, the reference to dependencies seems to refute the hypothesis, because in a true IoC system, the dependencies are determined at run time. JBoss' documentation mentions that XML descriptors are used to describe all the runtime needs of the components. I prefer specification of the runtime behavior of a class within the class itself, keeping all the information about a class in one place. However, since JBoss has not finished implementing their architecture, we'll have to wait for the answers to these questions to become clear.

Back to top

Current rough spots and evidence of sanding

The following sections compare some of the significant features in Apache Geronimo and JBoss.

Automatic schema creation for CMP

JBoss has almost always had automatic schema generation for Container Managed Persistence (CMP). It also has a nice feature called automatic schema migration, which automatically modifies a database table based on differences JBoss finds with a newly deployed application. This effectively reduces the need for database administrators to modify schemas when simple changes, such as the addition or removal of database columns, are performed. Of course, more complex changes would still require a schema migration tool of some sort.

Automatic schema creation for CMP is currently unfinished in Geronimo. To use CMP within Geronimo, you have to use one of the following methodologies:

• Generate your own database schema for the application and install it manually.
• Use one of the databases whose schema language is supported by TranQL, and then use the TranQL schema generator within your build system to generate the schema output at build time

You still have to prepare your database manually using this generated schema. However, Dain Sundstrom has been busy closing issues, including initial implementations of the automatic schema creation for CMP. With automatic schema generation working, I expect that deployment of a CMP application would generate the initial schema, and no SQL commands would have to be run by the user of the deployed application.

Connecting to multiple databases

Geronimo uses the TranQL library to support Java Database Connectivity (JDBC) connections to multiple databases for CMP. JBoss originally used a library called JBossCMP, and has more recently begun integration of the popular Hibernate library for database access, which allows JBoss to support many database dialects. TranQL has a well-defined dialect support structure, but currently doesn't support as many dialects out of the box as Hibernate does.

Automatic primary key and unknown primary key generation

Other features that Geronimo developers are currently working on include automatic primary key and unknown primary key generation for CMP. Primary key generation and unknown primary key field handling is now becoming supported, and more people are beginning to use it. Geronimo already supported auto-incrementing field primary keys and sequence table primary keys. I suspect that better support for this will be developed rapidly. JBoss has these features.

Clustering and failover

Another feature that JBoss has had for at least a couple of years is the clustering and failover feature. Clustering is the ability for an application server to run many instances of itself on one or many machines (usually many machines), and it allows application connections to any of the instances transparently. By this I mean that any instance seems like any other to the user; the session state is shared among instances, effectively increasing the performance of the application manyfold. Failover is another feature of this, meaning that at any time, one of the nodes in the cluster could fail, and the state of a user's session would survive on another machine in the cluster.

Geronimo 1.1.1 has many of the pieces of a clustering solution, but unfortunately several delays prevented those features from being completed, so developers will have to wait for future Geronimo releases before they can play with those. However, I've been told that there is a procedure for getting the Tomcat module within Geronimo 1.1.1 to work in a clustered fashion. (See Resources for a link to content that will help you configure Tomcat for failover and session replication.)

Compiling with Java 5.0

The Geronimo source code base currently does not compile with Java 5.0, and I understand the main reason for this is a dependency on a Common Object Request Broker Architecture (CORBA) implementation that uses classes within the Java 1.4 class library. If you don't use CORBA, you'll be able to run your compiled Geronimo server under Java 5.0 and also run applications written with Java 5.0 features within that Geronimo server.

This is, fortunately, a temporary situation. To replace the CORBA implementation in Geronimo, the team has begun to integrate Trifork CORBA. Trifork donated the source code for their Object Request Broker (ORB) to be part of the Geronimo project in recent months and has dedicated development resources to seeing the integration through. I think this is a good step forward for the Geronimo project, because replacement of the ORB will lead to Java 5.0 compatibility in the future.

XDoclet support

Development-time code generation is something many J2EE developers have come to rely on for simplification of the development process. XDoclet is one such code generator that's used heavily for J2EE development. It takes information from special documentation tags within your Java source code and turns that information into whatever code you want based on templates you've chosen to process. The main use within a J2EE context is automatic generation of deployment descriptors based on your source code. While JBoss has a rich set of XDoclet tags available for nearly every task you can think of related to deployment descriptor generation, Geronimo lags behind in this area. What this means is that many of the deployment plans used by Geronimo to specify the information not covered in the J2EE standard still need to be maintained by hand. Support for generation of deployment plans using XDoclet, Version 1.2.3 is being developed by a team within IBM®. I believe this is very important to streamlining application deployment on Geronimo. JBoss was active in development of XDoclet modules for its application server, and Geronimo must do something similar to help easily avoid the errors developers can introduce by incorrectly specifying their deployment plans.

Hot deployment

Finally, JBoss has had hot deployment since its early days. This means that applications can be deployed by placing files into a deploy directory, and JBoss monitors the directory and automatically deploys the application if anything changes in that directory. This makes it easy to get an application running and replace old versions with new versions without taking the server offline. Geronimo has various methods of deploying an application -- through the use of the deployer tool or directly from a Maven build script using the Geronimo deployment Maven plug-in.

Apache Geronimo 1.1.1 also has hot deployment. Fortunately, Aaron Mulder recently released a hot deploy capability that supports watching a specific directory for changes to files -- if a file has been added, it will be deployed. If a file has changed (new update time on the file or the size has changed), the file will be redeployed. You can configure the directory that you want to monitor and the frequency that it checks for changes to files.

Back to top

Only a matter of time

The Geronimo project has clearly achieved the critical mass it has needed to achieve its version 1.1.1 goals. Much-needed features are being implemented daily to fill any perceived holes (compared to JBoss) in the new J2EE server. I would hazard a guess that sometime during the first quarter of 2007, Geronimo will have all the features needed to migrate an application written for JBoss, Version 4. Learning Geronimo now, and writing applications with it, will be well worth the effort, enabling you to take full advantage of not only Geronimo 1.1.1, but also IBM WebSphere® Application Server Community Edition, which is based on Geronimo.

Back to top

Features at a glance

Resources

Learn

• Take a look at this Geronimo clustering example, which can help you configure Tomcat for failover and session replication.
  
  
• Read Srinath Perera's article "Geronimo GBean Architecture" to learn how to use the GBeans architecture.
  
  
• Visit the official JBoss site.
  
  
• Join the Apache Geronimo mailing list at apache.org.
  
  
• Visit Tom McQueeney's site Geronimo Live for lots of information and resources on Geronimo.
  
  
• Check out Applying the Apache License, Version 2.0 for guidance -- both inside and outside the Apache projects -- in understanding what you need to do to apply the Apache License, Version 2.0.
  
  
• Learn more about Apache Geronimo at the following sites:
  • Apache Geronimo
  • The Geronimo Wiki
  
  
• Read the article "Three ways to connect a database to a Geronimo application server" (developerWorks, June 2005) for additional information on setting up JDBC resources in Geronimo.
  
  
• See TranQL for information on this open source framework for building persistence engines.
  
  
• Find helpful resources for beginners and experienced users at the Get started now with Apache Geronimo section of developerWorks.
  
  
• Check out the IBM Support for Apache Geronimo offering, which lets you develop Geronimo applications backed by world-class IBM support.
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  
• Check out the developerWorks Apache Geronimo project area for articles, tutorials, and other resources to help you get started developing with Geronimo today.
  
  
• Browse all the Apache articles and free Apache tutorials available in the developerWorks Open source zone.
  
  

Get products and technologies

• Get JMX, an API developed by Sun Microsystems.
  
  
• Download Apache Geronimo.
  
  
• Download your free copy of IBM WebSphere Application Server Community Edition V1.0 -- a lightweight J2EE application server built on Apache Geronimo open source technology that is designed to help you accelerate your development and deployment efforts.
  
  
• Innovate your next open source development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Participate in the discussion forum.
  
  

About the author

Neal Sanche is a Java developer recently beached in the Microsoft® .NET world and fighting for any ties back to his old, comfortable roots. His experience includes development of several commercial J2EE applications, as well as several stand-alone Java applications. In his spare time, he writes music, takes photographs, and writes technical articles. Visit his Web site at http://www.nsdev.org to see several examples of each. You can reach the author at neal@nsdev.org.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Geronimo is young; JBoss is not
• Architecture is everything
• Current rough spots and evidence of sanding
• Only a matter of time
• Features at a glance
• Resources
• About the author
• Comments

Next steps from IBM

Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).

---

• Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
• Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
• Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
• Buy: Rational Application Developer

My developerWorks community

Dig deeper into Open source on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers