Previous Next Contents Index


Introducing Enterprise JavaBeans

This chapter describes how Enterprise JavaBeans (EJBs) work in the NAS 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 NAS application using EJBs to encapsulate business logic.

This chapter includes the following sections:

Note. If you already know about EJBs and how they are used in NAS, you may want to jump ahead to the chapter containing specific instructions and guidelines for developing EJBs for use with NAS: Building Business Entity EJBs and Using Session EJBs to Manage Business Rules.


What Enterprise JavaBeans Do
In NAS, 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 NAS developer, you need not worry about the container for your EJBs. The NAS 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 NAS.

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. For an introduction to EJBs, visit
http://java.sun.com:8081/products/ejb/docs.html.

The fundamental characteristics of EJBs are as follows:

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. EJBs provide 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.

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

Understanding Jar File Contracts The jar file contract specifies what information must be in the jar file a developer uses to package an EJB for deployment. With NAS, you can create a jar file containing EJBs using the NAS Deployment Tool. For more information, see the Administration Guide.

A jar file for an EJB includes:


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 A session EJB typically has the following characteristics. It:

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 NAS, 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 freed.

Understanding Entity Beans An entity EJB has the following characteristics. It:

The server that hosts EJBs and an EJB container provide a scalable runtime environment for many concurrently active entity EJBs. Entity EJBs represent either persistent data (such as a database or document), or an object that is used by an existing enterprise application.

In the NAS model, an EJB encapsulates a business object, such as a database. The life duration of an entity EJB can span the entire life of the application that instantiates it, or it can span some portion of it. For example, suppose you are in the automotive parts industry. You might create an inventory control entity bean that interfaces with your parts database everywhere throughout your application.


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

When a user invokes an NAS 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 provide business objects and data access for the life of the application and even beyond it. Entity beans, too, are primarily used to handle data access using the Java Database Connectivity (JDBC) API. Session beans provide temporary 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 a meaningful set of non-enterprise JavaBeans, and enterprise entity and session EJBs.


Designing an Object-Oriented Application
Partitioning an NAS 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, NAS-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 NAS applications that balance your need for execution speed with your need for sharing EJBs among applications and clients, and deploying applications across servers:

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. When the client is done with them, 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 NAS 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 NAS application, see Using Session EJBs to Manage Business Rules.

Using Entity Beans Entity beans are intended to represent persistent objects, such as data, documents, and specific business objects that may be accessed by multiple clients. When you design an application designate each business object as a potential entity bean. For example, an inventory control system combines a database with specialized methods for search, retrieval, removal, restocking, and reporting. The inventory control system is a perfect candidate for an entity bean.

An entity bean accesses a database through a combination of bean settings for transaction control and JDBC calls. These transaction settings and JDBC calls are refereed by the entity bean's container, which is transparent to you as the developer. The container provided with NAS handles the JDBC calls and result sets.

The high-level ability to support transactions through EJB properties is especially useful for entity beans because the bean can encapsulate control for distributed transactions that span multiple datasources without requiring you to handle the details.

While an entity bean may represent a business object to one or many clients, often there are specific client database events that are unique to the client. In these cases, you may want to use a session bean to control a client's interaction with the entity bean's database representation.

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

Planning for Failover Recovery Failover recovery is a process whereby a bean can reinstantiate itself after a server crash. Stateless session beans support failover recover, but stateful session beans do not.

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).

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

NAS fully supports JDBC 1.0 and also supports most of the JDBC 2.0 specification, including connection pools, distributed transaction support, and rowsets.

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

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

Deploying EJBs You normally deploy EJBs with the rest of an application using the NAS Deployment Manager. You can also choose to deploy manually for the purpose of testing your EJB, or upgrading before restarting the server.

For more information, see Deploying and Upgrading Applications.

 

© Copyright 1999 Netscape Communications Corp.