A beginner's guide to Enterprise JavaBeans

An introductory overview of the Java server-side application component standard

Enterprise JavaBeans (EJB) has generated a great deal of excitement since the March 1998 announcement of the Enterprise JavaBeans Specification Version 1.0. Companies such as Oracle, Borland, Tandem, Symantec, Sybase, and Visigenic, among many others, have announced and/or delivered products that adhere to the EJB specification. This month, we'll take a high-level look at what exactly Enterprise JavaBeans is. We'll go over how EJB differs from the original JavaBeans component model, and discuss why EJB has generated such an enormous amount of interest.

But first, an advisory: we won't be looking at source code or how-to topics this month. This article isn't a tutorial; rather it's an architectural overview. EJB covers a lot of territory, and without first understanding the basic concepts involved, code snippets and programming tricks are meaningless. If there's interest on the part of JavaWorld's readers, future articles may cover the specifics of using the Enterprise JavaBeans API to create your own Enterprise JavaBeans.

In order to understand why EJB is so attractive to developers, we need some historical background. First, we'll look at the history of client/server systems, and at the current state of affairs. Then, we'll discuss the various parts of an EJB system: EJB components -- which live on an EJB container running inside an EJB server -- and EJB objects, which the client uses as a kind of "remote control" of EJB components. We'll go over the two types of EJBs: session and entity objects. You'll also read about home and remote interfaces, which create EJB instances and provide access to the EJB's business methods, respectively. By the end of the article, you'll have an idea of how extensible servers can be built using Enterprise JavaBeans. But first, a look back in time.

Client/server history

Ancient history

In the beginning, there was the mainframe computer. And it was good. (Or as good as it got, anyway.) The state of the art in information processing through the 1960s consisted primarily of big, expensive machines used by large organizations to support their daily business operations. Minicomputers and timesharing in the 1970s increased the accessibility of computing power, but information and processing were still centralized on individual machines. The first personal computers in the 1980s quickly cluttered the corporate landscape with thousands of tiny islands of information, all tirelessly churning out reports of variable quality, losing critical data when they crashed, and quickly becoming inconsistent with each other.

Client/server to the rescue

The client/server architecture is one of the most common solutions to the conundrum of how to handle the need for both centralized data control and widespread data accessibility. In client/server systems, information is kept relatively centralized (or is partitioned and/or replicated among distributed servers), which facilitates control and consistency of data, while still providing access to the data users need.

Client-server systems are now commonly composed of various numbers of tiers. The standard old mainframe or timesharing system, where the user interface runs on the same computer as the database and business applications, is known as single tier. Such systems are relatively easy to manage, and data consistency is simple because data is stored in only one place. Unfortunately, single-tier systems have limited scalability and are prone to availability hazards (if one computer's down, your whole business goes down), particularly if communication is involved.

The first client/server systems were two-tier, wherein the user interface ran on the client, and the database lived on the server. Such systems are still common. One garden-variety type of two-tier server performs most of the business logic on the client, updating shared data by sending streams of SQL to the server. This is a flexible solution, since the client/server conversation occurs at the level of the server's database language. In such a system, a properly designed client can be modified to reflect new business rules and conditions without modifying the server, as long as the server has access to the database schema (tables, views, and so forth) needed to perform the transactions. The server in such a two-tier system is called a database server, as shown below.

Figure 1. A database server

Database servers have some liabilities, though. Often the SQL for a particular business function (for example, adding an item to an order) is identical, with the exception of the data being updated or inserted, from call to call. A database server ends up parsing and reparsing nearly identical SQL for each business function. For example, all SQL statements for adding an item to an order are likely to be very similar, as are the SQL statements for finding a customer in the database. The time this parsing takes would be better spent actually processing data. (There are remedies to this problem, including SQL parse caches and stored procedures.) Another problem that arises is versioning the clients and the database at the same time: all machines must shut down for upgrades, and clients or servers that fall behind in their software version typically aren't usable until they're upgraded.

Application servers

An application server architecture (see the next image) is a popular alternative to a database server architecture because it solves some of the problems database servers have.

Figure 2. An application server

A database server environment usually executes business methods on the client, and uses the server mostly for persistence and enforcing data integrity. In an application server, business methods run on the server, and the client requests that the server execute these methods. In this scenario, the client and server typically will use a protocol that represents a conversation at the level of business transactions, instead of at the level of tables and rows. Such application servers often perform better than their database counterparts, but they still suffer from versioning problems.

Both database and application systems can be enhanced by adding additional tiers to the architecture. So-called three-tier systems place an intermediate component between the client and the server. An entire industry -- middleware -- has cropped up to address the liabilities of two-tier systems. A transaction-processing monitor, one type of middleware, receives streams of requests from many clients, and may balance the load between multiple servers, provide failover when a server fails, and manage transactions on a client's behalf. Other types of middleware provide communications protocol translation, consolidate requests and responses between clients and multiple heterogeneous servers (this is particularly popular in dealing with legacy systems in business process reengineering), and/or provide service metering and network traffic information.

Multiple tiers provide a flexibility and interoperability that has resulted in systems with more than these three layers of service. For example, n-tier systems are generalizations of three-tier systems, each layer of software providing a different level of service to the layers above and beneath it. The n-tier perspective considers the network to be a pool of distributed services, rather than simply the means for a client to accesses a single server.

As object-oriented languages and techniques have come into vogue, so have client/server systems increasingly moved toward object-orientation. CORBA (Common Object Request Broker Architecture) is an architecture that allows objects within applications -- even objects written in different languages -- to run on separate machines, depending on the needs of a given application. Applications written years ago can be packaged as CORBA services and interoperate with new systems. Enterprise JavaBeans, which is designed to be compatible with CORBA, is another entry into the object-oriented application-server ring.

The purpose of this article is not to provide a tutorial on client/server systems, but it was necessary to provide some background in order to define context. Now let's look at what EJB has to offer.

Enterprise JavaBeans and extensible application servers

Now that we've looked at a bit of history and have an understanding of what application servers are, let's look at Enterprise JavaBeans and see what it offers in that context.

The basic idea behind Enterprise JavaBeans is to provide a framework for components that may be "plugged in" to a server, thereby extending that server's functionality. Enterprise JavaBeans is similar to the original JavaBeans only in that it uses some similar concepts. EJB technology is governed not by the JavaBeans Component Specification, but by the entirely different (and massive) Enterprise JavaBeans Specification. (See Resources for details on this spec.) The EJB Spec calls out the various players in the EJB client/server system, describes how EJB interoperates with the client and with existing systems, spells out EJB's compatibility with CORBA, and defines the responsibilities for the various components in the system.

Enterprise JavaBeans goals

The EJB Spec tries to meet several goals at once:

  • EJB is designed to make it easy for developers to create applications, freeing them from low-level system details of managing transactions, threads, load balancing, and so on. Application developers can concentrate on business logic and leave the details of managing the data processing to the framework. For specialized applications, though, it's always possible to get "under the hood" and customize these lower-level services.

  • The EJB Spec defines the major structures of the EJB framework, and then specifically defines the contracts between them. The responsibilities of the client, the server, and the individual components are all clearly spelled out. (We'll go over what these structures are in a moment.) A developer creating an Enterprise JavaBean component has a very different role from someone creating an EJB-compliant server, and the specification describes the responsibilities of each.

  • EJB aims to be the standard way for client/server applications to be built in the Java language. Just as the original JavaBeans (or Delphi components, or whatever) from different vendors can be combined to produce a custom client, EJB server components from different vendors can be combined to produce a custom server. EJB components, being Java classes, will of course run in any EJB-compliant server without recompilation. This is a benefit that platform-specific solutions can't hope to offer.

  • Finally, the EJB is compatible with and uses other Java APIs, can interoperate with non-Java apps, and is compatible with CORBA.

How an EJB client/server system works

To understand how an EJB client/server system operates, we need to understand the basic parts of an EJB system: the EJB component, the EJB container, and the EJB object.

The Enterprise JavaBeans component

An Enterprise JavaBean is a component, just like a traditional JavaBean. Enterprise JavaBeans execute within an EJB container, which in turn executes within an EJB server. Any server that can host an EJB container and provide it with the necessary services can be an EJB server. (This means that many existing servers may be extended to be EJB servers, and in fact many vendors have achieved this, or have announced the intention to do so.)

An EJB component is the type of EJB class most likely to be considered an "Enterprise JavaBean." It's a Java class, written by an EJB developer, that implements business logic. All the other classes in the EJB system either support client access to or provide services (like persistence, and so on) to EJB component classes.

The Enterprise JavaBeans container

The EJB container is where the EJB component "lives." The EJB container provides services such as transaction and resource management, versioning, scalability, mobility, persistence, and security to the EJB components it contains. Since the EJB container handles all of these functions, the EJB component developer can concentrate on business rules, and leave database manipulation and other such fine details to the container. For example, if a single EJB component decides that the current transaction should be aborted, it simply tells its container (in a manner defined by the EJB Spec, and the container is responsible for performing all rollbacks, or doing whatever is necessary to cancel a transaction in progress. Multiple EJB component instances typically exist inside a single EJB container.

The EJB object and the remote interface

Client programs execute methods on remote EJBs by way of an EJB object. The EJB object implements the "remote interface" of the EJB component on the server. The remote interface represents the "business" methods of the EJB component. The remote interface does the actual, useful work of an EJB object, such as creating an order form or deferring a patient to a specialist. We'll discuss the remote interface in more detail below.

1 2 Page
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more