A Paradigm Shift in Distributed Computing

Jan. 1, 1999 12:00 AM

As Java takes a leap toward the next generation of enterprise computing, enterprises get ready to deploy large-scale business applications using Java. This article describes how the new Enterprise Java-Beans (EJB) technology from Sun Microsystems can be instrumental in building distributed enterprise applications. We'll first look at the application server implemented by Weblogic, which uses EJB technology to provide business solutions. Then I'll discuss how this powerful technology can be used in the context of a true distributed environment such as CORBA.

Background
Most of you are probably familiar with Enterprise JavaBeans by now. The EJB specification defines a server-side component model for development and deployment of portable, reusable, multitier and distributed Java applications. A detailed overview of EJB architecture and its components appeared in the September 1998 JDJ (Vol. 3, Issue 9), so I won't spend much time on that subject. But I will give you a brief overview of the EJB environment and its components before going into detail about the EJB-based application server and EJB's fit with CORBA.

Typical EJB Environment
As shown in Figure 1, a typical EJB environment can support a variety of client environments, including desktop clients connected through a LAN, Web clients, telephony clients, smart cards and other devices. Business logic is implemented as reusable application components deployed in the EJB application server. These components have complete access to all types of data and applications, including relational and nonrelational databases, flat files, live data-feeds and legacy applications.

Sun Microsystems' Java Platform for the Enterprise (JPE) provides a foundation for the development and deployment of Java-based enterprise-class application systems. EJB is an essential piece of the complete JPE environment that elevates Java to a serious application development language capable of supporting mission-critical distributed enterprise application systems. JPE API consists of nine Java APIs - EJB, Java Naming and Directory Services (JNDI), Remote Method Invocation (RMI), Java Interface Definition Language (Java IDL), Servlets and Java Server Pages (JSP), Java Messaging Service (JMS), Java Transaction API (JTA), Java Transaction Service (JTS) and Java Database Connectivity (JDBC) - that enable Java applications to access the core enterprise-class infrastructure services through a set of standard programming interfaces that include EJB components.

Some of the primary EJB components are the EJB server and container, enterprise beans, session objects, entity objects and EJBObjects. The function of an EJB server is to manage resources needed to support EJB components. An EJB container is where an EJB bean "lives." It provides a scalable, secure and transactional environment in which EJBs can operate. The container manages the life cycle of the enterprise bean. It also generates an EJB object that is an interface for the enterprise bean and represents a client view of the enterprise bean. All client requests directed at the EJB object (such as a request to insert transaction, state and security rules) are intercepted by the EJB container (see Figure 2).

The EJBObject acts as a proxy, passing method invocation requests to an instance of the enterprise bean installed and executing within the container of the EJB server. Clients use the JNDI and EJBHome interface of the enterprise bean to locate an enterprise bean.

Entity Beans vs Session Beans
Entity beans represent persistent data that's maintained in a database or any underlying data source. In contrast, session beans are created by a client and in most cases exist only for the duration of a single client/server session. An EJB container supplies a "factory" interface for creating new instances of the enterprise bean and a "finder" interface for locating existing instances of entity beans (see Figure 3).

Entity beans are transactional and can be recovered following a system crash. Entity objects are also implicitly persistent. They can either manage their own persistence or delegate it to their container. Entity beans usually represent a one-to-many relationship to client(s). In a typical enterprise some of the examples of entity beans would be employees, customers and orders.

On the other hand, session beans typically are neither transactional nor recoverable following a system crash. They can be stateless or they can maintain conversational state across methods and transactions. Session beans have to manage their own persistence. They usually represent a one-to-one relationship to client(s). Examples of session beans are electronic shopping carts and grocery lists.

What do enterprises need in order to develop and deploy an EJB-based application? First, they need to implement enterprise beans containing their business logic and assemble any third-party beans into their applications. Once they've done this, they can use any enterprise server implementation provided by vendors such as Weblogic, Persistence and EJBHome to execute and manage their EJBs. The server provider will take care of distributed transaction management, distributed EJBs and other low-level system services. Since Weblogic Inc. is an industry leader in the Enterprise JavaBeans server market and one of the early adopters of Enterprise JavaBeans, we'll discuss their application server in the following sections.

Tengah Application Server
Weblogic Inc., which announced its acquisition by BEA Systems as this article was being written, is the leading provider of Java application servers. Its first version of the Java application server - T3, short for three-tier - was shipped in the fall of 1996. T3 was also the first server in the market to support EJB specification. The name T3 then became Tengah. Tengah has Pure Java certification and currently conforms to the JDK 1.1. The Tengah application server logically integrates EJB, Web and transaction services in one server. With Tengah, users can easily and quickly build, as well as deploy, server-side business components (in the form of Enterprise JavaBeans). The following sections describe major components of the Tengah application server.

Tengah Enterprise JavaBeans
Tengah EJB claims to support all the features of the EJB 1.0 specification. It also supports entity beans with both bean- and container-managed persistence, as well as "automatic" persistence on files and relational databases via container-managed persistence. In addition, Tengah supports distributed transactions that permit multiple beans that are distributed across heterogeneous server machines to participate in a single transaction. Global naming with JNDI, RSI-based security and support for multiple invocation protocols such as CORBA IIOP, HTTP, HTTPS and TCP are also included in Tengah.

A unique feature of Tengah is the bean bar for Tengah beans. The bean bar is a collection of EJBs that provide access to Tengah services, including login, event subscribe, publish, Tengah server-side workspace access and more. Users can develop Tengah applications using drag-and-drop programming of Tengah beans in any Java-Beans-compliant IDE.

Tengah COM
Tengah also supports integration with the Microsoft COM. Tengah's COM compiler provides the means to build Java-to-COM bridges; Tengah RMI is then used to register these objects in JNDI and provide access to them from anywhere in the network. With Tengah COM on the client side, existing Java application components (like EJB objects) running anywhere in the network can be exported as COM business components (such as Visual Basic, Visual C++ and Active Server Pages).

Tengah Servlets
Tengah implements the session management API of the standard Java Enterprise Servlet model. Session management makes it easy to develop Web-based applications that need the server to remember the state of the client transaction across many browser-Web server (HTTPD) interactions.

Tengah Cluster
Tengah servers can be grouped into a cluster to enhance the scalability and fault tolerance of a Web application. Clustering can be used to spread requests from a large user community across multiple Tengah servers.

Tengah Zero Administration Client
Tengah's ZAC is designed to provide automatic distribution and management of application or system software throughout an enterprise network or the Internet. Once clients are registered with the ZAC, it automatically ensures that every client system is kept up to date without additional user intervention.

Tengah JDBC
Tengah provides a JDBC driver with connection pools for relational database access. A connection pool in JDBC allows multiple database connections at the same time. The connection pool can automatically shrink and expand depending on the load. This means that an expanded connection pool can gradually shrink to its initial size to release unused database connections.

EJB Development and Deployment Using Tengah
This section describes how to implement Enterprise JavaBeans as well as how to configure, deploy and manage these EJBs in the runtime environment of the Tengah EJB server.

Implementation
To implement an Enterprise JavaBean, it's important to get familiar with the EJB API provided by Sun Microsystems. (Please see the Resources section to download the EJB API.) Three main packages are shipped as part of the EJB:

Package javax.ejb

Package javax.ejb.deployment

Package javax.jts

An Enterprise JavaBean is a class that a developer writes to provide application functionality. The developer can implement the bean as either a session bean or an entity bean by implementing the appropriate interface and declaring its type in the deployment descriptor used while deploying the bean. Typically, the developer will need to extend the javax.ejb.EnterpriseBean class from the javax.ejb package. Both the SessionBean and EntityBean interfaces extend from this class.
For instance, a session bean can be implemented as:

public class MyEJB implements javax.ejb.SessionBean---.

And, an entity bean can be implemented as:

public class MyEJB implements javax.ejb.EntityBean---.

The methods in your Enterprise Bean will never be invoked directly from the client. The client uses the EJBObject, which acts as a proxy to call the bean's methods. The EJBObject is a "true" network object that gets accessed by clients over the network. You have to create a remote interface that will describe the business methods of the enterprise bean you'd like the client to be able to invoke. The method names and the signatures listed in this remote interface should exactly match those implemented in the enterprise bean. For example, you might provide a remote interface for the EJB as follows:

public interface Account extends javax.ejb.EJBObject {
public void deposit (double amount) throws RemoteException;
public void withdraw (double amount) throws RemoteException;
public double balance() throws RemoteException;
}

It's important to note that the class javax.ejb.EJBObject will implement the java.rmi.Remote interface. The container vendor will generate the implementation code for the bean remote interface (Account interface in the above example) at the time the enterprise beans are installed.

For remote clients to access the enterprise bean, they first need to access the bean's "home" object which implements the home interface of the bean. The home interface lists one or more create() methods that can be used to create an instance of the enterprise bean. The server typically registers the home object (EJBHome) with the JNDI. The clients have to know the location of the namespace and the JNDI context factory class name for the home object. The home interface for an EJB bean might look like this:

public interface myHome extends EJBHome {
public void create () throws RemoteException;
public void create (String str) throws RemoteException;
}

Again, note that the class javax.ejb.EJBHome implements the java.rmi.Remote interface. The container vendor is responsible for providing the home object that implements this home interface. The implementation code acts as a factory to create the enterprise beans.

Tengah EJB Deployment Wizard
Once you've implemented your enterprise beans, you can use tools like Tengah's deployment wizard to configure and deploy the beans for use with the EJB server within your enterprise. You can use this wizard to:

Examine existing EJBeans and their deployment descriptor's configurable properties.

Modify and persist EJBeans' properties.

Generate EJBean interface classes for the EJBean execution environment.

You can invoke Tengah's deployment wizard from the command line with:
$ java weblogic.EJBDeployWizard options

In this instance, options can be used to get help or to set look and feel for the UI of the wizard.

Starting and Maintaining the Tengah Server
The Tengah server is a Java class file and can be started from the command line. Weblogic recommends that you start the server with -ms16m and -mx16m to ensure enough heap space for the server. This will ensure better performance in case of a more rigorous client connection load. The Tengah server also has its own garbage collection mechanism, purported to be more efficient than the one provided by Java. It might make sense in that case to turn off Java's asynchronous garbage collector. One possible command for starting the Tengah server could be:

$ java -noasyncgc -noclassgc -ms16m -mx16m weblogic.Server

Weblogic also provides an administrative tool to start up, shut down and monitor the execution of the Tengah server.

Current State of Tengah
Weblogic is currently shipping version 3.1 of Tengah. It includes multithreaded implementation for RMI and network connection pooling. Other noteworthy features include clustering for fault tolerance using JTS and full EJB 1.0 support. It also claims to have COM component integration. In future releases Tengah plans to support integration with JMS and other messaging middleware such as Microsoft's MSMQ and IBM's MQSeries.

EJB Meets CORBA
To add to the story of paradigm shift in distributed enterprise computing, it would be worthwhile to mention that OMG is working hard to enhance CORBA to facilitate its adoption in the enterprise world. the CORBA 3.0 specification, already underway at OMG, will simplify the use of CORBA ORBs for the development of distributed object applications and include support for EJB specification. This will allow EJB components to be reusable as CORBA components.

EJB architecture will be key to middle-tier solutions in CORBA-based applications. By treating EJB objects as CORBA objects, clients will be able to work with EJB components in different CORBA middle-tier environments without regard to the environment of the vendor hosting that component. A CORBA 3.0-compliant server, when encountering EJB components, will be able to load a Java Virtual Machine at runtime and run the EJB objects. The first draft for the CORBA 3.0 specification was expected to be released by the end of 1998.

Products like Weblogic's Tengah are already providing the means to support CORBA objects within EJB containers. This is possible since CORBA objects can be wrapped as EJBeans within an application server environment like Tengah.

EJB and CORBA: Complementary, Not Competing, Technologies
CORBA provides a language-independent distributed environment, while EJB components enhance this environment with portable, reusable, multitier network-centric Java components. Thus these technologies should be viewed not as competing but as complementary technologies to provide a distributed platform for enterprise computing. The EJB model integrates well with CORBA's distributed object model.

One example of this is EJB's transaction model. EJB's transaction architecture closely models CORBA's Object Transaction Service (OTS) specification. The following section describes the EJB transaction architecture and its mapping to the OTS architecture.

EJB Transaction Architecture An EJB runtime requires transaction propagation across multiple EJB servers on the network. This requires a distributed transaction service with two-phase commit to ensure recovery of transactions in case of a network failure. The EJB specification also requires the transactions to be able to span multiple EJB servers so that a bean in one server can act as a client to a bean in another server while preserving membership within the transaction. The transaction control for a bean is usually specified in the bean's Deployment Descriptor.

The transaction could be bean managed or container managed. Various transaction controls can be specified for the enterprise bean: TX_REQUIRES, TX_NOT_SUPPORTED, TX-_BEAN_MANAGED, TX_REQUIRES_NEW and so on. Session beans can implement the SessionSynchronization interface to receive callbacks from the transaction service. The enterprise beans are transactional. They carry the transactional state in the form of EJBContext, which is provided to every bean when it's first created. The session and entity beans carry SessionContext and EntityContext, respectively, both of which are subclasses of EJBContext. In addition, an EJB vendor may choose to provide support for client-demarcated transactions. This would allow the client to begin a transaction prior to invoking a method on the bean.

Mapping OTS Components into EJB Components The EJB transaction model is based on the OTS model specified by CORBA. In fact, the EJB specification requires its transaction service to be accessible using OTS 1.1 API. Hence, each of the OTS components can easily be mapped to an EJB object. For example, the Terminator object in OTS architecture could be viewed as an EJB container. In container-managed transactions the container can either commit or roll back a transaction, as appropriate. A transaction-aware JDBC driver in an EJB environment can act as a coordinator of OTS to register a connection with the transaction. Similarly, an EJB container can also act as a Coordinator to register a bean as a Synchronization object if the bean implements javax.ejb.SessionSynchronization interface (see Figure 4).

To keep the server requirements simpler, the current EJB specification doesn't require support for a nested transaction. Several other features of OTS aren't required by the current EJB specification, such as explicit transaction propagation. The JPE provides JTS, which is a Java mapping for the CORBA OTS. Enterprise JavaBeans support transactions using JTS. The EJB container and other transaction coordinator objects use the JTA to interface with the underlying OTS-compliant transaction service.

One other feature that I think will make CORBA a true counterpart of EJB is the addition of directory services to CORBA's naming service so that JNDI API can seamlessly access the CORBA service, or allow it to be integrated with any other namespace services.

What's Next?
The change in focus from client to server in the deployment of Java has created a demand for a component model that can target the server. Enterprise JavaBeans can satisfy this demand by providing a reusable server-side component model for the development of Java applications based on a multitier distributed architecture. The EJB component architecture represents a giant step forward in simplifying the development, deployment and management of enterprise applications. Enterprise JavaBeans will be a core piece of the JPE, which provides access to a core set of system services that's necessary for the development of enterprise-scale applications systems.

An adaptation of EJB by OMG would contribute significantly to its success. An interesting battle is emerging between Microsoft's middle-tier solution and EJB technology. Microsoft's distributed architecture, which consists of COM, Microsoft Transaction Service (MTS) and MSMQ is currently more stable and ahead in terms of implementation than the EJB architecture. The most recent acquisition of Weblogic Inc. by one of the veterans in distributed computing (BEA Systems) makes the battle even more interesting and indicates that the arrival of Enterprise JavaBeans may just be the beginning of a new era in enterprise computing.

Resources
OMG: www.omg.org
Weblogic Inc.: www.weblogic.com
Sun, Inc.: java.sun.com
Sun's Enterprise JavaBeans Page: http://java.sun.com/products/ejb
Sun's Java Naming and Directory Interface Page: http://java.sun.com/products/jndi

Related Links

About Bhaven Shah
Bhaven Shah, a member of the technical staff at i2 Technologies, Dallas, Texas, has BS and MS degrees in computer science. Bhaven has almost five years of programming experience with more than two years in Java. His current focus is client/server, distributed and GUI software development.