J2EE Pattern Relationships J2EE

A recent focus group of architects and designers raised a major concern: There seems to be a lack of understanding of how to apply patterns in combination to form larger solutions. We address this problem with a high-level visual of the patterns and their relationships. This diagram is called the J2EE Pattern Relationships Diagram and is shown in Figure.

Individual patterns offer their context, problem, and solution when addressing a particular need. However, it is important to step back and grasp the big picture to put the patterns to their best use. This grasping the big picture results in better application of the patterns in a J2EE application.

Reiterating Christopher Alexander's quote, a pattern does not exist in isolation and needs the support of other patterns to bring meaning and usefulness. Virtually every pattern in the catalog has a relationship to other patterns. Understanding these relationships when designing and architecting 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. This is the domino effect: What new problems are introduced when a particular pattern is introduced into the architecture? It is critical to identify these conflicts before coding begins.
  • Enables you to revisit the pattern relationships to determine alternate solutions. After possible problems are identified, revisit the pattern relationships and collect 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.

intercepting 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 preprocessing 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 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 subcomponents 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 controller working with a Dispatcher, 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 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 the 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 Composite Entity pattern groups parent-dependent objects into a coarse grained entity bean. It shows how to aggregate objects into a tree with a parent object that manages its dependent objects.

The Service Activator pattern enables asynchronous processing for enterprise bean components. The EJB specification version 2.0 defines a new type of enterprise bean called message-driven bean that provides similar functionality. However, this pattern can be leveraged by all EJB 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 for enterprise beans that use bean-managed persistence. 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.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

J2EE Topics