The Three-Tier Architecture Pattern Language Workshop

OOPSLA 2001,
Tampa Bay, Florida

October 15, 2001

Agenda
Submissions and Presentations
Discussion

Agenda

Introduction - Time: 8:30am - 9:00am

Backgrounds of participants
Expectations
Workshop Goals

Introduction to Patterns - Time: 9:00am - 9:30am by Michael Kircher
Experience Report - Time: 9:30am - 10:00am

Marco Torchiano, Lessons learnt from developing and changing an educational three tier system

Break - Time: 10:00am - 10:30am
Transactions, Persistency, and Resource Management - Time: 10:30am - 12:00pm

Jim Tyhurst, Choosing Transaction Models for Enterprise Applications
Brian Berenbach, Container Based Persistence
Prashant Jain, A Pattern Language for Resource Management in Three Tier Architectures

Lunch - Time: 12:00pm - 1:30pm
Moderated Discussion - Time: 1:30 - 3:00pm
Break - Time: 3:00pm - 3:30pm
Moderated Discussion - Time: 3:30pm - 5:00pm

Submissions and Presentations

Name	Affiliation	Position Paper (.pdf)	Presentation (.ppt)
Brian Berenbach	Siemens Corporate Research Inc.	Container Based Persistence	BrianBerenbach.ppt
Marco Torchiano, Letizia Jaccheri, Tor Stålhane	Norwegian University of Science and Technology	Lessons learnt from developing and changing an educational three tier system	MarcoTorchiano.ppt
Jim Tyhurst, Ph.D.	Tyhurst Technology Group LLC	Choosing Transaction Models for Enterprise Applications	JimTyhurst.ppt
Prashant Jain and Michael Kircher	Siemens AG	A Pattern Language for Resource Management in Three Tier Architectures	PrashantJain.ppt
Klaus Wolfmaier, Thomas Ziebermayr	Software Competence Center Hagenberg	A Layered Distributed Application: An Experience Report
Kjell Pettersson	RFV Data
Roger Larsson	Incrementa AB

Discussion

Usually you talk about three tiers, which are: presentation, business, data.
But to separate concerns even more, you group responsibilities into even more logical layers.

Why layers?

To manage complexity
Separate concerns
Scalability issues, such as load balancing
Ability to exchange user interfaces
Support for multiple communication channel

How many layers do you need?

Depends on the domain problem you try to solve.

The following list shows the layers we agreed on, which are most common:

Presentation Layer

Responsibility:

only presentation of the user interface

Forces:

avoid (hard) state
centralized business logic outside the client
easy deployment
internationalization and localization issues
type of presentation hardware

Patterns:

View of MVC
user interface patterns
PL for form-based user interfaces [PLoPD]
Web interface PL?
Human computer interaction PL [Jan Borchers]
View Panes, Standard Panes, Nouns and Verbs, Short Menus [c2.com]

View/Dialog Layer

Responsibility:

Manage the display state
keeping track of the conversational state

Forces:

type of presentation hardware
support for multiple user interfaces (presentation layers) and associated communication channels

Patterns:

Control of MVC
Fault Tolerant Telecommunications System Patterns [PLoPD2]
CHECKS programming language [PLoPD1]
Adapter
Mediator
Command
Command Processor
View Handler
Window per task [c2.com]

Process Layer

Responsibility:

contains business rules
ordering of user interactions
lifecycle of business use cases
is stateful, keeps application/session state
connects and coordinates services
managing multiple user roles
single point of authorization for user

Forces:

multiple business processes
internationalization of business rules
maintaining concurrent sessions
flexibility of roles and their coordination
evolving business processes
reusability, flexibility, scalability

Patterns:

State
Lifecycle
Interpreter
Interceptor
PL for Session Management [EuroPLoP]

Service Layer (Business Task)

Responsibility:

stateless
atomic actions/services, also allow composite services
no user interaction
covered by one transaction

Forces:

concurrency
reusability, flexibility, scalability
amount of granularity

Patterns:

Service Abstraction Layer
Server-Side Component Pattern Language [Voelter]
Business Components

Business Entity Layer

Responsibility

represents persistent data in the application
hides persistence details
might provide optimization of data access

Forces

fast access, relative to data layer
dynamic binding/publishing of interface
lifecycle of business objects
synchronization optimization
concurrent development

Patterns

Dynamic Object Model
Business Components

Data Access Layer

Responsibility

represents persistent data
hides physical database from the business entities
maps between paradigms

Forces

volume
caching
performance optimization
reusability, flexibility, scalability

Patterns

Crossing Chasms [PLoPD2, PLoPD3]
Object Relational Access Layer [PLoPD4]

Database Layer

Responsibility

keep data

Forces

Finding the right data and schema

Patterns

(Implied Object or Relational)

General/Cross-cutting Forces:

Event propagation (from lower layers to upper layers)
Security
Failure handling
Responsiveness
Dynamically configurable business rules

General Patterns:

Resource Management Pattern Language
Command
Distribution and Communication patterns
Security patterns
J2EE Blueprints
GoF

Discussion on Legacy Integration

Legacy Systems can be: Enterprise-Information-Systems, Back-Ends,
Mainframes (with overlap of course).

They can provide pure services, pure data access, or any combination of them.

Depending on the major focus of the legacy system, put them into the service or data layer, respectively.

Pattern Language Discussion

What kind of patterns is important to put into the pattern language?

Patterns to separate the layers
Patterns to find the right amount of layers
Documentation for newbies

start with simple patterns
continue with more complex patterns

What kind of pattern language could we document?

Finding the suitable architecture, finding forces to shape your architecture
Catalog existing patterns and pattern languages in the context of 3-tier architectures
How to structure your business process according to your domain problems?