: Creating Business Logic

Creating Business Logic

This chapter describes how to create Enterprise JavaBeans (EJBs). EJBs 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 Netscape Application Builder.

The following topics are described in this chapter:

About Enterprise JavaBeans

Creating Session EJBs

Creating Entity EJBs

Importing EJBs

Adding an EJB From Another Project

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 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 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 NAS makes uses of the NAS 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" on page 404. For an example, see "Task 11: Creating Enterprise JavaBeans" on page 221.

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 NAS makes use of the NAS 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" on page 406.

Importing EJBs

To import an EJB, perform the following steps:

Copy the JAR file to a directory under the NAS root.

Select Import EJB(s) from the Project menu.

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

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

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

Adding an EJB From Another Project

A single EJB can be used in multiple NAB projects. You might want to share an EJB for the following reasons:

To prevent overwriting of earlier copies of an EJB

If the bean came from an EJB JAR, you could just reimport from the EJB JAR into every project that is to use a given bean. But when the JAR is unpacked, the files will always go to the same place, relative to the NAS application root, overwriting earlier copies. If the EJB includes source files, and you have made any changes, they will be lost.

To make maintenance of the EJB easier

If the bean was created by a wizard, you could just rerun the wizard in every project, but then the EJB will have to have a different name in every project (unless the EJB's package is the project directory), and there will be a separate copy of its files in every project directory, which will be harder to maintain than a shared set of files.

Warning. If you share an EJB between projects, you must remember that changing the source file for an EJB within a project will cause changes in the projects with that share the EJB. Also, physically deleting an EJB from the file system while removing it from a project makes the files unavailable to other projects.

Typically, your EJB should be shared as a package name that locates the EJB outside of a particular project. Once an EJB has been created by a wizard or imported from into a project, you can add it to another NAB project, as follows:

Select Add File(s) from the Project menu.

Browse the ejb directory for a file of the form ejbNameVersion.ebx, where ejbName is a name, such as SB3, and Version is the version, which is 001 if there are no other EJBs with the same name. The following example shows browsing for a file called SB3001.ebx:

Double-click on the file or select it and choose Add to add the EJB to your file. The Project window with the new EJB shows the files that have been added:

The EJB files are added to the project's Enterprise JavaBeans folder. A new node is created for the bean files. Class files associated with the EJB do not exist until the bean is compiled; they are shown greyed-out in the Project window. After you compile an EJB, the Project window contains all the files:

Note. EJB class files appear in the folder that contains the EJB, not in the Compiled Files directory.

Examining and Changing EJB Properties

When you create an EJB, Netscape 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 files 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. See Chapter 10, "Using Wizards to Generate Project Files" for information for the data you specify in the Session and Entity EJB wizards. For general information about Enterprise JavaBeans and how you can use them in a NAS application, 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.

© Copyright 1999 Netscape Communications Corp.