Geronimo Container Services

The Geronimo server provides a rich set of container services for the use of the servers and components running inside Geronimo. Some of these services are also extended to the client application container, for use by application client code.

Naming and Directory Service

In a J2EE 1.4 system, the naming and directory service is accessed through the standard JNDI APIs. Geronimo provides a JNDI-compatible set of APIs to access the namespace containing all of its contained components. Figure 4-9 shows the operation of the Geronimo naming service.

Figure 4-9: Naming service support in Geronimo

In Figure 4-9, the Geronimo kernel gives every managed Geronimo component a name and registers it with the object lookup service inside Geronimo. A JNDI API implementation is available inside Geronimo to query the lookup service. These components can then be looked up and referenced throughout the Geronimo server using JNDI - by the different services, with any custom application code, or in configuration files that administrators create.

This means that one component can look up another component through JNDI. This capability is heavily used inside Geronimo. All Geronimo components are named according to the JSR-77 standard. This JSR specifies a convention for naming that, while convoluted for human to comprehend, is very efficient for computer to maintain and manage.

Naming service support is a quintessential feature of Geronimo. As Geronimo administrator, you will work frequently with the configuration of object name and references. Chapter 7 provides substantial details on the internal object naming convention used by Geronimo services.

The JNDI API can also be used by software components to locate configured J2EE resources, such as pooled JDBC connections or JMS destinations. A Geronimo administrator can configure these resources during deployment time. Chapters 13 and 16 provides details on such configuration.

Transaction

Geronimo supports declarative and programmatic transactions for deployed application components. Declarative transaction means that the component code itself does not deal directly with transactions. Instead, transaction boundaries can be specified during deployment time, by specifying them in a standard J2EE deployment descriptor.

A programmatic transaction is carried out by the application code. Applications can use a standard API (called JTA) to program its transaction. Programmatic transaction boundaries are typically of interest only to developers.

For many J2EE applications, the way to add a transaction to the application is via a declarative transaction during the deployment of the EJBs.

As an administrator, you should understand the options available for controlling transaction boundaries, and be familiar with the XML elements that control transaction boundary for deployment.

In Chapter 12, the deployment descriptors and elements that control transaction boundaries are examined.

Security

Geronimo supports container-wide security realms through the implementation of the Java Authentication and Authorization Service (JAAS), and an implementation of the Java Authorization Container Contract (JACC). This basically means that Geronimo can provide a variety of means (subject to plug-in modules) to authenticate a user before allowing access and then to authorize specific access based on user credentials.

There is a set of XML elements that can be used to configure security on most Geronimo resources being accessed (such as a JSP page, a servlet, an EJB, or a particular method of an EJB). These are the same elements regardless of the actual resource being protected - thanks to the container-wide uniform support of the security mechanism/policies. As an administrator, you should become familiar with this versatile set of security elements.

Chapter 15 provides a from-scratch overview of the security mechanisms packaged into Geronimo. You will also see how to use the security elements in the various deployment plans throughout Geronimo.

Manageability

Management of the Geronimo server, and visibility to all of its contained components, can be accomplished through Java Management Extension (JMX) APIs. JMX provides component-level management features based on manageable components called MBeans. The idea is for manageable software components to expose their manageable features through the properties and operations of an MBean. The JMX infrastructure can then coordinate the availability of the exposed information to a management tool or client application.

Every single Geronimo component can be optionally configured to be manageable by the developer. Since Geronimo does most of the work in making a component manageable, many component developers will take advantage of the opportunity. This is especially true for the suite of components that provide the essential J2EE services. Components such as the Tomcat or Jetty Web-tier servers are components that are created to be completely manageable.

As an administrator, you can gain access to this manageability through the use of the Web console, debug console, and jConsole (available in Java SE 5) tool. These tool displays many of the exposed properties and operations of the Geronimo server components to the administrator. The Web console in particular also enable configuration of the server components.

Chapter 7 shows the use of the debug console and jConsole to view managed components and their managed properties. Chapter 8 shows how to use the Web console to access and configure many of the managed components and their properties.

Configuration Management

With Geronimo, configuration management is a built-in feature that is pervasive throughout its design.

Every configured and deployed module in Geronimo is associated with a configuration. Geronimo manages these configurations, and relationships between configurations internally. This allow you to deploy, undeploy, and redeploy the modules with ease.

All Geronimo configurations are serializable. This means that the same configuration can be restarted, or transferred to a similar server and started. This ability to move configurations between machines is one of the many by design scalability features that is built into Geronimo. Geronimo takes advantage of this feature in its implementation of the Geronimo plug-ins. Chapter 17, an electronically downloadable bonus chapter from http://www.wrox.com, covers Geronimo plug-ins in more details.

As an administrator, you deploy and undeploy application modules to the Geronimo server. Each time add or remove modules on a Geronimo server instance, the set of managed configuration changes. Geronimo always maintains an image of the current set of configurations via a combination of the config.xml file and serialized binary image in the repository. It is often important, as an administrator, to be able to set the server to some known-good “base” state should a deployments fail catastrophic manner and cause server instability. This can be accomplished by keeping backup copies of known-good config.xml file.