Applying J2EE-Specific Patterns

Now that you understand the rationale and intent of patterns, how can you apply them to your J2EE applications? To do this, you must understand the J2EE design context, and you must also become familiar with the patterns themselves.

Applying Patterns in a Context

Most of the patterns defined for the J2EE platform range between the design and architecture levels. The most common J2EE architecture is largely assumed—a 3-tier business system—as the context for these patterns. You may be able to apply individual patterns in different styles of architecture, but as a pattern language, the current J2EE patterns are squarely targeted at a 3-tier, Web-based business system. The 3 tiers are usually classified as the presentation or Web tier, the middle or business tier, and the integration or data tier.

As well as consisting of multiple tiers, the target architecture is roughly based on the Model-View-Controller (MVC) principle. MVC is a form of pattern that can be applied at several levels. At the GUI level, it splits the responsibilities for interacting with the user between a data model, a presentation-oriented view, and a controller to govern the interaction. At the architectural level, this translates into entity EJBs (and various other components) providing a data model, servlets and JSPs providing the view, and Session EJBs providing the controller or business logic. Separating concerns in this way delivers a lot of flexibility. An example of this is that the model and controller (the data and the business logic) can be combined with a variety of views to expose the same functionality to different clients. This is shown in Figure 18.1.

Given this context, and given that an overall application style is in place, why do you need more patterns? Well, the purpose of applying patterns within an n-tier application generally relates to the systemic qualities of the application. Systemic qualities, sometimes called non-functional requirements, refer to qualities such as maintainability, extensibility, scalability, availability, and so on. By applying the patterns outlined today, you should be able to improve at least one of these systemic qualities in your application, if not several. When the case study is examined later, the impact on systemic qualities of the patterns applied is also considered.

If you are designing an application from scratch, it will be second nature to think of applying patterns to the design process. However, many times you will be working within a pre-defined architecture or with an existing application. This does not mean that patterns no longer apply. It is quite possible to apply patterns to existing applications to improve them. It may be that the original design was not well thought out, or that it used the technologies in a naïve way (quite common when technologies are new). A pattern can be retro-fitted to part of the application to improve the systemic qualities of the application and to generally clean it up. This process is called refactoring, and is a key element in many software processes. As part of examining the case study, several potential refactorings will be considered.

The last thing that you need before examining the case study is knowledge of the patterns themselves.

Generic Patterns

Table 18.1 lists some common, generic patterns that are documented in the GoF book.

Table 18.1. Common GoF Patterns

Pattern Name	Pattern Description
Proxy	Provide a surrogate for another object or component to control access to it or enable access to it
Decorator	Add a variable level of functionality dynamically with the ability to plug in or remove components or filters as required (sometimes also known as wrapper or pipes and filters)
Singleton	Provide a single instance of a component and a global point of access to it
Iterator	Provide sequential access to a collection of objects in a way that is independent of the underlying representation
Observer	Define a relationship between components so that a change in the state of one of them causes a notification of this change to be delivered to the others
Façade	Provide a unified interface for a subsystem, thereby hiding underlying complexity
Command	Encapsulate a request with its data so that it can be presented and executed as a whole, without having to specify many different processing methods

J2EE Presentation-Tier Patterns

Table 18.2 lists patterns that have been identified around the presentation (or Web) tier of an n-tier J2EE application. The origin of each pattern is denoted using initials—SJC (Sun Java Center), BLU (Sun J2EE Blueprints), TSS (TheServerSide.com).

Table 18.2. Common J2EE Presentation-Tier Patterns

Pattern Name	Pattern Description
Front Controller (SJC)	A servlet (or JSP) intercepts the request from the user and routes or “adds value” to the request.
Intercepting Filter (SJC)	Provide a Decorator-style (GoF) filter chain as part of a Front Controller.
View Helper (SJC)	Use a JavaBean or custom JSP tag to encapsulate functionality and separate Java functionality out of a JSP.
Composite View (SJC)	Compose a JSP from several different sub-components to provide a typical, multi-panel Web page view.
Dispatcher View (SJC)	A Front Controller (SJC) intercepts and routes (or dispatches) a request to a JSP (or view). The view or its View Helpers (SJC) retrieve the content and/or data required to populate the view.
Service to Worker (SJC)	A Front Controller intercepts and routes (or dispatches) a request to a JSP (or view). The Front Controller (SJC) (or its helpers) retrieves the content and/or data required and passes this to the view as JavaBeans.
Service Locator (SJC)	A client-side shared helper object caches frequently used EJB home interfaces and dispenses EJB remote references on request.

J2EE Business-Tier Patterns

Table 18.3 lists patterns that have been identified around the business (or middle) tier of an n-tier J2EE application. The origin of each pattern is denoted using initials—SJC (Sun Java Center), BLU (Sun J2EE Blueprints), TSS (TheServerSide.com).

Table 18.3. Common J2EE Business-Tier Patterns

Pattern Name	Pattern Description
Session Facade (SJC)	A Session EJB provides a Facade (GoF) to shield entity EJBs from direct client access and to obscure the data schema from the client.
Business Delegate (SJC)	A client-side object hides EJB-specific (or JMS-specific) interaction and exposes local business-oriented methods.
Value Object (SJC)	Provide a snapshot of underlying data to be used as a convenient data parcel between client and server to avoid chattiness (excessive network traffic between client and server).
Value Object Builder (SJC)	A constructor of Value Objects (SJC) from disparate server-side data sources. It presents one Value Object-based interface for a set of varied business data.
Composite Entity (SJC)	Create a coarse-grained business entity from a set of fine-grained data objects, such as entity EJBs or DAOs.
Value List Handler (SJC)	Have a session EJB act as a data cache and provide single/multiple data element Iterator (GoF) capability.
Page-by-page Iterator (BLU)	A variant of Value List Handler (SJC).
Fast Lane Reader (BLU)	Retrieve data for reading directly from the database for speed, write data back via entity EJBs for transactions and consistency.

J2EE Integration-Tier Patterns

Table 18.4 lists patterns that have been identified around the integration (or data) tier of an n-tier J2EE application. The origin of each pattern is denoted using initials—SJC (Sun Java Center), BLU (Sun J2EE Blueprints), TSS (TheServerSide.com).

Table 18.4. Common J2EE Integration-Tier Patterns

Pattern Name	Pattern Description
Data Access Object (SJC)	Encapsulate data access behind a common interface that can be implemented in different ways for different data sources. Typically used for data access in servlets and Session EJBs to encapsulate direct database access.
Service Activator (SJC)	Allow an EJB to be called on receipt of an asynchronous message.
EJB Observer (TSS)	An Observer-based (GoF) event pattern providing a strategy using EJBs.

Patterns Within J2EE

As noted previously, certain patterns occur within the J2EE environment itself, including the following:

• The Proxy pattern (GoF) is used widely in J2EE. Examples include RMI stubs as client-side proxies and EJB objects as server-side proxies.

• An EJB home interface acts as a Singleton (GoF) for the creation of EJB instances.

• The servlet filters provided as part of J2EE 1.3 are a form of the Intercepting Filter pattern (SJC).

There are many other patterns that are applied within the Java and J2EE environments.