CORE J2EE PATTERNS

WHAT ARE PATTERNS?

Patterns are about communicating problems and solutions

Recurring problems within a context expert solutions Patterns originated as a field of study in
brick and mortar architecture as a result of the work done by Christopher Alexander.

He has numerous books on patterns, but only became aware of the software industry’s interest in
his work in the last decade.
JEE or J2EE Design Patterns

J2EE design patterns are built for the developing the Enterprise Web-based Applications.

In J2EE , there are mainly three types of design patterns, which are further divided into
their sub-parts:

[Link] Layer Design Pattern

[Link] Layer Design Pattern

3. Integration Layer Design Pattern

JEE or J2EE Design Patterns
A). Presentation Layer Design Pattern

▪ Intercepting Filter Pattern

▪ Front Controller Pattern
▪ View Helper Pattern
▪ Composite View Pattern

B). Business Layer Design Pattern

▪ Business Delegate Pattern

▪ Service Locator Pattern
▪ Session Facade Pattern
▪ Transfer Object Pattern

C). Integration Layer Design Pattern

▪ Data Access Object Pattern
▪ Web Service Broker Pattern
Presentation Layer Design Pattern
• The presentation-tier request handling mechanism receives many different types of
requests, which require varied types of processing.

• Some requests are simply forwarded to the appropriate handler component, while other
requests must be modified, audited, or compressed before being further processed.

• One of the best example for Intercepting Filter Pattern is Spring

Security's DelegatingFilterProxy , which will intercept the HTTP request and do the
authentication check.
Problem
(Problem section describes the design issues faced by the developer)

Pre-processing and post-processing of a client Web request and response(HTTP) 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? Some of these checks are tests, resulting in a yes
or no answer that determines whether processing will continue. Other checks manipulate the
incoming data stream into a form suitable for processing. You want to intercept and manipulate
a request and a response before and after the request is processed.
 Forces
(This section describes Lists the reasons and motivations that affect the problem and the
solution. The list of forces highlights the reasons why one might choose to use the pattern
(CORE J2EE PATTERN) and provides a justification for using the pattern)

• You want centralized, common processing across requests, such as checking the data-
encoding scheme of each request, logging information about each request, or compressing
an outgoing response.

• You want pre and postprocessing components loosely coupled with core request-
handling services to facilitate unobtrusive addition and removal.

• You want pre and postprocessing components independent of each other and self
contained to facilitate reuse.
Solution

(Here solution section describes the solution approach briefly and the solution elements
in detail)

• Use an Intercepting Filter as a pluggable filter to pre and postprocess requests and
responses.

• A filter manager combines loosely coupled filters in a chain, delegating control to the
appropriate filter.

• In this way, you can add, remove, and combine these filters in various ways without
changing existing code.
Participants

• Filter(HANDLER) - Filter which will performs certain task prior or after execution of request

by request handler.
• Filter Chain - Filter Chain carries multiple filters and help to execute them in defined order

on target.
• Target - Target object is the request handler
• Filter Manager - Filter Manager manages the filters and Filter Chain.

• Client - Client is the object who sends request to the Target object.
Class Diagram
Sequence Diagram
Applicability

Use the Intercepting Filter pattern when

•A system uses pre-processing or post-processing requests

•A system should do the authentication/ authorization/ logging or tracking of request and then pass
the requests to corresponding handlers

•You want a modular approach to configuring pre-processing and post-processing schemes

 DESIGN PATTERN - FRONT CONTROLLER PATTERN
❑ The front controller design pattern is used to provide a centralized request handling mechanism so
that all requests will be handled by a single handler.
❑ This handler can do the authentication/ authorization/ logging or tracking of request and then pass
the requests to corresponding handlers.
❑ The front controller design pattern is a centralized entry point for handling requests.

Following are the entities of this type of design pattern.

•Front Controller - Single handler for all kinds of requests coming to the application (either web based/
desktop based).
•Dispatcher - Front Controller may use a dispatcher object which can dispatch the request to
corresponding specific handler.
•View - Views are the object for which the requests are made.
Helper : A helper is responsible for helping a view or controller complete its
processing. Thus, helpers have numerous responsibilities, including gathering
data required by the view and storing this intermediate model, in which case
the helper is sometimes referred to as a value bean.

Problem
(Problem section describes the design issues faced by the developer)

❑ You want a centralized access point for presentation-tier request handling.

Forces
(This section describes Lists the reasons and motivations that affect the problem and the solution. The
list of forces highlights the reasons why one might choose to use the pattern and provides a
justification for using the pattern)

•You want to avoid duplicate control logic.

•You want to apply common logic to multiple requests.
•You want to separate system processing logic from the view.
•You want to centralize controlled access points into your system.
Solution
(Here solution section describes the solution approach briefly and the solution elements in detail)

❑ Use a Front Controller as the initial point of contact for handling all related requests. The
Front Controller centralizes control logic that might otherwise be duplicated and
manages the key request handling activities.
Class Diagram
(Problem section describes the design issues faced by the developer)
Sequence Diagram
Participants and Responsibilities

• Front Controller - The Front Controller is the initial contact point for handling requests in
the system. It delegates to an Application Controller to perform action and view
management.

• Application Controller - An Application Controller is responsible for action and view

management, including locating and routing to the specific actions that will service a
request, and finding and dispatching to the appropriate view.

• Command - A Command performs the action that handles the request.

• View - A View represents the display returned to the client.

Consequences

•Centralizes control
•Improves manageability
•Improves reusability
•Improves role separation
 Applicability

Use the Front Controller pattern when

•you want to encapsulate common request handling functionality in single place.
•you want to implement dynamic request handling i.e. change routing without modifying the
code.
•make web server configuration portable, you only need to register the handler web server
specific way.
BUSINESS LAYER DESIGN PATTERN
Business Delegate Pattern
In business tier we have following entities.

•Client - Presentation tier code may be JSP, servlet or UI java code.

•Business Delegate - A single entry point class for client entities to provide access to Business
Service methods.
•LookUp Service - Lookup service object is responsible to get relative business implementation
and provide business object access to business delegate object.
•Business Service - Business Service interface. Concrete classes implement this business service to
provide actual business implementation logic.
Problem
• You want to hide clients from the complexity of remote communication with business
service components.

Forces
❖ You want to access the business-tier components from your presentation-tier components
and clients, such as devices, web services, and rich clients.
❖ You want to minimize coupling between clients and the business services, thus hiding the
underlying implementation details of the service, such as lookup and access.
❖ You want to avoid unnecessary invocation of remote services.
❖ You want to translate network exceptions into application or user exceptions.
❖ You want to hide the details of service creation, reconfiguration, and invocation retries
from the clients.

Solution
❖ Use a Business Delegate to encapsulate access to a business service. The Business
Delegate hides the implementation details of the business service, such as lookup and access
mechanisms.
Class Diagram-jms (java msg service)
and (EJB-Enterprise java beans)
Sequence Diagram
Consequences
❖ Reduces coupling, improves maintainability
❖ Translates business service exceptions
❖ Improves availability
❖ Exposes a simpler, uniform interface to the business tier
❖ Improves performance
❖ Introduces an additional layer
❖ Hides remoteness
SERVICE LOCATOR
Problem
❖ You want to transparently locate(how to locate services) business components and services in a
uniform manner.
Forces
❖ You want to use the JNDI API(Java Naming and Directory Interface) to look up and use
business components, such as enterprise beans and JMS components, and services such as data
sources.
❖ You want to centralize and reuse the implementation of lookup mechanisms for J2EE application
clients.
❖ You want to encapsulate vendor dependencies for registry implementations(provide storage
instance), and hide the dependency and complexity from the clients.
❖ You want to avoid performance overhead related to initial context creation and service lookups.
❖ You want to reestablish a connection to a previously accessed enterprise bean instance, using its
Handle object.
Solution
❖ Use a Service Locator to implement and encapsulate service and component lookup. A Service
Locator hides the implementation details of the lookup mechanism and encapsulates related
dependencies.
Class Diagram
Sequence Diagram
Consequences
❖ Abstracts complexity
❖ Provides uniform service access to clients
❖ Facilitates adding EJB business components
❖ Improves network performance
❖ Improves client performance by caching
Integration Layer Design Pattern
Data Access Object
Problem
❖ You want to encapsulate data access and manipulation in a separate layer.

Forces
❖ You want to implement data access mechanisms to access and manipulate data in a persistent
storage.
❖ You want to decouple the persistent storage implementation from the rest of your application.
❖ You want to provide a uniform data access API for a persistent mechanism to various types of
data sources, such as RDBMS, LDAP(lightweight directory accesss), OODB, XML
repositories, flat files, and so on.
❖ You want to organize data access logic and encapsulate proprietary features to facilitate
maintainability and portability.

Solution
❖ Use a Data Access Object to abstract and encapsulate all access to the persistent store. The Data
Access Object manages the connection with the data source to obtain and store data.
• Data sources provides connections to your relational
database.

• An SQL result set is a set of rows from a database.

Class Diagram
Sequence Diagram
WEB SERVICE BROKER
Problem

❖ You want to provide access to one or more services using XML and web protocols.

Forces
❖ You want to reuse and expose existing services to clients.
❖ You want to monitor and potentially limit the usage of exposed services, based on your
business requirements and system resource usage.
❖ Your services must be exposed using open standards to enable integration of heterogeneous
applications.
❖ You want to bridge the gap between business requirements and existing service
capabilities

Solution
❖ Use a Web Service Broker to expose and broker one or more services using XML and
web protocols.
Class Diagram
Sequence Diagram
Consequences

❖ Introduces a layer between client and service

❖ Existing remote Session Façades (341) need be refactored to support local
access
❖ Network performance may be impacted due to web protocols