There is a fundamental problem facing enterprise developers today. Writing distributed business applications is difficult. Writing any large application is difficult. This is compounded if the application is distributed, or lives in multiple pieces on a network. This is further compounded if the application must execute its business logic in a guaranteed, reliable fashion.

Another complication that enterprises face is that they are themselves fundamentally heterogeneous environments. In addition, enterprises seek to build their applications as fast as possible without being locked into one platform. Ideally, enterprise developers would like to be able to write the application once and run it on all of their platforms. Enterprise JavaBeans^TM technology seeks to provide this ability.

The Enterprise JavaBeans (EJB) component architecture is designed to enable enterprises to build scalable, secure, multiplatform, business-critical applications as reusable, server-side components. This article describes implications and architecture of the EJB component model, and presents an example of how EJB components work.

What is Enterprise JavaBeans Technology?

The EJB architecture is a server-side component model for the Java^TM platform. Its purpose is to solve the problems described above by allowing the enterprise developer to focus only on writing business logic. EJB technology has removed the need to write "plumbing" code. For example, the enterprise developer no longer needs to write code that handles transactional behavior, security, connection pooling, or threading, because the architecture delegates this task to the server vendor.

There are several benefits for the users and implementers of this technology:

• Productivity: Enterprise developers will be more productive using this technology. Not only do developers get all the productivity gains of developing on the Java platform, but they also get a boost from the fact that they only have to focus on writing their business logic.
• Industry Support: Customers attempting to build EJB systems will have a range of solutions to choose from. Enterprise JavaBeans technology has been adopted, supported and put on the product roadmaps of over 25 companies.
• Protection of Investments: Enterprise JavaBeans technology builds on top of the systems that exist in the enterprise today. In fact, many of the EJB products coming out will be built on top of established enterprise systems. The systems that exist in enterprises today will be running Enterprise JavaBeans components tomorrow.
• Architectural Independence: Enterprise JavaBeans technology insulates the developer from the underlying middleware. The developer sees only the Java platform. In addition to the cross-platform benefits described below, this allows the EJB server vendor the opportunity to improve and change the middleware layer without disturbing a user's EJB applications.
• Server-Side Write Once, Run Anywhere^TM: By leveraging the Java platform, EJB technology takes the notion of Write Once, Run Anywhere to a new level. It does this by guaranteeing that an EJB application will run on any server that faithfully provides the Enterprise JavaBeans APIs.

EJB Technology Design Goals

The server-side environment and the tools needed to service it have greatly influenced the design goals for EJB technology. One key design goal was to reduce (as much as possible) the process of building distributed applications. This goal has been accomplished by turning features that ordinarily would need to be hand-coded into simple declarative properties of the enterprise Beans. These declarative properties generate a significant increase in development efficiency because certain behaviors, like security and transactions, are set, not in code, but are "flags" on the Bean itself. This design feature is another way in which EJB technology allows the developer to focus solely on writing business logic.

The EJB specification creates an infrastructure that takes care of the system-level programming, such as transactions, security, threading, naming, object-life cycle, resource pooling, remote access, and persistence. It also simplifies access to existing applications, and provides a uniform application development model for tool creation and use.

Enterprise Application Models

In addition to providing the infrastructure, EJB technology addresses an additional issue. There are two fundamental models for building enterprise applications. In the first model, the client begins a session with an object that acts like an application, executing a unit of work on behalf of the client, possibly including multiple database transactions. In the second model, the client accesses an object that represents an entity in a database. EJB was designed to be broadly applicable, and as such covers both these models.

• Session Beans cover the first model. A session Bean is an object that represents a transient conversation with a client, and it executes database reads and writes for the client. These database accesses can be in the context of a transaction. A session Bean's fields contain the state of the conversation and are transient. The implication being that if either the server or the client crashes, the session Bean is gone. This model is typically used with database programming languages such as PL/SQL.
• Entity Beans cover the second model. An entity Bean represents data in a database, along with the methods to act on that data. In a relational database context, for a table of employee information, there is one Bean for each row in the table. Entity Beans are transactional, and are long-lived. As long as the data remains in the database, the entity Bean exists. This model is most typically used today in the object-oriented database market.

Note that in the EJB specification, support for session Beans is mandatory. Support for entity Beans is currently optional, but will become mandatory for version 2.0 of the specification.

EJB Architecture

The figure above illustrates the architecture of EJB technology. The EJB specification allows for any kind of client. This is because the specification does not mandate any remote object "wire" protocol. This means that a server can support multiple protocols like RMI, IIOP (CORBA), and DCOM. This implies that a client to an EJB server does not have to be written in the Java language.

The EJB server is a collection of services for supporting an EJB installation. These services include management of distributed transactions, management of distributed objects and distributed invocations on these objects, and low-level system services. In short, an EJB server manages the resources needed to support EJB components. An EJB server provider can provide an implementation of a container, (described below) and it can provide an API for third party vendors to plug-in additional EJB containers. The EJB specification allows developers a great deal of freedom in the design and implementation of servers.

An EJB container is just that: a home for EJB components. A container is where a Bean lives, just as a record "lives" in a database. It provides a scalable, secure, transactional environment in which Beans can operate. It is the container that handles the object life cycle, including creating and destroying an object. The container, among other things, also handles the state management of Beans.

A container is transparent to the client. There is no client API to it. When a Bean is installed in a container, the container provides two implementations: an implementation of the Bean's EJBHome interface, discussed below; and the Bean's remote interface. The container is also responsible for making the Bean's EJBHome interface available in JNDIª, the Java Naming and Directory Interface1.

To construct a Bean, you must first implement the business methods. For example, if you are writing a checking account Bean, you might implement a "debit" method as part of its interface. You must also implement one of two types of EJB interfaces, SessionBean or EntityBean. These interfaces include methods related to working set management, for example, and are not exposed to a client.

To this end, when a Bean is installed on a server, the remote interface, usually called a skeleton in CORBA, is automatically generated. The implementation of the remote interface is called the EJBObject and is an object that exposes only the remote interface specified by the programmer. The enterprise Bean class does not implement the remote interface, though it does contain methods with the same signatures. The EJBObject acts like a proxy, intercepting the remote object invocations and calling the appropriate methods on the enterprise Bean instance.

An EJB container implements the EJBHome interface of each enterprise Bean installed in the container. It allows for the creation of a Bean, deletion of a Bean and querying information or "metadata" about a Bean. The container makes the EJBHome interfaces available to the client through JNDI. For entity Beans, the EJBHome interface also contains one or more "finder" methods that allow a client to look up a Bean by a primary key.

Features

One of the most complex tasks application developers face is writing distributed transactional applications. A key feature of EJB technology is its support for distributed transactions. It lets you write applications that access multiple distributed databases, across multiple EJB servers. To make it easier, the EJB specification allows you to specify the transactional behavior declaratively at deployment time. The burden of managing transactional behavior is shifted to the server, specifically the container and EJB server providers. In the event that the Bean developer has more advanced transactional needs, the Bean can manage the transaction boundaries programmatically.

Security is a requirement for all enterprise products. The EJB component model leverages off the core Java platform security model, giving you two ways to set up security. First, you can set the security descriptor in the Bean's EJB-JAR file. Second, you can use the java.security package to manage security programmatically.

Another main design feature of EJB is that it is object communication protocol-neutral. This has a number of benefits. First, it frees the programmer to implement the client part of the application in the protocol of choice. Second, it allows the EJB server builder to implement the protocols that are most important to its customer base. For example, an ORB vendor might only implement the CORBA protocols, while a UNIX system provider might implement RMI and CORBA. In any case, the protocol used is transparent to the Bean developer who writes only to the Java platform.

The Java platform provides a number of inherent benefits to an EJB server. The most obvious of these is that once a Bean-based application is written it can run anywhere an enterprise Bean server is running. An adjunct benefit to this is scalability. If your current EJB application is hitting a performance wall, you can move your application part-and-parcel to another higher performing platform's EJB server.

Specialized containers can greatly simplify access to existing enterprise applications. Such a container can make existing non-Java language applications appear as Beans, enabling the Java language developer to access these applications without learning the specifics of the existing systems and applications.

Developer Roles

EJB Technology divides naturally into five developer roles: server provider, container provider, Enterprise Beans provider, application assemblers, and deployers. Each is described below:

• Server providers are specialists in distributed transaction management, dealing with distributed objects, and low-level systems services. Database and TP monitor vendors will typically fill this role.
• Container providers are generally specialists in systems programming, and might have application-domain experience, because containers have the ability to bridge the EJB environment to existing applications like SAP R/3 and CICS. The container provides the secure, scalable, transactional environment for a Bean, and hence the provider needs experience in these areas. Database and transaction server vendors typically fill this role as well, and provide a standard container.
• Enterprise Bean providers provide the building blocks for EJB applications. They are typically domain experts who code business logic in the form of Beans. They are not necessarily experts in database or systems programming. They produce an EJB JAR file that contains the components they produce. Object library vendors typically fill this role.
• Application assemblers are domain experts whose job is to build applications from third party Beans. They may also build a GUI on the client slide. An example of an application assembler is a programmer who builds an application that accesses deployed components.
• Deployers are usually familiar with an enterprise's operational environment. The deployer takes a packaged application and sets some or all of the application's security and transaction descriptors. The deployer might also use tools to modify the business logic of the Bean.

Development Process

It is important to note that there are several different scenarios for building EJB applications and components. The development process is different depending on whether or not you are writing a session Bean, an entity Bean, an application, or some combination of all three.

Consider a simple scenario involving a session Bean that involves updating a checking account. The development process for building an EJB component is simple. First, you write the business logic for your Bean or Bean-based application using an IDE like Java Workshop, CafŽ or JBuilder. After compilation, the Beans are packaged up into an EJB JAR file. This is similar to a regular JAR file, but it contains a serialized DeploymentDescriptor class instance, which contains the settings for security, transactional behavior, and so on. Next, you install the Bean on an EJB server using a deployment tool provided by the server vendor. It is at this time that the deployer (someone like a database administrator) will set the site-specific attributes of the Bean, such as transaction mode or security level. Once a Bean is installed on a server, a client can invoke the instance's remote methods.

Take an example from the electronic commerce area: A "shopping cart" for purchasing things over the Web. Consider how you might build a shopping cart Bean. You would start by building the remote interface for the Bean:

public interface ShoppingCart extends javax.ejb.EJBObject { boolean addItem(int itemNumber) throws java.rmi.RemoteException; boolean purchase() throws java.rmi.RemoteException; }

Note that the enterprise Bean class does not implement the Bean's remote interface. The EJBObject will do that. Also note that session Beans do not support automatic persistence. As a result, explicit database access must be done in its methods. For example, in the purchase() method, JDBC^TM calls could be used to update the database appropriately. The EJBObject generated by the container at install time implements the remote interface. The EJBObject acts as a proxy, passing method invocations through to Bean instance installed in the server.

The first thing a client does is to locate the EJBHome for the required Bean using JNDI. In this example our EJBHome object might appear as follows:

public interface CartHome extends javax.ejb.EJBHome { Cart create(String customerName, String account) throws RemoteException, BadAccountException; }

The CartHome interface contains a create() method that will be invoked whenever a client requests a new Bean. Note that this method is implemented in the EJBObject, and will call the ejbCreate() method in the Bean class when invoked.

Consider how the client side code for a shopping cart Bean might be written. In this case, the client side could be a servlet running in the Java Web Server, a thin client, a Java language application, or a C++ application using CORBA.

The EJBHome object for the ShoppingCart class can be located using the following code segment:

Context initialContext = new InitialContext(); CartHome cartHome = (CartHome) initialContext.lookup("applications/mall/shopping-carts");

In this sample, InitialContext() is called to get the root of the JNDI naming hierarchy. The lookup() method is used to get the CartHome. In this case "applications/mall/shipping-carts" is the JNDI path to the CartHome you are interested in. At this point, cartHome holds a reference to the EJBHome object for the ShoppingCartEJB. Note, however, that a client's JNDI name space might be configured to include EJB containers located on multiple machines on a network. The actual location of an EJB container is, in general, transparent to the client.

The following example illustrates how a client uses a EJBHome object and calls a method:

ShoppingCartEJB cart = cartHome.create("Emma", "0507"); cart.addItem(100); cart.addItem(251); cart.purchase();

In the code above, create() methods create a new session Bean. The variable cart contains a reference to the remote EJB Object that allows you to call its methods, addItem() and purchase(). Note that the create() methods in cartHome will call the corresponding ejbCreate() method on the Bean.

What's Next for EJB?

The EJB 1.0 specification was released to the public during JavaOne 1998. It provides a solid architectural foundation for building distributed business object systems. It should not be viewed as the last word on the subject, but rather as the first iteration in a process of perfecting the architecture. There are a few areas in the specification that need to be refined, most notably in EJB's model for handling persistent objects. Standardizing the contract between development tools and systems to provide a uniform debugging interface for all development environments is being considered as well.

Sun Microsystems will certainly be addressing the issue of compatibility in the near future. There are two areas where compatibility is an issue. The first is what actually constitutes an "EJB compatible" server. A compliance program is expected to be in place in the near future. The second is guaranteeing that EJB servers from different vendors can interoperate. Sun is in the process of getting feedback from their partners on this issue as to how to proceed.

Conclusion

Enterprise JavaBeans technology presents a new way to develop, deploy and manage distributed business applications. It does this by making it easier for the developer to write business applications as re-usable server components and not have to worry about system-level programming. The Enterprise JavaBeans component architecture represents a giant step forward in simplifying the development deployment and management of enterprise applications. For a complete description of Enterprise JavaBeans technology, visit the Enterprise JavaBeans web site.

An earlier version of this article appeared in the JavaReport.