Design Principles for Reusable, Composable and Extensible

FrameworksJilles van Gurp

Thanks• Axis Communications: Torbjörn Söderberg,

Per Flock

• Ericsson Mobile Applications Lab: Magnus Oestvall

• Jan Bosch (supervisor), Jelte Jansons (Opponent)

• Jan Mark de Haan, Matthew Kenrick, Jeroen Kolner for proofreading

Contents

• Introduction

• Composition & Evolution

• Communication Protocols

• Enhanced State Pattern

• Evaluation & Results

Introduction

• Framework: a partial design and implementation for an application in a given domain.

• Framework Composition: Multiple frameworks are used in an application

• Framework Evolution: Changes that are made to a framework during its ‘Life’

Framework

Desig n

In ter fac es

A b strac t classe s

C o m po n en ts

Ob jec ts

ref lec t

r ef lect

im p lem en t

im ple me n tin h er it

c o llab or ate with

M o re A bstr ac t

M o re im plem ent at io n or ient ed

Problems

• Applications depend on a framework changing the framework affects applications

• Frameworks make assumptions about the applications they’re used in these assumptions clash if more than one FW is used.

Research question

How can Frameworks be designed in such a way that composition and evolution problems are prevented.

How can frameworks in the domain of communication protocols be designed in such a way that evolution and composition problems are prevented

Methodology

• Analysis: how should frameworks in general be developed a set of guidelines

• Analysis of communication protocols problems

• A solution for problems in communication protocol frameworks

• Evaluation

Frameworks

• Whitebox Frameworks– interfaces– abstract classes

• Blackbox Frameworks– components

Composition Problems

• Two frameworks assume to be in control of the application

• Overlap in functionality

• Gap in functionality

• Framework has to work with legacy component

Evolution Problems

• The framework will change over time– Applications have to change too– Framework design is endangered

• Frameworks are often complex– Hard to change– Hard to use

Evolution problems (2)

• Frameworks often have poor documentation

• Frameworks have implicit usage rules

Consequences

• Change is avoided (to protect existing applications)

• Framework is used in the wrong way (resulting in errors, more maintenance work)

• Internal framework structure erodes over time

Guidelines

• 18 guidelines

• Four categories– Process– Design– Component– Implementation

Important guidelines

• Don’t put too much functionality in a FW, specialise the framework.

• Try too achieve loose coupling between components

• Make blackbox configuration easy

Communication Protocols

• Examples: IP, TCP, FTP, HTTP

• Work together in Protocol Stack

ISO OSI

A p pl ica tio n L ay e r

P re sen t atio n L ay e r

Ses s io n La y er

T ra n sp o rt L a ye r

Ne tw o rk L ay e r

D ata lin k L ay e r

P h y sica l L ay e r

A p p lic atio n L ay e r

Pr ese n tati o n L a y er

Se ss io n L ay e r

T ra n sp o rt La y er

N etw o rk L a y er

D at ali nk L a y er

Ph y sic al L a y er

Protocol Frameworks

• x-kernel

• Conduits/Conduits +/Java Conduits

• Axis’ Network Protocol Framework

x-kernel

• Object based, implemented in C

• High modularity

• High performance

Axis Network Protocol Framework

• Based on conduits and own frameworks

• Trades flexibility for performance

Conduits

• Object Oriented

• Very flexible (partly because of the extensive use of design patterns)

• Conduit: a natural or artificial channel through which something (as a fluid) is conveyed (Webster)

Plumbing

• 4 types of Conduits– Adaptor– Protocol/Session– Mux– Conduit Factory

A Conduit graph

I P

TC P UDP

Ad ap tor

Ad ap to r

Ad ap tor

M UX

C on d ui tFacto r y

creates

Benefits of Conduits

• Blackbox protocol stack configuration

• Highly object oriented

• Automated data transport through stack

• Session management

• Scalable through the use of threads

Disadvantages

• Does not support building protocols very much

• Object orientation has a performance price

Conduits & guidelines

• Conduits addresses two domains– protocol stack configuration– protocol implementation

• Loose coupling

• Blackbox configuration

Implementing a Protocol

• Protocols can be represented as Finite State Machines

• Conduits provides the State Pattern to implement protocols

State Pattern

St at eC onte xt S1

S 2 S 3

S 4 S5

S 6

a state machine

An example

SYN R ec eiv e d S YN Sen t

E s tab li she d

FI N W ait ( 1 )

FI N W ait ( 2 ) C los i ng

TI M E W ait C lo sed

C lo se W ait

L as t A ck

C lo sed

L is ten

Pa ss iv e o p encr ea te T C B

C lo sed e lete TC B

C l osed e lete TC B

Ac tiv e Op e ncr eate TC Bsen d SYN

S en dse n d S YN

rcv SY Nsnd SY N, A C K

rc v SYNsen d AC K

C lo sesen d FI N

R ec eiv e A C K o f FIN

R ece iv ed AC K o f S YNR ec eiv e SYN , AC Ksen d AC K

C lo sesen d FI N

R ec eiv e FINsen d AC K

C lo seSe nd FI N

R e ce iv e FI Nse n d A C K

R ec eiv e A C K o f FI NR e cei ve AC K o f FI N

T im eo u t ( 2m s)d el ete T C B

R e ce iv e FI NS en d AC K

Problems with the state pattern

• Complex implementation

• Hard to maintain implementations

Possible causes

• State pattern does not support all FSM concepts (states, input/output events, transitions, behavior)– states, transitions, events and behavior are put

in a single State class

• No blackbox way of building a FSM– you have to inherit from base classes

Finite State Machine Instantiation

• Necessary when the same FW is needed more than once in a system

• Example: – TCP can have thousands of connections at the

same time.– Each connection has it’s own FSM

• Not all objects have to be replicated

An alternative solution

aContext

aState aSta teaTransition

anEvent

anAction

sends anEvent

triggers

has ahas a

has a has a

has aexecutes

se ts state/uses context

An example

TS S

A

Context

E

Advantages

• Blackbox configuration

• More support for FSM concepts

• Easier to maintain

• More reuse possibilities

Implementation

• Blackbox framework for FSMs– object representation of FSM concepts

• Configuration tool– uses xml specification– separates behavior from control flow.

Results

• Guidelines

• Analysis of existing frameworks

• Enhanced State Pattern

• Implementation

• Small Evaluation of guideline usage and effectiveness in implementation