Chapter 7   Creating Business Logic


This chapter describes how to create Enterprise JavaBeans (EJBs), which determine the bulk of your application's actual data and rules processing.

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.

Note that you should consider creating your project's EJBs with an external IDE and import them into iPlanet Application Builder.

The following topics are described in this chapter:

• About Enterprise JavaBeans

• Creating Session EJBs

• Creating Entity EJBs

• Importing EJBs

• Examining and Changing EJB Properties

About Enterprise JavaBeans

---

The Enterprise JavaBeans architecture is a component-based model for development and deployment of object-oriented, distributed, enterprise-wide applications. An Enterprise JavaBean (EJB) is a single element in such 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 platform that supports EJBs.

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

The fundamental characteristics of EJBs are as follows:

• Creation and management of beans is handled at runtime by a container.

• Customization of beans is handled at deployment time by editing the beans' environment properties.

• Manipulation of metadata, such as transaction mode and security attributes, are separated from the enterprise Bean class, and handled instead by the container's tools at design and deployment time. Note that you actually manipulate the bean that runs in the container, and not the container. One of the key features of an EJB is that you can specify transaction management, isolation level, and security models on a per-bean basis. However, you can also define these features at deployment and runtimes.

• 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 can be deployed in any EJB-compliant container.

• Extending a bean to use specific container features prevents a bean from being deployed in other containers that do not support those features. It is possible to develop an EJB that can determine its environment and run appropriately.

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

Types of EJBs

There are two kinds of EJBs: session and entity. Each of these bean types has different uses in a server application. An EJB can be an object that represents

• a stateless service

• a session with a particular client, which automatically maintains state across multiple client-invoked methods

• a persistent entity shared among multiple clients.

Session EJBs

A session bean typically:

• Executes on a single client.

• Handles transaction management according to property settings, which includes custom transaction management.

• Updates shared data in an underlying database.

• Provides only indirect access to databases.

• Is relatively short lived.

• Is destroyed if the EJB server terminates.

A session bean implements its own business logic. All functionality for remote access, security, concurrency, and transactions is implemented 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 validate user database logins. Each time a user logs into your database, the application creates the session bean to validate the login. Once the login is validated or rejected, the session bean is freed.

Entity EJBs

An entity EJB typically:

• Represents data in the database.

• Is transactional.

• Allows shared access for any number of users.

• Can exist as long as its data in a database.

• Is persistent and exists when the EJB server is restarted.

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.

An EJB encapsulates a business object, such as a database connection. 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.

Creating Session EJBs

---

Session beans are intended to represent temporary objects, 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 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 session bean's container, which is transparent to you as the developer. The container provided with iAS makes uses of the iAS Database Access Engine (DAE) to handle the JDBC calls and result sets.

For information about using the Session EJB wizard to create an EJB, see Using the Session Bean Wizard.

Creating Entity EJBs

---

Entity beans are intended to represent persistent objects, such as rows in a database, documents, and specific business objects that may be accessed by multiple clients. When you design an application designate each database, document and 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 iAS makes use of the iAS Database Access Engine (DAE) to handle 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 data sources without requiring you to handle the details.

While an entity bean may represent the database 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 information about using the Entity EJB wizard to create an EJB, see Using the Entity Bean Wizard.

Importing EJBs

---

To import an EJB, perform the following steps:

1. Copy the JAR file to a directory under the iAS root.

2. Select Import EJB(s) from the Project menu.

3. Select the JAR file, either by navigating or by entering the file name, and click Add.

The iPlanet Application Builder unpacks the JAR file and places the files it contains into the appropriate project folders. The JAR file itself is not modified not is it imported into the project.

You can use the Add File(s) menu item in the Project menu to bring non-EJB JAR files into a project. These files are placed in the project's Miscellaneous Files folder.

Examining and Changing EJB Properties

---

When you create an EJB, iPlanet Application Builder creates a .properties file for it. This file contains meta-information for all other files in the EJB. You can double-click on this file's icon in the Project window to open a Properties editor that allows you to view and change this information.

EJB properties are displayed in four panels:

• General attributes

• Control descriptors

• Environment

• Access control

Many of these properties are set when you create the EJB using a wizard. For information for the data you specify in the Session and Entity EJB wizards, see , "Using Wizards to Generate Project Files". For information about Enterprise JavaBeans and how you can create XML files using the iPlanet Application Server, see the Programmer's Guide.

The general attributes panel contains information about the class names and the kind of bean.

The control descriptors panel contains information about the transaction attribute, isolation level, and run mode. You can change these descriptors if you want. You can also add or delete methods that override those defined in the bean.

The environment panel contains a list of keys and their values. You can modify them if you want.

The access control panel specifies the default access control and allows you to specify access for specific methods.