Overview

When building IT systems, the functionality required of the application must be specified and the business objects within the domain must be identified.

In “traditional” client/server systems, the application's functionality can be implemented in the front-end application or perhaps using database stored procedures, and the domain objects are usually tables within an RDBMS. In building an EJB-based system, the application's functionality corresponds to Session beans, and the domain objects correspond to Entity beans.

You learned yesterday that Session beans take on the responsibility of implementing the application's business functionality. There will still be a presentation layer to display the state of those Session beans, but its detail is unimportant in the larger scheme of things.

In the same way, Entity beans take on the responsibility of representing the domain data. There will still a persistent data store to manage the data, almost certainly an RDBMS, but the Entity beans abstract out and hide the detail of the persistence mechanism.

The N-tier Architecture Revisited

On the very first day, you were introduced to n-tier architectures, with the business logic residing in its own tier. With an EJB-based system, both Session and Entity beans are objects, so the business logic could reside in either of them. In practice, the business logic will be split over both, but to make the correct decision, it is worthwhile analyzing what is meant by that phrase “business logic.”

Business logic refers to the collection of rules, constraints, procedures and practices put in place by the business users to conduct their business. Some of the rules and constraints cannot be changed by the business, due to the domain in which the business is performed. For example, there could be legal constraints and obligations. The procedures and practices represent the (one particular) way in which business users have chosen to conduct business.

Rules and constraints generally apply across all applications. In other words, it doesn't matter what the business is trying to accomplish, they will still need to comply with such rules and constraints. This sort of business logic is best implemented through Entity beans, because Entity beans are domain objects that can be reused in many different applications.

In the business world, procedures and practices are usually the expression of some sort of application, so Session beans are the best vehicle to implement this type of business logic. Indeed, introducing computerized systems often changes these procedures and practices (hopefully for the better, sometimes for the worse) because computers make available new ways of accomplishing tasks.

• Session beans should have the business logic of a specific application—in other words, application logic. The functionality provided should allow the user to accomplish some goal.

• Entity beans represent domain objects and should have business logic that is applicable for all applications—in other words, domain logic. Usually, this logic will be expressed in terms of rules and constraints.

If there is any doubt as to where the functionality should be placed, it is safer to place it with the Session bean. It can always be moved later if it is found to be truly re-usable across applications.

Figure 6.1 shows a UML component diagram to illustrate that there are at least four logical layers in an EJB-based system. Normally, at least some of these layers will be on the same physical tier.

Comparison with RDBMS Technology

It's natural to compare Entity beans with relational databases, because there is a significant overlap in the objectives of both technologies.

If you like to think in client/server terms, you could think of Session beans as being an extension of the “client”, and Entity beans as being an extension of the “server”. It's important to realize that many clients can share a given Entity bean instance at the same time, just as many database clients can read some row from a database table at the same time.

You can also think of Entity beans as a high-performance data cache. Most RDBMS' store data pages or blocks in a cache so that the most commonly used rows in tables can be read directly from memory rather than from disk. Although the EJB specification does not require it, many EJB containers adopt a strategy such that Entity beans are also cached, so the data that they represent can also be read directly from memory. The advantage of the Entity bean cache over an RDBMS' data cache is that the Entity beans already have semantic meaning and can be used directly. In contrast, data read from an RDBMS' data cache needs to be reconstituted in some way before it can be used.

Identifying Entities

At their simplest, Entity beans can correspond to nothing more complex than a row in a database; any data that might reasonably be expected to exist in a relational database table is a candidate. This makes examples of Entity beans easy to come by:

• A Customer Entity bean would correspond to a row in a customer table keyed by customer_num. The list of contact phone numbers for that Customer (in a customer_phone_number detail table keyed on (customer_num, phone_num)) would also be part of the Customer Entity bean.

• An Invoice Entity bean might correspond to data in the order and order_detail tables.

• An Employee Entity bean could be persisted in an employee table. The employee's salary history might also be part of the Entity bean.

Identifying entities can be made easier if a proper discipline is adopted with relational modeling of the database. Of course, many databases just evolve over time as developers add tables to support new requirements. Ideally, though, there should be a logical database model and a physical database model. The former is usually captured as an Entity relationship diagram (ERD) with entities, attributes, and relationships. Relational database theory defines a process called normalization and different normal forms that aim to eliminate data redundancy. It is this stage at which the normalization rules are applied, to get to third normal form (at least).

Converting a logical database model to a physical model is in many ways mechanical. Every entity becomes a table, every attribute becomes a column, and every relationship is expressed through a foreign key column in the “child” table.

These entities identified in logical data modeling are the very same concepts that should be expressed as Entity beans. Moreover, one of the key “deliverables” from performing relational analysis is the selection of the primary key—the attribute or attributes that uniquely identify an instance. Entity beans also require a primary key to be defined, and this is manifested either as an existing class (such as java.lang.String or java.lang.Integer) or a custom-written class for those cases where the key is composite.

The name often given to such primary key classes is something like BeanPK, although it can be anything. You can think of the primary key as some object that identifies the bean.

Nevertheless, there are some differences between relational entities and Entity beans. Whereas relational modeling requires that the data is normalized, object modeling places no such constraints. Indeed, not even first normal form (where every attribute is scalar) needs to be honored. For example, a Customer Entity bean might have a vector attribute called phoneNumbers, with a corresponding accessor method getPhoneNumbers() that returns a java.util.List. In a physical data model, there would need to be a separate table to hold these phone numbers.

Even with a solid logical data model to guide you, selecting Entity beans is not necessarily straightforward. In particular, choosing the granularity of the entities can be problematic. With the customer example given earlier, the customer_phone table doesn't really seem significant enough to be an Entity. It's just the way in which vector attributes have to be modeled in relational databases. But what of the invoices? After all, invoices are sent to customers, and any given invoice relates only to the orders placed by a single customer. So perhaps invoices should be considered as just vector attributes of customers, with a getInvoices() accessor method? On the other hand, many modelers would argue that the concept of Invoice is significant enough in itself—with its own state, behavior, and lifecycle—to warrant being represented as its own Entity bean.

Specifying the interfaces should help you decide which is the correct approach. If the invoice entity really is significant, you will find that the customer's interface will be bloated with lots of invoice-related methods. At this point, you can tease the two entity objects apart.