Introduction to j2 ee patterns online training class

www.quontrasolutions.com info@quontrasolutions.com
info@quontrasolutions.com
Introduction to J2EE Patterns Online Training Classes

Design Patterns
•
A pattern is a proven solution to a problem in
a context.
•
Christopher Alexander says each pattern is a
three-part rule which expresses a relation
between a certain context, a problem, and a
solution.
•
Design patterns represent a solutions to
problems that arise when developing software
within a particular context.

Categorizing Pattern
Patterns, then, represent expert solutions to
recurring problems in a context and thus have
been captured at many levels of abstraction
and in numerous domains. Numerous
categories are:
•
Design
•
Architectural

MVC Design Pattern
•
Name (essence of the pattern)
– Model View Controller MVC
•
Context (where does this problem occur)
– MVC is an architectural pattern that is used when developing
interactive application such as a shopping cart on the Internet.
•
Problem (definition of the reoccurring difficulty)
– User interfaces change often, especially on the internet where look-
and-feel is a competitive issue. Also, the same information is
presented in different ways. The core business logic and data is

MVC Pattern
•
Solution (how do you solve the problem)
– Use the software engineering principle of “separation of concerns” to divide
the application into three areas:
•
Model encapsulates the core data and functionality
•
View encapsulates the presentation of the data there
can be many views of the common data
•
Controller accepts input from the user and makes
request from the model for the data to produce a
new view.

MVC Architecture
•
The Model represents the structure of the
data in the application, as well as application-
specific operations on those data.
•
A View (of which there may be many)
presents data in some form to a user, in the
context of some application function.

Intercepting Filter
•
Context: The presentation-tier request
handling mechanism receives many different
types of requests, which require varied types
of processing before forwarding to handler.
•
Problem: Preprocessing and post-processing
of a client Web request and response are
required.
•
Solution: Create pluggable filters to process
common services in a standard manner
without requiring changes to core request
info@quontrasolutions.co.uk

Intercepting Filter
•
Used for common services such as security,
logging, debugging etc.
•
These filters are components that are
independent of the main application code.
•
Filters allow on the fly transformations of
payload and header of both the request into a
resource and the response from a resource.

Writing a Filter
•
Implement the javax.servlet.Filter interface
•
Container will call the doFilter() method.
•
The doFilter method will modify the request or
response and then call the next filter in the
filter chain.
•
The FilterManager manages filter processing. It
creates the FilterChain with the appropriate
filters, in the correct order, and initiates
processing.

Filter Configuration
•
Configuring filter in the deployment descriptor
( web.xml )
•
<filter>
•
<filter-name>Image Filter</filter-name>
•
<filter-class>com.acme.ImageFilter</filter-
class>
•
</filter>
•
<filter-mapping>
•
<filter-name>Image Filter</filter-name>
•
<url-pattern>/*</url-pattern>

Interceptor Filter Pattern

Filter: Sequence Diagram
info@quontrasolutions.co.uk

Front Controller
•
Context: The presentation-tier request
handling mechanism must control and
coordinate processing of each user across
multiple requests, in either a centralized or
decentralized manner.
•
Problem: The system requires a centralized
access point for presentation-tier request
handling to support the integration of system
services, content retrieval, view management,
and navigation.

Front Controller
•
Solution: 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.

Front Controller
•
The controller provides a centralized entry
point that controls and manages Web request
handling.
•
Helps to reduce the code in form of scriptlets
in JSP page and promotes code reuse across
requests.
•
The Controller coordinates with a dispatcher
component for view management and
navigation.

Front Controller Pattern

Controller: Sequence Diagram

View Helper
•
Context: The system creates presentation
content, which requires processing of dynamic
business data.
•
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
www.quontrasolutions.co.uk info@quontrasolutions.co.uk

View Helper
•
Solution: 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.
•
Encapsulating business logic in a helper
instead of a view makes our application more
modular and facilitates component reuse.

View Helper Pattern

View Helper: Sequence Diagram

Dispatcher View
•
Context: System controls flow of execution and
access to presentation processing, which is
responsible for generating dynamic content.
•
Problem: There is no centralized component
for managing access control, content retrieval
or view management, and there is duplicate
control code scattered throughout various
views.

Dispatcher View
•
Solution: 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

Dispatcher View
•
Dispatcher pattern and the Service to Worker
pattern describe a similar structure.
•
Unlike the Service to Worker pattern, the
Dispatcher View pattern suggests deferring
content retrieval to the time of view
processing.
•
In the Dispatcher View pattern, the dispatcher
typically plays a limited to moderate role in
view management.

Dispatcher View
•
A limited role for the dispatcher occurs when
no outside resources are utilized in order to
choose the view. For example:
•
http://some.server.com/servlet/Controller?
next=login.jsp

Dispatcher View Pattern

Dispatcher View: Sequence
Diagram

Service to Worker
•
Context: The system controls flow of
execution and access to business data, from
which it creates presentation content.
•
Problem: There is no centralized component
for managing access control, content retrieval,
or view management, and there is duplicate
control code scattered throughout various
views.

Service to Worker
•
Solution: Combine a controller and dispatcher
with views and helpers to handle client
requests and prepare a dynamic presentation
as the response.
•
Controllers delegate content retrieval to
helpers, which manage the population of the
intermediate model for the view.

Service to Worker
•
In the Service to Worker pattern, the
dispatcher typically plays a moderate to large
role in view management.
•
In Service to Worker pattern, the dispatcher
can be more sophisticated and may invoke a
business service to determine the appropriate
view to display.
•
The shared structure of Service to Worker and
Dispatcher View consists of a controller

Service to Worker Pattern

Service to Worker: Sequence
Diagram

Business Delegate
•
Context: A multi-tiered, distributed system requires remote
method invocations to send and receive data across tiers. Clients
are exposed to the complexity of dealing with distributed
components.
•
Problem: Presentation-tier components interact directly with
business services, exposing the underlying implementation details
of the business service API to the presentation tier.
•
The presentation-tier components are vulnerable to changes in
implementation of the business services.
•
There is a detrimental impact on network performance because
presentation-tier components using the business service API make
too many invocations over the network, with no client-side caching
mechanism or aggregating service.

Business Delegate
•
Solution: 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.
•
Business Delegate reduces the coupling
between presentation-tier clients and the
system's business services, and other tiers.

Business Delegate Pattern

Business Delegate: Sequence Diagram

Delegate: Sequence Diagram with ID

Session Facade
•
Context: Enterprise beans encapsulate
business logic and business data and expose
their interfaces, and thus the complexity of
the distributed services, to the client tier.
•
Problem:
•
Tight coupling, which leads to direct
dependence between clients and business
objects;

Session Facade: The Problem
•
The client must represent and implement the
complex interactions regarding business
object lookups and creations.
•
The client grows larger and more complex to
fulfill increasing requirements.
•
The client becomes very susceptible to
changes in the business object layer;
•
The client is unnecessarily exposed to the
underlying complexity of the system.

Session Facade
•
Solution: 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 clients.

Session Facade
•
The session bean (representing the Session
Facade) manages the relationships between
business objects.
•
The session bean also manages the life cycle
of these participants by creating, locating
(looking up), modifying, and deleting them as
required by the workflow.

Session Facade Pattern

Session Facade: Sequence Diagram

Service Locator
•
Context: Service lookup and creation involves
complex interfaces and network operations.
•
Problem: The J2EE clients must either locate
the service component or create a new
component in order to interact with the
service components such as EJB and JMS.
•
The JNDI API enables clients to obtain an
initial context object that holds the
component name to object bindings and is
valid for the client session.

Service Locator
•
Solution: 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.

Service Locator Pattern

Service Locator: Sequence Diagram

Transfer Object Assembler
•
Context: The server-side business
components are implemented using session
beans, entity beans, DAOs etc.
•
Application clients frequently need to access
data that is composed from multiple objects.
•
Problem: Application clients typically require
the data for the model or parts of the model
to present to the user or to use for an
intermediate processing step before providing
some service.

•
A tight coupling between the client and the
distributed components of the model over the
network.
•
Client accesses the numerous distributed
components degrading the perfroamnce.
•
The client must reconstruct the model after
obtaining the model's parts from the
distributed components.
•
Changes to the model require changes to the
client as client tightly coupled to the model.

•
Solution: Use a Transfer Object Assembler to
build the required model or sub-model.
•
The Transfer Object Assembler uses Transfer
Objects to retrieve data from various business
objects and other objects that define the
model or part of the model.
•
Transfer Object Assembler constructs a
immutable composite Transfer Object that
represents data from different business
components for the model

Transfer Object Assembler Pattern

Transfer Object Assembler: Sequence

Transfer Object
•
Context: Application clients need to exchange
data with enterprise beans.
•
Problem: Some methods exposed by the
business components return data to the
client.
•
The client invokes a business object's get
methods multiple times until it obtains all the
attribute values.
•
Every method call made to the business

Transfer Object: Problem
•
In EJB application such remote invocations use
the network layer regardless of the proximity
of the client to the bean, creating a network
overhead.
•
As the usage of the remote methods
increases, application performance can
significantly degrade.
•
Therefore, using multiple calls to get methods
that return single attribute values is inefficient
for obtaining data values from an enterprise
bean.

Transfer Object
•
Solution: 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.

Transfer Object: Sequence
Diagram

Updater Transfer Object: Sequence

Data Access Object
•
Context: Access to data varies depending on
the source of the data.
•
Access to persistent storage, such as
database, varies depending on type of storage
and the vendor implementation.
•
Problem: Persistent storage is implemented
with different mechanisms, with marked
differences in the APIs to access the different
persistent storage mechanisms.

Data Access Object: Problem
•
Applications that need to access data from a
legacy or disparate system are often required
to use APIs that may be proprietary, creating a
direct dependency between application code
and data access code.
•
Including the connectivity and data access
code within these components introduces a
tight coupling between the components and
the data source implementation making it

Data Access Object
•
Solution: 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.
•
The DAO completely hides the data source
implementation details from its clients.
•
The DAO adapts to different storage schemes
without affecting its clients or business
components

Data Access Object Pattern

Data Access Object: Sequence Diagram

www.quontrasolutions.com
For More Details Contact us
Quontra Solutions
Visit: http://Www.quontrasolutions.com
Email: info@quontrasoluitons.com
Call us: (404) 900 - 9988

Introduction to j2 ee patterns online training class

More Related Content

Similar to Introduction to j2 ee patterns online training class (20)

More from QUONTRASOLUTIONS (20)

Recently uploaded (20)

Introduction to j2 ee patterns online training class