1.3. JOnAS Architecture
JOnAS is designed with services in mind. A service typically provides system resources to containers. Most of the components of the JOnAS application server are pre-defined JOnAS services. However, it is possible and easy for an advanced JOnAS user to define a service and to integrate it into JOnAS. Because J2EE applications do not necessarily need all services, it is possible to define, at JOnAS server configuration time, the set of services that are to be launched at server start.
The JOnAS architecture is illustrated in the following figure, showing WEB and EJB containers relying on JOnAS services (all services are present in this figure). Two thin clients are also shown in this figure, one of which is the JOnAS administration console (called JonasAdmin).
1.3.1. Communication and Naming Service
The Communication and Naming Service (also called Registry) is used for launching the RMI registry, the CosNaming, and/or the CMI registry, depending on the JOnAS configuration (that is, the CAROL configuration, which specifies which communication protocols are to be used). There are different registry launching modes, such as using the same JVM or not, and launching automatically if not already running. CAROL enables multi-protocol runtime support and deployment, which avoids having to redeploy components when changing the communication protocol.
The Communication and Naming Service provides the JNDI (Java Naming and Directory Interface) API to application components and to other services in order to bind and look up remote objects (for example, EJB Homes) and resource references (JDBC DataSource, Mail, and JMS connection factories, etc.).
1.3.2. EJB Container Service
The EJB Container Service is in charge of loading the EJB components and their containers. EJB containers consist of a set of Java classes that implement the EJB specification and a set of interposition classes that interface the EJB components with the services provided by the JOnAS application server. Interposition classes are specific to each EJB component and are generated by the deployment tool called GenIC.
JOnAS configuration provides a means for specifying that this service be launched during JOnAS initialization.
Enterprise JavaBeans (EJB) are software components that implement the business logic of an application (while the servlets and JSPs implement the presentation). There are three types of Enterprise JavaBeans:
Session beans are objects associated with only one client; they are short-lived (one method call or a client session) and represent the current state of the client session. They can be transaction-aware, stateful, or stateless.
Entity beans are objects that represent data in a database. They can be shared by several clients and are identified by means of a primary key. The EJB container is responsible for managing the persistence of such objects. The persistence management of such an object is entirely transparent to the client that will use it, and may or may not be transparent to the bean provider who develops it. This depends on if it is one of the following:
For an Enterprise Bean with Container-Managed Persistence, the bean provider does not develop any data access code; persistence management is delegated to the container. The mapping between the bean and the persistent storage is provided in the deployment descriptor, in an application server-specific way.
For an Enterprise Bean with Bean-Managed Persistence, the bean provider writes the database access operations in the methods of the Enterprise Bean that are specified for data creation, load, store, retrieval, and remove operations.
Message-driven Beans are objects that can be considered as message listeners. They execute on receipt of a JMS Java Message Service message; they are transaction-aware and stateless. They implement some type of asynchronous EJB method invocation. (Refer to http://java.sun.com/products/jms/.)
JOnAS configuration provides a means for specifying a set of EJB-JAR files to be loaded. EJB-JAR files can also be deployed at server runtime using the JOnAS administration tools.
For implementing Container-Managed Persistence of EJB 2.0 and EJB 2.1 (CMP2), JOnAS relies on the ObjectWeb JORM (Java Object Repository Mapping http://jorm.objectweb.org/) and MEDOR (Middleware Enabling Distributed Object Requests http://medor.objectweb.org/) frameworks. JORM supports complex mappings of EJBs to database tables, as well as several types of persistency support (relational databases, object databases, LDAP repositories, etc.).
JOnAS also implements the Timer Service features as specified in EJB 2.1.
1.3.3. WEB Container Service
The WEB Container Service is in charge of running a servlet/JSP engine in the JVM of the JOnAS server and of loading web applications (WAR files) within this engine. Currently, this service can be configured to use Tomcat (see http://jakarta.apache.org/tomcat/). Servlet/JSP engines are integrated within JOnAS as web containers, that is, containers that provide the web components with access to the system resources (of the application server) and to EJB components, in a J2EE-compliant way.
JOnAS configuration provides a means for specifying that the WEB Container Service be launched during JOnAS initialization. Additionally, JOnAS configuration provides a means for specifying a set of WAR files to be loaded. Such WAR files can also be deployed at server runtime using the JOnAS administration tools. User management for Tomcat and JOnAS has been unified. The class-loading delegation policy (priority to the Webapp classloader or to the parent classloader) can be configured.
Servlet (http://java.sun.com/products/servlet/) and JSP (http://java.sun.com/products/jsp/) are technologies for developing dynamic web pages. The servlet approach allows the development of Java classes (HTTP servlets) that generate HTML pages and that can be invoked through HTTP requests. Typically, servlets access the information system using Java APIs (such as JDBC or the APIs of EJB components) in order to build the content of the HTML page they will generate in response to the HTTP request. The JSP technology is a complement of the servlet technology. A JSP is an HTML page containing Java code within particular XML-like tags; this Java code is in charge of generating the dynamic content of the HTML page.
Servlets and JSPs are considered as J2EE application components, responsible for the application presentation logic. Such application components can access resources provided by the J2EE server (such as JDBC datasources, JMS connection factories, EJBs, mail factories). For EJB components, the actual assignment of these resources is performed at component deployment time and is specified in the deployment descriptor of each component, because the component code uses logical resource names.
1.3.4. EAR Service
The EAR Service is used for deploying complete J2EE applications, that is, applications packaged in EAR files, which themselves contain EJB-JAR files and/or WAR files. This service handles the EAR files and delegates the deployment of the WAR files to the WEB Container service and the EJB-JAR files to the EJB Container service. It handles creating the appropriate class loaders, as defined in the J2EE specification, in order for the J2EE application to execute properly.
For deploying J2EE applications, JOnAS must be configured to launch the EAR service and to specify the set of EAR files to be loaded. EAR files can also be deployed at server runtime using the JOnAS administration tools.
1.3.5. Transaction Service
The Transaction Service encapsulates a Java Transaction Monitor called JOTM, a project from ObjectWeb (http://jotm.objectweb.org). It is a mandatory service that handles distributed transactions. It provides transaction management for EJB components as defined in their deployment descriptors. It handles two-phase commit protocol against any number of Resource Managers (XA Resources). For J2EE, a transactional resource can be a JDBC connection, a JMS session, or a J2EE CA Resource Adapter connection. The transactional context is implicitly propagated with the distributed requests. The Transaction Monitor can be distributed across one or more JOnAS servers; thus a transaction may involve several components located on different JOnAS servers. This service implements the JTA 1.0.1 specification, thus allowing transactions from application components or from application clients to be explicitly started and terminated. Starting transactions from application components is allowed only from Web components, session beans, or message-driven beans. Restricting transactions to only these two types of beans is called Bean-managed transaction demarcation.
One of the main advantages of the EJB support for transactions is its declarative aspect, which means that transaction control is no longer hard-coded in the server application, but is configured at deployment time. This is known as container-managed transaction demarcation. With container-managed transaction demarcation, the transactional behavior of an Enterprise Bean is defined at configuration time and is part of the deployment descriptor of the bean. The EJB container is responsible for providing the transaction demarcation for the enterprise beans according to the value of transactional attributes associated with EJB methods. These attributes can be one of the following:
NotSupported: If the method is called within a transaction, this transaction is suspended during the time of the method execution.
Required: If the method is called within a transaction, the method is executed in the scope of this transaction; otherwise, a new transaction is started for the execution of the method and committed before the method result is sent to the caller.
RequiresNew: The method is always executed within the scope of a new transaction. The new transaction is started for the execution of the method and committed before the method result is sent to the caller. If the method is called within a transaction, this transaction is suspended before the new one is started, and resumed when the new transaction has completed.
Mandatory: The method should always be called within the scope of a transaction; otherwise, the container throws the TransactionRequired exception.
Supports: The method is invoked within the caller transaction scope. If the caller does not have an associated transaction, the method is invoked without a transaction scope.
Never: With this attribute the client is required to call the method without a transaction context, otherwise the container throws the java.rmi.RemoteException exception.
The ObjectWeb project JOTM (Java Open Transaction Manager), is actually based on the transaction service of earlier JOnAS versions. It will be enhanced to provide advanced transaction features, such as nested transactions and "Web Services" transactions (an implementation of DBTP is available).
1.3.6. Database Service
This service is responsible for handling Datasource objects. A Datasource is a standard JDBC administrative object for handling connections to a database. The database service creates and loads such datasources on the JOnAS server. DataSources to be created and deployed can be specified at JOnAS configuration time, or they can be created and deployed at server runtime using the JOnAS administration tools. The database service is also responsible for connection pooling; it manages a pool of database connections to be used by the application components, thus avoiding many physical connection creations, which are time-consuming operations. The database service can now be replaced by the JDBC Resource Adapter, to be deployed by the J2EE CA resource service, which additionally provides JDBC PreparedStatement pooling.
1.3.7. Security Service
The Security Service implements the authorization mechanisms for accessing J2EE components, as specified in the J2EE specification.
EJB security is based on the concept of roles. The methods can be accessed by a given set of roles. In order to access the methods, you must be in at least one role of this set.
The mapping between roles and methods (permissions) is done in the deployment descriptor using the security-role and method-permission elements. Programmatic security management is also possible using two methods of the EJBContext interface in order to enforce or complement security check in the bean code: getCallerPrincipal() and isCallerInRole (String roleName). The role names used in the EJB code (in the isCallerInRole method) are, in fact, references to actual security roles, which makes the EJB code independent of the security configuration described in the deployment descriptor. The programmer makes these role references available to the bean deployer or application assembler by way of the security-role-ref elements included in the session or entity elements of the deployment descriptor.
Web security uses the same mechanisms; however, permissions are defined for URL patterns instead of EJB methods. Therefore, the security configuration is described in the Web deployment descriptor. Programmatically, the caller role is accessible within a web component via the isUserInRole (String roleName) method.
In JOnAS, the mapping between roles and user identification is done in the user identification repository. When using Tomcat for user authentication, this user identification repository can be stored either in files, in a JNDI repository (such as LDAP), or in a relational database. This is achieved through a JOnAS implementation of the Realm for each Web container and through the JAAS (Java Authentication and Authorization Service) login modules for Java clients.
Realms use authentication resources provided by JOnAS, which enable you to rely on files, LDAP, or JDBC. These realms are in charge of propagating the security context to the EJB container during EJB calls. JAAS login modules are provided for user authentication of Web Container and Java clients. Certificate-based authentication is also available, with the CRLLoginModule login module for certificate revocation.
JOnAS also implements the Java Authorization Contract for Containers (JACC 1.0) specification, allowing you to manage authorizations as Java security permissions and to plug in any security policy provider.
1.3.8. Messaging Service
Asynchronous EJB-method invocation is possible on Message-driven Bean components. A Message-driven Bean is an EJB component that can be considered to be a JMS (Java Message Service) MessageListener; that is, a service that processes JMS messages asynchronously (see http://java.sun.com/products/jms). It is associated with a JMS destination. Its onMessage method is activated on the reception of messages sent by a client application to this destination. It is also possible for any EJB component to use the JMS API within the scope of transactions managed by the application server.
For supporting Message-driven Beans and JMS operations coded within application components, the JOnAS application server relies on a JMS implementation. JOnAS makes use of a third-party JMS implementation; currently the JORAM open-source software is integrated and delivered with JOnAS, the SwiftMQ product can also be used, and other JMS provider implementations can easily be integrated (see http://joram.objectweb.org/ and http://www.swiftmq.com/). JORAM provides several noteworthy features, particularly:
Reliability (with a persistent mode)
Distribution (transparently to the JMS client, it can run as several servers, thus allowing load balancing)
The choice of TCP or SOAP as the communication protocol for messages.
The JMS service is in charge of launching (or establishing a connection to) the integrated JMS server, which may or may not run in the same JVM as JOnAS. It also provides connection pooling and thread pooling (for Message-driven Beans). Through this service, JOnAS provides facilities to create JMS-administered objects such as the connection factories and the destinations, either at server-launching time or at runtime using the JOnAS administration tools.
Note that the same function of JMS implementation integration can now be achieved through a Resource Adapter, to be deployed by the J2EE CA Resource Service. Such a Resource Adapter, J2EE CA 1.5, is provided for JORAM.
1.3.9. J2EE CA Resource Service
The J2EE Connector Architecture (J2EE CA) allows the connection of different Enterprise Information Systems (EIS) to a J2EE application server. It is based on the Resource Adapter (RA); this is an architecture component—comparable to a software driver—that connects the EIS, the application server, and the enterprise application (J2EE components). The RA is generally provided by an EIS vendor and provides a Java interface (the Common Client Interface or CCI) to the J2EE components for accessing the EIS (this can also be a specific Java interface). The RA also provides standard interfaces for plugging into the application server, allowing them to collaborate to keep all system-level mechanisms (transactions, security, and connection management) transparent from the application components.
The application performs "business logic" operations on the EIS data using the RA client API (CCI), while transactions, connections (including pooling), and security on the EIS are managed by the application server through the RA (system contract).
The JOnAS Resource service is in charge of deploying J2EE CA-compliant Resource Adapters (connectors), packaged as RAR files, on the JOnAS server. RAR files can also be included in EAR files, in which case the connector will be loaded by the application classloader. Once Resource Adapters are deployed, a connection factory instance is available in the JNDI namespace to be looked up by application components.
A J2EE CA 1.0 Resource Adapter for JDBC is available with JOnAS. It can replace the current JOnAS database service for plugging JDBC drivers and managing connection pools. It also provides JDBC PreparedStatement pooling.
A J2EE CA 1.5 Resource Adapter for JMS is available with JOnAS. It can replace the current JOnAS Messaging service for plugging into JORAM.
1.3.10. Management Service
You require the Management service in order to administer a JOnAS server from the JOnAS administration console. Each server running this service is visible from the administration console.
The Management service is based on JMX (Java Management Extension). Standard MBeans defined within the JOnAS application server expose the management methods of the instrumented JOnAS server objects, such as services, containers, and the server itself. These MBeans implement the management model as specified in the J2EE Management Specification. The Management service runs a JMX server (currently the MX4J server, but the Sun RI server is also available). The MBeans of the JOnAS server are registered within this JMX server.
The JOnAS administration console is a Struts-based Web application (servlet/JSP) that accesses the JMX server to present the managed features within the administration console. Thus, through a simple Web browser, it is possible to manage one or several JOnAS application servers. The administration console provides a means for configuring all JOnAS services (and making the configuration persistent) and for deploying any type of application (EJB-JAR, WAR, EAR) and any type of resource (DataSources, JMS and Mail connection factories, J2EE CA connectors), all without the need to stop or restart the server. The administration console displays information for monitoring the servers and applications. This information includes used memory, used threads, number of EJB instances, and which component currently uses which resources. When Tomcat is used as Web Container, the Tomcat Management is integrated within the JOnAS console. A Management EJB (MEJB) is also delivered, providing access to the management features, as specified in the J2EE Management Specification.
1.3.11. Mail Service
A J2EE application component can send e-mail messages using JavaMail (see http://java.sun.com/products/javamail/). The Mail service of the JOnAS application server provides the resources necessary for the J2EE application components. The Mail service creates mail factories and registers these resources in the JNDI namespace in the same way that the database service or the JMS service creates Datasources or ConnectionFactories and registers these objects in the JNDI namespace. There are two types of mail factories: javax.mail.Session and javax.mail.internet.MimePartDataSource.