Java Open Application Server (JOnAS) for EJBTM

This document provides a short introduction to the Enterprise JavaBeansTM (EJBTM) concepts and shows the Bull 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, ... 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 dedicated to a particular EB class, it 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:

Two kinds of enterprise beans are defined in the specification:

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 which can be one of the following:

Session beans (and only Session 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 bean's business method via the javax.ejb.EJBContext interface and under the environment entry java:comp/UserTransction.

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 two kinds of bean: Session 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 only supported via the JDBC interface, and therefore in relational databases. This is motivated by the fact that JDBC is a standard interface, which makes the persistence management code independent of the data storage, which will thus be interchangeable. It is also predictable that non relational data storages will be accessible via the JDBC interface.

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