Discover the Apache Geronimo application server through the eyes of someonewho's used IBM WebSphere® Application Server for many years (along with othercommercial J2EE application servers). This tutorial explores the ins and outs ofGeronimo, comparing its features and capabilities to those of WebSphere ApplicationServer, and provides insight into how to conceptually architect sharing an applicationbetween 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 inunderstanding more about Geronimo.
• Want to gain a comparative groundwork understanding of Geronimo andWebSphere Application Server.
• Are considering sharing applications between WebSphere ApplicationServer and Geronimo.
• Simply want to learn and understand what other technologies are outthere (which I often do).
To get the most out of this tutorial, you should have a basic familiarity with the IBMWebSphere Application Server product family. You should also posses a generalunderstanding of J2EE terminology and technologies and how they apply to theWebSphere Application Server technology stack.
System requirements
If you'd like to implement the two technologies included in this tutorial, you'll needthe following software and components:
• IBM WebSphere Application Server. The version I'm using as a basecomparison is IBM WebSphere Application Server, Version 6.0. However,given the large install base of WebSphere, Version 5.1, I makeretrospective version references. To obtain this software, see your IBMsales representative to purchase, or check with your employer to see ifthey have available licenses. You can also download a trial version.
• Apache Geronimo. I've used Geronimo, Version 1.0, Milestone 3 as thecomparison version for this tutorial. You can download Geronimo underthe Apache Software Foundation (ASF) licensing scheme.
Because I've written this tutorial while traveling, I've been restricted to using myMicrosoft® Windows® XP Professional-based notebook computer on which all thesecomponents are installed. For the purposes of this tutorial, you can get away with512MB of memory and an Intel® Pentium® processor with Intel Centrino™ mobiletechnology at >1.6GHz or a Pentium 4 2.66GHz processor (I'm using a Pentium 43.06GHz with 1GB of memory).
Section 2. Introduction to Apache Geronimo and IBMWebSphere Application Server
This section gives you a high-level overview of Geronimo and WebSphereApplication Server. After completing this section, you'll have a better understandingof 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 SoftwareFoundation incubator stables, and it builds on the tremendous success of theApache Tomcat project. Originally conceived in late 2003, Geronimo, like many opensource initiatives, took form rapidly through the open source community'senthusiasm.
In May 2004, Geronimo became an official top-level Apache project. Since then ithas undergone J2EE 1.4 certification testing. As of the end of June 2005, Geronimois fully J2EE 1.4 compliant.
With Geronimo falling under an open source licensing banner, it's distributed througha General Public License (GPL)-like arrangement known as the Apache License.Unlike the Apache License, more typical GPL-like licensing schemes, such as theLesser General Public License (LGPL), muddy the water when entities, such asIndependent Software Vendors (ISVs), start to develop plug-ins and third-partyproducts consumed within an open source (LGPL) package.
Ultimately, this means that if you develop server products and development tools forGeronimo under the LGPL, there is ambiguity regarding how the derived work islicensed. That is, does a commercially developed support tool for Geronimoautomatically become LGPLed, or does it remain under its own licensingarrangement? This discussion is the source of much ongoing debate and is beyondthe scope of this tutorial.
One of the most interesting aspects of Geronimo is that it's based on many existingframeworks and tools that are individually available in the open source world. Youmight 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 thewheel, the Geronimo team has made a smart and architecturally valid decision toreuse existing components. The components that are incorporated into theGeronimo system include Apache Tomcat, Jetty, Velocity, Apache Eve, MX4J, andmany others. (Later in this tutorial, we'll cover the inner workings of the Geronimoserver.)
This framework is excellent for those who are bent toward a purer open sourceoperating philosophy, but it can prove to be an unusual operating model forarchitects or system managers who aren't well-versed in the intricacies of opensource tools. While it can be tempting to upgrade individual components withupdated versions as each is re-released, system operators may inadvertentlyupgrade the individual (open source) component and break the system. Like anyproduct you install and manage, upgrades of components that make up the overallplatform should be performed in conjunction with formal release schedules andsoftware concurrency matrixes.
Figure 1 provides a high-level component view of Geronimo. The major componentsthat are reused in each tier are shown in red boxes (these are only a handful of themore prominent external components incorporated into Geronimo). Theimplementation specifications are listed under each tier. Also, the blue-green box foreach tier depicts the custom components and the Geronimo core. The capabilitiesincorporated into these blue-green boxes represent the wiring and plumbing thatmake up Geronimo's core platform.
That's enough about Geronimo for a moment. The second player in this tutorial isIBM WebSphere Application Server, no doubt the market-leading J2EE applicationserver offering from IBM. WebSphere Application Server is deployed into some ofthe largest and most complex enterprise and Web-enabled applications globally. Thelatest 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 distributedarchitectures that are similar to service-oriented architectures (SOAs).
So why would someone who uses WebSphere Application Server consider usingGeronimo?
The power of Geronimo comes in its approach to (re)using existing open sourcepackages. Near the conclusion of this tutorial, a table outlines some of Geronimo'skey components and describes their sources (such as Apache or other open sourcecommunity 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 andGeronimo in detail.
Application server overview
Application servers are the centerpiece of any J2EE implementation. They provideall the run time, core operational infrastructure, and interface plumbing for deployedJava/J2EE applications. Being a specification-oriented architecture, J2EE mandatesthat any application server that aims to be called a J2EE application server mustadhere to the specification exactly.
As noted earlier, Geronimo, like any J2EE-compliant server, has had to undergosignificant testing through the J2EE certification process to become J2EE certified.Some people think the certification process is counterproductive; but although it's aresource- and time-intensive requirement for enterprise applications, it's consideredmandatory to always run on a fully certified platform.
The application server concept was developed years ago by pioneers, such as ATGwith its ATG Dynamo application server. The application server concept is anabstracted runtime architecture. The core idea is to hide the intricacies of integration,run time, communications, and so on from the developer and have the applicationserver run these facilities and services. Figure 2 shows a high-level view of thecontainer concept.
Figure 2. High-level context view of a J2EE application server
The container provides a medium by which deployed modules have their runtimeintrospective communications and IO managed. As shown in Figure 2, the containerrun time manages attempts to access the components deployed to the container. Nodirect access is provided to internally deployed components. This abstraction allowsthe 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 J2EEapplication servers.
Under the hood
The Web container is a well-known component of a J2EE environment. It'sresponsible 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) -- youcan have multiple JVMs -- it provides standard Java object-management services,such as garbage collection and object allocation/deallocation for servlets andJavaBeans.
Although the Web container is synonymous with Web-based technologies, it'scapable of running standard Java technologies such as JavaBeans and dataconnectivity services like Java Database Connectivity (JDBC). In smallerenvironments, many application architects choose not to use Enterprise JavaBeans(EJBs) -- and hence the EJB container. Instead they choose to operate all code andfunctionality from within the Web container.
There's nothing technically wrong with this approach. However, a few limitationsmight 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 alternativeapplication and platform design options.
Figure 3 shows an example Web container implementation within WebSphereApplication Server.
Figure 3. High-level context view of a Web container
The EJB container is synonymous with the Web container in that it provides andfacilitates the runtime requirements and services for operating EJBs.
One of the big selling points of EJBs is that an EJB container handles all thelow-level work that you typically need to do. This includes what I like to call theplumbing -- all the things that relate to file management, database connectivity(depending, of course, on CMP, BMP, or JDBC direct), threading, transactionmanagement, and so on. This type of development is typically the mostdeveloper-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 theapplication server. Essentially, the EJB container provides an operational constructfor the EJBs.
The EJBs communicate to the outside world through an intermediate layer. Figure 4shows the way EJB clients communicate to EJBs within the EJB container.
It's important for system managers to get an overview of the EJB technology in thecontext of the EJB container. Therefore, as a high-level overview of how the EJBworks in relation to the EJB container, Figure 4 shows a simple EJB transaction. Asdepicted in the figure, once the client has obtained a reference to the businesscomponents' home object, the client/client application requests the home object tofind or create an EJB.
The home object creates or finds the EJB, and a reference to the remote object (inother words, the remote EJB object) is returned to the client. The client then calls abusiness method to the EJB object. This EJB object works with the container tomanage the transaction, the communications, and the thread between the client andthe EJB itself. The EJB object at this point proxies the business method call and theassociated values to the bean for processing.
The EJB then processes the request using properties and values stored in the JavaNaming and Directory Interface (JNDI) context. After processing has beencompleted, the return values are proxied back to the EJB object, which returns thevalues to the client.
The stage at which the proxy between the client, the EJB object, and the EJB takesplace is a complex phase of the transaction. You can tweak many performancelevers at this point, both in code and in the EJB container and application server, tooptimize or tune the transaction.
In the current version of EJB (2.1), EJBs are one of the more complex areas of J2EEapplication development. To summarize, whereas the bulk of the complexity lies inthe application code, the EJB container and deployment model include many movingparts, 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 applicationcomponents are required to extend or implement. The container usesthese APIs and protocols to manage the components. Whenever acontainer needs to create, instantiate, or invoke methods on applicationcomponents, it's required to implement or extend these various, yetspecific, Java interfaces or classes.
2. Container services API: The element of the container that allowsinternally deployed and external components to gain access to the actualimplementation of the J2EE APIs mentioned earlier -- Java Authenticationand Authorization Service (JAAS), JNDI, Java Transaction Services(JTS), and so on.
3. Declarative services: The area where design strategies such asInversion of Control (IoC) begin to come into effect. Essentially, thedeclarative services of a container intercept the application components,based on the deployment description provided for each applicationcomponent, such as security and transactions.
4. Other container services: Services that include other runtime servicesrelated to component life cycle, resource pooling, garbage collection,clustering, and so on.
5. Resources: External resources, such as LDAP servers and databaseservers, to which you can connect your applications. Like any good J2EEapplication server, Geronimo allows you to connect to these resources.The OpenEJB container that Geronimo uses to implement EJB serviceslets you do this through its resource manager component. The resourcemanager component is analogous to that found in WebSphere ApplicationServer. If you're familiar with WebSphere Application Server, you knowthat you can manage the resource and JDBC manager components fromwithin the WebSphere Application Server's main administrative console.
Section 4. Key differences between Geronimo andWebSphere Application Server
This section details the key architectural and functional differences between the twoapplications, helping you gain a deeper understanding of the two application serversand their capabilities. You'll see how Geronimo's inherent architecture makes itflexible, similar to WebSphere Application Server's architecture. At the end of the
section you'll understand, however, why WebSphere Application Server andGeronimo can't be directly compared.
Key Geronimo components: dependency injection
If you use WebSphere Application Server on a regular basis, you'll find that theGeronimo architecture is holistically similar, but has a number of subtle yet importantdifferences. Geronimo started its life as a J2EE application server based around aJava Management Extensions (JMX) core. The JMX approach used the technologyto implement all the management layers and instrumentable logic within thecontainers. JMX was being implemented by the MX4J open source JMX engine,and, although a hearty piece of technology, it proved that the Geronimo team waspushing it beyond its design boundaries. The reason is that Geronimo fundamentallyoperates by way of a Geronimo Bean (GBean). GBeans are somewhat similar tomanaged beans (MBeans), but are more refined to Geronimo's purpose. (Moreabout these shortly.)
Unlike WebSphere Application Server, which uses MBeans for managementpurposes, Geronimo was attempting to use the GBeans/MBeansmanagement-centric approach to manage service-centric components. The concepthas merit and stretches conventional architecture, but the service-centric andmanagement-centric code are at right angles to each other. After what was probablysubstantial deliberation, the Geronimo team changed their strategy to replace theJMX 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 ofdependencies into the container at run time. This approach can provide decoupledconfigurations and code from the normal run time. For example, IoC letsIoC-compliant application servers seamlessly inject configurations or parametersinto the run time. This injection can include parameter setup (database URLs, forexample) 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 applicationitself, 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 theGeronimo core. The core, or kernel, is responsible for managing the life cycle anddependencies of all the individual components that run within a Geronimoapplication server. These managed components can be services, such astransaction managers, resource managers, resources like a database or directoryinstance, 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 andintermanagement of components so that when a deployed Web application serviceneeds a reference to another Web application when it bootstraps, there is reference,lookup, and location infrastructure in place to support this. (There are twoincarnations of this Geronimo kernel: one is a lightweight core for command-linepurposes, and the other is the full-fledged one just discussed.) WebSphereApplication Server doesn't have a core like that of Geronimo. Instead, WebSphereApplication Server operates by way of MBeans. But the implementation purpose ofthese MBeans stretches to high-order functions within the application server.
What does the Geronimo kernel look like? Figure 5 depicts a high-level architectureof the kernel. This diagram isn't an official view of the Geronimo world; it's myinterpretation 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 beginto understand how the kernel-based approach of Geronimo leads to a modulararchitecture. The services are another differing element between WebSphereApplication Server and Geronimo. They're used to managing the deployed serviceswithin the various containers. These services are managed by way of the GBeansJMX communications. In essence, this kernel architecture allows the Geronimo coreto mix and match its configured-to-run container services. For example, designershave a choice of Jetty or Tomcat as their Web application server. The selection anddeployment of either of these options is managed by the Web application service.
WebSphere Application Server and Geronimo can't be directly compared.WebSphere Application Server is a conglomeration of hundreds of components andfacilities. The Geronimo package fits on a CD, whereas the full WebSphereApplication 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. Geronimois lightweight both physically and from a runtime perspective. But if what you'retrying 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), thenGeronimo is a nice platform. Given WebSphere Application Server's hyperclusteringand scalability support, there is no comparison, in my view, for mission-criticalsystems.
However, because of the approach the Geronimo team has taken with the IoCkernel, Geronimo is better positioned to be deployed onto systems that have asmaller footprint. These might be embedded implementations or small devices thatneed J2EE services to operate deployed applications. (But in this case, why wouldn'tyou use Jini and JavaSpaces? Yet another discussion!)
Section 5. Topological considerations
This section outlines three common WebSphere Application Server deploymentapproaches and provides a comparative look at how you deploy Geronimo in thesame 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 subtledifferences. Let's look at a few topologies that can be applicable to both Geronimoand WebSphere Application Server and discuss the implications of each and thedifferences in the approaches.
Figure 6 depicts a WebSphere configuration containing a single Web server out infront of the environment and an application server operating a Web and an EJBcontainer. A database is included for data persistence.
This diagram depicts one of the simplest forms of a production-like environment thatyou'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 servercould be anything from a Sun ONE HTTP server (iPlanet) or an Apache HTTPserver. The IBM HTTPD Web server, distributed with IBM WebSphere ApplicationServer, is Apache under the covers. So, for a Geronimo implementation, you couldpotentially deploy an Apache HTTP server here, and use the Jakarta Tomcat Webcontainer 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 theHTTP server, its configuration passes the request to the Tomcat Web containersitting on the Geronimo core.
The Web container and EJB containers that are shown can also be readilysupported by Geronimo services. The Web container services could be supported byJetty or Tomcat, whereas the EJB services would be supported by the OpenEJBcontainer.
Dual-channel approaches to deployment
The next level of complexity adds an additional HTTP Web server to provideload-balancing capabilities at that physical tier. In Figure 7, the same back-endconfiguration as in Figure 6 is visible, with the Web and EJB containers as well asthe database tier. In this form of configuration, all components are supportable by aGeronimo implementation.
Figure 7. Dual Web instance, single back-end channel topology
For security purposes, it's possible to replace the HTTP servers withGeronimo-based Web containers (using Tomcat or Jetty) to proxy-enable therequests to the back-end Geronimo server where business logic resides. If you tookthis approach -- deploying two instances of, say, Tomcat under Geronimo as theHTTP servers -- it wouldn't be a technical or architectural issue. But dueconsideration needs to be applied to the operational and security facets of theapproach. This is a common approach for application platforms that have a heavyuse of Web components, such as JSPs and servlets, and that make little use ofheavier 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 issitting on or near Internet-based servers. In this scenario, you'd deploy Geronimoand Tomcat on the HTTP servers and tear down all inbound requests.Subsequently, logic in the Geronimo-based Tomcat server would re-establish therequest to the back-end Geronimo application server by a different mechanism orstrategy.
Complete dual-channel approach
The next evolution, shown in Figure 7, has two back-end Geronimo applicationservers. In Figure 8 you can see that two WebSphere Application Servers are
deployed. This is just as achievable under a Geronimo model. However, you'rerunning two stand-alone application server instances that might or might not bestateless.
Figure 8. Dual-channel topology
For the Web container aspects of the configuration, Tomcat supports a form ofclustering 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 byhaving two physical Geronimo application servers deployed with the same deployedapplication.
If you want to deploy an application on a Geronimo platform under a controlled andsmall budget, myriad options are available for clustering and failover support. Forexample, the Linux™ High Availability (HA) project (see Resources for a link to theWeb site) supports a fairly robust clusterware layer that lets you configure Geronimoapplication servers together in a hot-standby configuration. In this scenario, if one ofthe application servers that was servicing user requests failed, the clusterware fabricwould automatically failover to the second or tertiary server and resume processinguser requests. The failover time could be kept to a minimum if the standby serverwas configured to be in a hot-standby mode (Geronimo and applicationsbootstrapped 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 overhauledas part of Java EE 5 (J2EE Version 1.5), but they're part of J2EE 1.4. Geronimoextends the deployment descriptor concept to an extra level through the use ofdeployment plans.
Deployment plans let Geronimo-specific information overlay the J2EE-compliantdescriptors, ensuring that there are no clashes with the official schemas andallowing an abstracted deployment model for future features. Physically, thedeployment plan is another XML file; it can be located inside a module's archive orstored externally so you can manage and edit it through a deployment/managementtool.
A Geronimo deployment plan can have several different names depending on themodule type and its location. For example, the deployment plan for an EJB JARmodule, embedded in the JAR, is called openejb-jar.xml. Whereas a deploymentplan for an enterprise-application EAR module is called geronimo-application.xmlwhen embedded in the archive. When deployment plans are maintained outside ofthe archive, they can have any name.
Although I'm not a fan of deployment descriptors, this ability is a great concept; it letsGeronimo developers and architects segment their specific needs and configurationsaway from the specifications' needs. However, as with most WebSphere applicationdeployments these days, the industry has, for the most part, settled on Apache Antas the tool of choice. Ant makes Geronimo-specific tasks -- as well as the standardones for components like Apache Tomcat -- available to developers. Thus, anapplication destined for WebSphere Application Server can be easily deployed into aGeronimo application server environment. Of course, if the application you'rebuilding uses specific proprietary WebSphere API extensions and the like, this won'tbe a one-to-one mapping process.
Platform architectures
Like WebSphere Application Server, Geronimo runs on many server platforms. Atlatest 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 includethe IBM AIX® operating system. I suspect, however, that it isn't a support issue andthat 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 faras to say that Geronimo is operable on AIX and other operating systems that havecompliant Java Runtime Environment (JRE)/ and Java Development Kits (JDKs)available. This fairly exhaustive list of operating platforms that Geronimo runs on isyet another sound reason why Java is a powerful technology. Small to largeorganizations can operate the same form of technology.
Capable of operating as an N-Tier environment, Geronimo also allows for mixedenvironments. For example, many organizations choose to run lower-end(commodity-class) servers for Web tier, operating on platforms such as Linux orWindows; the back-end business and application tiers run higher-grade servers.Geronimo is flexible due to its inherent architecture, similar to that of WebSphereApplication Server.
Section 6. Geronimo module considerations
As discussed, Geronimo comes with modules that you can implement and removeusing the dynamic runtime services incorporated into Geronimo through theJMX-based GBeans IoC container. This section explores the core modules thatGeronimo 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 Webcontainer tier. The Web application container includes the choice of Jetty or Tomcatas the default Web container to provide the runtime functions for Java Webtechnologies (servlets, JSPs, and so on). The Web application services interface letsthese containers interconnect with other services and components within thedeployed Geronimo server environment. Geronimo allows an extended, specificGeronimo 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, EJBcontainer, 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 Webcontainer) provides services and management control over the container run time byway of servers (EJB application services). Geronimo supports entity-, session-, andmessage-driven beans, as well as newer features for J2EE 1.4, such as the EJB
The EJB container services natively support EJB 2.1 and are compatible with EJB2.0. Applications can access EJBs of both versions within the same application andthrough remote clients. Like the Web application services and container functions,the EJB deployment construct allows for Geronimo-specific configuration functions inaddition to the standard J2EE functions.
J2EE connectors
Geronimo includes a connector container that supports both inbound and outboundresource adapters. Outbound connectors are the typical gateways to enterpriseinformation systems, whereas inbound connectors allow external systems to deliverasynchronous messages back to Geronimo. Typically, this receiver function isfacilitated through message-driven EJBs running within the Geronimo EJB container.
Running against the J2EE connector 1.5 spec, connectors can be deployed as partof the server configuration (available to all applications) or as part of a specificapplication's configuration.
As is the case for all other containers within Geronimo, a connector .rar file caninclude Geronimo-specific configuration information in addition to the standard J2EEdeployment descriptor. Geronimo is compatible with and supports the earlier J2EEconnector 1.0 version of resource adaptors.
J2EE application clients
Geronimo provides a J2EE 1.4-compliant application client container that operates ina way similar to WebSphere-deployed Java/J2EE Application Client (JAC)deployments. The container provides services and functions for running applicationclients in a managed environment, typically from outside the core containers. Thislets a client application access all the resources in the server environment using thesame Java Naming and Directory Interface (JNDI) environment mapping techniquesthat EJB components and Web tier components would use to access otherapplication modules. All communication with the server remains transparent to theapplication, which eliminates the need for additional technologies or hoop-jumpingcustom code development. An application client can include Geronimo-specificconfiguration information in addition to the standard J2EE deployment descriptor.
J2EE application archives
Like WebSphere Application Server, Geronimo supports .ear file packaging. You cancustomize any application to configure and deploy specific Geronimo services whenthe application is deployed. Application dependencies can also be expressed,making it easier to handle groups of related applications.
Section 7. Sharing applications between Geronimo andWebSphere Application Server
This section describes considerations you'll need to review when sharingapplications between the two platforms. At the conclusion of this section, you'll find asummary of the open source nature of Geronimo, which includes a listing ofGeronimo's relationship with other open source projects.
IDE considerations
WebSphere Application Server and Geronimo are both J2EE-compliant applicationservers. As long as you don't use any proprietary extensions of WebSphereApplication Server, sharing applications between them should be a trivial task. Asmentioned 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 theIBM extensions within WebSphere Application Server -- you'll find it's straightforwardto build an application for Geronimo that was originally built for WebSphereApplication Server.
If you're an Eclipse lover, then you're in luck. Eclipse has several open source-basedWeb Tool Platform (WTP) plug-ins that allow seamless development ofGeronimo-bound J2EE applications. Tim Francis of IBM has written a greatquick-start guide to installing and using the Geronimo plug-in for Eclipse called"Create, deploy, and debug Apache Geronimo applications" (developerWorks, May2005). IBM's commercial integrated development environments (IDEs) -- IBMWebSphere Studio Application Developer and IBM Rational® Application Developerfor WebSphere Software -- are all but based on Eclipse, so you can manipulatethese plug-ins into being available for them, too.
Technology considerations
Given that Geronimo can run on virtually any operating system supported by Javatechnology, your choices of where to deploy your Geronimo installation are wide andvaried. My initial thoughts about this facet of your platform architecture focus onclustering and high availability. The current release of Geronimo provides littlesupport for clustering and so forth.
If you want to explore Geronimo in a more HA environment, you need to takeadvantage of other forms of clustering and availability techniques. WebSphereApplication Server, on the other hand, is a true HA, fully clusterable J2EE applicationserver. Although technically both application servers are J2EE compliant, there is nocomparison when it comes to the significant requirements and what comes suppliedout of the box in the way of clustering and HA functionality.
WebSphere Application Server has 15 layers of technology that provide HA andclustering capabilities, from the deployment manager features in WebSphereApplication Server Network Deployment, Version 5.1 and WebSphere ApplicationServer 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 byway of hardware or software load balancing. This form of HA would provide areverse-clustering type of configuration. As long as your application was mostlystateless, 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 bothcustom Geronimo-developed code and many open source packages. The followinglist indicates Geronimo's relationship with open source projects:
• JavaServer Pages 2.0: Jetty and Tomcat (see Resources for links tothese Web sites).
• Enterprise JavaBeans 2.1: OpenEJB (see Resources for a link to theEJB container project page).
• Java Message Service (JMS) 1.1: ActiveMQ (see Resources to link tothe ActiveMQ messaging engine home page).
• Java Naming and Directory Interface 1.2.1: Custom codeimplementation.
• Java Transaction API (JTA) 1.0: Custom manager with High-speedObjectWeb Logger (HOWL) for transaction logging, distributed transaction(XA) supported.
• 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 Resourcesfor a link to the Scout site).
• JSR 115 -- Java Authorization Contract for Containers (JACC):Custom development using JDK's Java Authentication and AuthorizationService (JAAS) support.
• Internal database: Apache Derby (see Resources for links to the Derbyproject page and developerWorks Derby content area).
• Persistence mechanism: Unified substrate for Container ManagedPersistence (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 theperspective of a WebSphere Application Server user. I've made a point not toprovide a comparative review of the two platforms, because doing so would be afruitless exercise, like comparing apples and oranges.
Geronimo is a fairly new technology, and it will undoubtedly undergo changes as itemerges. I believe that Geronimo's baseline architecture puts it in an interestingposition for the future, and I'm confident that it will be a viable alternative to theJBoss application server that's already available.
The Resources section includes links to some useful Geronimo material available onthe Web. Keep an eye on these resources for new and emerging information.
• Visit the developerWorks Apache Geronimo project area to access excellentresources, articles, and tutorials for Geronimo developers.
• Visit the Apache Geronimo home page for links to all the software, forums, anddocumentation 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, anotherCodehaus project used within Geronimo.
• Find more information about Derby, a reference architecture-like databasedeployed as the default Relational Database Management System (RDBMS)with Geronimo, at the Apache Derby project home page and in the IBMdeveloperWorks Apache Derby resource area.
• Visit the Axis open source Web services stack project page. WebSphereApplication Server also uses Axis for parts of its WS-I stack.
• Locate all relevant details of the MX4J open source project, which implementsthe 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 forWeb services compatibility.
• Deploy a JDBC connector using the connector from TranQL, which is part ofGeronimo.
Get products and technologies
• Download the Apache Tomcat Web application server.
Discuss
• Participate in the discussion forum for this content.
About the author
Adam NeatAdam Neat has been using IBM WebSphere products for many years now, havingarchitected 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 consultingfirm, 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 necessarilyreflect those of his employer.
