demystifying architectural styles nikunj mehta 3/11/02demystifying architectural styles2...

Demystifying Architectural Styles

Nikunj Mehta

3/11/02 Demystifying Architectural Styles 2

Architectural Styles

• Characterize– Structure, i.e. external appearance– Supported interactions, i.e. software connectors– Topological constraints

• Various categories– Motion of data, e.g. batch sequential, data flow– Order of computation, e.g. subroutines, objects – Communication centric, e.g. client/server, events– Data centric, e.g. databases, blackboard, hypertext– Layered, e.g. interpreter

3/11/02 Demystifying Architectural Styles 3

Why Research Architectural Styles?

• Design patterns are not enough– Styles support higher level reuse

• Component based software engineering– Avoiding COTS mismatches

• Model based software engineering– Avoiding model clashes

• Little is known about– Style similarities– Style primitives– Architectural primitives– Connector composition

3/11/02 Demystifying Architectural Styles 4

Mystical Nature of Styles

• Stem from principles of encapsulation, and information hiding

• Invisible software connectors are key• Origin of styles - a mystery

– How is a style created?

– How is a connector created?

• Codification of successful approaches• One size fits all?• How do we which styles is appropriate?

3/11/02 Demystifying Architectural Styles 5

We Need…

• Style and architectural primitives• Architectural composition techniques• Tool-supported formal model• Separation of behavioral, structural, compositional

and interaction concerns• Architectural prototyping framework• Connector composition• Architectural assembly language• Welcome Alfa!

3/11/02 Demystifying Architectural Styles 6

The Alfa Project

• Alfa – a bottom-up approach– Architecture needs composition

• Assembly language– Constructs and primitives for composition– Fine grain control over semantics– General but simple– Small set for analyzability and conceptual integrity– Style neutral and implementation agnostic

• Memories revived?– Assembly mnemonics and machine code– Start small, and then create languages and tools

3/11/02 Demystifying Architectural Styles 7

Composition primitives

• Particles– Simplest architectural

elements

• Portals– Entry/exit points for

particles

• Jumpers– Interaction ducts – Softwire

• Links– Interaction path between

particles

Fragment

OutputPortal

Jumper

InputPortal

Transport

3/11/02 Demystifying Architectural Styles 8

Behavioral primitives

• Fragment Controller– Locus of functional

computation

• Transport Controller– Locus of interaction

• Portal Controller– Locus of message

filtering/taggingFragment

OutputPortal

Jumper

InputPortal

Transport

3/11/02 Demystifying Architectural Styles 9

Interaction primitives

• Message– Communication

container

• Call– Procedural invocation

primitive

• Dispatcher– Dispatch messages and

calls to controllers

• Thread– Schedule and control

execution

• Queue– Buffer for holding

messages and calls

• Semaphore, Monitor, Rendezvous– Synchronization

3/11/02 Demystifying Architectural Styles 10

Architectural frameworkArchitectureManager

ArchitectureManager()getInstance()createParticle()createParticle()createMessage()createCall()stopParticle()shutParticle()removeParticle()startParticle()pauseParticle()linkParticles()linkParticles()unlinkParticles()joinMessageProcessing()

-$manager

FragmentController

FragmentController()getType()

TransportController

TransportController()handleMessage()getType()

ParticleController

HALT_READY : int = 5HALTED : int = 1REMOVE_READY : int = 4state : int = HALTEDSUSPENDED : int = 3READY : int = 2

getType()startParticle()stopParticle()pauseParticle()removeParticle()shutParticle()removeThyself()isActive()messageArrived()ParticleController()setDispatcher()getDispatcher()getOwner()sendMessage()

Dispatcher

dispatchMessage()stateChanged()

dispatcher

Particle

FRAGMENT : int = 1TRANSPORT : int = 2

Particle()Particle()handleMessage()getType()getController()getInputPortals()getOutputPortals()

owner

#controller

PortalController

jumperChanged()setPortal()

Portal

INCOMING : int = 1OUTGOING : int = 2direction : int

Portal()Portal()getDirection()getOwner()setJumper()removeJumper()getJumper()setPortalController()handleMessage()forwardMessage()

-owner

jumper

#controller

DefaultPortalController

DefaultPortalController()DefaultPortalController()handleMessage()

portal

Call

PARAMS : int = 0RESULT : int = 1EXCEPTION : int = 2resultAvailable : boolean = false

Call()setResult()getResult()getParams()setException()getException()

Message

SYSTEM_STOP : int = 1SYSTEM_START : int = 2SYSTEM_SHUT : int = 3SYSTEM_PAUSE : int = 4SYSTEM_REMOVE : int = 5MIN_TYPE_VALUE : int = 1024type : intpayload : Object

Message()Message()Message()getType()getPayload()

<<creates>>

<<creates>>

output

0..n

<<uses>>

inputs

0..n

<<uses>>

PooledAsynchronousDispatcher

countOfWorkers : int = 0DEFAULT_POOL_SIZE : int = 5

PooledAsynchronousDispatcher()PooledAsynchronousDispatcher()PooledAsynchronousDispatcher()PooledAsynchronousDispatcher()createWorkerThreadPool()startThreadPool()interruptThreadPool()isAliveThreadPool()stateChanged()

Dispatcher

dispatchMessage()stateChanged()

CircularQueue

DEFAULT_CAPACITY : int = 5emptySlots : intqueue[] : Objectcapacity : inthead : inttail : int

CircularQueue()CircularQueue()getLength()enqueue()dequeue()isFull()isEmpty()

Thread(from lang)

Queue

getLength()enqueue()dequeue()

isFull()isEmpty()

AsynchronousDispatcher

keepWorking : boolean = truewaiting : boolean = trueid : String

AsynchronousDispatcher()AsynchronousDispatcher()AsynchronousDispatcher()AsynchronousDispatcher()getWaitingLength()addToBuffer()getMessage()dispatchMessage()createWorkerThread()stateChanged()run()toString()

#worker

#queue

workers

1..n

<<uses>>

LinkedList(from util)

DynamicQueue

DynamicQueue()getLength()enqueue()dequeue()isFull()isEmpty()

Compositional Aspects Behavioral Aspects

3/11/02 Demystifying Architectural Styles 11

Composing Client Server

Style

P rotoco l

P rotoco lP rotoco l

Client

C on n

C on n

P rotoco l

Server

C on n

C on n

P rotoco l P rotoco l

C on n

C on n

Server

Server

C lient

C on n

C on n

P rotoco lP rotoco l

P rotoco lP rotoco l

P rotoco lP rotoco l Protocol

Con

nect

ion

Client

3/11/02 Demystifying Architectural Styles 12

Lessons learned

• Architecture approaches should be composable• Provide simple primitives that map consistently to

implementation• Data centric styles differ at fundamental level

from communication centric styles• Choose an architectural style that makes sense

– Know which style is good for your context

– Know the software connectors required

• Create architectural implementation framework