|Home > Index > Geronimo Architecture > 4 - Geronimo Module View|
The Module View contains high level information about how Geronimo is organized into subsystems and packages. It's also intended to give a high level picture of what each module/subsystem's purpose is and how it communicates with other modules/subsystems. For the purposes of this document, the focus with be the modules directory in the Geronimo Source.
A subsystem is a logical grouping of modules. Below is a list of subsystems and the modules assigned to those subsystems:
J2EE Management Model
Java Persistance API
ActiveMQ is an Apache implementation of a Message Bus. It's supports JMS 1.1 and is developed separately from Geronimo. More information can be found here. It's important to note with this subsystem that the code in Geronimo around ActiveMQ are just a wrappers (specifically a GBeans). There are three modules in this subsystem. The ge-activemq-rar module contains the ActiveMQ RAR (from the ActiveMQ project), the geronimo-activemq-gbean module contains the GBean wrappers around ActiveMQ. The geronimo-activemq-gbean-management contains the interfaces for accessing the subsystem externally. Using only these interfaces outside of the ActiveMQ subsystem allows another MQ solution substituted for ActiveMQ in the future. An example of how this subsystem is used externally (specifically the externally usable interfaces) is by the console. The console accesses the subsystem through the interfaces in geronimo-activemq-gbean-management, retrieved via GBean.
geronimo-directory provides access to the LDAP server embedded in Geronimo. The embedded LDAP server is provided by the ApacheDS project and is used for some demo applications that ship with Geronimo.
The Application Client subsystem handles calls from standalone applications that exist outside of the Geronimo instance. An example of this would be a CORBA call into the application server.
The geronimo-system module contains much of the core code required to run Geronimo. Internally, Geronimo uses GBeans rather than JMX MBeans to handle communication between modules. The code to convert between GBeans and MBeans are in this module along with an MBean Server (which basically just delegates calls to the Geronimo Kernel). Other things contained in this module is the code to start the Geronimo server and the runtime logging information.
This module is Geronimo's implementation of the Java Transaction API specification. The specification essentially has 4 required interfaces: UserTransaction, Transaction, TransactionManager, and XAResource. Implementations of these four interfaces are found in the geronimo-transaction module. The implementation of Transaction (TransactionImpl) is used by the application server for transaction aware processing. The UserTransaction implementation (GeronimoUserTransaction) is used by the web containers (Jetty and Tomcat) for usage in deployed web applications. TransactionManager is used when the application server manages the transactions for the application automatically (such as with some EJB operations). Finally the XAResource implementation (used through NamedXAResource in Geronimo) implements X/Open CAE Specification transaction standard.
Geronimo uses Codehaus's WADI software to aid it in clustering instances of Geronimo servers. The geronimo-clustering module contains more generic code, independent of WADI, such as interfaces for cluster nodes and distributed sessions. The other modules contain code utilizing WADI for distributing requests to the servers. More information on WADI can be found here.
This subsystem is Geronimo's implementation of the Sun's J2EE Management Model (JSR 77). The purpose of this subsystem is to provide generic interfaces for Geronimo's specific implementations. For example, in the geronimo-management modules there is an interface called JMSBroker that is implemented by the ActiveMQBroker.
JAAS is an Authentication and Authorization specification created by Sun. Geronimo has implemented this specification for use by applications deployed in Geronimo. There are two modules in this subsystem. The geronimo-security module contains the code that implements the JAAS specification.
JavaMail is a specification put out by Sun to abstract away some of the details of sending an Email in Java. Geronimo wraps these standard JavaMail classes so that they can be accessed and managed via GBeans. An example of how these are wrapped is the javax.mail.Session class. The Session class manages configuration and authorization information. In Geronimo, the Session class can be accessed via org.apache.geronimo.mail.MailGBean in the geronimo-mail module. JavaMail also uses the JavaBeans Activation Framework (JAF). The JavaBeans Activation Framework is intended to help identify the contents of the various attributes in JavaBeans. In the case of the JavaMail framework, it's used for MIME types. Geronimo has extended JAF to handle data from the MIME types, these classes are in the geronimo-activation module.
The J2EE Connector Architecture is a vendor independent specification for connecting and communicating with Enterprise Information Systems, such as Enterprise Resource Planning (ERP) systems. The Geronimo implementation of this is available in the geronimo-connector module. The associated geronimo-connector-builder module is used for converting the XML deployment plans into run-time connectors.
This subsystem contains an implementation of the Java Naming and Directory Interface. The geronimo-naming module contains all of the classes to handle JNDI look-ups and expose those classes via GBeans to the rest of the Geronimo server. The geronimo-naming-builder reads in deployment plans and creates new entries in the running JNDI contexts.
The Java Persistence API is a specification added to EJB 3.0 to allow easier persistence of EJBs. Geronimo uses Apache's OpenJPA implementation of JPA. More information on it can be found here. The purpose of the code in Geronimo around JPA Is wrapping the JPA code in a GBean. In the geronimo-persistence-jpa10 module, the PersistenceUnitGBean class allows access to the OpenJPA routines through the GBean. The geronimo-persistence-jpa10-builder module creates the persistence GBeans at runtime, from the XML configuration files.
The shared subsystem contains modules used by many other subsystems and also code that is used by various application server utilities and the demo applications that are shipped with Geronimo.
Apache Derby is a Java based relational database included with Geronimo. It's small memory footprint allows it to be embedded in applications. Derby is used in Geronimo for several things. First, Geronimo comes with several example applications that use a database, rather than require an external database to be installed, Derby was included. Derby is also used to help make searchable log files. The geronimo-derby module wraps Derby and exposes it as a GBean.
This module creates a cron like system for Geronimo. It utilizes the java.util.Timer class to schedule the execution of various tasks. It also allows the tasks to be transactional.
This is a small module that contains code to convert datasource configurations from the format used in BEA's Weblogic and JBoss's Application Server to Geronimo. It's only used by the console for creating new datasources.
The geronimo-upgrade module contains code to aid in the migration from one version of Geronimo to another. Utility code here migrates one version of a deployment plan to another.
This module handle remote connections to the MBeanServer. It handles authentication through JAAS and will contain a reference to the current running instance of the GBean/MBean Server.
Jetty and Tomcat are both web containers that are available for use with Geronimo. These web containers are not maintained by the Geronimo developers however there are GBean wrappers to many of the operations for the Jetty and Tomcat servers. The code for these subsystems are intended to adapt the containers into the Geronimo environment.
Modules for deploying web services inside of Geronimo. Geronimo includes the support of Axis, which is an implementation of SOAP and can be found here. The geronimo-webservice and geronimo-webservice-builder modules are more generic. The generic modules are used by the web containers, rather that using Axis directly (so the rest of the application server is not tied to Axis).