Previous     Contents     Index     DocHome     Next     
iPlanet Application Server Developer's Guide (Java)



Chapter 4   Introducing Enterprise JavaBeans


This chapter describes how Enterprise JavaBeans (EJBs) work in the iPlanet Application Server application programming model. This chapter begins by defining an EJB's role and delivery mechanisms. Next it describes the two EJB types—entity and session beans—and gives details on when to use them. Finally, the chapter provides a design overview of an object-oriented iPlanet Application Server application using EJBs to encapsulate business logic.

This chapter contains the following sections:



What Enterprise JavaBeans Do

In an iPlanet Application Server, EJBs are the application workhorses. Servlets act as the application's central dispatchers and handle the presentation logic. EJBs do the bulk of the application's actual data and rules processing, but provide no presentation or visible user interface services. EJBs enable partitioning of business logic, rules, and objects into discrete, modular, and scalable units. Each EJB encapsulates one or more application tasks or objects, including data structures and operation methods. EJBs 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. The iPlanet Application Server software environment provides the EJB container. This container provides all standard container services denoted by the Sun EJB specification and also provides additional services specific to an iPlanet Application Server.

The container handles remote access, security, concurrency, transaction control, and database accesses. 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 bean developer can create generic, task focused EJBs to be used with any vendor's products that support the EJB standard.



What is an Enterprise JavaBean?


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

The fundamental EJB characteristics are as follows:

  • Bean creation and management is handled at runtime by the iPlanet Application Server provided container.

  • Client access mediation is handled by the container and the server where the bean is deployed, freeing the bean developer 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 deployable 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 bean recompiling.

  • A client's bean definition view 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.

  • EJBs can be dynamically reloaded while the iPlanet Application Server is running.

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 application development model that uses EJBs, and guarantees greater bean reuse. The client contract stipulates how an EJB object is identified, how its methods are invoked, and how it is created and destroyed.

The EJB container enables distributed application building using your own components and components from other suppliers. The iPlanet Application Server provides high level transaction, state management, multithreading, and resource pooling wrappers, thereby shielding you from having to know the low-level API details.

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 tools at design and deployment. At runtime, a client's bean access is container-controlled by the server where the EJB is deployed.

The EJB container is also responsible for ensuring that a client can invoke the specialized business methods the EJB defines. While a bean developer implements methods inside the bean, the developer must 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 for 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 to create a bean. In addition, some EJB types, known as entity beans, must also define finder methods for each way used 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, and is completely transparent to a client. There are several parts to the component contract for any given bean, as follows:

  • Life cycle: For EJB session beans, this includes the javax.ejb.SessionBean and javax.ejb.SessionSynchronization interface implementations. For EJB entity beans, this includes the javax.ejb.EntityBean interface implementation.

  • 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 of its EJBs.

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


Understanding JAR File Contracts

The standard format used to package an enterprise bean 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 the iPlanet Application Server you can create a .jar file containing EJBs using the iPlanet Application Server Deployment Tool. For more information, see the Deployment Tool Online Help.

The EJB-JAR file must contain the Deployment Descriptor (DD) as well as all class files for the following:

  • The enterprise bean class.

  • The enterprise bean home and remote interface.

  • The primary key class for an entity bean.

In addition, the EJB-JAR file must contain the class files for all classes and interfaces for the enterprise bean class, and the remote and home interfaces to use. For more information on the EJB-JAR file contents, see Chapter 10 "Deployment Packaging."



Session Beans and Entity Beans


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

The following sections describe the two bean types.


Understanding Session Beans

Session EJBs 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 the iPlanet Application Server failover support for stateful session beans.

A session bean implements business rules or logic. All functionality for remote access, security, concurrency, and transactions are provided by the EJB container. A session EJB is a private resource used only by the client that creates it. For example, you might create an EJB to simulate an electronic shopping cart. Each time a user logs in to an 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:

  • Data representation in the Enterprise Information System (EIS) resource, usually a database.

  • Bean managed transaction demarcation.

  • Container managed transaction demarcation.

  • Shared access for all users.

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

  • Transparently survives EJB server crashes.

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



EJB Role in an iPlanet Application Server Application


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

When a user invokes an iPlanet Application Server application servlet from a browser, the servlet invokes one or more EJBs to do the bulk of the application's business logic and data processing. For example, the servlet may load a JavaServer Page (JSP) to the user's browser to request a user name and password, then pass the user 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 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, 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 shopping cart data 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 the 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 challenge when creating an application that uses EJBs is determining how to break up an application into servlets, JSPs, session beans, and/or entity beans.



Designing an Object-Oriented Application


Partitioning an iPlanet Application Server application's business logic and data processing into the most effective set of EJBs is the bulk of your job as a developer. There are no hard and fast rules for object-oriented design with EJBs, other than that entity bean instances tend to be long lived, persistent, and shared among clients, while session bean instances tend to be short lived and used only by a single client. Therefore, the following sections are mostly high level iPlanet Application Server specific information to improve application speed, making EJBs modular, shareable, and maintainable.

With all object-oriented development, you must determine what granularity level you need for your business logic and data processing. Granularity level refers to how many pieces you break an application into. A high level of granularity—where you divide an application into many, smaller, more narrowly defined EJBs—creates an application that may promote greater EJB sharing and reuse 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 application performance degradation and more overhead. EJBs, like JavaBeans, are not simply Java objects. EJBs are higher level entities than Java objects. They are components with remote call interface semantics, security semantics, transaction semantics, and properties.



Planning Guidelines

In general, create an iPlanet Application Server application to balance the need for execution speed with the need for sharing EJBs among applications and clients, and deploying applications across servers:

  • Ask the server 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 the application runs.

  • Create stateless session beans instead of stateful session beans as much as possible. If you must create stateful session beans, have the server 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 is used in many applications.

In addition to these general considerations, decide which parts of an application are candidates for entity and session beans.


Using Session Beans

Session beans are intended to represent transient objects and processes, such as a single database record, a document copy 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 the conversational state. Session beans that maintain the conversational state are called stateful session beans; beans that do not are called stateless session beans.

When a client is done with the session objects, the objects are released. When designing an application, designate each temporary, single client object as a potential session bean. For example, in an online shopping application each shopping cart is a temporary object. The cart lasts only as long as the customer selects 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 can also provide transaction settings. These transaction settings and JDBC calls are referenced by the session bean's container, which is transparent. The container provided with the iPlanet Application Server 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 iPlanet Application Server application, see Chapter 5 "Using Session EJBs to Manage Business Rules."


Using Entity Beans

Entity beans commonly represent persistent data. This data is maintained directly in a database or accessed through an EIS application as an object. A simple example of an entity bean is one defined to represent a single row in a database table and where each bean instance represents a specific row. A more complex example is an entity bean designed to represent complicated views of joined tables in a database where each bean instance represents the contents of a single shopping cart.

Unlike session beans, entity bean instances are accessed simultaneously by multiple clients. The container is responsible for synchronizing the instance state by transactions in use. This responsibility delegation to the container means that the bean developer does not need to consider concurrent access methods from multiple transactions.

An entity bean's persistence can either be managed by the bean or the container. When an entity bean manages its own persistence, it's called Bean Managed Persistence. When the bean delegates this to the container, it's called Container Managed Persistence (CMP).

  • Bean Managed Persistence: the bean developer implements persistence code (such as JDBC calls) directly in the EJB class methods for bean managed persistence. The possible downside is portability loss, if a proprietary interface is used, and the risk of tying the bean to a specific database.

  • Container Managed Persistence: the container provider uses the Deployment Tool to implement the container persistence. The container transparently manages the persistence state. Therefore, you do not need to implement any data access code in the bean methods. Not only is this method simpler 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 iPlanet Application Server application, see Chapter 6 "Building Entity EJBs."


Planning for Failover Recovery

Failover recovery is a process in which a bean can reinstantiate itself after a server crash. Both stateless and stateful session beans support failover recovery. The Deployment Tool is used to set the failover properties for session beans; for a description of these settings see the Deployment Tool Online Help. 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. For more information, see "Using Finder Methods."


Working with Databases

In an iPlanet Application Server, the preferred method for working with databases is through the JDBC API in conjunction with transaction attributes. Use the Java Naming and Directory Interface (JNDI) to obtain a database connection. JNDI provides a standard way for applications 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 iPlanet Application Server 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

Deploy EJBs with the rest of an application using the Deployment Tool. For more information on how to deploy EJBs, see the Deployment Tool Online Help. For information on property settings made by the Deployment Tool and how they effect an application, see Chapter 10 "Deployment Packaging."


Dynamically Reloading EJBs

EJB reloading in an iPlanet Application Server is done without restarting the server by simply redeploying the EJB. The iPlanet Application Server notices the new component and reloads it within 10 seconds. For more information, see Appendix B "Dynamic Reloading."


Note This feature is turned off by default for a production environment. Turn it on when needed.



Previous     Contents     Index     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated June 14, 2001