The document discusses various design patterns and frameworks related to web presentation layers and integrating web and business layers. It covers the Context Object pattern for encapsulating state in a protocol-independent way. It also discusses the Synchronizer Token pattern for controlling duplicate requests and client access flow. For integrating remote web and business layers, it describes the Service Locator and Business Delegate patterns for locating and accessing business services through a centralized lookup mechanism or delegate respectively. Finally, it compares Transaction Script, Domain Model, and Table Module as architectural patterns for the business layer.

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 2011/2012 q1 1

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 2011/2012 q1 2

3. Context Object: Structure
Example:
dsbw 2011/2012 q1 3

4. Context Object: Sequence Diagram
dsbw 2011/2012 q1 4

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 2011/2012 q1 5

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 2011/2012 q1 6

7. Session State Management
Solution Implementation Benefits Drawbacks
On the Client Hidden Form Fields Easy to Limited amount of
HTTP Cookies implement. data
URI Rewriting No problems with Security concerns
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 Recoverable performance
dsbw 2011/2012 q1 7

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 2011/2012 q1 8

9. Web Presentation/Business Layers Integration
Web Container Application Server
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 2011/2012 q1 9

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 2011/2012 q1 10

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 2011/2012 q1 11

12. Service Locator: Sequence Diagram
dsbw 2011/2012 q1 12

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 2011/2012 q1 13

14. Business Delegate: Structure
dsbw 2011/2012 q1 14

15. Business Delegate: Sequence Diagram
dsbw 2011/2012 q1 15

16. “Classic” J2EE Architecture
Web Container
J2EE
Servlets / Web Classes
Server
Business Interface
Business Delegate
RMI
EJB Container J2EE
Server
Session EJB
(Same or
Separate
JVM
Entity EJB (optional)
DBMS Legacy System
dsbw 2011/2012 q1 16

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 Works well with several transactions
might want to do: takes RDBMS need to do similar
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 2011/2012 q1 17

18. Transaction Script: Example
: WebPresLayer : DataSourceLayer
: NewPostTrans
execute( )
insert? = false
findAuthorsByName(name)
: RecordSet
next()
alt insertInToAuthors(name, password) [empty RecordSet]
insert? = true
get("password")
insert? = “passwords match”
opt insertInToPosts(title, content, author) [insert?]
dsbw 2011/2012 q1 18

19. Domain Model: Example
: WebPresLayer authorsDict :
Dictionary Post
Author
title : String
: NewPostTrans name : String
date : Date
password : String
1 0..* content : String
execute( )
get(name)
opt (name, password) a : Author [author didn’t exist]
put(name, a)
newPost(password, title, content )
checkPassword(password)
opt [passwordOK]
p : Post
ap
dsbw 2011/2012 q1 19

20. Table Module: Example
: WebPresLayer : Authors : Posts : DataSourceLayer
: NewPostTrans
execute( )
newPost(...)
findAuthorsByName(name )
: RecordSet
next()
insertInToAuthors(name, password)
get("password")
addNewPost(title, content, authorName)
insertInToPosts(...)
dsbw 2011/2012 q1 20

21. Business Layer Architectural Patterns
dsbw 2011/2012 q1 21

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
 www.corej2eepatterns.com
 java.sun.com/blueprints/corej2eepatterns/
dsbw 2011/2012 q1 22