As part of the analytical process, we must discern the types of objects or components that will be used in the application. There are a number of common object types that have been identified based on their usage, and as it happens, these object types relate directly to J2EE components. These object types are as follows.
Not all object definitions will fit clearly into one of these categories. In fact, it makes very good sense to create helper objects or convenience objects to facilitate development. But the top-level domain objects, which we referred to earlier, should each fall into one of these categories. The following sections explain these object types in more detail.
An entity object is an object that encapsulates business knowledge within the system. These objects are responsible for ensuring that the business logic of the organization is applied correctly in the system. Entity objects really represent a category of objects that perform a range of functions, including applying business logic and managing data retrieval operations. Java design patterns provide additional guidance on how to design these components.
The entity object within a J2EE system is generally represented by an EJB running within the application server. In some cases, a JavaBean component may be used to encapsulate this functionality.
A boundary object represents an interface of some type, either a system interface or a user interface. This is a component that is responsible for interacting with the user and relaying user input back to the entity objects (the business tier components) through control objects.
In J2EE architectures, these objects are represented by presentation tier components, servlets, or JSP pages. They could also be represented by client tier components such as applets or Java Webstart components.
Control objects are responsible for workflow, managing the progression of work and application navigation through the system. These objects marshal the resources of the entity and boundary objects of the system. They do not execute business logic per se, as that is the responsibility of the entity objects.
In J2EE architecture, these objects are most commonly represented using EJBs, specifically the EJB session bean. But workflow may also be managed to some extent on the presentation tier using servlets, where these web tier control objects would interact with JavaBeans and Java helper classes to execute workflow logic.
Lifecycle objects encapsulate the logic of finding, instantiating, and later destroying the object resources used by the control objects. These objects effectively isolate this logic and enhance maintainability by locating this activity in a small set of objects. Lifecycle objects can also be used to ensure that proper housekeeping is being done and that resources are being freed when they are no longer needed. In J2EE, these objects are most likely to be Java helper objects used by the control objects to marshal the resources needed to perform their work.
The sequence diagram in Figure 323 provides an example of these objects to a portion of a system. The shoppingUI object represents a boundary object. This object interacts with the user and initiates the shopping process. The shoppingUI calls the shoppingAccess object to create the various objects needed to begin the shopping process. Once the initiateShopping call to the shoppingAccess object has completed, the shoppingUI will then interact with the shoppingControl object; the shoppingAccess object, as a lifecycle object, is responsible for simply finding, creating, and deleting objects.
Figure 3-23 Shopping cart sequence diagram.
The shoppingAccess object will return a reference to the shoppingControl object, a control object. This object controls the access to the various objects needed to use the shopping cart. In this example, most of that work is performed through the Cart object, an entity object that provides access to the shopping cart. The Cart object in turn manages access internally to the Order, Catalog and CheckOut objects.
Java design patterns expand on many of these concepts and provide additional guidance on how to design objects for Java applications. These design patterns have been applied directly to the J2EE architecture and are presented in detail in Chapter 32. At this point it is suffice to say that the principals we have outlined here are not invalidated by Java design patterns, but are instead supported and expanded.