Sun Java Center - J2EE Patterns

Print-friendly Version

A recent focus group of architects and designers raised a major concern: there seems to be a lack of understanding on how to apply patterns in combination to form larger solutions. We address this problem in two ways:

• High-level visual of the patterns and their relationships. This is called the J2EE Pattern Relationship diagram.
• Low -level visual of the pattern relationships showing the relationships between the pattern roles. We call this the J2EE Pattern Framework diagram.

While individual patterns offer their context, problem, and solution to address a particular need, it is important to understand the big picture to put the patterns to their best use. Virtually every pattern in the catalog has a relationship to other patterns. Understanding and knowing these relationships when you design and architect a solution helps in the following ways:

• Enables you to consider what other new problems may be introduced when you consider applying a pattern to solve your problem.
• Enables you to visit the pattern relationships to determine alternate solutions. Perhaps the new problems can be addressed by selecting a different pattern or by using another pattern in combination with the one you have already chosen.

The following diagram shows the relationships between the patterns.

Figure: Pattern Relationships

Decorating Filter intercepts incoming requests and outgoing responses and applies a filter. These filters may be added and removed in a declarative manner, allowing them to be applied unobtrusively in a variety of combinations. After this pre-processing and/or post-processing is complete, the final filter in the group vectors control to the original target object. For an incoming request, this is often a Front Controller, but may be a View.

Front Controller is a container to hold the common processing logic that occurs within the presentation tier and that may otherwise be erroneously placed in a View. A Front Controller handles requests and manages content retrieval, security, view management, and navigation, delegating to a Dispatcher component to dispatch to a View.

View Helper encourages the separation of formatting-related code from other business logic. It suggests using Helper components to encapsulate logic relating to initiating content retrieval, validation, and adapting and formatting the model. The View component is then left to encapsulate the presentation formatting. Helper components typically delegate to the Business Services via a Business Delegate, while a View may be composed of multiple sub-components to create its template.

Composite View suggests composing a View from numerous atomic pieces. Multiple smaller views, both static and dynamic, are pieced together to create a single template.

Business Delegate reduces coupling between tiers and provides an entry point for accessing the services that are provided by another tier. The Delegate may also provide results caching for common requests to improve performance. A Business Delegate typically uses a Service Locator to locate service objects, such as an EJB Home object and JMS Connection factory.

The Service to Worker and Dispatcher View patterns represent a common combination of other patterns from the catalog. The two patterns share a common structure, consisting of a FrontController working with Dispatchers, Views, and Helpers. The Service to Worker and the Dispatcher View patterns are identical with respect to the components involved, but differ in the division of labor among those components. Unlike the Service to Worker pattern, the Dispatcher View pattern suggests deferring content retrieval and error handling to the time of View Processing. Also, the Dispatcher View pattern suggests the Dispatcher plays a more limited role in View Management, as the choice of View is typically already included in the request.

The Service Locator provides lookup and lifecycle services to clients, typicaly the Business Delegates. The Service Locator hides the implementation details of the lookup service and the complexity of the lookup process from the clients. It provides a uniform central point for all lookups in the application.

The Session Façade provides coarse-grained services to the clients by hiding the complexities of the business object interactions. The Session Façade may use the Service Locator pattern to locate services. The Session façade may also use other patterns to provide its services: Value Object, Value Object Assembler, Value List Handler, Service Activator, and Data Access Object.

The Value Object pattern provides best techniques and strategies to exchange data across tiers (that is, across system boundaries). This pattern attempts to reduce the network overhead by minimizing the number of network calls to get data from the business tier.

The Value Object Assembler constructs a composite value object from various sources. These sources could be EJB components, data access objects, or other arbitrary Java objects. This pattern is most useful when the client needs to obtain data for the application model or part of the model.

The Value List Handler uses the GoF iterator pattern to provide query execution and processing services. The Value List Handler may also cache the results and return subsets of the result to the clients as requested. By using this pattern, it is possible to avoid overheads associated with finding large numbers of entity beans.

The Aggregate Entity pattern offers best practice to design a coarse-grained entity bean. It shows how to aggregate objects into a tree with a root (independent) object that manages its dependent objects. This pattern is most suitable for entity beans that use container managed persistence.

The Service Activator pattern enables asynchronous processing for enterprise bean components. (The EJB 2.0 specification defines a new message bean that provides similar functionality.) However, this pattern benefits applications that have a need for asynchronous processing with enterprise bean components.

The Data Access Object pattern provides loose coupling between the business and resource tiers. The Data Access Object intercepts and services all access to the resource tier, making the implementation details of the resource tiers transparent to the clients. The data in the resource tier can reside in database systems, proprietary systems, other external systems and services. By using this pattern, you can build applications that are more flexible and portable.

J2EE Patterns Framework

The diagram below shows each J2EE pattern and the connection between the roles of each pattern so that you understand how the patterns connect together to form a framework. The dotted and solid lines between patterns indicate relationship dependencies. Note that the dotted lines show optional dependencies, while the solid lines indicate required dependencies.

The J2EE Patterns framework diagram shows the relationships between fine grained elements of each patterns. We have represented such relationships using an UML diagram using assosications and dependencies in an attempt to help you to understand the implications of choosing one or more of these patterns. We believe that this diagram also helps the developer in choosing the proper combination of patterns when designing an end-to-end (presentation-business-integration) solution using the J2EE patterns.

Relationship to Known Patterns

There is a wealth of software pattern documentation available today. The patterns in these different books are at various levels of abstraction. There are architecture patterns, design patterns, analysis patterns, and programming patterns. The most popular and influential of these books is "Design Patterns: Elements of Reusable Object-Oriented Software", often referred to as the "Gang of Four", or GoF book. The patterns in the GoF book describe expert solutions for object design.

Our pattern catalog includes patterns that describe the structure of an application, and others that describe design elements.

The unifying theme of the pattern catalog is its support of the J2EE platform. In some cases, the patterns in the catalog are based on or related to an existing pattern in the literature. In these cases, we have attempted to communicate this relationship by referencing the existing pattern in the name of the J2EE pattern and/or including a reference and citation in the "Related Patterns" section at the end of each pattern description. For example, some patterns are based on GoF patterns that are considered in a J2EE context. In those cases, the J2EE pattern name includes the GoF pattern name in addition to including the relationship to the GoF pattern in the related patterns section.

(c) 2000-2001 Sun Microsystems, Inc. All Rights Reserved.

Version 1.0 Beta