# Java Open Application Server (JOnAS): a J2EETM Platform

Last modified at 2006-11-30, JOnAS 4.8

This document provides an overview of the JOnAS platform. The content of this document is the following:

- Introduction
  - J2EE
  - ObjectWeb
- JOnAS Features
  - System Requirements
  - Java Standard Conformance
  - Key Features
  - JOnAS Packages
- JOnAS Architecture
  - Communication and Naming service
  - EJB Container service
  - WEB Container service
  - Ear service
  - Transaction service
  - Database service
  - Security service
  - Messaging service
  - JCA Resources service
  - Management service
  - Mail service
  - WebServices service
  - HA service
- JOnAS Development and Deployment Environment
  - JOnAS Configuration and Deployment Facilities
  - JOnAS Development Environments
- Clustering and Performance
- Perspectives

## Introduction

### J2EE

The SunTM J2EE specification, together with its related specifications ( EJBTM, JMSTM,...), defines an architecture and interfaces for developing and deploying distributed Internet JavaTM server applications based on a multi-tier architecture. This specification intends to facilitate and standardize the development, deployment, and assembling of application components; such components will be deployable on J2EE platforms. The resulting applications are typically web-based, transactional, database-oriented, multi-user, secured, scalable, and portable. More precisely, this specification describes two kinds of information:

- The first is the runtime environment, called a J2EE server, which provides the execution environment and the required system services, such as the transaction service, the persistence service, the Java Message Service (JMS), and the security service.
- The second is programmer and user information explaining how an application component should be developed, deployed, and used.

Not only will an application component be independent of the platform and operating system (since it is written in Java), it will also be independent of the J2EE platform.

A typical J2EE application is composed of 1) presentation components, also called "web components" (Servlets and JSPsTM), which define the application Web interface, and 2) enterprise components, the "Enterprise JavaBeans" (EJB), which define the application business logic and application data. The J2EE server provides containers for hosting web and enterprise components. The container provides the component life-cycle management and interfaces the components with the services provided by the J2EE server. There are two types of containers; the web container handles Servlet and JSP components, while the EJB container handles the Enterprise JavaBeans components. A J2EE server can also provide an environment for deploying Java clients (accessing EJBs); it is called client container.

### ObjectWeb

JOnAS is an open source application server, developed within the ObjectWeb consortium. ObjectWeb is an open source initiative which can be compared to Apache or Linux, but in the area of middleware. The aim of ObjectWeb is to develop and promote open source middleware software.

ObjectWeb is an International Consortium hosted by INRIA, officially founded in February 2002 by Bull, France Telecom, and INRIA. All software is available with the LGPL license.

The technical objective of this consortium is to develop a distributed component-based, middleware technology, in line with CORBA, Java, and W3C standards. The intent is to apply the component model, as already used at the application level in J2EE and in the CORBA Component Model, at the middleware level itself. The functional coverage of ObjectWeb projects addresses naming, trading, communication (events, messages), availability and safety (transactions, persistence, replication, fault tolerance), load balancing, and security. Some related topics are also addressed, such as robustness, optimization, code quality, as well as benchmarks, tests, evaluations, demonstrators, and development tools. More recently, the middleware eco-system around JOnAS within ObjectWeb addresses Service Oriented Architecture (SOA).

ObjectWeb already has a significant number of members: corporations, universities, individual members (individual membership is free). ObjectWeb members contribute to ObjectWeb orientations and participate in all ObjectWeb working groups, meetings, workshops, and conferences. The community of developers and users working with ObjectWeb components and platforms is constantly growing.

## JOnAS Features

JOnAS is a pure Java, open source, application server. Its high modularity allows to it to be used as

- a J2EE server, for deploying and running EAR applications (i.e. applications composed of both web and ejb components),
- an EJB container, for deploying and running EJB components (e.g. for applications without web interfaces or when using JSP/Servlet engines that are not integrated as a JOnAS container),
- a Web container, for deploying and running JSPs and Servlets (e.g. for applications without EJB components).

### System Requirements

JOnAS is available for JDK 1.4 and JDK 5. It has been used on many operating systems (Linux, AIX, Windows, Solaris, HP-UX, etc.), and with different Databases (Oracle, PostgreSQL, MySQL, SQL server, Access, DB2, Versant, Informix, Interbase, etc.).

### Java Standard Conformance

JOnAS supports the deployment of applications conforming to J2EE 1.4 specification. Its current integration of Tomcat or Jetty as a Web container ensures conformity to Servlet 2.4 and JSP 2.0 specifications. The JOnAS server relies on or implements the following Java APIs: EJBTM 2.1, JTATM 1.0.1, JDBC 3.0, J2EE CATM 1.5, JMXTM 1.2, JNDITM 1.2.1, JMSTM 1.1, JavaMailTM 1.3, ServletTM 2.4, JSPTM 2.0, JAASTM 1.0, JACCTM 1.0, Web Services 1.1, JAX-RPCTM 1.1, SAAJTM 1.2, JAXRTM 1.0, J2EE Management 1.0, JAFTM 1.0, JAXPTM 1.2 specifications. JOnAS is architectured in terms of services.

### Key Features

JOnAS provides the following important advanced features:

- Management: JOnAS server management uses JMX and provides a JSP/Struts-based management console. It provides high level functionalities for monitoring and managing clusters of JOnAS servers.
- Services: JOnAS's service-based architecture provides for high modularity and configurability of the server. It allows the developer to apply a component-model approach at the middleware level, and makes the integration of new modules easy (e.g. for open source contributors). It also provides a way to start only the services needed by a particular application, thus saving valuable system resources. JOnAS services are manageable through JMX.
- Scalability: JOnAS integrates several optimization mechanisms for increasing server scalability. This includes a pool of stateless session beans, a pool of message-driven beans, a pool of threads, a cache of entity beans, activation/passivation of entity beans, a pool of connections (for JDBC, JMS, J2EE CA), storage access optimizations (shared flag, isModified).
- Clustering: JOnAS clustering solutions, both at the WEB and EJB levels, provide load balancing, high availability, and failover support.
- Distribution: JOnAS works with several distributed processing environments, due to the integration of the CAROL (Common Architecture for RMI ObjectWeb Layer) ObjectWeb project, which allows simultaneous support of several communication protocols:
  - RMI using the Sun proprietary protocol JRMP
  - RMI on IIOP
  - CMI, the "Cluster aware" distribution protocol of JOnAS
  - IRMI, an open source RMI protocol implementation

  JOnAS benefits from transparent local RMI call optimization.

- Support of "Web Services:" Due to the integration of AXIS, JOnAS allows J2EE components to access "Web services" (i.e., to be "Web Services" clients), and allows J2EE components to be deployed as "Web Services" endpoints. Standard Web Services clients and endpoints deployment, as specified in J2EE 1.4, is supported.
- Support of JDO: By integrating the ObjectWeb implementation of JDO, SPEEDO, and its associated J2EE CA Resource Adapter, JOnAS provides the capability of using JDO within J2EE components.
- Early support of EJB3: Even before the EJB3 specification (part of Java EE 5, the new J2EE specification) is finalized, JOnAS already provides an EJB3 container. This one is available as a J2EE CA Resource Adapter, which may be deployed on JOnAS 4. It is developed as a standalone ObjectWeb project, named EasyBeans. This container makes EJB development far more easy.

Three critical J2EE aspects were implemented early on in the JOnAS server:

- J2EECA: Enterprise Information Systems (EIS) can be easily accessed from JOnAS applications. By supporting the Java Connector Architecture, JOnAS allows deployment of any J2EE CA-compliant Resource Adapter (connector), which makes the corresponding EIS available from the J2EE application components. For example, Bull GCOS mainframes can be accessed from JOnAS using their associated HooX connectors. Moreover, with J2EE 1.4, resource adapters are now the "standard" way to plug JDBC drivers and JMS implementation, to J2EE platforms. A JDBC Resource Adapter is available with JOnAS, which provides JDBC PreparedStatement pooling and can be used in place of the JOnAS DBM service. A JORAM JMS Resource Adapter is also available. The JOnAS EJB3 early container is also available as a Resource Adapter.
- JMS: JMS implementations can be easily plugged into JOnAS. They run as a JOnAS service or through a resource adapter in the same JVM (Java Virtual Machine) or in a separate JVM. JOnAS provides administration facilities that hide the JMS proprietary administration APIs. Currently, two JMS implementations can be used: the JORAM open source JMS implementation from Objectweb, and Websphere MQ. JORAM management is particularly strongly integrated within the JOnAS management console. Clustering configurations involving load balacing and high availability at the JMS level are also available thanks to JORAM HA features.
- JTA: The JOnAS platform supports distributed transactions that involve multiple components and transactional resources. The JTA transactions support is provided through JOTM, a Transaction Monitor that has been developed on an implementation of the CORBA Transaction Service (OTS). Originally this transaction monitor was JOnAS internal; it has been extracted to be available as a standalone project, JOTM.

### JOnAS Packages

JOnAS is available for download with three different packagings:

- A simple packaging contains the JOnAS application server only, without the associated Web Container implementation. To use it for J2EE Web applications, Tomcat or Jetty must be installed (with an adequate version) and it must be configured to work with JOnAS.
- A JOnAS-Tomcat package contains both JOnAS and Tomcat, pre-configured, and with compiled examples. This is a ready-to-run J2EE application server.
- A JOnAS-Jetty package contains both JOnAS and Jetty, pre-configured, and with compiled examples. This is a ready-to-run J2EE application server.

These packages also contain AXIS, thus providing pre-configured "Web Services" support.

## 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 (this figure only misses the HA service). Two thin clients are also shown in this figure, one of which is the JOnAS administration console (called JonasAdmin).

### Communication and Naming Service

This service (also called "Registry") is used for launching the RMI registry, the CosNaming, and/or the CMI registry, depending on the JOnAS configuration (CAROL configuration, which specifies which communication protocols are to be used). There are different registry launching modes: in the same JVM or not, automatically if not already running. CAROL enables multi-protocol runtime support and deployment, which avoids having to redeploy components when changing the communication protocol.

This service provides the JNDI API to application components and to other services in order to bind and lookup remote objects (e.g. EJB Homes) and resource references (JDBC DataSource, Mail and JMS connection factories, etc.).

### EJB Container Service

This service is in charge of loading the EJB 2.1 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; this tool is automatically called at deployment time, if necessary.

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, short-lived (one method call or a client session), that 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:
  - An enterprise bean with Container-Managed Persistence. In this case, 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.
  - An enterprise bean with Bean-Managed Persistence. In this case, 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.

JOnAS configuration provides a means for specifying a set of ejb-jar files to be loaded at server start. 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) and MEDOR (Middleware Enabling Distributed Object Requests) frameworks. JORM supports complex mappings of EJBs to database tables.

The JOnAS EJB 2.1 container provides many optimization mechanisms to improve data access and scalability: pool of instances, caches, lock policies...

JOnAS also implements the Timer Service features as specified in EJB 2.1.

### WEB Container Service

This 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 or Jetty. Servlet/JSP engines are integrated within JOnAS as "web containers," i.e. such containers 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 this service be launched during JOnAS initialization. Additionally, JOnAS configuration provides a means for specifying a set of war files to be loaded. War files may also be deployed at server runtime using the JOnAS administration tools. User management for Tomcat/Jetty and JOnAS has been unified. The class-loading delegation policy (priority to the Webapp classloader or to the parent classloader) can be configured. Tomcat management has been strongly integrated within the JOnAS management console.

Servlet and JSPTM are technologies for developing dynamic web pages. The Servlet approach allows the development of Java classes (HTTP Servlets) that can be invoked through HTTP requests and that generate HTML pages. Typically, Servlets access the information system using Java APIs (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 J2EE components, the actual assignment of these resources is performed at component deployment time and is specified in the deployment descriptor of each component, since the component code uses logical resource names.

### Ear Service

This service is used for deploying complete J2EE applications, i.e. 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, 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.

### Transaction Service

This service encapsulate a Java Transaction Monitor called JOTM (a project from ObjectWeb). It is a mandatory service which 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 may 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 only allowed from Web components, session beans, or message-driven beans (only these two types of beans, which 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 behaviour 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, which 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, else, 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 will always be 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, else the container will throw 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, else the Container throws the `java.rmi.RemoteException` exception.

### 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.

### Security Service

This 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, the user 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. Thus, 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. 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 login modules for Java clients. These Realms use authentication resources provided by JOnAS, which rely either 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 CRLLoginModule login module for certificate revocation.

JOnAS also implements the Java Authorization Contract for Containers (JACC 1.0) specification, allowing authorizations to be managed as java security permissions, and providing the ability to plug any security policy provider.

### Messaging Service

Asynchronous EJB method invocation is possible on Message-driven Beans components. A Message-driven Bean is an EJB component that can be considered as a JMS (Java Message Service) MessageListener, i.e. which processes JMS messages asynchronously. It is associated with a JMS destination and 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, and other JMS provider implementations can easily be integrated. JORAM provides several noteworthy features: in particular, reliability (with a persistent mode), distribution (transparently to the JMS client, it can run as several servers, thus allowing load balancing), and the choice of TCP or SOAP as communication protocol for transmitting messages.

The JMS service is in charge of launching (or establishing 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 may 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.

### 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), an architecture component comparable to a software driver, which 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 JORAM.

### Management Service

The Management service is needed to administrate a JOnAS server from the JOnAS administration console. Each server running this service is visible from the administration console. This service is based on JMX. Standard MBeans are defined within the JOnAS application server; they expose the management methods of the instrumented JOnAS server objects such as services, containers, the server itself. These MBeans implements the management model as specified in the J2EE Management Specification. The Management service runs a JMX server (if not available within the JDK, as is the case with JDK 5). 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), 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, such as used memory, used threads, number of EJB instances, the state of pools, which component currently uses which resources, etc.. When Tomcat is used as Web Container, the Tomcat Management is integrated within the JOnAS console. The concept of domain allows a set of servers to be managed from a single management console, clusters have been introduced within the console, allowing, for example, an application to be deployed on a predefined subset of JOnAS instances. The cluster management allows remote control and monitoring of cluster nodes; EJB and HTTP clusters resulting from HA and load balancing configurations are automatically detected and displayed in the console. A Management EJB (MEJB) is also delivered, providing access to the management features, as specified in the J2EE Management Specification. This MEJB is also accessible through Web Services. JASMINe, a new ObjectWeb project dedicated to cluster deployment and monitoring has been created.

### Mail Service

A J2EE application component can send e-mail messages using JavaMailTM. The Mail service of the JOnAS application server provides the necessary resources to such 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.

### WebServices Service

This service is implemented on top of AXIS and is used for the deployment of Web Services.

### HA Service

This service is used for implementing Stateful Session Beans replication, when configuring high availibility at the EJB/RMI level within a clustered environment.

## JOnAS Development and Deployment Environment

### JOnAS Configuration and Deployment Facilities

Once JOnAS has been installed in a directory referenced by the JONAS_ROOT environment variable, it is possible to configure servers and to deploy applications into several execution environments. This is achieved using the JONAS_BASE environment variable. JONAS_ROOT and JONAS_BASE can be compared to the CATALINA_HOME and CATALINA_BASE variables of Tomcat. While JONAS_ROOT is dedicated to JOnAS installation, JONAS_BASE is used to specify a particular JOnAS instance configuration. JONAS_BASE designates a directory containing a specific JOnAS configuration, and it identifies subdirectories containing the EJB-JAR, WAR, EAR, and RAR files that can be loaded in this application environment. There is an ANT target in the JOnAS build.xml file for creating a new JONAS_BASE directory structure. Thus, from one JOnAS installation, it is possible to switch from one application environment to another by just changing the value of the JONAS_BASE variable. There are two ways to configure a JOnAS application server and load applications: either using the administration console or by editing the configuration files. There are also "autoload" directories for each type of application and resource (EJB-JAR, WAR, EAR, RAR) that allow the JOnAS server to automatically load the applications located in these directories when starting.

A tool named "newjc" is provided to deploy and configure a set of JOnAS servers within a cluster.

JOnAS provides several facilities for deployment:

- For writing the deployment descriptors, plugins for Integrated Development Environments (IDE) provide some generation and editing features (Eclipse and JBuilder plugins are available). The NewBean JOnAS built-in tool generates template deployment descriptors. The Xdoclet tool also generates deployment descriptors for JOnAS. A JSR88-compliant (J2EE 1.4) deployment tool named "Dolphin" is available in beta version within the Ishmael ObjectWeb project.
- Some basic tools for the deployment itself are the JOnAS GenIC command line tool and the corresponding ANT ejbjar task. The IDE plugins integrate the use of these tools for deployment operations.

Fractal Deployment Framework (FDF) is a tool for deploying and configuring the JOnAS software on a distributed environment.

### JOnAS Development Environments

There are many plugins and tools that facilitate the development of J2EE applications to be deployed on JOnAS. IDE plugins for Eclipse (JOPE, Lomboz, and, of course, WTP) and JBuilder (Kelly) provide the means to develop, deploy, and debug J2EE components on JOnAS. The Xdoclet code-generation engine can generate EJB interfaces and deployment descriptors (standard and JOnAS specific ones), taking as input the EJB implementation class containing specific JavaDoc tags. The JOnAS NewBean tool generates templates of interfaces, implementation class, and deployment descriptors for any kind of EJB. Many development tools may work with JOnAS; refer to the JOnAS tools page for more details.

In addition, JOnAS is delivered with complete J2EE examples, providing a build.xml ANT file with all the necessary targets for compiling, deploying, and installing J2EE applications.

## Clustering and Performance

Clustering for an application server generally makes use of three features: Load Balancing (LB), High Availability (HA) and Failover. Such mechanisms can be provided at the Web container level by dispatching requests to several Servlet/JSP engine instances, at the EJB container level by dispatching EJB requests to several EJB container instances, and at the database level by using several databases. A replicated JNDI naming is also necessary.

JOnAS provides Load Balancing, HA, and Failover at the WEB container level using the Apache Tomcat mod_jk plugin and an HTTP in memory session-replication mechanism based on JGroups. The plugin dispatches HTTP requests from the Apache web server to Tomcat instances running as JOnAS web containers. Server fluctuations are automatically taken into account. This plugin supports round-robin and weighted round-robin load-balancing algorithms, with a sticky session option.

Load balancing and HA are provided at the EJB container level in JOnAS. Operations invoked on EJB Home interfaces (EJB creation and retrieval) and invocations of business methods on stateless session beans are dispatched on the nodes of the cluster. The mechanism is based on a "clustered-aware" replicated JNDI registry using a Clustered remote Method Invocation protocol (CMI). The stubs contain the knowledge of the cluster and implement the load-balancing policy, which may be round-robin and weighted round-robin; these stubs are dynamically updated according to cluster topology changes (dynamic cluster). This load-balancing policy may be easily customized. Failover at the EJB level is provided by implementing a stateful session bean state replication mechanism that ensures the transaction and global consistency.

Load balancing and HA may also be provided at the JMS level, thanks to the JORAM HA capabilities.

The JOnAS clustering architecture is illustrated in the following figure.

Apache is used as the front-end HTTP server; Tomcat is used as the JOnAS web container. The JOnAS servers share the same database. The mod_jk plug-in provides Load Balancing / High Availability at the Servlet/JSP level. Failover is provided through the in-memory, session-replication mechanism. Load Balancing / High Availability is provided at the EJB level through the CMI protocol associated with the replicated, clustered-aware JNDI registry. Tomcat may or may not run in the same JVM as the EJB container. JOnAS provides some documentation for configuring such an architecture.

The use of the C-JDBC ObjectWeb project offers load balancing and high availability at the database level. The use of C-JDBC is transparent to the application (in our case to JOnAS), since it is viewed as a standard JDBC driver. However, this "driver" implements the cluster mechanisms (reads are load-balanced and writes are broadcasted). The database is distributed and replicated among several nodes, and C-JDBC load balances the queries between these nodes. An evaluation of C-JDBC using the TPC-W benchmark on a 6-node cluster has shown performance scaling linearly up to six nodes.

In addition to clustering solutions, JOnAS provides many mechanisms, intrinsic to the JOnAS server, for being highly scalable and efficient. This includes the following:

- A pool of stateless session bean instances
- A pool of entity bean instances, configurable for each entity bean within its deployment descriptor
- Activation/passivation of entity beans, passivation can be controlled through the management console
- Many locking policies for entity beans are available in the EJB 2.1 container, in order to adapt the locking policy to the application needs, at the entity bean granularity level
- Pools of connections, for JDBC, JMS, J2EE CA connectors
- A pool of threads for message-driven beans
- Session bean timeout can be specified at deployment
- A "shared" flag in the specific deployment descriptor of an entity bean indicates whether the persistent representation of this entity bean is shared by several servers/applications, or whether it is dedicated to the JOnAS server where it is loaded. In the latter case, the optimization performed by JOnAS consists of not reloading the corresponding data between transactions
- The usual EJB 1.1 "isModified" (or "Dirty") mechanism is available for avoiding storage of unmodified data
- An optimization called "Data Prefetching" provides JDBC resultsets re-use by the EJB container (this optimization reduces the number of SQL statements executed by the EJB container).

## Perspectives

As an open source implementation of an application server, JOnAS is constantly evolving to satisfy user requirements and to follow the related standards. The main JOnAS evolutions currently planned are the following:

- The JOnAS services architecture will be re-engineered in order to provide more flexible, dynamic and adaptable configuration and management features. It will be achieved by using the OSGi technology and will be the first step of the JOnAS 5 development
- Support of the Java EE 5 specification will be provided
- JOnAS Management will continuously be improved
- The clustering mechanisms will be improved
- Advanced cluster configuration management and monitoring (including self management features) will be developed in the JASMINe project

Sun, Java, and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.