Java Open Application Server (JOnAS) for EJBTM

This document provides a short introduction to the Enterprise JavaBeansTM (EJBTM) concepts and shows the JOnAS approach for providing an EJB environment. The document is structured as follows:

Introduction

The SunTM Enterprise JavaBeans specification defines an architecture and interfaces for developing and deploying distributed JavaTM server applications based on a multi-tier architecture. This specification intends to facilitate and normalize the development, deployment and assembling of applicative components (called enterprise beans); such components will be deployable on EJB platforms. The resulting applications are typically transactional, database-oriented, multi-user, secured, scalable and portable. More precisely, this EJB specification describes two kinds of information:

Not only will an enterprise bean be independent of the platform and operating system (since written in Java), but also of the EJB platform.

The Enterprise JavaBeansTM Model

The EJBTM specification defines a server component model. An Enterprise JavaBean (EB) is a "non visual" software component running on the server part of an application. An EB may be configured at deployment time by editing its properties. The resources needed by an EB are transactional services, storage services, security services, naming services, messaging services, ... Such resources are provided to the bean by the EJB server. The interface between an EB and the EJB server is materialized by an architectural component called "container". An EJB container is generated by the tools associated to the EJB server. The container is in charge of the EB instances life cycle and persistence, and of the interaction with the transaction and security services.

An Enterprise Bean is composed of the following parts, that are to be developed by the Enterprise Bean Provider:

Three kinds of enterprise beans are defined in the specification:

JOnAS implements the EJB specification, by providing the elements of an EJB Server (Transaction Manager, Persistence Manager, ...) and the tools to generate containers.

Transaction Management

One of the main advantages of the EJBTM 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 container is responsible for providing the transaction demarcation for the enterprise beans. The container's responsabilities depend on the value of transactional attributes associated to EB methods which can be one of the following:

Session beans and message-driven beans (and only these two kinds of beans) can be used with "Bean-managed transaction demarcation". In this case the Container is responsible to suspend any transaction that may be associated with the client request and must make the javax.transaction.UserTransaction interface available to the session or message-driven bean's business method via the javax.ejb.EJBContext interface and under the environment entry java:comp/UserTransaction.

JOnAS is built on top of the JTM (JavaTM Transaction Manager), which is a Java version of the Bull OrbTP product, an implementation of the CORBA Object Transaction Service. The JTM manages distributed transactions. It handles two-phase commit protocol against any number of Resource Managers. The transactional context is implicitly propagated with the distributed requests. The JTM may be distributed across one or more EJB servers; thus a transaction may involve several beans located on different EJB servers. JTM's transactions may be demarcated explicitly by the client, or by the bean itself; transaction demarcation may also be implicit, i.e. performed by the container according to the transactional attributes values. The figure below shows different distribution architecture cases for three Enterprise Beans involved in the same transaction. JOnAS allows these different architecture configurations; this is very interesting from the performance point of view, when the architecture must be adapted to the resources distribution.

Enterprise Bean distribution architectures
Case 1: The three beans B1, B2 and B3 are located on the same EJB server, which embeds a Java Transaction Monitor.

Case 2: The three beans are located on different EJB servers, one of them running the Java Transaction Monitor, which manages the global transaction.

Case 3: The three beans are located on different EJB servers, the Java Transaction Monitor is running outside of any EJB server.

Case 4: The three beans are located on different EJB servers. Each EJB server is running a Java Transaction Monitor. One of the JTM acts as the master monitor, while the two others are slaves.

Of course, the EJB servers may be located on the same or on different machines. Each EJB server runs in a separate Java Virtual Machine (JVM), as well as the JTM when it runs in a stand alone way (not within an EJB server, as in case 3).

Persistence Management

The EJBTM specification defines three kinds of bean: Session beans, message-driven beans and entity beans. As opposed to sessions beans, an entity bean represents persistent data, i.e. it is an object view of an entity stored in a persistent storage (generally a database). The persistence management of such an object is entirely transparent to the client that will use it, and may be or may not be transparent to the bean provider that will develop it. This conforms to the EJB reference architecture where the client does not see any data access operation, such operations being used on the server side implementation only (in the enterprise bean implementation). An entity bean may be one of the two following categories:

In both cases, the data access operations are developed or generated by the EJB environment using JDBCTM (or JSQL) to access relational databases, or using other (proprietary) classes for accessing non relational data storages.

With JOnAS, the support of entity beans conforms to the EJB specification and is based on JDBC :

Currently, persistence management is supported via the JDBC interface on most relational databases (Oracle, Informix, Sybase, InstantDb, Postgres, Ingres, Interbase, SQL Server, ...) and also on the Versant Object-Oriented database (this last feature is provided by the Libelis partner). JOnAS supports JDBC 2.0 drivers (with XA interfaces) and thus is able to perform two-phase commit.

JOnAS will evolve towards EJB 2.0 persistence management which includes the support of relationships between entity beans.

Security Management

The purpose of the security in the EJB™ architecture is to permit or not the access to the methods of an EJB.
All the concepts of security is based on the notion of roles. The methods can be accessed by a given set of roles. In order to access the methods, the user must be at least in one of this set of roles.
These roles and the mapping between roles and methods (permissions) present a simplified security view of the enterprise beans application.
When the EJB is deployed in the target operational environment, the System Administrator has to map the set of security roles to the "specific" roles of the target operational environment, e.g. groups on Unix systems.

The EJB™ specification defines two kinds of security management:

The declarative one is set by the Bean Deployer or the Application Assembler to integrate the security of an EJB component in the target operational environment and the programmatic one is used by the Bean Programmer to enforce security in the code of the EJB itself in the case where the declarative one is not sufficient or not appropriate.

These two kinds of security management are not exclusive: in most "real world" applications, they complete each other to make the EJB architecture more secure.

In case of declarative security management, the Bean Deployer and the Application Assembler use the security-role and method-permission elements included in the assembly-descriptor element of the deployment descriptor to set up access control of the methods of the EJB component.
They're also responsible for binding the security system of the EJB architecture to the target operational environment.

For programmatic security management, the EJB platform provides the Bean Programmer with two methods in order to enforce security check in the bean code:

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 the way of the security-role-ref elements included in the session or entity elements of the deployment descriptor.

In JOnAS, the security is avalaible with the following restrictions:

Java Messaging Service

For asynchronous EJB method invocation, JOnAS provides Message-driven Beans as specified in the EJB 2.0 specification. A Message-driven Bean is an EJB component which may be considered as a JMS (Java Message Service) MessageListener, i.e. which processes JMS messages asynchronously: it implements the onMessage(javax.jms.Message) method, defined in the javax.jms.MessageListener interface. It is associated with a JMS destination, the onMessage method will be activated on the reception of messages sent by a client application to this destination.

It is also possible for any EJB component to send or "synchronously receive" JMS messages, using the JMS API, and this within the scope of a global transaction managed by the EJB Server (this was already specified in EJB 1.1). The bean programmer has the possibility to use resources (by the way of resource references) that may be JDBC (a DataSource) or JMS (a ConnectionFactory) connection factories. Thus, the bean programmer is able to provide JMS code inside of an EJB method, in order to send a message toward a JMS Queue or Topic. These messages will be received by JMS clients, which may be stand alone Java applications, EJB components, the EJB client application... The EJB Container is able to take into account these JMS operations within a global EJB transaction which may include other resources such as databases.

Details about JMS should be found in the Java Message Service Specification 1.0.2.

In the JOnAS JMS integration, JOnAS makes use of a third party JMS implementation (currently the Joram opensource is integrated and delivered with JOnAS, the SwiftMQ product may also be used, other JMS provider implementations may easily be integrated). JOnAS provides facilities to automatically create JMS administered objects such as the connection factories and the destinations at server launching time.

Distribution

The distributed environment in the EJB world is RMI. Currently JOnAS is working on two distributed processing environments:

Used with Jeremie, JOnAS benefits from local RMI calls optimization.

In the future, JOnAS will support RMI/IIOP, thus providing CORBA interoperability.

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