Points of View

Once the architecture and the significant features and concepts of the specification of the Enterprise JavaBeans are known, we would like, in conclusion, to clarify various perspectives on the architecture.

EJB from the Point of View of Application Development

It is interesting to consider Enterprise JavaBeans from the point of view of application development. For this we should return to the scenario of Chapter 1. The application developer described there could use Enterprise JavaBeans as a basis for the prototype to be developed. He or she could use a J2EE-compatible server including an EJB container from any supplier and develop the prototype in the form of Enterprise Beans. We would like to consider whether the secondary problems that arise from the business problem can be neutralized using Enterprise JavaBeans as the basis technology. We wish to investigate whether the application developer can concentrate completely on the problems of the application domain. To this end we recall a figure from Chapter 1 (see Figure 3-9).

Figure 3-9: Secondary issues in a business problem.

There is certainly the requirement of reusability due to the client-server-oriented architecture. There is also the necessity for security characteristics of the transaction service of Enterprise JavaBeans in order to ensure a smooth multiuser operation.

The characteristic of scalability means that applications that are realized as Enterprise Beans or as aggregates of beans can be partitioned among several servers. For example, the servers can use the same database as back-end system. Thus the burden of client queries, depending on the application, is divided among several servers, while the database is centrally located. Through locational transparency of Enterprise Beans with a remote interface (which is ensured by a central naming and directory service) the following are possible:

• Distribute individual applications of an application system among several servers.

• Store individual beans from one server on another server.

• Set up additional servers and store beans or aggregates of beans there.

Moreover, many application servers offer mechanisms for the allocation of tasks. In this regard a cluster of application servers (independent of the application that the client uses) concerns itself with the optimal servicing of the client's queries. However, this feature is provider-dependent and not required by the architecture of Enterprise JavaBeans.

The subject of availability becomes significant in regard to the locational transparency of Enterprise Bean components, which is ensured by the central naming and directory service. If an application server goes out of service, the beans installed there are installed on another server. The information necessary for the installation is already contained in the deployment descriptor of the Enterprise Beans, and they can generally be transported unaltered. A change in the configuration in the naming and directory service allows them to be placed at the service of clients on another server without the configuration of the client having to be changed.

Since Enterprise JavaBeans are ever more tightly bound in the context of the Java 2 platform, Enterprise Edition, the connection with the outside world is not a critical topic. With the support of a web container (see Figure 3-2), at least the basic technological and architectural prerequisites are given to create a connection with the outside world. In Chapter 9 we shall devote ourselves to this topic in somewhat greater detail.

Once all the uses of an application system have been realized based on Enterprise JavaBeans, then the potential for integration of the applications among one another is very high. The exchange of data within the application is simple in this case (even more so if a central database is used). Enterprise JavaBeans can also be used to integrate applications belonging to various systems. Using a message service, which the EJB container has had to integrate since version 2.0, it is even possible to achieve dynamic coupling of applications and systems. A message service makes a number of communication channels available over which n-to-n communication with dynamically changing partners is possible.

Through the use of specialized EJB containers, which use an application system other than a database system as persistence system, these systems can be integrated into EJB-based systems. Under certain conditions one can also envision employing Enterprise Beans as wrappers and interfaces to simple systems (to the extent to which that is possible within the limits of programming restrictions).

Applications are constructed from a number of Enterprise Beans, each of which encapsulates a particular functionality. This granularity, as established by the component paradigm, makes it possible for the development of an application system to be structured from a variety of viewpoints. Each component can be a partial project. It is easier to manage each subproject than to keep track of the entire project all at one time.

The interfaces to the outside world are defined for each component (and thus for each subproject). This results in a trend toward shortening the development cycle. Not least, the architecture of Enterprise JavaBeans plays an active role, since the application developer (i.e., the bean developer) is freed from the development of system-technical functionality. The presence of a unified platform allows this system-technical functionality to be reused, and the bean developer can concentrate fully on the solution of the application-related problems.

The configurability of an EJB-based system is given primarily via the deployment descriptor. This makes it possible for beans, at the time of installation in a server, to adapt themselves to a variety of situations. The run-time behavior of an Enterprise Bean can also be influenced by the settings in the deployment descriptor. Using the bean environment, parameters can be set that the bean can evaluate at run time.

An EJB-based system can also be configured via the exchange of bean classes. In fact, the new bean classes offer the same interface; that is, they use the same home and remote interfaces as the old bean classes, but they offer a different implementation. To the client the beans with altered implementation appear under the same names in the JNDI as before. For the client the exchange of implementations plays no role, in that the old agreement (the promised functionality of the interface) is preserved.

In the case of container-managed persistence, Enterprise JavaBeans offer the concept of transparent, automatic data storage. The Enterprise Bean leaves data storage to the EJB container and the persistence manager. It need not concern itself with the technical aspects of data storage. Such a bean can be used without difficulty in other EJB containers.

Through the deployment of specialized EJB containers (as can be seen in Figure 3-10) it is possible to achieve a stepwise migration from the old system. The state of the data and the systems can be reused. For the bean the EJB container is not only a run-time environment and service provider but also the interface to the old system (which to the bean is essentially transparent). After the complete takeover of the data (for example, into a relational database system) the beans already developed can be reused through installation in another EJB container.

Figure 3-10: An Enterprise JavaBean scenario.

It is possible to extend the functionality of an EJB-based system without difficulty by installing new Enterprise Beans. Under certain conditions new beans can make use of the functionality of already existing beans.

From the viewpoint of the application developer as described in the scenario of Chapter 1 all the secondary problems that arise can be neutralized by the use of Enterprise JavaBeans. EJB was the correct approach to the solution of the problem.

EJB from the Point of View of the Component Paradigm

An additional point of view from which Enterprise JavaBeans can be considered is that of the component paradigm. In the preceding chapters some basic points about this were presented. Two questions then arise:

• Are Enterprise Beans genuine components?

• Do Enterprise JavaBeans fulfill the requirements of the component architecture?

To elucidate these questions we must measure the properties of Enterprise Beans and the EJB architecture against the requirements presented in Chapter 2.

In view of the definition presented in Chapter 2, Enterprise Beans are genuine components. The fundamental characteristic of the standardized interface is given in the form of the home and remote interfaces or the local home and local interfaces. The interface is standardized by the guidelines of the component model of the Enterprise JavaBeans specification. The interface represents a sort of contract to which an Enterprise Bean is compelled to adhere. This interface is independent of the implementation. A bean can be developed and maintained as a single unit. Whether this represents a self-contained functionality depends on the developer. This characteristic of a component cannot be compelled by the specification, but it should serve as a guideline to the developer of an Enterprise Bean.

In order to determine whether the architecture of the Enterprise JavaBeans does justice to the requirements of the component paradigm, we would like to evaluate the various characteristics that we presented in Chapter 2:

• Independence of the environment: Enterprise JavaBeans are based completely on the programming language Java. Enterprise Beans can be deployed only in a Java environment. However, via CORBA they can be used in conjunction with other environments. The specification of version 2.1 designates RMI-IIOP as communications protocol, which should ensure compatibility with CORBA.

• Locational transparency: The location of a component with a remote interface is fully transparent, since the Enterprise Beans can be located via the naming and directory service as well as RMI, and also can be addressed on remote computers. The specification also requires a producer to include a naming and directory service in the system environment and emphasizes the distributed nature of Enterprise Beans. Locational transparency is not a characteristic of Enterprise Beans with a local interface.

• Separation of the interface and implementation: This property is provided to Enterprise JavaBeans through the concept of the home and remote, respectively local home and local remote, interfaces.

• Self-descriptive interfaces: In the case of Enterprise JavaBeans it is possible to obtain information about the remote interface(s) of a component. The home object uses the method getEJBMetaData() to return an object of type javax.ejb.EJBMetaData (for relevant details see [21]). This object provides, among other things, information about the home and remote interfaces of an Enterprise Bean. Using the Java reflection API (see [4]) it is possible to investigate the interfaces at run time and to program dynamic calls to Enterprise Bean methods. The combination of naming and directory services (JNDI), the metadata interface (javax.ejb.EJBMetaData), and the Java reflection API offers possibilities comparable to those of the interface repository of CORBA (cf. [17]). It is the task of the EJB container to generate for an Enterprise Bean a corresponding implementation class for the metadata interface from the specifications of the deployment descriptor.

• Problem-free immediate usability (Plug & Play): At the time of installation of an Enterprise Bean the implementation classes for the home and remote interfaces must be generated and compiled. By means of these an Enterprise Bean component becomes usable (without it having to be altered in the process) by the EJB container of a particular producer. All information that is necessary for the installation process is contained in the bean class itself and in the deployment descriptor (which is a part of the component). The binary independence of the component code of an Enterprise Bean exists to the extent that the components comply with the binary standard defined by the Java programming language. This results is problem-free usability of an Enterprise Bean component in every EJB container.

• Ability of integration and composition: This issue is accommodated by a certain role in the EJB process model, the application assembler. The composition of Enterprise Beans into an aggregate is specifically provided for.

Enterprise JavaBeans can be considered a component architecture. It will be interesting to see what extensions and improvements are offered in future versions.

EJB from the Enterprise Point of View

A final point of view is that of Enterprise JavaBeans from the point of view of the Enterprise. In Chapter 2 we defined criteria that a basic technology should satisfy from this viewpoint: economic viability, security, and meeting the enterprise's requirements. It is difficult to give an objective evaluation of a technology according to such global criteria. Nonetheless, we may certainly conclude that Enterprise JavaBeans, on grounds of economic viability as defined in Chapter 2, are certainly of interest to an enterprise, particularly for those businesses that engage in application development (whether internally or for external customers).

In the sections above we have already seen the advantages of such a technology. In the development of enterprise-related logic in Enterprise Beans the developer is freed totally from having to deal with technical system issues. The technological basis has been developed by specialists in this field and conforms to a (quasi) standard. Thus development can be focused directly on the problems of the particular enterprise. The component-oriented point of view enables a greater granularity and thereby makes development more transparent and more easily kept under control. The EJB technology offers all the prerequisites for allowing the application systems to grow with the enterprise (with respect both to greater functionality and to growth in the number of employees).

With respect to security the enterprise is supported not only by the security mechanisms of the specification and the programming language Java. Since Enterprise JavaBeans defines a standard in a certain sense that is already supported by a number of producers, there are relatively few dependencies on a particular application server vendor. It would, however, be desirable to achieve an official standardization of Enterprise JavaBeans through the work of a standardization committee. Nevertheless, an investment in this technology could pay off over a long period of time.

The specification defines many conditions that ensure the fail-safe operation of EJB-based systems. An example is the stringent restrictions on the development of beans. Among other things, this should help to avoid unstable conditions in the system. Another example is the separation of system functionality and enterprise-specific functionality. It benefits reliability and security that the system functionality has been developed by a specialist. A wide deployment of the system among many customers by a responsible developer should lead more rapidly to a higher quality than what could be obtained by in-house development.

As for the needs of enterprises, the EJB specification is directed precisely at those enterprises that develop their own applications or act as a service provider for other enterprises. As a rule, the developers in such enterprises are specialists in particular application areas, but not in the domain of system development. The result is often applications that deal with the technical problems, but cause dissatisfaction through shortcomings in the technological foundations. With the model of Enterprise JavaBeans it is precisely this issue that is dealt with. The demand for a stable basic architecture that offers a convenient component model that can be embedded in the application logic should exist in many areas and in many enterprises. Precisely because applications deployed in businesses are becoming ever more complex, there is ever increasing demand for stable, secure, and flexible basic architectures.