Guidelines: Designing Subsystems for J2EE Applications
Topics
Introduction
These guidelines supplement Guidelines: 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 Guidelines: Enterprise
Java Beans.
Note also that an Application Client is considered to be a specialized Design
Subsystem. See Guidelines: 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 (activity:
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 Concepts:
Mapping from Design to Code for a discussion of these options.) The corresponding
design use-case realizations 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 Guidelines:
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 Guidelines:
Interfaces for J2EE Applications. For more information on modeling EJBs,
see Guidelines: Enterprise JavaBeans.
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 Guidelines:
Enterprise JavaBeans. 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 Guidelines:
Enterprise JavaBeans for more information on DAO classes.

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