1. Intercepting Filter:

Problem : Preprocessing and post-processing of a client Web request and response are required.When a request enters a Web application, it often must pass several entrance tests prior to the main processing stage. For example,

Has the client been authenticated?

Does the client have a valid session?

Is the client’s IP address from a trusted network?

Does the request path violate any constraints?

What encoding does the client use to send the data?

Do we support the browser type of the client? 

Forces Common processing, such as checking the data-encoding scheme or logging information about each request, completes per request.

Centralization of common logic is desired.

Services should be easy to add or remove unobtrusively without affecting existing components, so that they can be used in a variety of combinations, such as

Logging and authentication

Debugging and transformation of output for a specific client

Uncompressing and converting encoding scheme of input

Definition : Create pluggable filters to process common services in a standard manner without requiring changes to core request processing code. The filters intercept incoming requests and outgoing responses, allowing preprocessing and post-processing. We are able to add and remove these filters unobtrusively, without requiring changes to our existing code

2. Front Controller : Use a controller as the initial point of contact for handling a request. The controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies.

3. Composite View : Use composite views that are composed of multiple atomic subviews. Each component of the template may be included dynamically into the whole and the layout of the page may be managed independently of the content.

4. View Helper :

Problem : Presentation tier changes occur often and are difficult to develop and maintain when business data access logic and presentation formatting logic are interwoven. This makes the system less flexible, less reusable, and generally less resilient to change.

Intermingling the business and systems logic with the view processing reduces modularity and also provides a poor separation of roles among Web production and software development teams.

Forces :Business data assimilation requirements are nontrivial.

Embedding business logic in the view promotes a copy-and-paste type of reuse. This causes maintenance problems and bugs because a piece of logic is reused in the same or different view by simply duplicating it in the new location.

It is desirable to promote a clean separation of labor by having different individuals fulfill the roles of software developer and Web production team member.

One view is commonly used to respond to a particular business request.

Defintion : A view contains formatting code, delegating its processing responsibilities to its helper classes, implemented as JavaBeans or custom tags. Helpers also store the view’s intermediate data model and serve as business data adapters.

5. Dispatcher View : (Request Dispatcher)

Combine a controller and dispatcher with views and helpers to handle client requests and prepare a dynamic presentation as the response. Controllers do not delegate content retrieval to helpers, because these activities are deferred to the time of view processing. A dispatcher is responsible for view management and navigation and can be encapsulated either within a controller, a view, or a separate component.

How is it different from Service to Worker ?

While this pattern and the Dispatcher View pattern describe a similar structure, the two patterns suggest a different division of labor among the components. In Service to Worker, the controller and the dispatcher have more responsibilities.

Unlike the Service to Worker pattern, the Dispatcher View pattern suggests deferring content retrieval to the time of view processing

In the Service to Worker pattern, the dispatcher might be more sophisticated. The dispatcher may invoke a business service to determine the appropriate view to display.

6. Business Delegate :  Use a Business Delegate to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture

7. Session façade :

Why ?

- Tight coupling, which leads to direct dependence between clients and business objects;

- Too many method invocations between client and server, leading to network performance problems;

- Lack of a uniform client access strategy, exposing business objects to misuse.

Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to client

8. Service Locator

Use a Service Locator object to abstract all JNDI usage and to hide the complexities of initial context creation, EJB home object lookup, and EJB object re-creation. Multiple clients can reuse the Service Locator object to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility

9. Transfer Object

Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.

10. Value List Handler

Use a Value List Handler to control the search, cache the results, and provide the results to the client in a result set whose size and traversal meets the client’s requirements

11. Data Access Object

Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data.

When the underlying storage is subject to change from one implementation to another, this strategy may be implemented using the Abstract Factory pattern. The Abstract Factory can in turn build on and use the Factory Method implementation. In this case, this strategy provides an abstract DAO factory object (Abstract Factory) that can construct various types of concrete DAO factories, each factory supporting a different type of persistent storage implementation. Once you obtain the concrete DAO factory for a specific implementation, you use it to produce DAOs supported and implemented in that implementation.

12. Command Pattern

Encapsulate a request as an object, thereby letting you parameterize clients with different requests.

Action classes in Struts is an example of command pattern

13 Abstract Factory: (Creational)

Provide an interface for creating families of related or dependent objects (products) without specifying their concrete classes.

J2EE technology uses this pattern for the EJB Home interface, which creates new EJB objects.

It isolates concrete classes.
It makes exchanging product families easy.
It promotes consistency among products.
Supporting new kinds of products is difficult

14. Factory Method

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

J2EE technology uses this pattern for the EJB Home interface, which creates new EJB objects.

Eliminates the need to bind application-specific classes into your code.
Gives subclasses a hook for providing an extended version of an object being constructed.