The document discusses several design patterns for Java EE applications: - Model-View-Controller (MVC) separates an application into three main components - the model, the view, and the controller. - Intercepting Filter allows preprocessing and postprocessing of requests and responses without changing core processing code. Filters can add or remove services like security and logging. - Front Controller provides a centralized entry point to handle requests and coordinate other components like views. - View Helper moves business logic from views to separate helper classes to improve modularity.

1. J2EE Patterns
Solutions to Some Common
Problems

2. 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.
i.e Patterns = problems.solution pairs in a context

3. 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
• Analysis
• Creational
• Structural
• Behavioral

4. 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
stable.

5. 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.

6. 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.
• A Controller translates user actions (mouse motions,
keystrokes, words spoken, etc.) and user input into
application function calls on the model, and selects the
appropriate View based on user preferences and
Model state.

7. 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 processing code.
• The filters intercept incoming requests and outgoing
responses, allowing preprocessing and post-processing.
• Such filters can be added or removed unobtrusively,
without requiring changes to our existing code.

8. 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.
• Filters do not generally create a response or
respond to a request as servlets do , rather they
are used to modify the request or the response

9. 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.
• The FilterChain is an ordered collection of
independent filters.

10. 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>
• </filter-mapping>

11. Interceptor Filter Pattern

12. Filter: Sequence Diagram

13. 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.

14. 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.

15. 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.
• An application may use multiple controllers in a
system, each mapping to a set of distinct services.

16. Front Controller Pattern

17. Controller: Sequence Diagram

18. 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
and reduces modularity.

19. 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.
• The overriding goal is partitioning of business
logic outside of the view.

20. View Helper Pattern

21. View Helper: Sequence Diagram

22. 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.
• Additionally, business logic and presentation
formatting logic are intermingled within these
views, making the system less flexible, less
reusable, less resilient to change and reducing
modularity.

23. 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 view,
or a separate component.

24. 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 describes the combination of the
Front Controller and View Helper patterns with a
dispatcher component.

25. 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
• The dispatcher playing a moderate role is the
case where the client submits a request directly
to a controller with a query parameter that
describes an action to be completed:
• http://some.server.com/servlet/Controller?
action=login
• The dispatcher may access resources such as an
XML configuration file that specifies the
appropriate view to display.

26. Dispatcher View Pattern

27. Dispatcher View: Sequence Diagram

28. 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.
• Additionally, business logic and presentation
formatting logic are intermingled within thee
views, making the system less flexible, less
reusable, and less resilient to change.

29. 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.
• A dispatcher is responsible for view management
and navigation and can be encapsulated either
within a controller or a separate component.

30. 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 working
with a dispatcher, views, and helpers.

31. Service to Worker Pattern

32. Service to Worker: Sequence Diagram

33. 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.
• Exposing the service APIs directly to the client forces the client to
deal with the networking issues associated with the distributed
nature of Enterprise JavaBeans (EJB) technology.

34. 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.
• The Business Delegate hides underlying service,
handles the exceptions from the business services,
performs retry or recovery operations on failure.
• It can cache results and references to remote business
services improving the performance.

35. Business Delegate Pattern

36. Business Delegate: Sequence Diagram

37. Delegate: Sequence Diagram with ID

38. 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;
• 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.

39. 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.

40. 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.
• The Session Facade manages the interactions
between the business data and business service
objects participating in the workflow, and it
encapsulates the business logic associated with
the requirements.

41. 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.
• Some relationships between business objects are
transient, which means that the relationship is
applicable to only that interaction or scenario,
while other relationships may be more
permanent.

42. Session Facade Pattern

43. Session Facade: Sequence Diagram

44. 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.
• Since locating a JNDI-administered service object
is common to all clients that need to access that
service object, the JNDI code is duplicated.
• Also the JNDI code is dependent on the vendor
supplied context factory implementation.

45. 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.
• The pattern provides a mechanism to abstract all
dependencies and network details into the
Service Locator.

46. Service Locator Pattern

47. Service Locator: Sequence Diagram

48. 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.
• The model is a distributed collection of objects such as
DAO, session beans etc put together in a structured
manner.
• The client obtains the model by access individually
each distributed object that defines the model.

49. Transfer Object Assembler
• 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.

50. Transfer Object Assembler
• 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
• When a model is composed of a combination of many
components, the client must interact with numerous such
business components to obtain all the data necessary to
represent the model.
• Hence when model has multiple components, the clients
become tightly coupled to the model implementation and
make numerous remote method invocations to obtain data.

51. Transfer Object Assembler Pattern

52. Transfer Object Assembler: Sequence

53. 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 service
object is potentially remote.

54. 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.

55. 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.
• It reduces the number of remote calls and avoids
the associated overhead.
• Since the Transfer Object is passed by value to
the client, all calls to the Transfer Object instance
are local calls instead of remote method
invocations.

56. Transfer Object Pattern

57. Transfer Object: Sequence Diagram

58. Updater Transfer Object: Sequence

59. 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.
• Access mechanisms, supported APIs, and features
vary between different types of persistent stores.

60. 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 difficult and tedious to migrate the
application from one type of data source to another.
• When the data source changes, the components need
to be changed to handle the new type of data source.

61. 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

62. Data Access Object Pattern

63. Data Access Object: Sequence Diagram

64. STRUCTURAL DESIGN PATTERNS
Other Design Patterns

65. Decorator Pattern
• The Decorator Pattern is used for adding
additional functionality to a particular object as
opposed to a class of objects.
• A Decorator, also known as a Wrapper, is an object
that has an interface identical to an object that it
contains.
• Any calls that the decorator gets, it relays to the
object that it contains, and adds its own
functionality along the way, either before or after
the call.
• This gives you a lot of flexibility, since you can
change what the decorator does at runtime, as
opposed to having the change be static and
determined at compile time by sub classing.

66. Decorator Pattern
• A Decorator is a concrete instance of the abstract
class and is indistinguishable from the object that
it contains.
• This can be used to great advantage, as you can
recursively nest decorators without any other
objects being able to tell the difference, allowing
a near infinite amount of customization.
• Decorators add the ability to dynamically alter
the behavior of an object.
• Good idea to use in a situation to change the
behavior of an object repeatedly during runtime.
• It helps to add behavior or responsibilities to an
object.

67. Decorator Pattern

68. Command pattern
• A Command pattern is an object behavioral
pattern used to achieve complete decoupling
between the sender and the receiver.
• A sender is an object that invokes an operation,
and a receiver is an object that receives the
request to execute a certain operation.
• With decoupling, the sender has no knowledge of
the Receiver's interface.
• The term request here refers to the command
that is to be executed.
• The Command pattern allows to vary when and
how a request is fulfilled thus providing flexibility
as well as extensibility.

69. Command Pattern
• Intent:
• encapsulate a request in an object
• allows the parameterization of clients with different
requests
• allows saving the requests in a queue
• Implementation:
• The Client asks for a command to be executed.
• The Invoker takes the command, encapsulates it and
places it in a queue, in case there is something else to
do first, and the ConcreteCommand that is in charge of
the requested command, sending its result to the
Receiver.

70. Command Pattern

71. Factory Pattern
• Factory Method is a creational pattern which helps to
model an interface for creating an object which at creation
time can let its subclasses decide which class to instantiate.
• Factory Pattern is responsible for "Manufacturing" an
Object.
• It helps to instantiate the appropriate Subclass by creating
the right Object from a group of related classes.
• The Factory Pattern promotes loose coupling by eliminating
the need to bind application-specific classes into the code.
• The use of factories gives the programmer the opportunity
to abstract the specific attributes of an Object into specific
subclasses which create them.
• Define an interface for creating an object, but let the
subclasses decide which class to instantiate. The Factory
method lets a class defer instantiation to subclasses.

72. Factory Pattern

73. Singleton Pattern
• Singleton involves only one class which is
responsible to instantiate itself, to make sure it
creates not more than one instance; in the same
time it provides a global point of access to that
instance.
• The same instance can be used from everywhere,
being impossible to invoke directly the
constructor each time.
• Intent:
• Ensure that only one instance of a class is
created.
• Provide a global point of access to the object.

74. Singleton Pattern
• Implementation:
• It involves a static member in the "Singleton"
class, a private constructor and a static public
method that returns a reference to the static
member.
• The Singleton Pattern defines a getInstance
operation which exposes the unique instance
which is accessed by the clients.
• Constructor is not accessible from outside of the
class.

75. Singleton: Specific Implementation issues
• Thread-safe implementation: Singletons can be used
specifically in multi-threaded application to make sure
the reads/writes are synchronized.
• Lazy instantiation: Synchronization can be very
expensive considering the performance. When the
singleton object is already created it should be
returned without using any synchronized block.
• Such optimization consist of checking in an
unsynchronized block if the object is null and if not to
check again and create it in an syncronized block. This
is called double locking mechanism.

76. Singleton: Specific Implementation issues
• Early instantiation using static field: The singleton object is
instantiated when the class is loaded and not when it is first
used, due to the fact that the instance member is declared
static.
• Classes loaded by different classloaders: If a class(same
name, same package) is loaded by 2 different classloaders
they represents 2 different clasess in memory.
• Serialization: If Singleton class implements
java.io.Serializable interface, when a singleton is serialized
and then deserialized more than once, there will be
multiple instances of Singleton created. It can be avoided
by implementing the readResolve method.
• Abstract Factory and Factory Methods implemented as
singletons: Having 2 factories might have undesired effects
when objects are created. Hence, to ensure that a factory is
unique it should be implemented as a singleton, thus
avoiding to instantiate the class before using it.

77. Singleton Pattern