J2EE Design Pattern

Classification : Confidential

- Aliyan Zubedi.


Agenda

• J2EE Design Patterns

– Introduction to Design Patterns – MVC Design Pattern– Presentation Tier Design Patterns– Business Tier Design Patterns– Integration Tier Design Patterns


Introduction to Design Patterns

• Design patterns are usually the result of years of experience, collaboration and refinement. Design patterns generally arise through solving problems. Over time the best techniques to solve each problem are discovered and refined. We will identify, examine and attempt to classify a number of the problems commonly encountered by Developers / programmers.

• Patterns are usually obvious to experienced programmers. More difficult is the task of describing these patterns in a way that makes them accessible and understandable to less experienced developers.


Introduction to Design Patterns• According to Christopher Alexander: • "Each pattern describes a problem which occurs over

and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"

• So a design pattern is a formal description of a problem and its solution. Design patterns must have a simple, descriptive name that can be readily used when referring to the pattern. A pattern should document the problem, its solution and the consequences of using it.


Introduction to Design Patterns• Design patterns can be used to assist us in solving

related problems. If we can learn to recognize the existence of known patterns in new problems we can apply the same techniques to solve them.

• The importance of design patterns is that they formally document problems and their solutions. This gives us a means to recognize and refer to known problems. We also have a means for comparing alternative solutions with full awareness of the consequences of each alternative.


Model–view–controller (MVC)

• MVC is an architechtural pattern used in software engineering. Successful use of the pattern isolates business logic from user interface considerations, resulting in an application where it is easier to modify either the visual appearance of the application or the underlying business rules without affecting the other. In MVC



• Model - The model represents enterprise data and the business rules that govern access to and updates of this data.

• View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes.



Controller - The controller translates interactions with the view into actions to be performed by the model. Based on the user interactions and the outcome of the model actions, the controller responds by

selecting an appropriate view.



View

CONTROLLER

Model DB

Presentation Tier Business Tier

Integration Tier


Presentation Tier J2EE Design Patterns

• Intercepting Filter

• Front Controller

• View Helper

• Composite View

• Dispatcher View

• Service To Worker


Intercepting Filter

• Most applications have some requirements, such as security and logging that are applicable across all application requests. To add such functionality separately to each application service would be time-consuming, error-prone, and difficult to maintain.

• Even implementing these services within a front controller would still require code changes to add and remove services. The sequence diagram in Figure 1 below shows how each Web resource is responsible for calling such services individually.

http://java.sun.com/blueprints/patterns/FrontController.html


Intercepting Filter

• The Intercepting Filter pattern wraps existing application resources with a filter that intercepts the reception of a request and the transmission of a response.

• An intercepting filter can pre-process or redirect application requests, and can post-process or replace the content of application responses.

• Example is ServletFilter and entries need to be provided in web.xml file in Filter Tag.


Intercepting Filter

Client Intercpt Filter 1 Intercpt Filter 2 Resources 1

requestintercepted


Front Controller

• Many interactive Web applications are composed of interdependent web pages. Such applications can be hard to maintain and extend.

• The Front Controller pattern defines a single component that is responsible for processing application requests.


Front Controller


Front Controller

Client

Main Servlet Front

ControllerModel DB

request Dispatch

Select View


View Helper

• View Helper Design pattern’ helps in separating a view from its processing logic. When we want to avoid the embedding programming logic, like scriptlets in jsp’, we can go with using custom tag and JSTL, to separate programming logic from the view.

• A View delegates its processing responsibilities to its helper classes, implemented as POJOs, custom tags, or tag files. Helpers serve as adapters between the view and the model, and perform processing related to formatting logic, such as generating an HTML table.


View Helper

Client View

HelperHelper

Presentation Model

JavaBeans Tag FileCustom Tag

Dispatches Uses


Composite View

• Many pages in an application view have the some different content and also some common content. As a user browses through the pages, the data and content among the different pages varies, but many elements such as a common header or sidebar on each view remain the same.

• The structure and layout of each page may be the same on all the pages of the view. And some elements or sections of a page may appear on several different pages. When such elements and groups are coded directly into application views, views are difficult to modify and are likely to contain inconsistencies.


Composite View

• In addition, a consistent look and feel for every application view is difficult to achieve, and more difficult to maintain, when coding views directly.

• A Composite View is a view built using other reusable sub-views. A single change to a sub-view is automatically reflected in every composite view that uses it.

• Furthermore, the composite view manages the layout of its sub-views and can provide a template, making consistent look and feel easier to achieve and modify across the entire application.


Composite View

SideBar.jsp

Header.jsp

Footer.jsp

Main.jsp


Dispatcher View

• Dispatcher View describes the combination of the Front Controller and View Helper patterns with a dispatcher component. The controller and the dispatcher typically have limited responsibilities, while this pattern provides upfront processing and view management logic

• In the Dispatcher View pattern, the dispatcher typically plays a limited to moderate role in view management. A limited role for the dispatcher occurs when no outside resources are utilized in order to choose the view.


Dispatcher View

• The information encapsulated in the request is sufficient to determine the view to dispatch the request. For example:

• http://some.server.com/servlet/Controller?next=login.jsp

• The sole responsibility of the dispatcher component in this case is to dispatch to the view login.jsp.


Dispatcher View

Client Controller Dispatcher View


Service To Worker

• Service to Worker describes the combination of the Front Controller and View Helper patterns with a dispatcher component.

• While this pattern and the Dispatcher View pattern describe a similar structure,. In Service to Worker, the controller and the dispatcher have more responsibilities.


Service To Worker

• On the other hand, in the Service to Worker pattern, may invoke a business service to determine the appropriate view to display. And the shared structure of Service to Worker and Dispatcher View consists of a controller working with a dispatcher, views, and helpers.

• Helper class can help in invoking business methods


Service To Worker

Client Controller Dispatcher View

Helper


Business Tier J2EE Design Patterns

• Business Delegate

• Service Locator

• Session Façade

• Composite Entity

• Transfer Object

• Transfer Object Assembler

• Value List Handler


Business Delegate

• When the presentation-tier components (JSP / Servlet) access the business services implemented by the business-directly through the exposed API of the services and the clients are exposed to the complexity of dealing with distributed components.

• The client is tightly coupled to the Business layer / EJB layer, creating dependencies between client and server that affect both development, run-time and project management concerns. Due to this the presentation-tier components are vulnerable to changes in the implementation of the business services, when ever the implementation of the business services change, the exposed implementation code in the presentation tier must change too


Business Delegate

• Solution is to create a layer of Business Delegate is

• 1) To reduce coupling between presentation-tier clients and business services.

• 2) The Business Delegate hides the underlying implementation details of the business service, such as Lookup and access details of the EJB architecture.

• 3) The business delegate object abstracts the business services API and provides standard interface to the client components. It hides the underlying implementation detail such as lookup mechanism and the API of the business services. And this reduces the coupling between the clients and the business services.

• 4) Another benefit is that delegate may cache results and references to remote business services, caching can significantly improve performance, because it limits unnecessary and potentially costly round trips over the network.


Business Delegate

Client Business Delegate Business Services

Service Locator


Service Locator

• Service lookup and creation involves complex interfaces and network operations.

• J2EE clients interact with service components, such as • Enterprise JavaBeans (EJB) and Java Message Service (JMS)

components, • Which provide business services and persistence capabilities,

to interact with these components; clients must either locate the service component (referred to as a lookup operation) or create a new component. For instance, an EJB client must locate the enterprise bean's home object, which the client then uses either to find an object or to create or remove one or more enterprise beans.


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.

• This pattern reduces the client complexity that results from the client's dependency on and need to perform lookup and creation processes, which are resource-intensive. To eliminate these problems, this pattern provides a mechanism to abstract all dependencies and network details into the Service Locator.


Service Locator

Client Service Locator Initial Context

Service FactoryBusiness Service


Service Facade

• Session façade is one design pattern that is often used while developing enterprise applications, it is implemented as a higher level component (i.e.: Session EJB), and it provides single interface for the functionality of an application or part of it, and it decouples lower level components simplifying the design.


Service Facade

• Think of bank situation, where you have someone that would like to transfer money from one account to another, in this type of scenario, the client has to check that the user is authorized, get the status of the two accounts, check that there are enough money on the first one, and then call the transfer, the entire transfer has to be done in a single transaction otherwise if something goes wrong, the situation has to be restored.


Service Facade

• When we want to expose business components and services to remote clients, when we want to avoid giving clients direct access to business-tier components, to prevent tight coupling with the clients

• When we want to provide a remote access layer to your business object and other business tier components, when want to expose your application services and other services to remote clients, when we want to centralize all business logic that needs to be exposed to remote clients


Service Facade

• Solution is to use SESSION FAÇADE to encapsulate business tier components and expose services to remote clients and client access session façade instead of accessing business components directly


Service FacadeBEFORE / without SESSION FACADE

Client object Entity Bean 2Session Bean 1 Entity Bean 1

Network boundary

do This()

do That()

do More()


Service FacadeSESSION FACADE

Session Facade Session B1 Entity B1

do This()

do That()

do More()

Client object Entity B2

Do()


Composite Entity

• Mapping an object model to an EJB object model is a

common design problem in J2EE applications.

• Given a network of inter-related objects, you must choose whether each object should be implemented as an entity EJB or a plain old Java object, and manage the relationships between the objects.

• Dependent objects, which are objects whose data are meaningful only in the context of a relationship to another object, are especially prone to problems. For example, in many applications, an Account object is meaningless outside of its relationship to its associated parent Customer object.


Composite Entity

• The Composite Entity design pattern offers a solution to modeling networks of interrelated business entities.

• The composite entity's interface is coarse-grained (larger module then fine grained or subsystem), and it manages interactions between fine-grained objects internally. This design pattern is especially useful for efficiently managing relationships to dependent objects.


Composite Entity

Composite EntityCustomer

Dependent ObjectProfile

Dependent ObjectAccount

Dependent ObjectAddress

Dependent ObjectContact Info

Dependent ObjectCredit Card


Transfer Object

• Previously known as Value Object

• A transfer object is a serializable class, Transfer Objects which encapsulate the bulk business data used for transferring multiple data elements over a tier. A single method call is used to send and retrieve the Transfer Object / Value Objects.

•The client receives the Transfer Object / Value Objects and can then invoke getter methods on the Transfer Object to get the individual attribute values from the Transfer Object.

• It help in transferring multiple data elements over a tier, it will reduce remote request across the network. Basically a java beans (setters and getters) these are called a value objects or transfer objects


Transfer Object

client Transfer objectcomponent

Create / access


Transfer Object Assembler • The Transfer Object Assembler constructs a composite Transfer

Object that represents data from different business components. The Transfer Object caries the data for the model to the client in a single method call. And the client obtains such Transfer Objects with the sole purpose of using them for presentation and processing in a read-only manner. Clients are not allowed to make changes to the Transfer Objects.

• The clients tend to make numerous remote method invocations to obtain the data from each individual component. Like DAO, session façade, other services, use a Transfer Object Assembler to build an application model as a composite Transfer Object. The Transfer Object Assembler aggregates multiple Transfer Objects from various business components and services, and returns it to the client.

• Combination of various Transfer Object and bind in one is TOA (transfer object assembler)


Transfer Object Assembler

client Transfer object assembler

ApplicationModel

Businessobject

Service

DAO

SessionFacade

use

use

assembles

access

access

access

access


Value List Handler

• Web applications frequently allow users to browse large virtual lists,

such as query result sets, which can not practically be transmitted to the remote client. Access to the list is usually read-only and bi-directional,. And you have a remote client that wants to iterate over a large results list

• The Value List Handler design pattern provides a more efficient way to iterate a large, read-only list across tiers. A value list handler provides a client with an Iterator for a virtual list that resides in another application tier. The Iterator typically accesses a local ordered collection of Transfer Objects, representing a sub range of the large list. A Data Access Object usually manages access to the list data, and may provide caching.

• Use a Value List Handler to search, cache the results, and allow the client to traverse and select items from the results.

http://java.sun.com/blueprints/patterns/TransferObject.html

http://java.sun.com/blueprints/patterns/DAO.html


Value List Handler

client ValueListHandler

DAO

use

access

manages

Valuelist

creates

ValuelistIterator

iterates

uses


Integration Tier J2EE Design Patterns

• Data Access Object

• Service Activator


Data Access Object

• The Data Access Object design pattern provides a technique for

separating object persistence and data access logic from any particular persistence mechanism or API. The Data Access Object approach provides flexibility to change an application's persistence mechanism over time without the need to re-engineer application logic that interacts with the Data Access Object tier.

• The Data Access Object (DAO) layer is an essential part of good application architecture. Business applications almost always need access to data from relational or object databases and the Java platform offers many techniques for accessing this data.

• Using DAO any database can be used to the application, and re-engineering is not required.

• 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 Access Object

client DataAccessObject+Create:void+Read:Object+Update:void+Delete:void

use

TransferObject

datasource

resultset

access

use

use / creates

creates


Service Activator

• When a client needs to access an enterprise bean, it first looks up

the bean's home object. The client requests the Enterprise JavaBeans (EJB) component's home to provide a remote reference to the required enterprise bean. The client then invokes business method calls on the remote reference to access the enterprise bean services. All these method calls, such as lookup and remote method calls are synchronous. The client has to wait until these methods return.

• Some application clients may require asynchronous processing for the server-side business objects because the clients do not need to wait or do not have the time to wait for the processing to complete. In cases where the application needs a form of asynchronous processing


Service Activator

• Solution is using a Service Activator to receive asynchronous client

requests and messages. On receiving a message, the Service Activator locates and invokes the necessary business methods on the business service components to fulfill the request asynchronously.

• Any client that needs to asynchronously invoke a business service, such as an enterprise bean, may create and send a message to the Service Activator. The Service Activator receives the message and parses it to interpret the client request. Once the client's request is parsed or unmarshalled, the Service Activator identifies and locates the necessary business service component and invokes business methods to complete processing of the client's request asynchronously.

• The Service Activator may optionally send an acknowledgement to the client of success or failure


Service Activator

Client

Creates(sends)

MessageRequest

Message ListenerService Activator

Receives

EJBBusiness Object

Activates


Q & A Session

Q & A

Thank You

J2EE Design Pattern

Documents

Transcript of J2EE Design Pattern