Chapter 4   Introducing Enterprise JavaBeans


This chapter describes how Enterprise JavaBeans (EJBs) work in the iAS application programming model.

This chapter begins by defining an EJB in terms of its roles and delivery mechanisms. Next it describes the two types of EJBs—entity beans and session beans—and when to use them. Finally, the chapter closes with an overview of designing an object-oriented iAS application using EJBs to encapsulate business logic.

This chapter includes the following sections:

• What Enterprise JavaBeans Do

• What Is an Enterprise JavaBean?

• Session Beans and Entity Beans

• The Role of EJBs in iAS Applications

• Designing an Object-Oriented Application

Note If you already know about EJBs and how they are used in iAS, you may want to jump ahead to the chapter containing specific instructions and guidelines for developing EJBs for use with iAS: Chapter 6 "Building Business Entity EJBs and Chapter 11 "Creating and Managing User Sessions.

What Enterprise JavaBeans Do

---

In iAS, Enterprise JavaBeans (EJBs) are the workhorses of your applications. If servlets act as the central dispatcher for your application and handle presentation logic, EJBs do the bulk of your application's actual data and rules processing, but provide no presentation or visible user-interface services. EJBs enable you to partition your business logic, rules, and objects into discrete, modular, and scalable units. Each EJB encapsulates one or more application tasks or application objects, including data structures and the methods that operate on them. Typically they also take parameters and send back return values.

EJBs always work within the context of a "container," which serves as a link between the EJBs and the server that hosts them. As an iAS developer, you need not worry about the container for your EJBs. The iAS software environment provides the container for your EJBs. This container provides all the standard container services denoted by the Sun EJB specification, and it provides additional services that are specific to iAS.

In fact, the container handles all actual remote access, security, concurrency, transaction control, and database access. Because the actual implementation details are part of the container and there is a standard, prescribed interface between a container and its EJBs, the bean developer is freed from having to know or handle platform-specific implementation details. Instead, the enterprise bean developer can create generic, task-focused EJBs that can be used with any vendor's products that support the EJB standard.

What Is an Enterprise JavaBean?

---

The Enterprise JavaBeans architecture is a component-based model for development and deployment of object-oriented, distributed, enterprise applications. An Enterprise JavaBean (EJB) is a single component in such an application. Applications written using EJBs are scalable, encapsulate transactions, and permit secure multiuser access. These applications can be written once and then deployed on any server platform that supports EJBs.

The fundamental characteristics of EJBs are as follows:

• Creation and management of beans is handled at runtime by a container. iAS itself provides the container for enterprise beans you write as part of your server application.

• Mediation of client access is handled by the container and the server where the bean is deployed, freeing the bean designer from having to process it.

• Restricting a bean to use standard container services defined by the EJB specification guarantees that the bean is portable and can be deployed in any EJB-compliant container.

• Including a bean in, or adding a bean to an application made up of other, separate bean elements—a "composite" application—does not require source code changes or recompiling of the bean.

• Definition of a client's view of a bean is controlled entirely by the bean developer. The view is not affected by the container in which the bean runs or the server where the bean is deployed.

The EJB specification further states that an enterprise bean establishes three "contracts": client, component, and jar file.

Understanding Client Contracts

The client contract determines the communication rules between a client and the EJB container, establishes a uniform development model for applications that use EJBs, and guarantees greater reuse of beans. In particular the client contract stipulates how an EJB object is identified, how its methods are invoked, and how it is created and destroyed.

The container for EJBs enable you to build distributed applications using your own components and components from other suppliers. iAS provides high-level transaction, state management, multithreading, and resource pooling wrappers, shielding you from having to know the details of many low-level APIs.

An EJB instance is created and managed at runtime by a container class, but the EJB itself can be customized at deployment time by editing its environmental properties. Metadata, such as transaction mode and security attributes, are separate from the bean itself, and are controlled by the container's tools at design and deployment. At run time, a client's access to a bean is controlled by the container and the server where the EJB is deployed.

The EJB container is also responsible for ensuring that a client can invoke the specialized business methods that the EJB defines. While a bean developer implements methods inside the bean, the developer must also provide a "remote interface" to the container that tells the container how clients can call the bean's methods.

Finally, the EJB supplies a "home interface" to the container. The home interface extends the javax.ejb.EJBHome interface defined in the EJB specification. This provides a mechanism for clients to create and destroy EJBs. At its most basic, the home interface defines zero or more create(...) methods for each way there is to create a bean. In addition, some types of EJBs, known as entity beans, must also define finder methods, one or more for each way there is to look up a bean or a collection of beans.

Understanding Component Contracts

The component contract establishes the relationship between an EJB and its container. As such, it is completely transparent to a client. There are several parts to the component contract for any given bean.

• Life cycle: For EJB session beans, this includes implementation of the javax.ejb.SessionBean and javax.ejb.SessionSynchronization interfaces. For EJBs entity beans, it includes instead implementation of the javax.ejb.EntityBean interface.

• Session context: A container implements the javax.ejb.SessionContext interface to pass services and information to a session bean instance when the bean instance is created.

• Entity context: A container implements the javax.ejb.EntityContext interface to pass services and information to an entity bean when the bean instance is created.

• Environment: A container implements java.util.Properties and makes it available to its EJBs.

• Services information: A container makes its services available to all its EJBs.

Finally, you can extend the component contract to provide additional services specific to your application needs.

Understanding Jar File Contracts

The standard format used to package enterprise Beans is the ejb-jar file. This format is the contract between the Bean Provider and Application Assembler, and between the Application Assembler and the Deployer. With iAS, you can create a jar file containing EJBs using the iAS Deployment Tool (iASDT). For more information, see the Administration and Deployment Guide.

The ejb-jar file must contain the deployment descriptor (DD) as well as all the class files for the following:

• The enterprise bean class.

• The enterprise bean home and remote interface.

• If the bean is an entity bean, the primary key class.

In addition, the ejb-jar file must contain the class files for all the classes and interfaces that the enterprise bean class, and the remote home interfaces depend on. For further details on the ejb-jar file contents see Chapter 10 "Packaging for Deployment.

Session Beans and Entity Beans

---

There are two kinds of EJBs: entity and session. Each of these bean types is used differently in a server application. An EJB can be an object that represents a stateless service, an object that represents a session with a particular client (and which automatically maintains state across multiple client-invoked methods), or can be a persistent entity object possibly shared among multiple clients.

The following sections describe these two bean types in more detail.

Understanding Session Beans

Session EJBs typically have the following characteristics:

• They execute in relation to a single client.

• Optionally, they handle transaction management according to property settings.

• Optionally, they update shared data in an underlying database.

• They are relatively short-lived.

• They are not guaranteed to survive a server crash, unless you use iAS failover support for stateful session Beans.

A session bean implements business logic. All functionality for remote access, security, concurrency, and transactions is provided by the EJB container. A session EJB is a private resource used only by the client that creates it.

In iAS, an EJB that encapsulates business rules or logic is a session bean. The life duration of a session EJB is usually brief. For example, you might create an EJB to simulate an electronic shopping cart. Each time a user logs into your application, the application creates the session bean to hold purchases for that user. Once the user logs out or finishes shopping, the session bean is removed.

Understanding Entity Beans

Entity EJBs have the following characteristics:

• Representation of data in the backend resource, usually a database.

• Bean-managed transaction demarcation.

• Container-managed transaction demarcation.

• Shared access for any number of users.

• Exists as long as its data is in a database.

• Transparently survives crashes of the EJB server.

The server that hosts EJBs and an EJB container, provides a scalable runtime environment for many concurrently active entity EJBs. Entity EJBs represent persistent data.

The Role of EJBs in iAS Applications

---

EJBs do the vast majority of business logic and data processing in an iAS application. They function invisibly behind the scenes to make an application work. Even though EJBs are at the heart of iAS applications, users are seldom aware of EJBs, nor do they ever interact directly with them.

When a user invokes an iAS application servlet from a browser, the servlet, in turn, invokes one or more EJBs to do the bulk of your application's business logic and data processing. For example, the servlet may load a Java Server Page (JSP) to the user's browser to request a user name and password, and the servlet also passes the user's input to a session bean to validate the input.

Once a valid user name and password combination is accepted, the servlet might instantiate one or more entity bean and session beans to execute the application's business logic, and then terminate. The beans themselves might instantiate other entity or session beans to do further business logic and data processing.

For example, suppose a servlet invokes an entity bean that gives a customer service representative access to a parts database. Access to the parts database might mean the ability to browse the database, to queue up items for purchase by the customer, to place the customer order (and permanently reduce the number of parts in the database), and to bill the customer. It might also include the ability to reorder parts when stock is low or depleted.

As part of the customer order process, a servlet creates a session bean that represents a "shopping cart" to keep temporary track of items as a customer orders them. When the order is complete, the data in the shopping cart is transferred to the order database, the quantity of each item in the inventory database is reduced, and the shopping cart session bean is freed.

As this simplified example illustrates, EJBs are invoked by a servlet to handle most of your application's business logic and data processing. Entity beans, are primarily used to handle data access using the Java Database Connectivity (JDBC) API. Session beans provide transient application objects and perform discrete business tasks.

The greatest challenge you face when creating an application that uses EJBs is determining how to break your application into servlets, JSPs, session Beans, and/or entity Beans.

Designing an Object-Oriented Application

---

Partitioning an iAS application's business logic and data processing into the most effective set of EJBs is a large part of your job as a developer. There are no hard and fast rules for object-oriented design with EJBs, other than that instances of entity beans tend to be long-lived, persistent, and shared among clients, while instances of session beans tend to be short-lived, and used only by a single client. Therefore, what follows in these sections is mostly high-level, iAS-specific advice for improving application speed, making your EJBs modular and shareable, and easing maintenance.

As is the case with all object-oriented development, you must determine what level of granularity you need for your business logic and data processing. Level of granularity refers to how many pieces you break your application into. A high level of granularity—where you divide your application into many, smaller, more narrowly defined EJBs—creates an application that may promote greater sharing and reuse of EJBs among different applications at your site. A low level of granularity creates a more monolithic application that usually executes more quickly.

Note Decomposing an application into a moderate to large number of separate EJBs can create a huge degradation of application performance and more administrator overhead. EJBs, like JavaBeans, are not simply Java objects. They are components with remote call interface semantics, security semantics, transaction semantics, and properties. EJBs are higher level than Java objects.

Planning Guidelines

In general, create iAS applications that balance your need for execution speed with your need for sharing EJBs among applications and clients, and deploying applications across servers:

• Ask your administrator to co-locate EJBs with your presentation logic (servlets and JSPs) on the same server to reduce the number of remote procedure calls (RPCs) when you run your application.

• Create stateless session beans instead of stateful session beans as much as possible. If you must create stateful session beans, have your administrator turn on sticky load balancing for better performance.

• Create session EJBs that are small, generic, and narrowly task-focused. Ideally, these EJBs encapsulate behavior that can be used in many of your applications.

In addition to these general considerations, you must also decide which parts of your applications are candidates for becoming entity beans and which are candidates for becoming session beans.

Using Session Beans

Session beans are intended to represent transient objects and processes, such as updating a single database record, a copy of a document for editing, or specialized business objects for individual clients, such as a shopping cart. These objects are available only to a single client. Because of this, session Beans can maintain client-specific session information, called conversational state. Session Beans that maintain conversational state are called stateful Session Beans; Beans that do not are called stateless Session Beans.

When the client is done with the session objects, the objects are released. When you design an application, designate each such temporary, single-client object as a potential session bean. For example, in an online shopping application, each customer's shopping cart is a temporary object. The cart lasts only as long as the customer is selecting items for purchase. Once the customer is done and the order is processed, the cart object is no longer needed and is released.

Like an entity bean, a session bean may access a database through JDBC calls. A session bean, too, can provide transaction settings. These transaction settings and JDBC calls are refereed by the session bean's container, which is transparent to you as the developer. The container provided with iAS handles the JDBC calls and result sets.

For a complete discussion of using session beans to define temporary objects and rules for single-client access in an iAS application, see Chapter 5 "Using Session EJBs to Manage Business Rules.

Using Entity Beans

Entity beans most commonly represent persistent data. This data is maintained directly in a database, or accessed through a backend application as an object. A simple example of an Entity Bean would be one that is defined to represent a single row in a database table, and where each instance of the Bean represents a specific row. A more complex example would be an Entity Bean designed to represent complicated views of joined tables in a database where each instance of the Bean would represent a single customer's shopping cart contents.

Unlike Session Beans, Entity Bean instances can be accessed simultaneously by multiple clients. The container, is responsible for synchronizing the instance's state by using transactions. This delegation of responsibility to the container, means the Bean developer does not need to worry about concurrent access to methods from multiple transactions.

The persistence of an Entity Bean can either be managed by the bean itself, or by the bean's container. When the Entity Bean manages it's own persistence, it's called Bean-managed persistence. When the bean delegates this function to the container, it's called container-managed persistence (CMP).

• Bean-managed Persistence. The bean developer must implement persistence code (such as JDBC calls) directly in the EJB class methods, if the bean is to manage it's own persistence. The possible downside of this implementation is the loss of portability, if a proprietary interface is used, and also the risk of tieing the bean to a specific database.

• Container-managed Persistence (CMP). The container provider uses the iAS Deployment Tool (iASDT) to generate the bean code to implement the container persistence process. The container manages, transparently to the bean, the persistence state. The bean developer does not need to implement any data access code in the bean's methods. Not only is this method simpler for the bean developer to implement, but it makes the bean fully portable, without any ties to a specific database.

For a complete discussion of using entity beans to define persistent objects and business logic in an iAS application, see Chapter 6 "Building Business Entity EJBs.

Planning for Failover Recovery

Failover recovery is a process whereby a bean can reinstantiate itself after a server crash. Both stateless and stateful Session Beans support failover recovery. The iAS Deployment Tool is used to set the failover properties for session beans, for a description of how to make these settings refer to the iASDT Administration and Deployment Guide. For more information about session bean failover recovery see Chapter 5 "Using Session EJBs to Manage Business Rules.

Entity beans support failover recovery with the caveat that the reference to the bean is lost after a server crash. To recover an entity bean, you must create a new reference to it with a finder, see "Using Finder Methods" in Chapter 4 "Introducing Enterprise JavaBeans.

Working with Databases

In iAS, the preferred method for working with databases is through the Java Database Connectivity (JDBC) API in conjunction with transaction attributes.You use the Java Naming and Directory Interface (JNDI) to obtain a database connection. JNDI provides a standard way for the application to find and access database services independent of JDBC drivers.

For a complete discussion of using entity beans to define persistent objects and business logic in an iAS application, see Chapter 8 "Using JDBC for Database Access.

For a complete description of transaction controls available through session and entity beans, see Chapter 7 "Handling Transactions with EJBs.

Deploying EJBs

You deploy EJBs with the rest of an application using the iAS Deployment Tool (iASDT).

For more information on how to deploy EJBs using iASDT, see the Administration and Deployment Guide.

For information on the meaning of the property settings made by iASDT and how they effect your application, see Chapter 10 "Packaging for Deployment.