The Three-Tier Architecture Pattern Language

Design Fest

EuroPLoP 2001
Kloster Irsee,

July 5-6, 2001

The following are the proceedings of the design fest.

Submissions

Name	Affiliation	Submission Link
Nicolai Josuttis	Solutions in Time, Germany	NicolaiJosuttis.pdf
Oliver Vogel	Systor AG, Switzerland	OliverVogel.pdf
Markus Voelter	Mathema AG, Germany	MarkusVoelter.pdf
Thomas Neumann	Systor AG, Germany	ThomasNeumann.pdf
Prashant Jain and Michael Kircher	Siemens AG, Germany	JainKircher.pdf

Layers 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

Responsibiliy:

only presentation of the user interface

Forces:

avoid (hard) state
no business logic

Patterns:

MVC
user interface patterns

View/Dialog Layer

Responsiblity:

Manage the display state
support for multiple user interfaces (presentation layers) and associated communication channels
keeping track of the conversational state

Forces:
Patterns:

Process Layer

Responsiblity:

contains business rules
lifecycle of business use cases
is stateful, keeps application/session state
connects and coordinates services

Forces:
Patterns:

Service Layer (Business Process)

Responsibility:

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

Forces:
Patterns:

Service Abstraction Layer
Server-Side Component Pattern Language
Business Components

Business Entity Layer

Responsibility

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

Forces

fast access, relative to data layer

Patterns

Dynamic Object Model
Busines Components

Data Layer

Responsibility

represents persistent data

Forces

slow access

Patterns

Object-to-Relational mapping

General Patterns:

Resource Management Pattern Language
Command
Distribution and Communciaton patterns
Security patterns

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?