Last modified at 2003-11-14, JOnAS 3.3.1
This document provides an overview of the JOnAS J2EE platform. The content of this document is the following:
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:
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.
JOnAS is an open source implementation of J2EE, 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.
Thus, the global ObjectWeb architectural model goes top down from applications (as benchmarks such as Rubis from the JMOB project) running on middleware platforms (such as JOnAS, OpenCCM or ProActive). The platforms are based on technical components such as Message-Oriented Middleware (JORAM which implements JMS), a communication framework (CAROL), a persistence framework (JORM), a database query framework (MEDOR), a transactional monitor (JOTM), an Object Request Broker (Jonathan). A technical component such as C-JDBC allows any platform to benefit from database clusters. JOnAS makes use of all these ObjectWeb components (JORAM, CAROL, Jonathan, JORM, MEDOR, C-JDBC, and soon JOTM), but also uses open source components from other communities, such as Tomcat or Jetty being used as a Web container, or for AXIS being used to provide the "Web Services" environment.
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 is a pure Java, open source, application server conforming to the J2EE specification. However, its high modularity allows to it to be used as
JOnAS is available for JDK 1.3 or 1.4. 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.).
JOnAS is an implementation of J2EE 1.3. It currently conforms to EJB 2.0. Its current integration of Tomcat or Jetty as a Web container ensures conformity to Servlet 2.3 and JSP 1.2 specifications. The JOnAS server relies on or implements the following Java APIs: JCATM 1.0, JDBCTM 2.0, JTATM 1.0.1, JMSTM 1.1, JMXTM 1.0, JNDITM 1.2.1, JAASTM 1.0, JavaMailTM 1.3.
In addition to the implementation of all J2EE-related standards, JOnAS provides the following important advanced features:
Three critical J2EE aspects were implemented early on in the JOnAS server:
JOnAS is available for download with three different packagings:
These packages also contain AXIS, thus providing pre-configured "Web Services" support.
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).
This service (also called "Registry") is used for launching the RMI registry, the CosNaming, the CMI registry, and/or the Jeremie 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.).
This 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:
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 (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, as well as several types of persistency support (relational databases, object databases, LDAP repositories, etc.).
JOnAS already implements the Timer Service features as specified in EJB 2.1 (J2EE 1.4).
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.
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.
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.
This is a Java Transaction Monitor called JOnAS JTM. 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 JTM 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 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.ObjectWeb has created a project called JOTM (Java Open Transaction Manager), which is based on the JOnAS transaction service. It has been enhanced to provide advanced transaction features, such as nested transactions and "Web Services" transactions (an implementation of DBTP is available). JOTM will be integrated into JOnAS in the near future.
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.
This service implements the authorization mechanisms for accessing EJB
components, as specified in the EJB 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.
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 Realms for Tomcat or Jetty (i.e., UserDatabaseRealm, MemoryRealm, JDBCRealm, JNDIRealm) and through the JAAS login modules for Java clients. 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.
Asynchronous EJB method invocation is possible on Message-driven Beans components, as specified in the EJB 2.0 specification. 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, the SwiftMQ product can also be used, 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.
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.
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. The Management service runs a JMX server (currently the Sun RI JMX). 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, which component currently uses which resources, etc.. When Tomcat is used as Web Container, the Tomcat Management is integrated within the JOnAS console.
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.
This service is implemented on top of AXIS and is used for the deployment of Web Services.
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.
JOnAS provides several facilities for deployment:
There are many plugins and tools that facilitate the development of J2EE applications to be deployed on JOnAS. IDE plugins for JBuilder (Kelly) and Eclipse (JOPE) 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 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 JavaGroup. 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) 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. In the near future, a load-balancing mechanism based on the nodes load will be available. Failover at the EJB level will be provided by implementing a stateful session bean state replication mechanism.
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:
Some benchmarks and JOnAS Use cases have already proven that JOnAS is highly scalable (e.g., refer to the Rubis results or the OpenUSS Use case). Rubis is a benchmark for e-commerce J2EE applications, which now belongs to the ObjectWeb JMOB (Java Middleware Open Benchmarking) project. OpenUSS is an operational University portal with approximately 10,000 users.
As an open source implementation of a J2EE server, JOnAS is constantly evolving to satisfy user requirements and to follow the related standards. The main JOnAS evolutions currently planned are the following:
Sun, Java, and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.