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 a database. In building an EJB-based system, the application's functionality corresponds to Session beans, and the business objects correspond to Entity beans.

You saw 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 business domain data. There will still be a persistent data store to manage the data, almost certainly a database, but the Entity beans abstract out and hide the details of the persistence mechanism.

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

Rules and constraints of business logic generally apply across all applications. In other words, it doesn't matter what the business logic is trying to accomplish; it 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 business 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 form of EJB to implement this type of business logic.

In other words:

• Session beans should have the business logic specific to an application—application logic. The functionality provided should allow the user to accomplish some goal.

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

If there is any doubt as to where the functionality should be placed, it is safer to place it within a 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.

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 the same row from a database table at the same time.

At its simplest, an Entity bean can correspond to nothing more complex than a single row in a database table. But Entity beans may also represent more complex business objects, with data potentially stored in more than one row or table in the database. For example:

• A Customer Entity bean could correspond to a row in a customer table keyed by customer_num. The list of contact phone numbers for that Customer (in acustomer_phone_number detail table keyed on (customer_num, phone_num)) may 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.

The entities identified in data modeling are the very same concepts that should be expressed as Entity beans. Entity beans require that a primary key be defined; a primary key cannot be a primitive but can be any serializable java object. 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.

Even with a solid data model to guide you, selecting Entity beans is not necessarily straightforward. In particular, choosing the granularity of the entities can be problematic. Specifying the interfaces for the Entity beans should help you decide the correct entity model. If an Entity bean interface becomes bloated with lots of methods you should study the purpose of each method and group related methods together. You may find that your single entity is actually two or more separate entities. Conversely, if you have a lot of entities with a couple of methods in each interface, you may find you can amalgamate the small entities in a single business entity.

Once you have identified your entities, creating them as J2EE Entity beans is slightly more complex than creating the Session beans you studied yesterday because you need to supply more information; specifically you have to describe the persistent data.