2.2 Business Entities and Processes, and Enterprise Bean Types

As already noted, EJB applications organize the application's business rules into components. Each component typically represents a business entity or a business process. Some EJB components implement business entities, whereas others implement business processes.

2.2.1 Business Entities

A business entity is a business object representing some information maintained by an enterprise. A business entity has state, or data values, and this state is kept persistently, typically in a database. Business processes can change the state of a business entity. However, the business entity and its state exist independently of the business processes that change the entity state.

For example, you might have a business entity, such as Customer, that represents your customer data and the business rules associated with the data. You might also have an Order entity that encapsulates customer order data with its associated business rules. Other examples of business entities are Account, Employee, and so forth.

Each business entity maintains state about itself. For example, the Customer entity keeps the customer's shipping and billing address as part of its state. The business rules associated with a business entity constrain the values of the entity state. For example, a business rule may dictate that the ZIP code field in the customer billing address field must be a valid five- or nine-digit ZIP code. It is desirable to enforce this business rule when changes are attempted to the ZIP code field, regardless of the business process that makes the changes to the ZIP code.

Often, relationships are defined between business entities. For example, the Customer entity and the Order entities have a one-to-many association relationship. The business rules for the entities involved in a relationship include the maintenance of the relationship. The rules for the maintenance of relationships involve deciding under what conditions one entity becomes associated with another entity, what conditions may change that association, and how the deletion of one entity impacts associated entities. For example, the designer of an application needs to ask such questions as, Does an Order have to be associated with a Customer? If a Customer is deleted, should all Orders associated with the Customer be deleted as well?

2.2.2 Business Processes

A business process is a business object that typically encapsulates an interaction of a user with business entities. A business process typically updates or changes the state of the business entities. A business process may also have its own state. If a business process has its own state, the state exists only for the duration of the business process; when the business process completes, the state ceases to exist.

Although some business processes require that the state of a business process be persistent, the state of other business processes may be transient. Persistent state is usually required when a business process has multiple steps, each possibly performed by different actors. A business process with multiple actors is called a collaborative business process. This need for multiple steps performed by multiple actors may occur, for example, when processing a loan application or an expense report.

Transient state is usually sufficient if one actor in one conversation can complete the business process. In this book, we refer to a business process with one actor as a conversational business process: One actor engages in a conversation with the system. (An actor can be a user or another program.) A good example of a conversational business process is an individual withdrawing money at an automated teller machine (ATM) or an employee enrolling into a company's benefits program.

Other examples of business processes are such actions as fulfilling an order, promoting an employee, scheduling a meeting among multiple participants, closing a bank account, processing a loan application, electing members to the board of directors, scheduling a payment via an online banking application, and so forth. Most business-to-customer Web applications can be considered business processes. These processes are typically conversational business processes.

2.2.3 Business Rules

After identifying the business entities and the business processes, the application architect needs to formulate the business rules. The business rules are organized according to the components that implement the business entities and processes.

The business rules that apply to the state of a business entity should be implemented in the component that represents the business entity. The idea is to keep rules that pertain to an entity's state independent of any business process that acts on the business entity. Certainly, the business rules should be independent of the component representing the business process. For example, the business rule that an account balance must not be allowed to become negative should be implemented in the component that represents the Account entity, because this rule is independent of the business processes that cause the account balance to change.

Likewise, the business rules that apply to a specific business process should be implemented in the component that represents the business process. For example, the business rule that the dollar amount of an ATM withdrawal transaction must be a multiple of $20 should be implemented in the component that implements the ATM withdrawal business process, not in the Account entity.

2.2.4 Enterprise Bean Types

In EJB applications, the business entities and processes are implemented as enterprise beans. The EJB architecture defines three types of enterprise beans: session beans, entity beans, and message-driven beans. Session beans may be stateful or stateless. Entity beans may manage their state themselves bean-managed persistence or let the container do it for them container-managed persistence. Message-driven beans are always stateless: Their life cycle is similar to that of stateless session beans.

The syntax of the session bean and that of the entity bean client-view API are almost identical. However, the two enterprise bean types have different life cycles and different persistence management and provide different programming styles to their clients. Message-driven beans do not have a client-view API; instead, clients communicate asynchronously with message-driven beans in a message-oriented manner. In general, a developer must know the type of the enterprise bean when writing a client application. However, in the case of message-driven beans, the bean's existence is hidden behind the message destination to which the client sends messages.

Stateless Bean Types: Message-Driven Beans and Stateless Session Beans

Message-driven beans and stateless session beans are stateless, which means they retain no client state between method invocations. As a result, stateless beans are typically used to model business processes rather than business entities. Because they are stateless, these bean types are lightweight and provide a high degree of scalability. In addition, because they retain no client state, stateless session beans and message-driven beans can be used across multiple clients.

Stateful Bean Types: Differentiating Session Beans and Entity Beans

To understand whether a business process or business entity should be implemented as a stateful session bean or an entity bean, it is important to understand the life-cycle and programming differences between them. These differences pertain principally to object sharing, object state, transactions, and container failure and object recovery. (See Table 2.1.)

Object sharing pertains to entity objects. Only a single client can use a stateful session bean, but multiple clients can share an entity object among themselves.

The container typically maintains a stateful session bean's object state in main memory, even across transactions, although the container may swap that state to secondary storage when deactivating the session bean.

The object state of an entity bean is typically maintained in a database, although the container may cache the state in memory during a transaction or even across transactions. Other, possibly non-EJB-based, programs can access the state of an entity object that is externalized in the database. For example, a program can run an SQL query directly against the database storing the state of entity objects. In contrast, the state of a stateful session object is accessible only to the session object itself and the container.

The state of an entity object typically changes from within a transaction. Because its state changes transactionally, the container can recover the state of an entity bean should the transaction fail. The container does not maintain the state of a session object transactionally. However, the bean developer may instruct the container to notify the stateful session objects of the transaction boundaries and transaction outcome. These notifications allow the session bean developer to synchronize manually the session object's state with the transactions. For example, the stateful session bean object that caches changed data in its instance variables may use the notification to write the cached data to a database before the transaction manager commits the transaction.

Session objects are not recoverable; that is, they are not guaranteed to survive a container failure and restart. If a client has held a reference to a session object, that reference becomes invalid after a container failure. (Some containers implement session beans as recoverable objects, but this is not an EJB specification requirement.) An entity object, on the other hand, survives a failure and restart of its container. If a client holds a reference to the entity object prior to the container failure, the client can continue to use this reference after the container restarts.

Table 2.1 depicts the significant differences in the life cycles of a stateful session bean and an entity bean.

Table 2.1. Entity Beans and Stateful Session Beans: Life-Cycle Differences

Functional Area	Stateful Session Bean	Entity Bean
Object state	Maintained by the container in main memory across transactions. Swapped to secondary storage when deactivated.	Maintained in database or other resource manager. Typically cached in memory in a transaction.
Object sharing	A session object can be used by only one client.	An entity object can be shared by multiple clients. A client may pass an object reference to another client.
State externalization	The container internally maintains the session object's state. The state is inaccessible to other programs.	The entity object's state is typically stored in a database. Other programs, such as an SQL query, can access the state in the database.
Transactions	The state of a session object can be synchronized with a transaction but is not recoverable.	The state of an entity object is typically changed transactionally and is recoverable.
Failure recovery	A session object is not guaranteed to survive failure and restart of its container.[a] The references to session objects held by a client become invalid after the failure.	An entity object survives the failure and the restart of its container. A client can continue using the references to the entity objects after the container restarts.

^[a] Some containers may implement session objects as recoverable objects, but this is not required by the EJB specification.

Choosing Entity Beans or Stateful Session Beans

The architect of the application chooses how to map the business entities and processes to enterprise beans. No prescriptive rules dictate whether to use a stateful session bean or an entity bean for a component: Different designers may map business entities and processes to enterprise beans differently.

You can also combine the use of session beans and entity beans to accomplish a business task. For example, you may have a session bean represent an ATM withdrawal that invokes an entity bean to represent the account.

The following guidelines outline the recommended mapping of business entities and processes to entity and session beans. The guidelines reflect the life-cycle differences between the session and entity objects.

• A bean developer typically implements a business entity as an entity bean.

• A bean developer typically implements a conversational business process as a stateful session bean. For example, developers implement the logic of most Web application sessions as session beans.

• A bean developer typically implements as an entity bean a collaborative business process: a business process with multiple actors. The entity object's state represents the intermediate steps of a business process that consists of multiple steps. For example, an entity object's state may record the changing information state on a loan application as it moves through the steps of the loan-approval process. The object's state may record that the account representative entered the information on the loan application, the loan officer reviewed the application, and application approval is still waiting on a credit report.

• If it is necessary for any reason to save the intermediate state of a business process in a database, a bean developer implements the business process as an entity bean. Often, the saved state itself can be considered a business entity. For example, many e-commerce Web applications use the concept of a shopping cart, which stores the items that the customer has selected but not yet checked out. The state of the shopping cart can be considered to be the state of the customer shopping business process. If it is desirable that the shopping process span extended time periods and multiple Web sessions, the bean developer should implement the shopping cart as an entity bean. In contrast, if the shopping process is limited to a single Web session, the bean developer can implement the shopping cart as a stateful session bean.

2.2.5 Message-Driven Beans

Message-driven beans are asynchronously invoked enterprise beans. Message-driven beans are designed for integrating EJB applications with message-oriented enterprise applications.

Message-driven beans do not have a client-view API; that is, they do not define home or component interfaces. Clients access message-driven beans by sending them messages.

Unlike session or entity beans, message-driven beans do not have business methods. Message-driven beans define a message listener method, which the EJB container invokes to deliver messages. Furthermore, message-driven beans also do not hold any state between invocations of the message listener method. Their life cycle is very similar to that of stateless session beans.

Message-driven beans are generally used to implement business processes rather than business entities. Designers should consider implementing a business process as a message-driven bean if that process needs to execute as a result of an external application sending a message. Message-driven beans thus allow a loosely coupled form of integration with other enterprise applications. (Chapter 6 explores message-driven beans in depth.)