1. J2EE DESIGN PATTERN @Diego Thanh Nguyen - http://free.smartbiz.vn 10/8/12www.smartbiz.vn1

2. Table Of Content  I. GoF Design Pattern  I.1. Creation Patterns  I.2. Structural Patterns  I.3. Behavioral Patterns  II. J2EE Presentation :  III. J2EE Business:  IV. J2EE Integration 10/8/12www.smartbiz.vn2

3. I. How Design Patterns Arise ? 10/8/12www.smartbiz.vn3 1. Problem 2. Context 3. Solution 3. Solution Benefits Related Patterns Consequences Forces IF you find yourself in CONTEXT for example EXAMPLES, with PROBLEM, entailing FORCES THEN for some REASONS, apply DESIGN FORM AND/OR RULE to construct SOLUTION leading to NEW CONTEXT & OTHER PATTERNS

4. I. Design-Pattern Catalog 10/8/12www.smartbiz.vn4 Defer object creation to another object Describe ways to assemble objects Describe algorithms and flow control

5. I.1. Creation Patterns  Creational Patterns prescribe the way that objects are created. These patterns are used when a decision must be made at the time a class is instantiated.  Singleton: ensure a class has one Instance, and provide a global point of access to it.  Abstract Factory: provide an interface for creating families of related or dependent objects without specifying their concrete classes. 10/8/12www.smartbiz.vn5

6. I.1.1 Abstract Factory  Intent: create families of related objects without specifying subclass names  Applicability: when clients cannot anticipate groups of classes to instantiate  Concrete factories create groups of strategies 10/8/12www.smartbiz.vn6

7. I.2. Structural Patterns  Structural Patterns prescribe the organization of classes and objects.  Adapter  Convert the interface of a class into another interface that clients expect  Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces  Decorator  Extend the functionality of the original class in a way that is transparent to the client class 10/8/12www.smartbiz.vn7

8. I.2.1. Composite  Intent  treat individual objects & multiple, recursively- composed objects uniformly  Applicability  Objects must be composed recursively,  and no distinction between individual & composed elements,  and objects in structure can be treated uniformly 10/8/12www.smartbiz.vn8

9. I.2.1. Composite  CORBA Naming Service example using CosNaming::BindingIterator (which is an example of the “Batch Iterator” pattern compound from POSA5) 10/8/12www.smartbiz.vn9 Composite Node Leaf Node

10. I.3. Behavioral Patterns  Behavioral Patterns prescribe the way objects interact with each other. They help make complex behavior manageable by specifying the responsibilities of objects and the ways they communicate with each other.  State: allow an object to alter its behavior when its internal state changes 10/8/12www.smartbiz.vn10

11. I.3.1. Strategy  Intent  define a family of algorithms, encapsulate each one, & make them  interchangeable to let clients & algorithms vary independently  Applicability  When object is configurable with one of many algorithms,  and all algorithms can be encapsulated,  and one interface covers all encapsulations 10/8/12www.smartbiz.vn11

12. I.3.1. Strategy  Strategy applied in distributed (middleware) 10/8/12www.smartbiz.vn12 Hook for the concurrency strategy Hook for the request demuxing strategy Hook for marshaling strategy Hook for the connection management strategy Hook for the underlying transport strategy Hook for the event demuxing strategy

13. 13 I.3.1. Oracle Fusion Component OracleFusion Groupware API: A unified interface for all connectors that access the groupware servers via WebDAV, applying Singleton, Façade and Factory design patterns All connectors utilize the Jakarta Jackrabbit (client-side) API to send requests to and receive responses from a variety of WebDAV-enabled groupware servers Jakarta Jackrabbit re-uses some of open source libraries such as the Jakarta Commons library (HTTP Client &Logging), JDOM (JSR 102), JTA, JMX, …

14. 10/8/12www.smartbiz.vn14 I.3.2. OF Design Pattern  Singleton: the Connector class must only have one instance because it’s wasteful & useless to keep several instances on memory. Keeping so many connectors will difficult to manage lifecycle & impact the performance of application.  Factory Method: because of we assume our API can be used against multiple servers so that there must be a Connector for each server (i.e. ECExchangeConnector, ECLotusDominoConnector, ECOpenGroupwareConnector). Each connector is responsible for manufacturing its own managers (MailManager, CalendarManager, TasksManager) and delegate the jobs to them. The connector will only be determined by the client depending on the configuration.  For example, if a client (portlet) need to send a mail by Exchange server then it will call the ECExchangeConnector; this connector then will use its localized manager ExchangeMailManager to make life easier.  Abstract Factory: ECGroupwareFactory is the abstract factory class for all connectors because it will expose a unified interface for connectors to client.  Facade: the unified interface will be defined in the Façade pattern. As stated before, a specific Connector will delegate the appropriate jobs to its subsystems (managers). The façade pattern also decouples the managers from the client and other managers, thereby promoting independence and portability.

15. 15 I.3.1. OF Design Pattern 10/8/12www.smartbiz.vn

16. I.4.1. Observer Pattern  Easier to keep a consistent and maintainable view of the data  Half as many connections between actions, views  Views are independent and unaware of each other 10/8/12www.smartbiz.vn16 Action Data View  View & Action  View Messages about the data Data notifies observers via events when the state of the data changes

17. I.4.2. Implementing an Observer 1.Assign the subject to the observers (MainForm_Load) IssueSubject 10/8/12www.smartbiz.vn17

18. I.4.3. Implementing an Observer m_subject = new IssueSubject() paneA.Subject = m_subject paneB.Subject = m_subject... 1.Assign the subject to the observers (MainForm_Load) IssueSubject a b c d 10/8/12www.smartbiz.vn18

19. I.4.4. Implementing an Observer m_subject = new IssueSubject() paneA.Subject = m_subject paneB.Subject = m_subject... 1.Assign the subject to the observers (MainForm_Load) 2.Observers bind and save changes to Subject.DataSet IssueSubject a b c d 10/8/12www.smartbiz.vn19

20. I.4.5. Implementing an Observer m_subject = new IssueSubject() paneA.Subject = m_subject paneB.Subject = m_subject... 1.Assign the subject to the observers (MainForm_Load) 2.Observers bind and save changes to Subject.DataSet 3.When data changes, subject raises DataChanged event a b c d IssueSubject 10/8/12www.smartbiz.vn20

21. I.4.6. Implementing an Observer m_subject = new IssueSubject() paneA.Subject = m_subject paneB.Subject = m_subject... 1.Assign the subject to the observers (MainForm_Load) 4.Observers handle subject events to rebind data, if they care m_subject.DataChanged += … ‘ rebind 2.Observers bind and save changes to Subject.DataSet 3.When data changes, subject raises DataChanged event IssueSubject a b c d 10/8/12www.smartbiz.vn21

22. I.5.1. Coordinate Command State  Related menu and toolbar widgets are not automatically handled together  Command Pattern  Command objects unify the state and action for related UI widgets  Example:  “Save” action  Menu item  Toolbar button  Context menu 10/8/12www.smartbiz.vn22

23. I.5.2. Implementing a Command 10/8/12www.smartbiz.vn23 action = new Command.Action(this.WorkOffline_Action) offlineCommand = new Command(action) 1.Create a Command for each action in MainForm_Load() MenuItemCommander.Connect(menuWorkOffline, offlineCommand ) ToolBarButtonCommander.Connect(tlbOffline, offlineCommand ) 2.Wire menu items and toolbar buttons to the Command using Commander objects 3.Control button and menu item state through the Command ' Disable all UI widgets connected to this command offlineCommand.IsEnabled = false

24. I.6.1. Accelerated J2EE Development  Architect Service-Oriented Components  Design for Flexible, Agile Applications and Iterative Development  Apply/Extend Pre-Built COTS Components  Infrastructure and Common Business Components  Generate/Extend Custom Components  Rapidly Specify and Provision New Components  Leverage Industry Development Standards  Frameworks (STRUTS, Spring / Weld, Hibernate)  Patterns (MVC)  XML, Best Practices 10/8/12www.smartbiz.vn24

25. II. J2EE Application Design Patterns 10/8/12www.smartbiz.vn25

26. II. Model-View-Controller – Passive 10/8/12www.smartbiz.vn26 :Controller :Model:View handleEvent service update getData

27. II. Model-View-Controller – Active 10/8/12www.smartbiz.vn27 Model Controller View > Observer +update() :Model:View update getData data handleEvent notify

28. II.1. Presentation Tier Patterns  Intercepting Filter  Front Controller: Use of a Controller to handle all web requests  Dispatcher View: The controller works with a Dispatcher that handles navigation  Composite View  View Helper  Service to Worker 10/8/12www.smartbiz.vn28

29. II.2. Intercepting Filter  Problems:  Verify authentication  Check type of client  Is the session valid?  Solution: implement one or more Intercepting filters.  Sample: Filter-servlet - can transparently pre and post process all requests in an unlimited length filter chain. 10/8/12www.smartbiz.vn29

30. II.3. Front Controller & Dispatcher  Front Controller - Problems:  Multiple views.  Navigation logic embedded in views.  Difficult to maintain view logic as application grows.  Want to reuse view navigation within multiple clients. 10/8/12www.smartbiz.vn30

31. II.3. Front Controller - Dispatcher 10/8/12www.smartbiz.vn31

32. III.4. View Helper  Problem:  Many common operations in each view.  Often view output is dependant on business data.  Create more cohesive look and feel.  Like to hand off UI to web design group  Solution:  Basically anything that helps you display your model data in a reusable fashion.  Implemented as JavaBeans, Tags or XML/XSLT  See the JSTL, JSF and Struts. 10/8/12www.smartbiz.vn32

33. II.5. Composite View  Problem:  Many common & recurring components in a view.  Fragments may display differently given user type (i.e. faculty, student).  Look and feel in flux needs to be easily updateable.  Differs from View Helper as the Composite View decides which sub-views to include while View Helper generally decides how to display a given sub-view. 10/8/12www.smartbiz.vn33

34. III. Business Tier Patterns  Business Delegate: use of a Business Delegate to hide Implementation Detail.  Session Façade  Service Locator  Value Object  Composite Entity  Value Object Assembler  Value List Handler 10/8/12www.smartbiz.vn34

35. III.1. Business Delegate 10/8/12www.smartbiz.vn35

36. III.2. Session Façade Pattern  Problem:  Need very loose coupling between client and ever changing business tier.  Data tier changing; need to improve reuse.  Session Bean provides unified approach  Façade hides Entity Bean Details 10/8/12www.smartbiz.vn36

37. IV. Integration  Data Access Object  Service Activator  User Workflow Integrator 10/8/12www.smartbiz.vn37

38. IV.1. Data Access Object 10/8/12www.smartbiz.vn38

39. 10/8/12www.smartbiz.vn39