EJB Technology Overview

Introduction

The Enterprise JavaBeans (EJB) 1.1 specification defines an architecture for the development and deployment of transactional, distributed object applications-based, server-side software components. Organizations can build their own components or purchase components from third-party vendors. These server-side components, called enterprise beans, are distributed objects that are hosted in Enterprise JavaBean containers and provide remote services for clients distributed throughout the network.
Two-tier and three-tier environments

In two-tier client-server environments, programmers write applications that are closely tied to vendor-specific software. Typically, two-tier applications access database services or transaction services directly from the client. Such applications are sometimes called fat clients because the application logic resides on the client, making the clients large and complex. This is depicted by the following diagram:

Three-tier client-server applications employ an intermediary, or middle-tier, application server, which operates between client applications and the back-end databases. The middle tier houses the business logic of the system and coordinates the interaction of the presentation on the client with the back-end databases.

There are two fundamental motivations for using a three-tier architecture over a two-tier model:

* Improved scalability, availability, and performance
* Improved flexibility and extensibility of business systems

Two-tier systems perform well by leveraging the processing power of the client, but the dedicated nature of many clients to a single back-end resource, like a database, produces a bottleneck that inhibits scalability, availability, and performance as client populations grow large. Three-tier systems attempt to mitigate this bottleneck by managing back-end resources more effectively. This is accomplished through resource management techniques like pooling and clustering of middle-tier servers. Pooling makes three-tier systems more effective by allowing many clients to share scarce resources like database connections, which reduces the workload on back-end servers. Clustering makes three-tier systems more available and scalable because multiple servers and resources can support fail-over and balance the loads of a growing client population.

Three-tier systems are more flexible and extensible than their two-tier counterparts because the business logic and services, such as security and transactions, reside on the middle-tier and are largely hidden from the client applications. If properly implemented, as is the case with Enterprise JavaBeans, services are applied automatically to client requests and are therefore invisible. Because services are not visible to the client, changes to services are also invisible. Changes and enhancements to business logic on the middle tier can also be hidden from client applications if implemented correctly.

Additionally, when clients and middleware components are implemented in the Java programming language, there is a tremendous potential for portability. The class files that implement the clients as well as the application servers can be relocated quite easily to the hosts that are currently most appropriate.

Over the last two to three years, several vendors have released Java-based three-tier application servers, all of which are capable of interacting with and managing back-end server operations. Even though these middleware products support distributed architectures that are a very significant advance over two-tier designs (and over pre-Java application servers), their fundamental limitation is that their programming models tend to be vendor specific. This means that an organization must invest heavily in a vendor's model and that systems are not portable, leading to vendor lock-in.

As the object-oriented programming paradigm has grown in popularity, distributed-object systems have thrived. Several distributed-object technologies now exist. The most popular are CORBA, created by the Object Management Group , Java RMI (JRMP) from Sun Microsystems, and DCOM and MTS (a.k.a. COM+) from Microsoft. Each has its strengths and weaknesses. Enterprise JavaBeans from Sun Microsystems is the most recent addition to this mix and in some regards, it's both a competitor and a partner in these technologies.

CORBA (Common Object Request Broker Architecture) went a long way toward addressing vendor lock-in issues in three-tier computing as did other open standards like LDAP. Unfortunately, while CORBA has revolutionized distributed computing, the programming model proved too complex and the vendor adherence to the specification unbalanced. CORBA has advanced distributed computing, but has proven too difficult to implement and less portable than expected.

Enterprise JavaBeans (EJB) is Sun Microsystems' solution to the portability and complexity of CORBA. EJB introduces a much simpler programming model than CORBA, allowing developers to create portable distributed components called enterprise beans. The EJB programming model allows developers to create secure, transactional, and persistent business objects (enterprise beans) using a very simple programming model and declarative attributes. Unlike CORBA, facilities such as access control (authorization security) and transaction management are extremely simple to program. Where CORBA requires the use of complex APIs to utilize these services, EJB applies these services to the enterprise bean automatically according to declarations made in a kind of property file called a deployment descriptor. This model ensures that bean developers can focus on writing business logic while the container manages the more complex but necessary operations automatically.

Portability in EJB works because the EJB specification mandates a well-defined set of contracts between the EJB container (the vendor's server) and the EJB component (the business object). These contracts or rules state exactly what services a container must make available to an enterprise bean and what APIs and declarative attributes the bean developer needs to create an enterprise bean. The life cycle of an enterprise bean is specified in detail, so the vendor knows how to manage the bean at run time and the bean developer knows exactly what an enterprise bean can do at any moment in its existence.

Enterprise JavaBeans simplifies the development, deployment, and access to distributed objects. The developer of an EJB distributed object, an enterprise bean, simply implements the object according to the conventions and protocol established for Enterprise JavaBeans. EJB-capable application servers may, and do, use any distributed network protocol including the native Java RMI protocol (JRMP), proprietary protocols, or CORBA's network protocol (IIOP). Regardless of the underlying network protocol used in a particular product, EJB uses the same programming API and semantics to access distributed objects as Java RMI-IIOP. The details of the protocol are hidden from the application and bean developer; the mechanics of locating and using distributed beans are the same for all vendors.

Note: An enterprise bean is not the same as a JavaBean. A JavaBean is developed using the java.beans package, which is part of the Java 2 Standard Edition. JavaBeans are components that run on one machine, within a single address space. JavaBeans are process components. An enterprise bean is developed using the javax.ejb package, a standard JDK extension, which is a part of the Java 2 Enterprise Edition. Enterprise beans are components that run on multiple machines, across several address spaces. Enterprise beans are thus interprocess components. JavaBeans are typically used as GUI widgets, while enterprise beans are used as distributed business objects.

---