Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[DSBW Spring 2009] Unit 07: WebApp Design Patterns & Frameworks (2/3)


Published on

Published in: Technology
  • Be the first to comment

[DSBW Spring 2009] Unit 07: WebApp Design Patterns & Frameworks (2/3)

  1. 1. Unit 7: Design Patterns and Frameworks (cont.)  Other Web presentation layer issues:  Design Pattern: Context Object  Web Presentation layer refactoring: Synchronizer Token  Session state management  Web presentation/Business layers integration  Integration patterns with remote business layer: Service Locator  Business Delegate   Business layer architectural patterns  Transaction Script  Domain Model  Table Module dsbw 2008/2009 2q 1
  2. 2. Context Object  Problem: You want to avoid using protocol-specific system information outside of its relevant context.  For example, web components receive protocol-specific HTTP requests. Sharing HTTP requests with other components both within and outside the presentation tier exposes these components to protocol specifics.  Forces: You have components and services that need access to system  information.  You want to decouple application components and services from the protocol specifics of system information.  You want to expose only the relevant APIs within a context.  Solution: Use a Context Object to encapsulate state in a protocol- independent way to be shared throughout your application dsbw 2008/2009 2q 2
  3. 3. Context Object: Structure Example: dsbw 2008/2009 2q 3
  4. 4. Context Object: Sequence Diagram dsbw 2008/2009 2q 4
  5. 5. Synchronizer Token  Problem: Clients make duplicate resource requests that should be monitored and controlled, or clients access certain views out of order by returning to previously bookmarked pages.  Forces: You want to control the order or flow of the requests.  You want to control duplicate request submissions from a client.  Such duplicate submissions may occur when the user clicks the Back or Stop browser buttons and resubmits a form  Solution: Use a Synchronizer Token to monitor and control the request flow and client access to certain resources. dsbw 2008/2009 2q 5
  6. 6. Synchronizer Token: Mechanics  Create one or more helper classes responsible for generating and comparing one-time-use, unique tokens.  The component managing this activity delegates to these helpers, managing the temporary storage of a fresh token for each client submission.  A copy of the token is stored per user on the server and on the client browser. The token is typically stored on the client browser as a hidden field and on the server in a user session.  Add logic to check whether the token arriving with the client request matches the token in the user session. dsbw 2008/2009 2q 6
  7. 7. Session State Management Solution Implementation Benefits Drawbacks On the Client Hidden Form Fields Easy to Limited amount of implement. data HTTP Cookies No problems with Security concerns URI Rewriting load-balanced if data not server clusters encrypted On the Web HttpSession and Easy-to-use APIs Load-balanced container the like server clusters require special treatments On a DB Stored in a DB Sharable Penalizes DB table performance Recoverable dsbw 2008/2009 2q 7
  8. 8. Web Presentation/Business Layers Integration Web Container Web Presentation Layer Business Layer Data Source Layer Web server  Local procedure calls between web presentation and business components  Direct access to the controllers in the business layer dsbw 2008/2009 2q 8
  9. 9. Web Presentation/Business Layers Integration Application Server Web Container Business Layer Web Presentation Layer Data Source Layer Web server  Remote communication between web presentation and business components:  Communication protocols and/or middleware for distributed components  Name and/or directory services to locate remote components  DTOs to transfer data between remote components dsbw 2008/2009 2q 9
  10. 10. Service Locator  Problem: You want to transparently locate business components and services in a uniform manner.  Forces:  You want to use a lookup mechanism to locate business components and other services.  You want to centralize and reuse the implementation of lookup mechanisms for application clients.  You want to encapsulate vendor dependencies for registry implementations, and hide the dependency and complexity from the clients.  You want to avoid performance overhead related to initial context creation and service lookups.  You want to reestablish a connection to a previously accessed component and service  Solution: Use a Service Locator to implement and encapsulate service and component lookup. dsbw 2008/2009 2q 10
  11. 11. Service Locator: Structure  Target: the service or component that the Client is looking up  IntialContext: the starting point in the lookup and creation process.  RegistryService: the registry implementation that holds the references to the services or components that are registered as service providers for Clients  Cache: holds onto references that have been previously looked up. dsbw 2008/2009 2q 11
  12. 12. Service Locator: Sequence Diagram dsbw 2008/2009 2q 12
  13. 13. Business Delegate  Problem: You want to hide clients (Web presentation components) from the complexity of remote communication with business service components.  Forces:  You want to access the business layer components from your Web presentation layer components.  You want to minimize coupling between clients and the business services, thus hiding the underlying implementation details of the service, such as lookup and access.  You want to avoid unnecessary invocation of remote services.  You want to translate network exceptions into application or user exceptions.  You want to hide the details of service creation, reconfiguration, and invocation retries from the clients.  Solution: Use a Business Delegate to encapsulate access to a business service. dsbw 2008/2009 2q 13
  14. 14. Business Delegate: Structure dsbw 2008/2009 2q 14
  15. 15. Business Delegate: Sequence Diagram dsbw 2008/2009 2q 15
  16. 16. “Classic” J2EE Architecture Web Container J2EE Servlets / Web Classes Server Business Interface Business Delegate RMI J2EE EJB Container Server (Same or Session EJB Separate JVM Entity EJB (optional) DBMS Legacy System dsbw 2008/2009 2q 16
  17. 17. Business Layer Architectural Patterns Architectural Description Benefits Drawbacks Pattern Transaction A single procedure for Simple paradigm Duplicated code as Script each action that a user several transactions Works well with might want to do: takes need to do similar RDBMS the input from the things presentation, processes it, and stores data in the database. Domain Model Conceptual Model Pure OO: reuse, Object-Relational objects become Business inheritance, impedance Layer components polymorphism, etc. mismatch. Design Patterns Data Mapper. Table Module Third way solution: OO Takes advantage Not so easy to business layer with of many Data implement than coarse objects that Access APIs Transaction Script correspond to DB tables (ADO.NET, JDO, Not so powerful JDBC, …) than Domain Model dsbw 2008/2009 2q 17
  18. 18. Transaction Script: Example : WebPresLayer : DataSourceLayer : NewPostTrans execute( ) insert? = false findAuthorsByName(name) : RecordSet next() alt insertInToAuthors(name, password) [empty RecordSet] insert? = true get(quot;passwordquot;) insert? = “passwords match” opt [insert?] insertInToPosts(title, content, author) dsbw 2008/2009 2q 18
  19. 19. Domain Model: Example authorsDict : : WebPresLayer Dictionary Post Author title : String name : String : NewPostTrans date : Date password : String 1 0..* content : String execute( ) get(name) [author didn’t exist] opt (name, password) a : Author put(name, a) newPost(password, title, content ) checkPassword(password) [passwordOK] opt p : Post a p dsbw 2008/2009 2q 19
  20. 20. Table Module: Example : WebPresLayer : Authors : Posts : DataSourceLayer : NewPostTrans execute( ) newPost(...) findAuthorsByName(name ) : RecordSet next() insertInToAuthors(name, password) get(quot;passwordquot;) addNewPost(title, content, authorName) insertInToPosts(...) dsbw 2008/2009 2q 20
  21. 21. Business Layer Architectural Patterns dsbw 2008/2009 2q 21
  22. 22. References  Books  ALUR, Deepak et al. Core J2EE Patterns: Best Practices and Design Strategies, 2on Edition, Prentice Hall PTR, 2003.  FOWLER, Martin Patterns of Enterprise Application Architecture, Addison Wesley, 2002.  JOHNSON, Rod and HOELLER Juergen. Expert One-on-One J2EE Development without EJB, Willey Publishing, 2004  Web sites   dsbw 2008/2009 2q 22