Apache Geronimo Uncovered a View Through the Eyes of a Websphere Application Server Expert

Apache Geronimo uncovered A view through the eyes of a WebSphere Application Server expert

Skill Level: Intermediate

Adam Neat ([email protected]) Author Freelance

16 Aug 2005

Discover the Apache Geronimo application server through the eyes of someone who's used IBM WebSphere® Application Server for many years (along with other commercial J2EE application servers). This tutorial explores the ins and outs of Geronimo, comparing its features and capabilities to those of WebSphere Application Server, and provides insight into how to conceptually architect sharing an application between WebSphere Application Server and Geronimo.

Section 1. Before you start

This tutorial is for you if you:

• Use WebSphere Application Server daily and are interested in understanding more about Geronimo. • Want to gain a comparative groundwork understanding of Geronimo and WebSphere Application Server. • Are considering sharing applications between WebSphere Application Server and Geronimo. • Simply want to learn and understand what other technologies are out there (which I often do).

Prerequisites

To get the most out of this tutorial, you should have a basic familiarity with the IBM WebSphere Application Server product family. You should also posses a general understanding of J2EE terminology and technologies and how they apply to the WebSphere Application Server technology stack.

System requirements

If you'd like to implement the two technologies included in this tutorial, you'll need the following software and components:

• IBM WebSphere Application Server. The version I'm using as a base comparison is IBM WebSphere Application Server, Version 6.0. However, given the large install base of WebSphere, Version 5.1, I make retrospective version references. To obtain this software, see your IBM sales representative to purchase, or check with your employer to see if they have available licenses. You can also download a trial version. • Apache Geronimo. I've used Geronimo, Version 1.0, Milestone 3 as the comparison version for this tutorial. You can download Geronimo under the Apache Software Foundation (ASF) licensing scheme. Because I've written this tutorial while traveling, I've been restricted to using my Microsoft® Windows® XP Professional-based notebook computer on which all these components are installed. For the purposes of this tutorial, you can get away with 512MB of memory and an Intel® Pentium® processor with Intel Centrino™ mobile technology at >1.6GHz or a Pentium 4 2.66GHz processor (I'm using a Pentium 4 3.06GHz with 1GB of memory).

Section 2. Introduction to Apache Geronimo and IBM WebSphere Application Server

This section gives you a high-level overview of Geronimo and WebSphere Application Server. After completing this section, you'll have a better understanding of the frameworks of the two application servers.

A tale of two: Apache Geronimo

Geronimo is the newest open source Java™ 2 Platform, Enterprise Edition (J2EE) application server available. The project has been forged out of the Apache Software Foundation incubator stables, and it builds on the tremendous success of the Apache Tomcat project. Originally conceived in late 2003, Geronimo, like many open source initiatives, took form rapidly through the open source community's enthusiasm.

In May 2004, Geronimo became an official top-level Apache project. Since then it has undergone J2EE 1.4 certification testing. As of the end of June 2005, Geronimo is fully J2EE 1.4 compliant.

With Geronimo falling under an open source licensing banner, it's distributed through a General Public License (GPL)-like arrangement known as the Apache License. Unlike the Apache License, more typical GPL-like licensing schemes, such as the Lesser General Public License (LGPL), muddy the water when entities, such as Independent Software Vendors (ISVs), start to develop plug-ins and third-party products consumed within an open source (LGPL) package.

Ultimately, this means that if you develop server products and development tools for Geronimo under the LGPL, there is ambiguity regarding how the derived work is licensed. That is, does a commercially developed support tool for Geronimo automatically become LGPLed, or does it remain under its own licensing arrangement? This discussion is the source of much ongoing debate and is beyond the scope of this tutorial.

One of the most interesting aspects of Geronimo is that it's based on many existing frameworks and tools that are individually available in the open source world. You might say that Geronimo is an open source project made up of open source projects (a framework of frameworks perhaps), which means that, instead of reinventing the wheel, the Geronimo team has made a smart and architecturally valid decision to reuse existing components. The components that are incorporated into the Geronimo system include Apache Tomcat, Jetty, Velocity, Apache Eve, MX4J, and many others. (Later in this tutorial, we'll cover the inner workings of the Geronimo server.)

This framework is excellent for those who are bent toward a purer open source operating philosophy, but it can prove to be an unusual operating model for architects or system managers who aren't well-versed in the intricacies of open source tools. While it can be tempting to upgrade individual components with updated versions as each is re-released, system operators may inadvertently upgrade the individual (open source) component and break the system. Like any product you install and manage, upgrades of components that make up the overall platform should be performed in conjunction with formal release schedules and software concurrency matrixes.

Figure 1 provides a high-level component view of Geronimo. The major components that are reused in each tier are shown in red boxes (these are only a handful of the more prominent external components incorporated into Geronimo). The implementation specifications are listed under each tier. Also, the blue-green box for each tier depicts the custom components and the Geronimo core. The capabilities incorporated into these blue-green boxes represent the wiring and plumbing that make up Geronimo's core platform.

Figure 1. High-level component view of Geronimo

A tale of two: IBM WebSphere Application Server

That's enough about Geronimo for a moment. The second player in this tutorial is IBM WebSphere Application Server, no doubt the market-leading J2EE application server offering from IBM. WebSphere Application Server is deployed into some of the largest and most complex enterprise and Web-enabled applications globally. The latest incarnation of WebSphere Application Server -- Version 6 -- takes scalability, robustness, and performance features to a new level.

Packed into WebSphere Application Server's functionality is a plethora of features, functions, and capabilities that cover everything from basic JavaServer Pages (JSP) serving to capabilities that let you manage and run highly integrated and distributed architectures that are similar to service-oriented architectures (SOAs).

So why would someone who uses WebSphere Application Server consider using Geronimo?

The power of Geronimo comes in its approach to (re)using existing open source packages. Near the conclusion of this tutorial, a table outlines some of Geronimo's key components and describes their sources (such as Apache or other open source community projects).

Now, let's dive deeper into the world of J2EE application servers.

Section 3. Considerations of J2EE application servers: What makes them tick?

This section explores the container constructs of WebSphere Application Server and Geronimo in detail.

Application server overview

Application servers are the centerpiece of any J2EE implementation. They provide all the run time, core operational infrastructure, and interface plumbing for deployed Java/J2EE applications. Being a specification-oriented architecture, J2EE mandates that any application server that aims to be called a J2EE application server must adhere to the specification exactly.

As noted earlier, Geronimo, like any J2EE-compliant server, has had to undergo significant testing through the J2EE certification process to become J2EE certified. Some people think the certification process is counterproductive; but although it's a resource- and time-intensive requirement for enterprise applications, it's considered mandatory to always run on a fully certified platform.

The application server concept was developed years ago by pioneers, such as ATG with its ATG Dynamo application server. The application server concept is an abstracted runtime architecture. The core idea is to hide the intricacies of integration, run time, communications, and so on from the developer and have the application server run these facilities and services. Figure 2 shows a high-level view of the container concept.

Figure 2. High-level context view of a J2EE application server

The container provides a medium by which deployed modules have their runtime introspective communications and IO managed. As shown in Figure 2, the container run time manages attempts to access the components deployed to the container. No direct access is provided to internally deployed components. This abstraction allows the container to manage facilities such as pooling, connection rating, load balancing, and more.

Let's look at the two primary containers that make up fully compliant J2EE application servers.

Under the hood

The Web container is a well-known component of a J2EE environment. It's responsible for processing presentation-based components, such as JSPs, servlets, and other types of presentation, such as static content from HTML and XHTML files.

Because the Web container operates in its own Java Virtual Machine (JVM) -- you can have multiple JVMs -- it provides standard Java object-management services, such as garbage collection and object allocation/deallocation for servlets and JavaBeans.

Although the Web container is synonymous with Web-based technologies, it's capable of running standard Java technologies such as JavaBeans and data connectivity services like Java Database Connectivity (JDBC). In smaller environments, many application architects choose not to use Enterprise JavaBeans (EJBs) -- and hence the EJB container. Instead they choose to operate all code and functionality from within the Web container.

There's nothing technically wrong with this approach. However, a few limitations might exist from both a performance and an application functionality point of view. These mainly relate to application distribution and integration to legacy systems. This type of approach is acceptable because you can use several alternative application and platform design options.

Figure 3 shows an example Web container implementation within WebSphere Application Server.

Figure 3. High-level context view of a Web container

The EJB container

The EJB container is synonymous with the Web container in that it provides and facilitates the runtime requirements and services for operating EJBs.

One of the big selling points of EJBs is that an EJB container handles all the low-level work that you typically need to do. This includes what I like to call the plumbing -- all the things that relate to file management, database connectivity (depending, of course, on CMP, BMP, or JDBC direct), threading, transaction management, and so on. This type of development is typically the most developer-intensive aspect of coding applications that require any of these services.

The other important point to note is that the EJB container operates from within the application server. Essentially, the EJB container provides an operational construct for the EJBs.

The EJBs communicate to the outside world through an intermediate layer. Figure 4 shows the way EJB clients communicate to EJBs within the EJB container.

Figure 4. How EJB container services work

Inner workings of the EJB container

It's important for system managers to get an overview of the EJB technology in the context of the EJB container. Therefore, as a high-level overview of how the EJB works in relation to the EJB container, Figure 4 shows a simple EJB transaction. As depicted in the figure, once the client has obtained a reference to the business components' home object, the client/client application requests the home object to find or create an EJB.

The home object creates or finds the EJB, and a reference to the remote object (in other words, the remote EJB object) is returned to the client. The client then calls a business method to the EJB object. This EJB object works with the container to manage the transaction, the communications, and the thread between the client and the EJB itself. The EJB object at this point proxies the business method call and the associated values to the bean for processing.

The EJB then processes the request using properties and values stored in the Java Naming and Directory Interface (JNDI) context. After processing has been completed, the return values are proxied back to the EJB object, which returns the values to the client.

The stage at which the proxy between the client, the EJB object, and the EJB takes place is a complex phase of the transaction. You can tweak many performance levers at this point, both in code and in the EJB container and application server, to optimize or tune the transaction.

In the current version of EJB (2.1), EJBs are one of the more complex areas of J2EE application development. To summarize, whereas the bulk of the complexity lies in the application code, the EJB container and deployment model include many moving parts, so the system manager needs to be well versed in what's going on. This

model is equally applicable to WebSphere Application Server and Geronimo.

The five main parts of the EJB container model are the:

1. Container contract: A set of APIs (and protocols) that the application components are required to extend or implement. The container uses these APIs and protocols to manage the components. Whenever a container needs to create, instantiate, or invoke methods on application components, it's required to implement or extend these various, yet specific, Java interfaces or classes.

2. Container services API: The element of the container that allows internally deployed and external components to gain access to the actual implementation of the J2EE APIs mentioned earlier -- Java Authentication and Authorization Service (JAAS), JNDI, Java Transaction Services (JTS), and so on.

3. Declarative services: The area where design strategies such as Inversion of Control (IoC) begin to come into effect. Essentially, the declarative services of a container intercept the application components, based on the deployment description provided for each application component, such as security and transactions.

4. Other container services: Services that include other runtime services related to component life cycle, resource pooling, garbage collection, clustering, and so on.

5. Resources: External resources, such as LDAP servers and database servers, to which you can connect your applications. Like any good J2EE application server, Geronimo allows you to connect to these resources. The OpenEJB container that Geronimo uses to implement EJB services lets you do this through its resource manager component. The resource manager component is analogous to that found in WebSphere Application Server. If you're familiar with WebSphere Application Server, you know that you can manage the resource and JDBC manager components from within the WebSphere Application Server's main administrative console.

Section 4. Key differences between Geronimo and WebSphere Application Server

This section details the key architectural and functional differences between the two applications, helping you gain a deeper understanding of the two application servers and their capabilities. You'll see how Geronimo's inherent architecture makes it flexible, similar to WebSphere Application Server's architecture. At the end of the

section you'll understand, however, why WebSphere Application Server and Geronimo can't be directly compared.

Key Geronimo components: dependency injection

If you use WebSphere Application Server on a regular basis, you'll find that the Geronimo architecture is holistically similar, but has a number of subtle yet important differences. Geronimo started its life as a J2EE application server based around a Java Management Extensions (JMX) core. The JMX approach used the technology to implement all the management layers and instrumentable logic within the containers. JMX was being implemented by the MX4J open source JMX engine, and, although a hearty piece of technology, it proved that the Geronimo team was pushing it beyond its design boundaries. The reason is that Geronimo fundamentally operates by way of a Geronimo Bean (GBean). GBeans are somewhat similar to managed beans (MBeans), but are more refined to Geronimo's purpose. (More about these shortly.)

Unlike WebSphere Application Server, which uses MBeans for management purposes, Geronimo was attempting to use the GBeans/MBeans management-centric approach to manage service-centric components. The concept has merit and stretches conventional architecture, but the service-centric and management-centric code are at right angles to each other. After what was probably substantial deliberation, the Geronimo team changed their strategy to replace the JMX core with an Inversion of Control (IoC) container.

A discussion of dependency injection (through IoC) is a tutorial in itself; but briefly, IoC -- or dependency injection -- is an approach that allows the injection of dependencies into the container at run time. This approach can provide decoupled configurations and code from the normal run time. For example, IoC lets IoC-compliant application servers seamlessly inject configurations or parameters into the run time. This injection can include parameter setup (database URLs, for example) or the name of action classes in a Model-View-Controller (MVC) framework, which can be changed at run time and/or changed by the application itself, and then reinjected.

While IoC is a clever pattern, I'd suggest caution with its use. Use it if you need it, not because it's the cool thing to do at the moment.

The Geronimo core

Another of Geronimo's key differences from WebSphere Application Server is in the Geronimo core. The core, or kernel, is responsible for managing the life cycle and dependencies of all the individual components that run within a Geronimo application server. These managed components can be services, such as transaction managers, resource managers, resources like a database or directory instance, or deployed applications.

The Geronimo core (kernel) also manages the process of wiring all the individual

components to each other, which allows them to work together at run time.

For example, the kernel takes care of managing the intercommunication and intermanagement of components so that when a deployed Web application service needs a reference to another Web application when it bootstraps, there is reference, lookup, and location infrastructure in place to support this. (There are two incarnations of this Geronimo kernel: one is a lightweight core for command-line purposes, and the other is the full-fledged one just discussed.) WebSphere Application Server doesn't have a core like that of Geronimo. Instead, WebSphere Application Server operates by way of MBeans. But the implementation purpose of these MBeans stretches to high-order functions within the application server.

What does the Geronimo kernel look like? Figure 5 depicts a high-level architecture of the kernel. This diagram isn't an official view of the Geronimo world; it's my interpretation and understanding of the core.

Figure 5. High-level Geronimo kernel model

I'll cover deployment later in the tutorial. However, looking at Figure 5, you can begin to understand how the kernel-based approach of Geronimo leads to a modular architecture. The services are another differing element between WebSphere Application Server and Geronimo. They're used to managing the deployed services within the various containers. These services are managed by way of the GBeans JMX communications. In essence, this kernel architecture allows the Geronimo core to mix and match its configured-to-run container services. For example, designers have a choice of Jetty or Tomcat as their Web application server. The selection and deployment of either of these options is managed by the Web application service.

Apples and oranges

WebSphere Application Server and Geronimo can't be directly compared. WebSphere Application Server is a conglomeration of hundreds of components and facilities. The Geronimo package fits on a CD, whereas the full WebSphere Application Server package fills many CDs.

At the end of the day, WebSphere Application Server is a J2EE application server. Now Geronimo is too. The differences stem from a convention I've tried to avoid: calling Geronimo lightweight compared to WebSphere Application Server. Geronimo is lightweight both physically and from a runtime perspective. But if what you're trying to deploy your applications onto isn't (yet) mission critical and is lightweight (that is, a small application with only tens or hundreds of components), then Geronimo is a nice platform. Given WebSphere Application Server's hyperclustering and scalability support, there is no comparison, in my view, for mission-critical systems.

However, because of the approach the Geronimo team has taken with the IoC kernel, Geronimo is better positioned to be deployed onto systems that have a smaller footprint. These might be embedded implementations or small devices that need J2EE services to operate deployed applications. (But in this case, why wouldn't you use Jini and JavaSpaces? Yet another discussion!)

Section 5. Topological considerations

This section outlines three common WebSphere Application Server deployment approaches and provides a comparative look at how you deploy Geronimo in the same configuration.

The fun of topological architecture: single-channel approaches

How do you deploy Geronimo in contrast with WebSphere Application Server? Deployment into various flavors of environments is similar in both with a few subtle differences. Let's look at a few topologies that can be applicable to both Geronimo and WebSphere Application Server and discuss the implications of each and the differences in the approaches.

Figure 6 depicts a WebSphere configuration containing a single Web server out in front of the environment and an application server operating a Web and an EJB container. A database is included for data persistence.

Figure 6. Single-channel-based J2EE application topology

This diagram depicts one of the simplest forms of a production-like environment that you'll encounter. In the configuration shown, the Web server is the first physical tier. In the case of a WebSphere Application Server implementation, this Web server could be anything from a Sun ONE HTTP server (iPlanet) or an Apache HTTP server. The IBM HTTPD Web server, distributed with IBM WebSphere Application Server, is Apache under the covers. So, for a Geronimo implementation, you could potentially deploy an Apache HTTP server here, and use the Jakarta Tomcat Web container connection property settings to bind the two together. In this approach, URL matching can be performed so that when a request for a URL is received by the HTTP server, its configuration passes the request to the Tomcat Web container sitting on the Geronimo core.

The Web container and EJB containers that are shown can also be readily supported by Geronimo services. The Web container services could be supported by Jetty or Tomcat, whereas the EJB services would be supported by the OpenEJB container.

Dual-channel approaches to deployment

The next level of complexity adds an additional HTTP Web server to provide load-balancing capabilities at that physical tier. In Figure 7, the same back-end configuration as in Figure 6 is visible, with the Web and EJB containers as well as the database tier. In this form of configuration, all components are supportable by a Geronimo implementation.

Figure 7. Dual Web instance, single back-end channel topology

For security purposes, it's possible to replace the HTTP servers with Geronimo-based Web containers (using Tomcat or Jetty) to proxy-enable the requests to the back-end Geronimo server where business logic resides. If you took this approach -- deploying two instances of, say, Tomcat under Geronimo as the HTTP servers -- it wouldn't be a technical or architectural issue. But due consideration needs to be applied to the operational and security facets of the approach. This is a common approach for application platforms that have a heavy use of Web components, such as JSPs and servlets, and that make little use of heavier J2EE components, such as EJBs. It's also often used, as previously noted, for security purposes when a developer wants to ensure that no application logic is sitting on or near Internet-based servers. In this scenario, you'd deploy Geronimo and Tomcat on the HTTP servers and tear down all inbound requests. Subsequently, logic in the Geronimo-based Tomcat server would re-establish the request to the back-end Geronimo application server by a different mechanism or strategy.

Complete dual-channel approach

The next evolution, shown in Figure 7, has two back-end Geronimo application servers. In Figure 8 you can see that two WebSphere Application Servers are

deployed. This is just as achievable under a Geronimo model. However, you're running two stand-alone application server instances that might or might not be stateless.

Figure 8. Dual-channel topology

For the Web container aspects of the configuration, Tomcat supports a form of clustering and session state replication. So in effect you can achieve a similar -- albeit limited in comparison -- level of clustering and state load balancing. However, if state isn't an issue for you, then you can achieve this form of configuration by having two physical Geronimo application servers deployed with the same deployed application.

If you want to deploy an application on a Geronimo platform under a controlled and small budget, myriad options are available for clustering and failover support. For example, the Linux™ High Availability (HA) project (see Resources for a link to the Web site) supports a fairly robust clusterware layer that lets you configure Geronimo application servers together in a hot-standby configuration. In this scenario, if one of the application servers that was servicing user requests failed, the clusterware fabric would automatically failover to the second or tertiary server and resume processing user requests. The failover time could be kept to a minimum if the standby server was configured to be in a hot-standby mode (Geronimo and applications bootstrapped and waiting for requests).

Deployment approaches

Geronimo uses the same conventions as any compliant J2EE application server by

using deployment descriptors. Deployment descriptors are being greatly overhauled as part of Java EE 5 (J2EE Version 1.5), but they're part of J2EE 1.4. Geronimo extends the deployment descriptor concept to an extra level through the use of deployment plans.

Deployment plans let Geronimo-specific information overlay the J2EE-compliant descriptors, ensuring that there are no clashes with the official schemas and allowing an abstracted deployment model for future features. Physically, the deployment plan is another XML file; it can be located inside a module's archive or stored externally so you can manage and edit it through a deployment/management tool.

A Geronimo deployment plan can have several different names depending on the module type and its location. For example, the deployment plan for an EJB JAR module, embedded in the JAR, is called openejb-jar.xml. Whereas a deployment plan for an enterprise-application EAR module is called geronimo-application.xml when embedded in the archive. When deployment plans are maintained outside of the archive, they can have any name.

Although I'm not a fan of deployment descriptors, this ability is a great concept; it lets Geronimo developers and architects segment their specific needs and configurations away from the specifications' needs. However, as with most WebSphere application deployments these days, the industry has, for the most part, settled on Apache Ant as the tool of choice. Ant makes Geronimo-specific tasks -- as well as the standard ones for components like Apache Tomcat -- available to developers. Thus, an application destined for WebSphere Application Server can be easily deployed into a Geronimo application server environment. Of course, if the application you're building uses specific proprietary WebSphere API extensions and the like, this won't be a one-to-one mapping process.

Platform architectures

Like WebSphere Application Server, Geronimo runs on many server platforms. At latest count, it operates on the following:

• Sun Solaris (8 and 9) • HP-UX 11.0 • Microsoft Windows XP, 2000, and 2003 • MAC OS X • Linux, including Red Hat SUSE, Gentoo, Mandrake, and Debian • Linux x86-64 through SUSE Interestingly, the list of available platforms that Geronimo works on doesn't include the IBM AIX® operating system. I suspect, however, that it isn't a support issue and that Geronimo works on anything that is compatible with all the moving components

-- all of which are Java related. So, although I can't guarantee anything, I'd go so far as to say that Geronimo is operable on AIX and other operating systems that have compliant Java Runtime Environment (JRE)/ and Java Development Kits (JDKs) available. This fairly exhaustive list of operating platforms that Geronimo runs on is yet another sound reason why Java is a powerful technology. Small to large organizations can operate the same form of technology.

Capable of operating as an N-Tier environment, Geronimo also allows for mixed environments. For example, many organizations choose to run lower-end (commodity-class) servers for Web tier, operating on platforms such as Linux or Windows; the back-end business and application tiers run higher-grade servers. Geronimo is flexible due to its inherent architecture, similar to that of WebSphere Application Server.

Section 6. Geronimo module considerations

As discussed, Geronimo comes with modules that you can implement and remove using the dynamic runtime services incorporated into Geronimo through the JMX-based GBeans IoC container. This section explores the core modules that Geronimo provides.

What's in Geronimo's bag of tricks?

Geronimo's core modules contain the following components:

Web application container

Geronimo, like any J2EE application servers, operates a Web application or Web container tier. The Web application container includes the choice of Jetty or Tomcat as the default Web container to provide the runtime functions for Java Web technologies (servlets, JSPs, and so on). The Web application services interface lets these containers interconnect with other services and components within the deployed Geronimo server environment. Geronimo allows an extended, specific Geronimo configuration to be included in the deployment components. Given this, Web applications can actively participate in security services provided by Geronimo, allowing easy authentication and access management between Web container, EJB container, and connector services.

Enterprise JavaBeans

Geronimo includes services and hooks for EJB-compliant container control. Currently implemented through OpenEJB, Geronimo (in a similar vein to the Web container) provides services and management control over the container run time by way of servers (EJB application services). Geronimo supports entity-, session-, and message-driven beans, as well as newer features for J2EE 1.4, such as the EJB

timer capability and Web services.

The EJB container services natively support EJB 2.1 and are compatible with EJB 2.0. Applications can access EJBs of both versions within the same application and through remote clients. Like the Web application services and container functions, the EJB deployment construct allows for Geronimo-specific configuration functions in addition to the standard J2EE functions.

J2EE connectors

Geronimo includes a connector container that supports both inbound and outbound resource adapters. Outbound connectors are the typical gateways to enterprise information systems, whereas inbound connectors allow external systems to deliver asynchronous messages back to Geronimo. Typically, this receiver function is facilitated through message-driven EJBs running within the Geronimo EJB container.

Running against the J2EE connector 1.5 spec, connectors can be deployed as part of the server configuration (available to all applications) or as part of a specific application's configuration.

As is the case for all other containers within Geronimo, a connector .rar file can include Geronimo-specific configuration information in addition to the standard J2EE deployment descriptor. Geronimo is compatible with and supports the earlier J2EE connector 1.0 version of resource adaptors.

J2EE application clients

Geronimo provides a J2EE 1.4-compliant application client container that operates in a way similar to WebSphere-deployed Java/J2EE Application Client (JAC) deployments. The container provides services and functions for running application clients in a managed environment, typically from outside the core containers. This lets a client application access all the resources in the server environment using the same Java Naming and Directory Interface (JNDI) environment mapping techniques that EJB components and Web tier components would use to access other application modules. All communication with the server remains transparent to the application, which eliminates the need for additional technologies or hoop-jumping custom code development. An application client can include Geronimo-specific configuration information in addition to the standard J2EE deployment descriptor.

J2EE application archives

Like WebSphere Application Server, Geronimo supports .ear file packaging. You can customize any application to configure and deploy specific Geronimo services when the application is deployed. Application dependencies can also be expressed, making it easier to handle groups of related applications.

Section 7. Sharing applications between Geronimo and WebSphere Application Server

This section describes considerations you'll need to review when sharing applications between the two platforms. At the conclusion of this section, you'll find a summary of the open source nature of Geronimo, which includes a listing of Geronimo's relationship with other open source projects.

IDE considerations

WebSphere Application Server and Geronimo are both J2EE-compliant application servers. As long as you don't use any proprietary extensions of WebSphere Application Server, sharing applications between them should be a trivial task. As mentioned earlier -- assuming all good developers use Ant as their build script tool, and assuming you haven't developed an application that relies too heavily on the IBM extensions within WebSphere Application Server -- you'll find it's straightforward to build an application for Geronimo that was originally built for WebSphere Application Server.

If you're an Eclipse lover, then you're in luck. Eclipse has several open source-based Web Tool Platform (WTP) plug-ins that allow seamless development of Geronimo-bound J2EE applications. Tim Francis of IBM has written a great quick-start guide to installing and using the Geronimo plug-in for Eclipse called "Create, deploy, and debug Apache Geronimo applications" (developerWorks, May 2005). IBM's commercial integrated development environments (IDEs) -- IBM WebSphere Studio Application Developer and IBM Rational® Application Developer for WebSphere Software -- are all but based on Eclipse, so you can manipulate these plug-ins into being available for them, too.

Technology considerations

Given that Geronimo can run on virtually any operating system supported by Java technology, your choices of where to deploy your Geronimo installation are wide and varied. My initial thoughts about this facet of your platform architecture focus on clustering and high availability. The current release of Geronimo provides little support for clustering and so forth.

If you want to explore Geronimo in a more HA environment, you need to take advantage of other forms of clustering and availability techniques. WebSphere Application Server, on the other hand, is a true HA, fully clusterable J2EE application server. Although technically both application servers are J2EE compliant, there is no comparison when it comes to the significant requirements and what comes supplied out of the box in the way of clustering and HA functionality.

WebSphere Application Server has 15 layers of technology that provide HA and clustering capabilities, from the deployment manager features in WebSphere Application Server Network Deployment, Version 5.1 and WebSphere Application Server Extended Deployment, Version 6 to internally aware application components (clones, application server instances, and so on).

Don't get me wrong -- a Geronimo-deployed application could theoretically scale by way of hardware or software load balancing. This form of HA would provide a reverse-clustering type of configuration. As long as your application was mostly stateless, changing between N+1 Geronimo instances would be straightforward.

Summary of the open source nature of Geronimo

As highlighted several times throughout this tutorial, Geronimo is made up of both custom Geronimo-developed code and many open source packages. The following list indicates Geronimo's relationship with open source projects:

• JavaServer Pages 2.0: Jetty and Tomcat (see Resources for links to these Web sites). • Enterprise JavaBeans 2.1: OpenEJB (see Resources for a link to the EJB container project page). • Java Message Service (JMS) 1.1: ActiveMQ (see Resources to link to the ActiveMQ messaging engine home page). • Java Naming and Directory Interface 1.2.1: Custom code implementation. • Java Transaction API (JTA) 1.0: Custom manager with High-speed ObjectWeb Logger (HOWL) for transaction logging, distributed transaction (XA) supported. • JavaMail 1.3: Custom coding. • JavaBeans Activation Framework (JAF) 1.0: Custom coding. • JSR 77 -- J2EE Management 1.0: Custom coding with MX4J. • JSR 88 -- J2EE Deployment 1.1: Custom code implementation. • Java Management Extensions (JMX) 1.2: MX4J. • Java Data Access API (JDBC) 3.0, 2.1: Code from TranQL (see Resources for a link to the TranQL site). • Java API for XML Processing (JAXP) 1.2: JDK support where applicable, and Apache Xerces. • J2EE Connector Architecture (J2CA) 1.5: Custom coding; includes JMS resources and JDBC pools. • JSR 109 -- Implementing Enterprise Web Services 1.1: Apache Axis

(see Resources to link to the Axis project page). • Java API for XML-based RPC (JAX-RPC): Apache Axis. • SOAP with Attachments API for Java (SAAJ) 1.2: Apache Axis. • Java API for XML Registries (JAXR) 1.0: Apache Scout (see Resources for a link to the Scout site). • JSR 115 -- Java Authorization Contract for Containers (JACC): Custom development using JDK's Java Authentication and Authorization Service (JAAS) support. • Internal database: Apache Derby (see Resources for links to the Derby project page and developerWorks Derby content area). • Persistence mechanism: Unified substrate for Container Managed Persistence (CMP)-oriented and Beans/Plain Old Java Object (POJO)-oriented schemes over TranQL. • Interoperability: JDK support and custom code. Table source: Sing Li, fellow IBM developerWorks author

Section 8. Summary

Hopefully this tutorial has given you a comparative view of Geronimo from the perspective of a WebSphere Application Server user. I've made a point not to provide a comparative review of the two platforms, because doing so would be a fruitless exercise, like comparing apples and oranges.

Geronimo is a fairly new technology, and it will undoubtedly undergo changes as it emerges. I believe that Geronimo's baseline architecture puts it in an interesting position for the future, and I'm confident that it will be a viable alternative to the JBoss application server that's already available.

The Resources section includes links to some useful Geronimo material available on the Web. Keep an eye on these resources for new and emerging information.

Resources

Learn • Visit the developerWorks Apache Geronimo project area to access excellent resources, articles, and tutorials for Geronimo developers. • Visit the Apache Geronimo home page for links to all the software, forums, and documentation you need. From here, you can access mailing lists, newsgroups, and much more. • Learn about the Jetty application server. • Check out the EJB container (OpenEJB) project page located at Codehaus. • Visit the project home page of the ActiveMQ messaging engine, another Codehaus project used within Geronimo. • Find more information about Derby, a reference architecture-like database deployed as the default Relational Database Management System (RDBMS) with Geronimo, at the Apache Derby project home page and in the IBM developerWorks Apache Derby resource area. • Visit the Axis open source Web services stack project page. WebSphere Application Server also uses Axis for parts of its WS-I stack. • Locate all relevant details of the MX4J open source project, which implements the core JMX infrastructure. • Visit the Linux High Availability (HA) project site. • Read "Create, deploy, and debug Apache Geronimo applications" (developerWorks, May 2005) for more information on using the Eclipse plug-in. • Visit the Apache Scout Web site. Geronimo uses Scout to implement JAXR for Web services compatibility. • Deploy a JDBC connector using the connector from TranQL, which is part of Geronimo. Get products and technologies • Download the Apache Tomcat Web application server. Discuss • Participate in the discussion forum for this content.

About the author

Adam Neat Adam Neat has been using IBM WebSphere products for many years now, having architected applications and systems on WebSphere platforms that are among some

of the biggest WebSphere-based applications globally. Based out of Melbourne, Australia, Adam is an executive manager for a global management and IT consulting firm, leading custom architecture groups within the APAC region. To contact Adam, or for more information about his background, please visit his personal Web page. The thoughts and statements in this tutorial are Adam's own and do not necessarily reflect those of his employer.