This document summarizes various design patterns and frameworks related to web presentation layers and business layers. For web presentation layers, it discusses the Context Object pattern for encapsulating state, the Synchronizer Token pattern for controlling request flow, and different approaches to session state management. It also reviews integration patterns for connecting web presentation and business layers, including the Service Locator and Business Delegate patterns. Finally, it examines common architectural patterns for the business layer such as Transaction Script, Domain Model, and Table Module.

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. 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. Context Object: Structure
Example:
dsbw 2008/2009 2q 3

4. Context Object: Sequence Diagram
dsbw 2008/2009 2q 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 2008/2009 2q 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 2008/2009 2q 6

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. 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. 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. 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. 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. Service Locator: Sequence Diagram
dsbw 2008/2009 2q 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 2008/2009 2q 13

14. Business Delegate: Structure
dsbw 2008/2009 2q 14

15. Business Delegate: Sequence Diagram
dsbw 2008/2009 2q 15

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. 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. 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. 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. 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. Business Layer Architectural Patterns
dsbw 2008/2009 2q 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 2008/2009 2q 22