Jacob : a software framework to support the development of e-services, and its comparison to Enterprise Java Beans 

Serge Chaumette and Pierre Vignéras, Université Bordeaux 

There is an increasing need for distributed services both in the domain of scientific computing and data mining. Java addresses this domain by means of the Enterprise Java Beans technology. We believe the EJBs have a number of problems that we try to address and solve in the framework we propose. It is called Jacob, Active Containers of Objects for Java. This work takes place in the Jem Project carried out at LaBRI, Laboratoire Bordelais de Recherche en Informatique, within the Distributed Systems and Objects team. 

Figure (a) shows the simplified overall structure of the Enterprise Java Beans architecture. Basically, an EJB lives within an EJB Container. This container is in charge of managing the life cycle of each bean it contains. This is done through the home interface that each bean must implement. The bean also exports a so called remote interface (using RMI) to its clients through its container - what requires a RMI compilation - so as to provide them with what are called the business methods. 

(a) Enterprise Java Beans 

(b) Java Active Containers of Objects 

The main problem of the EJB framework is that it is static, mainly because it is based on RMI. Therefore we propose Jacob, Active Containers of Objects for Java to solve this problem. Figure (b) shows the simplified overall structure of the framework that we have developed. Using Active Containers, an object does not need to make its interface visible to its possible clients. The active container does that in a standard, dynamic manner using reflection and provides clients with a unique call method. 

If compared to EJBs, the main advantages of Jacob are the following: (1) - Using EJBs, each bean must provide two interfaces, one to effectively talk with its clients and one to talk with its container. In Jacob, we offer dynamic object encapsulation, and we have no need for the declaration of any interface or the use of a dedicated compiler; we use reflection (2) - As a consequence of (1), EJBs must have been designed to be EJBs whereas any object can become part of a Jacob system. Furthermore, any serializable object can migrate between active containers. 
(3) - When required, an object can be accessed directly using any protocol such as RMI, UDP, etc., avoiding the overhead due to the process of going through the container, what is not a basic feature of the EJBs framework. (4) - We off er asynchronous remote method invocation; this is not available with EJBs. Furthermore, compared to other systems, we still provide in this asynchronous framework a real, effective, exception handling mechanism. 

The drawback of our approach is that by using dynamic mechanisms such as re we loose some of the compile time type checking that is possible using the EJBs framework. It seems that the notion of proxy that has recently been introduced in Java 1.3 might help to solve this problem, at least partially. 

In the near future we will improve the prototype software that we have developed. We will  also focus on the development of a significant use example and on performance measurements. Of course we also need to implement the services provided by the EJB framework: persistence, check points, transactions, etc.