www.quontrasolutions.com
info@quontrasolutions.com
Introduction to J2EE Patterns Online Training Classes
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
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.
www.quontrasolutions.com
info@quontrasolutions.com
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
www.quontrasolutions.com
info@quontrasolutions.com
MVC Design Pattern
•
Name (essence of the pattern) –
•
Context (where does this problem occur) –
•
Model View Controller MVC
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 lookand-feel is a competitive issue. Also, the same information is presented info@quontrasolutions.com in different ways. The core business logic and data is
www.quontrasolutions.com
info@quontrasolutions.com
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.
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
MVC Architecture
•
•
The Model represents the structure of the data in the application, as well as applicationspecific 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.
www.quontrasolutions.com
info@quontrasolutions.com
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
www.quontrasolutions.com
info@quontrasolutions.com
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.
www.quontrasolutions.com
info@quontrasolutions.com
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.
www.quontrasolutions.com
info@quontrasolutions.com
Filter Configuration
•
• • •
Configuring filter in the deployment descriptor ( web.xml ) <filter> <filter-name>Image Filter</filter-name> <filter-class>com.acme.ImageFilter</filterclass>
•
</filter>
•
<filter-mapping>
• •
<filter-name>Image Filter</filter-name> <url-pattern>/*</url-pattern>
www.quontrasolutions.com
info@quontrasolutions.com
Interceptor Filter Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Filter: Sequence Diagram
info@quontrasolutions.co.uk
www.quontrasolutions.com
info@quontrasolutions.com
Front Controller
â&#x20AC;˘
â&#x20AC;˘
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.
www.quontrasolutions.com
info@quontrasolutions.com
Front Controller
â&#x20AC;˘
â&#x20AC;˘
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. info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
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.
www.quontrasolutions.com
info@quontrasolutions.com
Front Controller Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Controller: Sequence Diagram
info@quontrasolutions.com
www.quontrasolutions.co.uk
info@quontrasolutions.co.uk
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.com
info@quontrasolutions.com
View Helper
â&#x20AC;˘
â&#x20AC;˘
â&#x20AC;˘
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.
www.quontrasolutions.com
info@quontrasolutions.com
View Helper Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
View Helper: Sequence Diagram
info@quontrasolutions.com
Dispatcher View â&#x20AC;˘
â&#x20AC;˘
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.
www.quontrasolutions.com
info@quontrasolutions.com
Dispatcher View
â&#x20AC;˘
â&#x20AC;˘
â&#x20AC;˘
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
www.quontrasolutions.com
info@quontrasolutions.com
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 â&#x20AC;˘
â&#x20AC;˘
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
www.quontrasolutions.com
info@quontrasolutions.com
Dispatcher View Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Dispatcher View: Sequence Diagram
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Service to Worker
â&#x20AC;˘
â&#x20AC;˘
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. info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Service to Worker
â&#x20AC;˘
â&#x20AC;˘
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.
www.quontrasolutions.com
info@quontrasolutions.com
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
www.quontrasolutions.com
info@quontrasolutions.com
Service to Worker Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Service to Worker: Sequence Diagram
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
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.
www.quontrasolutions.com
info@quontrasolutions.com
Business Delegate
â&#x20AC;˘
â&#x20AC;˘
â&#x20AC;˘
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.
www.quontrasolutions.com
info@quontrasolutions.com
Business Delegate Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Business Delegate: Sequence Diagram
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Delegate: Sequence Diagram with ID
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
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; info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
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 underlyinginfo@quontrasolutions.com complexity of the system.
www.quontrasolutions.com
info@quontrasolutions.com
Session Facade
â&#x20AC;˘
â&#x20AC;˘
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 coarsegrained service access layer to clients.
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Session Facade
â&#x20AC;˘
â&#x20AC;˘
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.
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Session Facade Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Session Facade: Sequence Diagram
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
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.
www.quontrasolutions.com
info@quontrasolutions.com
Service Locator
â&#x20AC;˘
â&#x20AC;˘
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 recreation. 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. info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Service Locator Pattern
info@quontrasolutions.com
Service Locator: Sequence Diagram
www.quontrasolutions.com
info@quontrasolutions.com
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 info@quontrasolutions.com some service.
www.quontrasolutions.com
info@quontrasolutions.com
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.
www.quontrasolutions.com
info@quontrasolutions.com
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
www.quontrasolutions.com
info@quontrasolutions.com
Transfer Object Assembler Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Transfer Object Assembler: Sequence
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
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
www.quontrasolutions.com
info@quontrasolutions.com
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 info@quontrasolutions.com 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 Pattern
Transfer Object: Sequence Diagram
www.quontrasolutions.com
info@quontrasolutions.com
Updater Transfer Object: Sequence
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Data Access Object
â&#x20AC;˘
â&#x20AC;˘
â&#x20AC;˘
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. info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Data Access Object: Problem
â&#x20AC;˘
â&#x20AC;˘
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 info@quontrasolutions.com
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
www.quontrasolutions.com
info@quontrasolutions.com
Data Access Object Pattern
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
Data Access Object: Sequence Diagram
info@quontrasolutions.com
www.quontrasolutions.com
info@quontrasolutions.com
For More Details Contact us
Quontra Solutions Visit: http://Www.quontrasolutions.com Email: info@quontrasoluitons.com Call us: (404) 900 - 9988
info@quontrasolutions.com