Introduction to J2EE Patterns Online Training Classes

1. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Introduction to J2EE Patterns Online Training Classes info@quontrasolutions.co.uk

2. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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 info@quontrasolutions.co.uk

3. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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 info@quontrasolutions.co.uk

4. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

5. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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.co.uk

6. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

7. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

8. info@quontrasolutions.co.uk www.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. • 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 info@quontrasolutions.co.uk

9. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

10. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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> info@quontrasolutions.co.uk

11. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Interceptor Filter Pattern info@quontrasolutions.co.uk

12. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Filter: Sequence Diagram info@quontrasolutions.co.uk

13. info@quontrasolutions.co.uk www.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. info@quontrasolutions.co.uk

14. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

15. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

16. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Front Controller Pattern info@quontrasolutions.co.uk

17. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Controller: Sequence Diagram info@quontrasolutions.co.uk

18. info@quontrasolutions.co.uk www.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 and reduces modularity. info@quontrasolutions.co.uk

19. info@quontrasolutions.co.uk www.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. • The overriding goal is partitioning of business logic outside of the view. info@quontrasolutions.co.uk

20. info@quontrasolutions.co.uk www.quontrasolutions.co.uk View Helper Pattern info@quontrasolutions.co.uk

21. info@quontrasolutions.co.uk www.quontrasolutions.co.uk View Helper: Sequence Diagram info@quontrasolutions.co.uk

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. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

24. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

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. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Dispatcher View Pattern info@quontrasolutions.co.uk

27. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Dispatcher View: Sequence Diagram info@quontrasolutions.co.uk

28. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

29. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

30. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

31. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Service to Worker Pattern info@quontrasolutions.co.uk

32. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Service to Worker: Sequence Diagram info@quontrasolutions.co.uk

33. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

34. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

35. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Business Delegate Pattern info@quontrasolutions.co.uk

36. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Business Delegate: Sequence Diagram info@quontrasolutions.co.uk

37. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Delegate: Sequence Diagram with ID info@quontrasolutions.co.uk

38. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

39. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

40. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

41. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

42. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Session Facade Pattern info@quontrasolutions.co.uk

43. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Session Facade: Sequence Diagram info@quontrasolutions.co.uk

44. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

46. info@quontrasolutions.co.uk www.quontrasolutions.co.uk Service Locator Pattern info@quontrasolutions.co.uk

47. Service Locator: Sequence Diagram

48. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

49. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk

50. info@quontrasolutions.co.uk www.quontrasolutions.co.uk 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. info@quontrasolutions.co.uk