Introduction

These guidelines supplement Guideline: Design Subsystem with guidance specific to J2EE application development. We recommend you read Guidelines: Design Subsystem prior to reading these J2EE-specific guidelines. These guidelines apply to design subsystems of larger granularity than individual EJBs. For guidelines on EJBs, refer to Guideline: Enterprise JavaBean (EJB).

Note also that an Application Client is considered to be a specialized Design Subsystem. See Guideline: J2EE Application Client.

Evolving Design Subsystems

When a subsystem is first identified, it may initially be technology neutral. That is, it may be specified by interfaces, a textual description, and some state machines that describe the expected behavior of the operations. However, such technology-neutral subsystems are typically evolved to technology-specific representations.

The following gives an example of how a technology-neutral design subsystem is evolved to a technology-specific subsystem.

Subsystem specification (Black-box view of the subsystem)

A subsystem specification can initially be modeled as having abstract UML interfaces.

Consider the preliminary design of a Customer subsystem, shown in Figure 1. 

Figure 1: Preliminary Design-Customer Subsystem

ICustomerMgt is further defined to have operations, such as "getCustomerDetails" and "setCustomerDetails".

As the design becomes more detailed (Task: Subsystem Design), these abstract interfaces are replaced by language and technology specific elements. (You can choose to maintain the more abstract model of the subsystem; for example, if there's a need to implement the same design in more than one language or technology. See Concept: Mapping from Design to Code for a discussion of these options.) The corresponding design Artifact: Use-Case Realization are updated to match the interface changes.

In this example, Figure 2 is a black-box or specification view of the Customer subsystem. Subsequent design indicated that the Customer subsystem should be an entity EJB. The preliminary design subsystem is transformed into EJB interfaces as follows:

• ICustomerMgt =>
  • CustomerHome ?EJBEntityHomeInterface?
• ICustomer =>
  • Customer ?EJBRemoteInterface?

Figure 2: Black-box View of the Customer Design Subsystem

The interfaces exposed by Design Subsystems might include regular Java interfaces, EJB interfaces (such as Java Interfaces), EJB interfaces (remote and home), or even one or more delegate or access classes that hide the existence of one or more EJBs entirely. Note that all of these, including Java interfaces, are modeled as UML classes and not UML interfaces (see Guideline: Interfaces for J2EE Applications). For example, a session bean is often used as a facade for accessing a set of closely related entity beans. In this case, only the session bean's interfaces would be exported from the subsystem.

Message-driven beans consume messages asynchronously from a destination (or endpoint). Therefore, a destination could also serve as an "interface" for a Design Subsystem that contains message-driven beans.

Note that since local interfaces are used by other closely-coupled EJBs within the same Design Subsystem and, they appear in the realization of subsystems more often than in the visible interfaces exposed by a subsystem.

For more information on interfaces in a J2EE application, see Guideline: Interfaces for J2EE Applications. For more information on modeling EJBs, see Guideline: Enterprise JavaBean (EJB).

Subsystem realization (White-box view of the subsystem)

Design Subsystems should expose only what clients require. Therefore, the class that implements an EJB is private to the subsystem, and is logically part of the subsystem realization. The subsystem realization could become:

• a set of collaborating EJBs and classes, hidden by a one or more visible delegate or access classes
• a single EJB with no other collaborating classes

Continuing the previous Customer subsystem example, the realization of the subsystem includes:

• CustomerEntityEJB (component) ?EJBEntityBean?
• CustomerBean ?EJBImplementation?
• additional helper classes

Figure 3 shows a white-box view (that is, within the subsystem) of the Design Subsystem. Note that the EJB classes are modeled as described in Guideline: Enterprise JavaBean (EJB). This internal view of the subsystem is referred to as the subsystem realization. In this view, we see decisions not visible to clients. For example, in this realization of the subsystem a Data Access Object (DAO) class accesses persistent data using the JDBC API. (In another design, container-managed persistence might have been used.) See Guideline: Enterprise JavaBean (EJB) for more information on DAO classes.

Figure 3: White-box View of the Customer Design Subsystem