Layers

Intent

After collecting requirements from customers, we have to define the architecture of the system

So, we need to find a high-level subdivision of the system into constituent parts

Need to orgainize the mess into a workable structure

We will introduce the Layers pattern to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction

Example

Networking protocols is the best known

The International Standardization Organization (ISO) defined the following architectural model, the OSI 7-Layer Model

Layered approach is considered better practice, since different issues separately reaps several benefits

For example, development by team, support incremental coding, testing

Rewriting can be down on a certain layer only

Context

A large system that require decomposition

Problem

The system we are building is divided by mix of low and high level issues, where high-level operations reply on the lower-level ones

For example, high-level will be interactive to user and low-level will be concerned with hardware implementation

So, we need to balance the following requirements:

• Late source code changes should not ripple the whole system
• Interface should be stable (or better yet defined by standard)
• Parts of the system should be exchangeable (i.e., a particular layer can be changed)
• Might need to build other systems with the same low level issues
• Grouping of component is needed
• Complex components need further decomposition
• The system will be built by a team of programmers

Solution

Structure your system into an appropriate number of layers and place them on top of each other

The lowest layer is called Layer 1 ... Layer J-1, Layer J ... the highest is called Layer N

Most of the services that Layer J provides are composed of services provided by Layer J - 1.

Thus, the services of each layer implement a strategy for combining the services of the layer below in a meaningful way. (Whether you would like exception of not depends on the system you build)

Structure

Services of Layer J only used by Layer J+1 - there are no further direct dependencies between layers

The following represents a high conceptual view of Layers:

Client ---------- uses -----------------  Layer N

                                          Layer N-1

                                            ...

                                          Layer 1

In more detail, it might look something like this:

             ||              |              ||
             ||              |--------------||

             ||              |              ||
             |---------------|              ||

Dynamics / Scenario

Scenario I (Client called to Layer N)

Client issues a request to Layer N

Layer N cannot carry out, so it calls to Layer N-1 for services

Layer N - 1 sends requests to Layer N - 2

... Layer 2 sends requests to Layer 1

Services finally get performed in Layer 1

Replies passed back up from Layer 1 to Layer 2 ...

Replies passed back up from Layer N -2 to Layer N - 1

Reply passed back up from Layer N - 1 to Layer N

(Single request might get mapped to mulitple requests when going to lower layers)

Scenario II (Bottom-up communication)

A chain of actions starts at Layer 1 (a device driver detects input ...)

Inputs are translated into an internal format for Layer 2

... go to Layer 3,4,5 and so on ...

A "response" are detected in Layer N

(Called notifications)

(Scenario I is fan out, Scenario II is either remain 1:1 or condensed into a single notification)

Scenario III (Requests only travel through a subset of the layers from top to bottom)

Request to Layer N

Layer N calls Layer N-1 for services then "stop"

(Layer like this have to maintain state information / control info)

(Caching is one example of this scenario)

Scenario IV (Requests only travel through a subset of the layers from bottom to top)

An event is detected in Layer 1

Replies to Layer 2, then Layer 3, then "stop"

(Layer 3 probably has checking in place to look for repeated request from lower layers)

Scenario V (Communicate with 2 stacks)

...

Implementation

Define the abstraction criterion

Common Layers Principles

• User-visible elements
• Specific application modules
• Common services level
• Operating system interface level
• Operating system
• Hardware

Determine the number of abstraction levels

Name the layers and assign tasks to each of them

Specify the services

Refine the layering

Specify an interface for each layer

Structure individual layers

Specify the communication between adjacent layers

Decouple adjacent layer

(For example, upper layers know lower layers, but not vice versa)

(Higher layers register callback and still maintain upper layer hidden)

(Could relax some constraint for performance)

Design an error-handling strategy

Variants

Relaxed Layerd System

Layering Through Inheritance

Shared Component for some Layers

Known Uses

JVM

APIs

AS/400 MI

TCP/IP

Windows NT with Relaxed Layered system

ERP

Consequences

Advantages

Reuse of Layers

Support for standardization - dependencies are kept local

Exchangeability

Disadvantages

Cascades of changing behavior when behavior of a layer changes ... e.g. lower layer output increase 100x

Lower efficiency

Unnecessary work

Difficulty of establishing the correct granularity of layers