22
1 dsbw 2011/2012 q1 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 Unit 7: Design Patterns and Frameworks (cont.)

Unit 07: Design Patterns and Frameworks (2/3)

Embed Size (px)

Citation preview

Page 1: Unit 07: Design Patterns and Frameworks (2/3)

1 dsbw 2011/2012 q1

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

Unit 7: Design Patterns and Frameworks (cont.)

Page 2: Unit 07: Design Patterns and Frameworks (2/3)

2 dsbw 2011/2012 q1

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

Context Object

Page 3: Unit 07: Design Patterns and Frameworks (2/3)

3 dsbw 2011/2012 q1

Context Object: Structure

Example:

Page 4: Unit 07: Design Patterns and Frameworks (2/3)

4 dsbw 2011/2012 q1

Context Object: Sequence Diagram

Page 5: Unit 07: Design Patterns and Frameworks (2/3)

5 dsbw 2011/2012 q1

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.

Synchronizer Token

Page 6: Unit 07: Design Patterns and Frameworks (2/3)

6 dsbw 2011/2012 q1

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.

Page 7: Unit 07: Design Patterns and Frameworks (2/3)

7 dsbw 2011/2012 q1

Session State Management

Solution Implementation Benefits Drawbacks

On the Client Hidden Form Fields

HTTP Cookies

URI Rewriting

Easy to

implement.

No problems with

load-balanced

server clusters

Limited amount of

data

Security concerns

if data not

encrypted

On the Web

container

HttpSession and

the like

Easy-to-use APIs Load-balanced

server clusters

require special

treatments

On a DB Stored in a DB

table

Sharable

Recoverable

Penalizes DB

performance

Page 8: Unit 07: Design Patterns and Frameworks (2/3)

8 dsbw 2011/2012 q1

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

Page 9: Unit 07: Design Patterns and Frameworks (2/3)

9 dsbw 2011/2012 q1

Web Presentation/Business Layers Integration

Application Server

Business Layer

Data Source Layer

Web Container

Web Presentation

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

Page 10: Unit 07: Design Patterns and Frameworks (2/3)

10 dsbw 2011/2012 q1

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.

Service Locator

Page 11: Unit 07: Design Patterns and Frameworks (2/3)

11 dsbw 2011/2012 q1

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.

Page 12: Unit 07: Design Patterns and Frameworks (2/3)

12 dsbw 2011/2012 q1

Service Locator: Sequence Diagram

Page 13: Unit 07: Design Patterns and Frameworks (2/3)

13 dsbw 2011/2012 q1

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.

Business Delegate

Page 14: Unit 07: Design Patterns and Frameworks (2/3)

14 dsbw 2011/2012 q1

Business Delegate: Structure

Page 15: Unit 07: Design Patterns and Frameworks (2/3)

15 dsbw 2011/2012 q1

Business Delegate: Sequence Diagram

Page 16: Unit 07: Design Patterns and Frameworks (2/3)

16 dsbw 2011/2012 q1

Web Container

Servlets / Web Classes

Business Delegate

Business Interface

EJB Container

Session EJB

Entity EJB (optional)

DBMS Legacy System

RMI

J2EE

Server

J2EE

Server

(Same or

Separate

JVM

“Classic” J2EE Architecture

Page 17: Unit 07: Design Patterns and Frameworks (2/3)

17 dsbw 2011/2012 q1

Business Layer Architectural Patterns

Architectural

Pattern

Description Benefits Drawbacks

Transaction

Script

A single procedure for

each action that a user

might want to do: takes

the input from the

presentation, processes

it, and stores data in the

database.

Simple paradigm

Works well with

RDBMS

Duplicated code as

several transactions

need to do similar

things

Domain Model Conceptual Model

objects become Business

Layer components

Pure OO: reuse,

inheritance,

polymorphism, etc.

Design Patterns

Object-Relational

impedance

mismatch.

Data Mapper.

Table Module Third way solution: OO

business layer with

coarse objects that

correspond to DB tables

Takes advantage

of many Data

Access APIs

(ADO.NET, JDO,

JDBC, …)

Not so easy to

implement than

Transaction Script

Not so powerful

than Domain Model

Page 18: Unit 07: Design Patterns and Frameworks (2/3)

18 dsbw 2011/2012 q1

Transaction Script: Example

: WebPresLayer

: NewPostTrans

: DataSourceLayer

: RecordSet

execute( )

findAuthorsByName(name)

next()

insertInToAuthors(name, password)

get("password")

insertInToPosts(title, content, author)

alt [empty RecordSet]

insert? = false

insert? = true

insert? = “passwords match”

opt [insert?]

Page 19: Unit 07: Design Patterns and Frameworks (2/3)

19 dsbw 2011/2012 q1

Domain Model: Example

[passwordOK]

: WebPresLayer

: NewPostTrans

authorsDict : Dictionary

a : Author

p : Post

execute( )

get(name)

(name, password)

newPost(password, title, content ) checkPassword(password)

opt [author didn’t exist]

a p

opt

put(name, a)

Author

name : String password : String

Post

title : String

date : Date content : String 0..* 1 1 0..*

Page 20: Unit 07: Design Patterns and Frameworks (2/3)

20 dsbw 2011/2012 q1

Table Module: Example

: WebPresLayer

: NewPostTrans

: Authors : Posts

: RecordSet

: DataSourceLayer

execute( )

newPost(...)

findAuthorsByName(name )

insertInToAuthors(name, password)

addNewPost(title, content, authorName)

insertInToPosts(...)

get("password")

next()

Page 21: Unit 07: Design Patterns and Frameworks (2/3)

21 dsbw 2011/2012 q1

Business Layer Architectural Patterns

Page 22: Unit 07: Design Patterns and Frameworks (2/3)

22 dsbw 2011/2012 q1

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/

References