| Chapter 4. Elements of Geronimo [DRAFT (1.0-pre)] | ||
|---|---|---|
 | Part I. Getting Started |  |
| Chapter 4. Elements of Geronimo [DRAFT (1.0-pre)] | ||
|---|---|---|
| | Part I. Getting Started | |
Table of Contents
This chapter gives a brief introduction to many important aspects of Geronimo:
The high-level architecture of Geronimo, composed of a kernel and services
How to start specific services or applications
The style and typical syntax of Geronimo configuration files
How Geronimo services, applications, and resources are packaged and deployed
The ClassLoader hierarchy used by Geronimo
These topics are more related than you might think. Every service, resource, or application is configured with a Geronimo deployment plan and deployed to the server in the same way, becoming a "configuration" available to the server. The kernel manages the lifecycle of the configuration, and the components within the configuration. Each configuration can be started when the server is started, and gets its own ClassLoader when run. These ClassLoaders can be arranged into a hierarchy, so each configuration may have a parent and many children.
The Geronimo core, or kernel, is small and basically responsible for managing the lifecycle and dependencies of all the individual components that run within Geronimo. Those components may be services (such as a transaction manager), resources (such as a database pool), or applications (such as a web application). The kernel also manages the process of hooking individual components up to each other, so separate components can work together at runtime. For example, the web application service (usually Jetty or Tomcat) needs a reference to every web application that starts, so when it gets an incoming HTTP request, it can dispatch it to the appropriate web application.
A diagram of a simplified Geronimo runtime might look like this (don't worry about the specific services yet, but look at the relationship between the kernel and the components):
TODO: Replace this with a better-looking diagram
In Figure 4.1, “Components in a Geronimo Runtime”, the solid bars indicate that the kernel starts and manages all of the other components. The dashed lines indicate that the individual components communicate with each other once they're up and running. The diagram is a little busy, but note that the kernel is ultimately responsible for the lifecycle of all of these components. Components don't load or manipulate each other directly; instead the kernel sets up the components and provides the communication pathways between them.
Every component managed by the kernel is a Geronimo bean, or GBean. Further, some components are broken down and deployed as multiple GBeans, for more fine-grained monitoring and management. For example, when a J2EE application is deployed, a number of GBeans are deployed representing (among other things):
The application
Each J2EE module within the application (EJB JAR, web application WAR, etc.)
Each servlet in a web application (for the Jetty web container)
Each EJB in an EJB JAR
Each connection factory or admin object configured for a J2EE connector
While GBeans representing application components are automatically created and deployed by the server, most GBeans can be configured and deployed manually. GBeans can declare read/write attributes, allowing the administrator to configure the GBean (for example, setting a port for the web application service to listen on). In addition, all GBeans can handle lifecycle events, implementing certain logic that should be run during startup or shutdown (for example, each web listener service starts an HTTP listener during startup, and stops it during shutdown). With these configuration and runtime features defined, GBeans can be monitored, configured, started, and stopped through the standard Geronimo management interface.
If you want to write additional components that should run in Geronimo, you can deploy new GBeans. You may encounter this, for example, if you want to deploy a custom JMS server configuration (see Section 7.5.2, “Message Broker GBean Configuration”), or if you want to add a brand new service. GBeans can be deployed as part of an application configuration, or as top-level standalone components in the Geronimo server. The same tools are used to deploy and manage GBeans as to deploy and manage J2EE applications.
The most important GBeans included with Geronimo are described in detail in Chapter 19, Overview of Core Geronimo Services [EMPTY].
When GBeans communicate with each other, they are not actually interacting directly. Instead, the kernel inserts a proxy in between, and the proxy provides only the methods that the destination GBean wants to expose. (In the case where there's an interface declaring the methods to be exposed, the proxy implements that interface.) So the actual communication looks more like this:
In this case, the EJB service needs a reference to a transaction manager, and the kernel gives it a proxy that implements the same interface as the actual TransactionManager GBean. This makes it easy to substitute transaction manager implementations, and gives the kernel the chance to manage the communication process between the two GBeans (including allowing one component to restart without forcing everything that depends on it to restart at the same time).
| |  | |
| 3.8. Running Geronimo as a Windows or UNIX Service |  | 4.2. Server Startup and Configurations |
