From Dependable Architectures To Dependable Systems

University of Southern CaliforniaCenter for Systems and Software Engineering

From Dependable ArchitecturesTo Dependable Systems

Nenad MedvidovicCenter for Systems and Software Engineering

Computer Science DepartmentViterbi School of Engineering

University of Southern CaliforniaLos Angeles, U.S.A.

[email protected]

mailto:[email protected]


Goals of the Talk• Identify some challenges• Suggest some solutions• Motivate future research• Invite dissenting opinions


Goals of the Talk

The problem is this big

and sometimes ill-defined


Goals of the Talk

I will talk to youabout this much of it


Goals of the Talk

I will suggest a solutionfor this much of it


Goals of the Talk

But, hopefully, we will havethis much fun!


What Is Dependability?• Degree of user confidence that the system will

operate as expected• Key dimensions

– Availability– Reliability– Security– Safety

• But also– Repairability– Maintainability– Survivability– Fault tolerance


What Is Architecture?• A high-level model of a system

– The system’s “blueprint”• Represents system organization

– Data– Computation– Interaction– Structure

• Embodies system properties– Communication integrity, performance,

throughput, liveness, . . .Can/does it embody dependability? (how) Can those properties be transferred to the

system itself?


A “Traditional” Architectural Model


A “Traditional” Architectural Model

What/where is the dependability?


A “Standard” Architectural Model

Segment(from ssi)

AttributeDescription(from serializati...

ResourceDescription(from serializati...

HttpCredential(from ht...

PlainRemoteResource(from adm...

HtmlHead(from ht...

SampleMuxHandler(from m...

Stresser(from tes...

JigsawHttpSessionContext(from servl. ..

HtmlStyle(from ht...

AdminContext(from admin)

AuthUserPrincipal(from a...

IPMatcherNode(from au...

HttpBag(from ht...

HtmlGenerator(from ht.. .

DirectoryResource(from resourc...

FileResource(from resourc...

HttpEntityTag(from ht...

HttpManager(from ht.. .

CGIHeaderHolder(from fram...

Shuffler(from ht...

IndexersCatalog(from index...

ResourceIndexer(from index...

MuxClientFactory(from m...

ResourceContext(from resourc...

EventManager(from t ime...

ResourceStoreManager(from sto...

PropertySet(from conf...

FramedResource(from resourc...

ServerHandlerManager(from daem...

AdminWriter(from adm...

Serializer(from serializati...

RequestTimeout(from ht.. .

MimeType(from mime)

IPMatcher(from auth)

ExternalContainer(from resourc...

PICS(from pi...

SSIFrame(from s...

SSIStream(from s...

ArrayDictionary(from ut...

CommandRegistry(from comman...

VariantState(from NegotiatedFra...

SampleResourceIndexer(from index...

ProtocolFrame(from frames)

MimeClientFactory(from ht...

MimeParser(from mi...

DAVMimeClientFactory(from webd...

ResourceException(from resourc...

SocketOutputBuffer(from sock...

DebugThread(from sock...

ThreadCache(from ut...

SocketClientFactoryStats(from sock...

httpd(from http)

MuxSession(from m...

ResourceFilter(from resources)

HttpMimeType(from ht...

HttpTokenList(from ht...

ResourceReference(from resources)

HTTPPrincipal(from a...

ProxyRequestObserver(from pro...

ProfileRef(from cc...

HttpExtList(from ht...

Client(from http)

CCPPRequest(from cc...


: WebBrowser

: SocketClient : httpd : DirectoryResource : ContainerResource : FramedResource : LookupResult

processRequest(Request) perform(RequestI nterface) <<create>>

lookup(LookupState, LookupResult) [lookup(LookupState, LookupResult)]

[lookup(LookupState, LookupResult)] setTarget(resourceReference)

internalLookup() lookup(LookupState, LookupResult)

[moreComponents]:

HTTPD Resources

Figure 10: Sequence diagram for the request processing use case.



: WebBrowser

: SocketClient : httpd : DirectoryResource : ContainerResource : FramedResource : LookupResult

processRequest(Request) perform(RequestI nterface) <<create>>

lookup(LookupState, LookupResult) [lookup(LookupState, LookupResult)]

[lookup(LookupState, LookupResult)] setTarget(resourceReference)

internalLookup() lookup(LookupState, LookupResult)

[moreComponents]:

HTTPD Resources

Figure 10: Sequence diagram for the request processing use case.


What/where is the dependability?


But, We Can Model Anything• Meta-H, ROOM, UniCon, etc. can help ensure

real-time properties in models• Markov chains can help ensure reliability in

models• Multi-versioning connectors can help ensure

fault tolerance• Code/data mobility and replication formalisms

can help ensure availability• . . .


But, We Can Model Anything• Meta-H, ROOM, UniCon, etc. can help ensure

real-time properties in models• Markov chains can help ensure reliability in

models• Multi-versioning connectors can help ensure

fault tolerance• Code/data mobility and replication formalisms

can help ensure availability• . . .

So then the problem is solved, right?


Why the Problem Isn’t Solved


Architecture(ADL)



Architecture(ADL)

Design(UML)



Architecture(ADL)

Implementation(middleware, bus

technolgies)

Design(UML)

Object-Oriented

Programming Language (OOPL)D/COM

CORBAC++

Java

Visual Basic

JEDI

Java Beans

C2



P ro b lem S p aceD o m a in E n titie s

C la s s N a m e

A ttr ibute s

O p e ra tion

C la s s N a m e

A ttr ib ute s

O pe ra tion

C la s s N a m e

A ttr ibu te s

O pe ra tion

C la s s N a m e

A ttr ibute s

O pe ra tionC la s s N a m e

A ttr ibute s

O pe ra tion

A rchitecture S p ace

D es ig n S p ace

C o m p on e n tsC o n n e c to rs

C la s s esC O T S C om p on e n ts



From Models to Systems

Clock

Weather Repository

Map

WeatherAnalyzer

ResourceManager

StrategyAnalysisKB

SimulationAgent

ResourceMonitor

SAKBUI

HQ UI

StrategyAnalyzer

Agent DeploymentAdvisor

Commander UI

SoldierUI

Commander UI

SoldierUI



Host 2Host 1

Host 3 Host 4 Host 5

Clock

Weather Repository

Map

WeatherAnalyzer

ResourceManager

StrategyAnalysisKB

SimulationAgent

ResourceMonitor

SAKBUI

HQ UI

StrategyAnalyzer


Commander UI

SoldierUI

Commander UI

SoldierUI


The remainder of this talk will focus on two key questions:


1. How do we get from


Clock

Weather Repository

Map

WeatherAnalyzer

ResourceManager

StrategyAnalysisKB

SimulationAgent

ResourceMonitor

SAKBUI

HQ UI

StrategyAnalyzer


Commander UI

SoldierUI

Commander UI

SoldierUI

Host 2Host 1


and



toClock

Weather Repository

Map

WeatherAnalyzer

ResourceManager

StrategyAnalysisKB

SimulationAgent

ResourceMonitor

SAKBUI

HQ UI

StrategyAnalyzer


Commander UI

SoldierUI

Commander UI

SoldierUI

Host 2Host 1


Host 2Host 1


Clock

Weather Repository

Map

WeatherAnalyzer

ResourceManager

StrategyAnalysisKB

SimulationAgent

ResourceMonitor

SAKBUI

HQ UI

StrategyAnalyzer


Commander UI

SoldierUI

Commander UI

SoldierUI

and



toClock

Weather Repository

Map

WeatherAnalyzer

ResourceManager

StrategyAnalysisKB

SimulationAgent

ResourceMonitor

SAKBUI

HQ UI

StrategyAnalyzer


Commander UI

SoldierUI

Commander UI

SoldierUI

to

?

Host 2Host 1


Host 2Host 1


Clock

Weather Repository

Map

WeatherAnalyzer

ResourceManager

StrategyAnalysisKB

SimulationAgent

ResourceMonitor

SAKBUI

HQ UI

StrategyAnalyzer


Commander UI

SoldierUI

Commander UI

SoldierUI

and



2. How do we know


2. How do we know

is “better” than

?


Outline• From architectures to systems• Ensuring dependability

Problem definition Proposed solution

• Concluding remarks


Outline From architectures to systems• Ensuring dependability




How Do I Dependably Implement an Architecture?

• Architectures provide high-level concepts– Components, connectors, ports, events, configurations

• Programming languages provide low-level constructs– Variables, arrays, pointers, procedures, objects

• Bridging the two often is an art-form– Middleware can help “split the difference”

• Existing middleware technologies– Support some architectural concepts (e.g., components, events)– but not others (e.g., connectors, configurations)– Impose particular architectural styles


How Do I Dependably Implement an Architecture?

• Architectures provide high-level concepts– Components, connectors, ports, events, configurations

• Programming languages provide low-level constructs– Variables, arrays, pointers, procedures, objects

• Bridging the two often is an art-form– Middleware can help “split the difference”

• Existing middleware technologies– Support some architectural concepts (e.g., components, events)– but not others (e.g., connectors, configurations)– Impose particular architectural styles

What is needed is “architectural middleware”


Architectural Middleware• Natively support architectural concepts as middleware

constructs• Include system design support

– Typically via an accompanying ADL and analysis tools– May support explicit architectural styles

• Support round-trip development– From architecture to implementation and back

• Support automated transformation of architectural models to implementations– i.e., dependable implementation

• Examples– ArchJava– Aura– c2.fw– Prism-MW


Dependable ImplementationArchitecture

(ADL)


technolgies)

Design(UML)

Object-Oriented


CORBAC++

Java

Visual Basic

JEDI

Java Beans

C2


Architecture(ADL)


technolgies)Object-Oriented


CORBAC++

Java

Visual Basic

JEDI

Java Beans

C2

Dependable Implementation


IComponentIConnector

Scaffold

AbstractDispatcher

Round RobinDispatcher

AbstractScheduler

FifoScheduler

Brick

Architecture

ExtensibleComponent

Component

Connector

Event

Port

IPort

Serializable

IArchitecture

#mutualPort

Example: Prism-MW


Using Prism-MW


Architecture - DEMO

class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture ("DEMO");

Using Prism-MW


Architecture - DEMO


Using Prism-MW

// create componentsComponentA a = new ComponentA ("A");ComponentB b = new ComponentB ("B");ComponentD d = new ComponentD ("D");

Component BComponent A Component D


Architecture - DEMO


Using Prism-MW

// create componentsComponentA a = new ComponentA ("A");ComponentB b = new ComponentB ("B");ComponentD d = new ComponentD ("D");// create connectorsConnector conn = new Connector("C");

Component BComponent A Component D CConnector C


Architecture - DEMO


Using Prism-MW

// create componentsComponentA a = new ComponentA ("A");ComponentB b = new ComponentB ("B");ComponentD d = new ComponentD ("D");// create connectorsConnector conn = new Connector("C");// add components and connectors arch.addComponent(a);arch.addComponent(b);arch.addComponent(d);arch.addConnector(conn);

Component BComponent A

Component D

CConnector C


Architecture - DEMO


Using Prism-MW

// create componentsComponentA a = new ComponentA ("A");ComponentB b = new ComponentB ("B");ComponentD d = new ComponentD ("D");// create connectorsConnector conn = new Connector("C");// add components and connectors arch.addComponent(a);arch.addComponent(b);arch.addComponent(d);arch.addConnector(conn);

Component BComponent A

Component D

CConnector C

// establish the interconnectionsarch.weld(a, conn);arch.weld(b, conn);arch.weld(conn, d)

}}


Deploying a Prism-MW Architecture


Deploying a Prism-MW Architecture

add (DataRepository : source HQ) : HQ;

weld (TopDistributionConnector, C1_AvailableTroops) : Commander1;


Outline From architectures to systems Ensuring dependability




Let’s Pick Availability• The degree to which a system is operational and

accessible when required for use [IEEE]• Deployment architecture influences availability

– Components on the same host can communicate regardless of the network’s status

– Components on different hosts are insulated from each other’s failures

• Quantifying availability– Ratio of the

number of successfully completed interactionsin the system to the total number of attempted interactions


• We may not know many relevant system parameters– Dependability of each component– Frequency of component interactions– Volume of component interactions– Dependability of component interactions– CPU usage on each host– Dependability of each host– Effective bandwidth of each network connection– Dependability of each network connection– . . .

Maximizing Availability a priori




Current deployment architecture may not work well




Current deployment architecture may not work well

Number of possible deployment architectures is kn


Find a function HCf : such that the

n

i

n

jji

n

i

n

jjiji

ccfreq

cfcfrelccfreqA

1 1

1 1

),(

))(),((),(

system’s overall availability

is maximized, and the following conditions are satisfied:

Simplified Problem Definition

],1[],1[ nlnk ))()(()1),(( lklk cfcfcccolloc ))()(()1),(( lklk cfcfcccolloc



Problem definitionProposed solution



Overview of the Approach• Objective

– Identify the problem• Log and examine system eventsActively monitor the system during runtime

– Develop a solution• Decide which data to cache• Decide which components to replicate• Introduce multiple execution modesCalculate an improved system deployment

– Apply the solution to eliminate the problem• Cache or hoard data • Replicate data or codeRedeploy (parts of) the system


Improving Availability via Redeployment

Time

Availability

A1

A2

TM TRT

TOTE T’M T’RT’

T’OT’E

A3

A4


First Identify the Problem

Time

Availability

A1

A2

TM TRT

TOTE



AbstractMonitor

Scaffold

AbstractDispatcher


AbstractScheduler

FifoScheduler

Brick

Architecture

ExtensibleComponent

Component

Connector

Event

Port

IPort

Serializable

IArchitecture

#mutualPort

Disconnection Rate

EvtFrequency

Monitoring in Prism-MW


Monitoring in Action

34

31

18

2 615

16

4 12

21

8

3 9

29 1 28

2030

17

14

0

2226

13

27

10

33

7

24

25

32

19

23

11

5


Then Develop a Solution

Time

Availability

A1

A2

TM TRT

TOTE


1

100

10000

1000000

Time taken(in ms)

0

0.2

0.4

0.6

0.8

1

z

Achieved availability

10 comps 100 comps 200 comps 1000 comps 100 comps 30 comps 300 comps 4 hosts 10 hosts 20 hosts 100 hosts 40 hosts 7 hosts 70 hosts

Suite of algorithms:Exact – exponential complexityStochastic – quadratic complexityAdaptive greedy – cubic complexityDecentralized – quadratic complexity

Estimating in Action


Automatic Algorithm Selection

AC

AS

T0STES

GreedyAG

AEExact

TEG TEE

T0G T0E

Time

Availability

TRTR TRT

Stochastic


AC

AS

T0STES

GreedyAG

AEExact

TEG TEE

T0G T0E

Time

Availability

TRTR TRT

Stochastic

Automatic Algorithm Selection


Then Apply the Solution

Time

Availability

A1

A2

TM TRT

TOTE



Scaffold

AbstractDispatcher


AbstractScheduler

FifoScheduler

Brick

Architecture

ExtensibleComponent

Component

Connector

Event

Port

IPort

Serializable

Admin

IArchitecture

#mutualPort

AbstractAdmin

DeployerAbstract

Redeployment Algo

Exact

Stochastic

Adaptive Greedy

Redeployment in Prism-MW


Redeployment in Action

Admin

34

31

18

2 615

16

4 12

21

Admin

8

3 9

29 1

Admin

28

2030

17

14

0Admin

2226

13

27

10

33

7

24

25

32

19

23

11

Deployer

5


Going from

Host 2Host 1


Clock

Weather Repository

Map

WeatherAnalyzer

ResourceManager

StrategyAnalysisKB

SimulationAgent

ResourceMonitor

SAKBUI

HQ UI

StrategyAnalyzer


Commander UI

SoldierUI

Legend:

User interface component(fixed to a host)

Processing or datacomponent

Commander UI

SoldierUI

Host 2

Hardware host

Network link

Interaction pathbetween components


to



Problem definitionProposed solution

Concluding remarks


Concluding RemarksStill so much to do

Enrich/complete the modelsFocus on additional aspects of dependabilityAddress dependability trade-offsAddress feature interactionsAddress emergent propertiesDetermine which concerns are (not) architectural


Promise or Illusion?If we can define it, we should be able to

Analyze for itBuild itMeasure itAct on it

So, why haven’t we done it yet?


The Playing Field

Dependability

HardwareProperties

SoftwareProperties

Availability

Reliability

Security

Safety

InteractionFrequency

Interaction Volume

Component Size

Interaction Volume

ComponentCPU Usage

AvailableMemory

Available CPU

NetworkReliability

NetworkBandwidth

Survivability

ComponentFailure Rate

H/W Properties

S/WProperties

Dependability


Exploring the Problem Space


Questions?

From Dependable Architectures To Dependable Systems

Documents

Transcript of From Dependable Architectures To Dependable Systems