architectural building blocks for plug-and-play system...

Architectural Building Blocks forPlug-and-Play System Design

Shangzhu Wang, George S. Avrunin,Lori A. Clarke

Department of Computer ScienceUniversity of Massachusetts Amherst

{shangzhu,avrunin,clarke}@cs.umass.edu

The Problem

Developing concurrent and distributedsystems is difficult and costly Unpredictable behaviors due to

interleavings between parallel components

Component Interactions Represent synchronizations and

communications between components

Large design space of alternative semantics A wide range of interaction mechanisms (e.g. RPC, MP,

EBN) and their variations Choosing appropriate interaction semantics for a system

can be challenging

Important yet hard to get right

Semantics of interactions intertwined withcomponents’ computations

Changes in the interaction semantics often requirechanges in the components, limiting the reusability ofcomponents

State of the Practice/Art Connectors represent component interactions

Finite-state verification can be used to evaluatethe correctness of design Provides early feedback about the appropriateness of

the choices of interaction semantics

ADLs are often restricted in the kinds of interactionsemantics they support

Component designs tend to include some aspects ofthe semantics of interactions

But extremely costly when frequent changes are madeto the design

An Illustrative Example

The Single-lane Bridge Example

Controller Controller

EnterRequestExitRequest

Design of the Single-lane Bridge Example– (exactly-N-cars-per-turn)

BlueController RedController

BlueCar RedCar

Component Connector

Blue_Enter Red_Exit Blue_Exit Red_Enter

Oops!


RedController

BlueCar RedCar


send enterRequest;enter the bridge;

BlueController Oops!


RedController

BlueCar RedCar


send enterRequest;receive ack;enter the bridge

BlueController Oops!


RedController

BlueCar RedCar


BlueControllerreceive enterRequest;if safe send ack;


RedController

BlueCar RedCar


BlueController


RedController

BlueCar RedCar


BlueController

Safe! But…


RedController

BlueCar RedCar


BlueController

Deadlock!!

insufficient buffering


RedController

BlueCar RedCar


BlueController

Deadlock!!


if buffer is not full send exitRequest


RedController

BlueCar RedCar


BlueController

if buffer is not full send exitRequest


Deadlock!!


RedController

BlueCar RedCar


BlueController

No crash !Deadlock free !

What is Needed

Architectural support to Minimize the impact on the components when

connectors are changed Allow easy experimentation with alternative design

choices of interaction semantics Increase the reusability of both components and

connectors Reduce the cost of frequently re-computing models for

finite-state verification

Outline of Our Approach Support plug-and-play system design

Define a small set of standard interfaces fordifferent component interactions

Define a library of building blocks for theconstruction of connectors with differentinteraction semantics

Facilitate design-time verification Increase reusability of component models Build connector models by composing reusable

models of building blocks

Standard Interfaces forComponent Interactions

Only a small set of interfaces are needed Define the standard protocols between

components and connectors

The same interface can be used with manydifferent interaction semantics Connectors can be modified or replaced without

changing the components Components are more likely to be reused when

the design of interactions is changed

A Library of Building Blocks

Connectors are decomposed into channelsand ports Composable and reusable Channels represent the communication media of

connectors Ports are mediators between components and

channels capture different synchronization semantics of

connectors important for supporting the standard component

interfaces

Protocols Between Building Blocks A message passing example

Asynchronous Nonblocking Send

component channelsend port

m

m

BufferStatus = “inOk”/ “inFail”

RecvStatus= “sendOk”

“recvOk”

m



m

mBufferStatus = “inOk”

m


Synchronous Blocking Send

“recvOk”

msc Asynchronous Nonblocking Send


m

m

BufferStatus = “inOk”/ “inFail”


m

“recvOk”

msc Synchronous Blocking Send


m

mBufferStatus = “inOk”

“recvOk”

m



Examples of Message PassingBuilding Blocks

Priority queue

FIFO queueChannelsSingle-slot buffer

Nonblocking remove

Nonblocking copy

Blocking removeReceive Ports

Blocking copy

Synchronous checking

Synchronous blocking

Asynchronous checkingSend PortsAsynchronous blocking

Asynchronous nonblocking

Sender Receiver

Plug and Play with Message Passing

MP

Synchronous blocking send & nonblocking receive

Nonblockingreceive port

FIFO queue

Synchronousblocking send port

Sendinterface

Receiveinterface

Library of Message Passing Building blocks

The Single-lane Bridge Example – (exactly-N-cars-per-turn)



RedController

RedCar

BlueController

BlueCar

Red_Exit

Single-slot

AsynNbSend

BlRecv

Blue_Exit

AsynNbSend

Single-slot BlRecv

Blue_Enter

FIFO

AsynBlSend

FIFO

AsynBlSend

Red_Enter

Oops!


RedController

RedCar


BlueController

BlueCar

AsynNbSend

FIFO FIFOSingle-slot Single-slot

AsynNbSend

BlRecv BlRecv

AsynBlSendAsynBlSend

Oops!

SynBlSendSynBlSend


RedController

RedCar


BlueController

BlueCar

AsynNbSend


AsynNbSend

BlRecv BlRecv

Oops!

SynBlSendSynBlSend


RedController

RedCar


BlueController

BlueCar

AsynNbSend


AsynNbSend

BlRecv BlRecv

Deadlock!!

SynBlSendSynBlSend


RedController

RedCar


BlueController

BlueCar

AsynBlSend


AsynBlSend

BlRecv BlRecv

Deadlock!!

A More Efficient Single-lane Bridge– (at-most-N-cars-per-turn)

Red_Blue

Blue_Red

A More Efficient Single-lane Bridge

RedController

RedCar


BlueController

BlueCar

SynBlSendAsynBlSend


SynBlSend AsynBlSend

BlRecv BlRecv

– (at-most-N-cars-per-turn)

NbRecv NbRecv

Summary Support plug-and-play design of component-

based systems A small set of standard component interfaces that

minimize the impact of changes to connectors oncomponents

A library of pre-defined building blocks for theconstruction of a variety of different connectors

Allows easy experimentation with alternative designchoices of interaction semantics

Facilitate design-time verification Increase the reusability of both components and

connectors Save model-construction time when verification needs

to be repeated

Summary (cont’d) Applied to message passing

Interfaces and protocols designed Building blocks defined and models constructed in

Promela Example systems evaluated using SPIN

Not tied to particular modeling languages or verification tools

Developing more building blocks to supportother interaction mechanisms RPC, Publish/Subscribe Can reuse many of the message passing building

blocks

Related Work Modeling connectors for verification, e.g.,

Wright (Allen et al. ’97) AIDS (Ray et al. ’03) Constraint Automata (Arbab et al. ’04) Model checking pub-sub systems (Garlan et al. ’03) Compositional approach (Caporuscio et al. ’04)

Architecture evolution, e.g., Medvidovic et al. ’99, van der Hoek et al. ’01

Ports, e.g., ACME (Garlan et al. ’97), ArchJava (Aldrich et al. ’02)

Mediators, wrappers, adaptable components, e.g., Sullivan et al. ’92, Spitznagel et al. ’03, , Heineman ’98

Ongoing & Future Work Support for additional interaction semantics

Provide a shared library of building blocks for different interactionmechanisms

Define a systematic way to create and define arbitrary buildingblocks

Tools to support our approach Implementing extensions to AcmeStudio (Garlan, et al.) Hierarchical building blocks, pre-built connectors Integrating design-time verification, provides guidance for fixing

problems More substantial case studies

To evaluate applicability, scalability, etc. Optimizations for finite-state verification

To reduce composed models

Thank you!

Questions?

The Single-lane Bridge Example


The Single-lane Bridge Example Plug-and-play design using the pre-defined message

passing building blocks Connectors are described by composing a selective subset of

the message passing building blocks Allows easy experimentation with alternative choices of

message passing semantics Evaluate the system design using SPIN/Promela

Check properties: Is the system deadlock free? Is the bridge “safe”?

Our approach increases the reuse of the formal modelswhen designs need to be changed due to property violationsor major functional requirements changes

msc Blocking receive

component channelreceive port

RecvRequest

“outOk”

m

RecvStatus = “recvSucc”

RecvRequest

m

msc Nonblocking receive

component channelreceive port

RecvRequest

“outOk”RecvStatus = “recvSucc”

RecvRequest

m

“outFail”RecvStatus = “recvFail”

Null


Design-time Verification Finite-state verification

Check important specification properties of a system Based on searching the state space of a finite-state model of

a system for paths leading to the violation of the property E.g. SPIN, SMV, FLAVERS

Predefined and reusable formal models are createdfor the library of building blocks Connector models are composed from the predefined

building block models Not tied to any particular verification tools or modeling

languages Reduce the need of re-constructing component

models when only connectors are changed

The Single-lane Bridge Problem(with emergency vehicles)

RedController

RedCar


BlueController

BlueCar

connector

component

sendPorts

recvPorts

Red_Blue

Blue_RedFIFO FIFO

RedEmergencyBlueEmergency

AsynBlSend

NbRecv

SynBlSend

NbRecv

AsynBlSend SynBlSend

The Single-lane Bridge Example(with emergency vehicles)

RedController

RedCar

Red_Exit Blue_Exit

BlueController

BlueCar

connector

component

sendPorts

recvPorts

Red_Blue

Blue_Red

Priority Priority

RedEmergencyBlueEmergency

AsynBlSend

NbRecv

SynBlSend

NbRecv

AsynBlSend SynBlSend

Red_Blue_Em

Blue_Red_Em

Red_EnterBlue_Enter

NbCopy NbCopy

Notes

Refer details to the paper in the talk Refer verification-specific details to the

tech report

Related workInteraction Paradigms Paradigms for process interaction in distributed programs

[’91 Andrews] Paradigms for multithreaded, parallel, and distributed

programming, e.g. [’00 Andrews] Message Passing Interface (MPI) Etc.

Middleware Polylith [’94 Purtillo, et al.] CORBA COM Enterprise Java Beans Mediators [’94 Sullivan] etc.

Related workComponent-based ADLs Darwin [’97 Magee,et al.]

UniCon [’96 Shaw, et al.]

Wright [’97 Allen and Garlan]

ACME [’97 Garlan, et al.] A comparison framework for ADLs

[’00 Medvidovic, et al] etc.

Related work

Formalizing interactions and connections A formal basis for architectural connection

[’97 Allen and Garlan] Composable semantics [’02 Niu, et al.] Compositional connector wrappers

[’03 Spitznagel and Garlan] etc.

Related workApply finite state verification to component

interactions Model checking pub-sub system [’03 Garlan, et al.] Invariant-based verification of synchronization

[’02 Deng, et al.] Deadlock detection in distributed object systems

[’01 Kaveh and Emmerich] Modeling, specifying and verifying message passing

systems [’01 Bollig, et al.] Applying Static Analysis to Software Architectures [’97

Naumovich, et al.] etc.

The Promela Model of Ports

proctype AsynNbSendPort(SynChan component; SynChan

connector){

MsgBody data;end: do :: connector.c?_,eval(_pid) :: atomic{ component.d?data; component.c!sendOk,_pid; data.sendPort_pid = _pid; connector.d!data } od}

proctype AsynBlSendPort(SynChan component; SynChan connector){MsgBody data;end: do :: connector.c?_,eval(_pid); :: atomic{ component.d?data; data.sendPort_pid = _pid; do :: connector.d!data; if :: connector.c?connInOk,eval(_pid); break :: connector.c?connInFail,eval(_pid) fi od; component.c!sendOk,_pid } od}


proctype SynBlSendPort(SynChan component; SynChan

connector){MsgBody data;end: do :: atomic{ component.d?data;

data.sendPort_pid = _pid; do :: connector.d!data; if ::

connector.c?connInOk,eval(_pid); break ::

connector.c?connInFail,eval(_pid) fi od; connector.c?recvOk,eval(_pid); component.c!sendOk,_pid } od }

proctype SynNbSendPort(SynChan component; SynChan connector){

end: do :: atomic{ component.d?data; data.sendPort_pid = _pid; connector.d!data; if :: connector.c?connInOk,eval(_pid); connector.c?recvOk,eval(_pid) :: connector.c?connInFail,eval(_pid) fi; component.c!sendOk,_pid } od}


proctype NsBlRecvPort(SynChan component; SynChan

connector){

MsgBody data;end: do :: component.c?recvRequest,_; do :: connector.c!outRequest,_; if :: connector.d?data -> component.c!recvSucc ,_pid; component.d!data; break :: connector.c?connOutFail,0 fi od od}

proctype NsNbRecvPort(SynChan component; SynChan connector){

MsgBody data;end: do :: component.c?recvRequest,_; connector.c!outRequest,_; if :: connector.c?connOutFail,0 -> component.c!recvFail,_pid; component.d!data :: connector.d?data -> component.c!recvSucc; component.d!data fi od}

FIFO Queue in Promelaproctype FIFO_queue(SynChan sender; SynChan

receiver){ chan buffer = [BUFFER_SIZE] of {MsgBody}; xs buffer; MsgBody data;

do :: atomic{ sender.d?data; if :: full(buffer) -> sender.c!connInFail,data.sendPort_pid :: nfull(buffer) -> buffer!data; sender.c!connInOk,data.sendPort_pid fi }

:: atomic{ receiver.c?outRequest; if :: empty(buffer) -> receiver.c!connOutFail :: nempty(buffer) -> buffer?data; receiver.d!data; sender.c!recvOk,data.sendPort_pid } :: atomic{ receiver.c?outRequest; if :: empty(buffer) -> receiver.c!connOutFail :: nempty(buffer) -> buffer?<data>; receiver.d!data} od }

Basic Assumptions for Connectors Sends connInOk when the message is successfully

buffered; sends connInFail when it fails to buffer themessage (e.g. when the buffer is full) leaves to the sendPort to decide what to do with these

feedbacks

Sends connOutFail when the requested message is notavailable; otherwise directly delivers the message to therecvPort

Always sends recvOk to the corresponding sendPort whena message is delivered to a recvPort Although the sendPort may not care

Subtlety of the semantics of connectors(notes)

When my buffer is full,

Do not accept the sending of messages to me

Works with blocking send, but not nonblocking send

Accept the sending of messages, but hold the newly receivedmessage which will be eventually put into the buffer (retry by theconnector)

has a cache that holds up to 1 message, what happens if there aremore waiting

The blocking semantics could also be implemented using “retry by thesend port”

Accept the sending but just drops the message (lossy), in this case,do I send connInfail?

Does not work with blocking send

Example Variations ofMessage Passing Semantics

Synchronous ~ Asynchronous A synchronous sender sends a message and waits until it is

told that the message has been received An asynchronous sender sends a message and returns right

away regardless whether the message has been received

Blocking ~ Nonblocking ~ Checking Selective ~ Nonselective Copy ~ Remove Buffer type


Synchronous ~ Asynchronous Blocking ~ Nonblocking ~ Checking

Blocking receive / nonblocking receive Blocking send / nonblocking send / checking send

Selective ~ Nonselective Copy ~ Remove Buffer type


Synchronous ~ Asynchronous Blocking ~ Nonblocking Selective ~ Nonselective

A selective receiver could specify certain matching criteriafor retrieving messages

A nonselective receiver accepts any message it gets

Copy ~ Remove Buffer type


Synchronous ~ Asynchronous Blocking ~ Nonblocking Selective ~ Nonselective Copy ~ Remove

A receiver may choose to copy a message or remove amessage from a buffer when it does a receive

Buffer type


Synchronous ~ Asynchronous Blocking ~ Nonblocking ~ Checking Selective ~ Nonselective Copy ~ Remove Buffer type

Size, ordering (e.g. FIFO queue, priority queue) Reliable or lossy

Connection Rules Components cannot interact with each other without

going though ports and channels A component can have more than one send or receive ports

Each port mediates between one component and onechannel

Each channel can have connections to more than oneport A channel cannot interact with a component directly

Currently assuming a static model

Asynchronous Nonblocking Send msc Asynchronous Nonblocking Send


m

m

“inOk” / “inFail”


m

“recvOk”

Asynchronous Blocking Send msc Asynchronous Blocking Send

sender channelsend port

m

m

“inOk”

m

“recvOk”


Synchronous Blocking Send msc Synchronous Blocking Send


m

m “inOk”

“sendOk”

“recvOk”

m

Synchronous Nonblocking Send msc Synchronous Nonblocking Send


m

m “inOk” /“inFail”

m“recvOk”

SendStatus = “sendFail”

(if “inFail”)

(if “inOk”)

SendStatus = “sendOk”

Blocking Receive

msc Blocking receive

receiver channelreceive port

RecvRequest

“outOk”

m

RecvStatus = “recvSucc”

RecvRequest

m

Nonblocking Receive

msc Nonblocking receive

receiver channelreceive port

RecvRequest

“outOk”RecvStatus = “recvSucc”

RecvRequest

m

“outFail”RecvStatus = “recvFail”

Null

The Single-lane Bridge Example Version 3: Emergency vehicles may enter the bridge

from either side Emergency vehicles have higher priorities to enter the bridge

Change Blue_Enter and Red_Enter to priority queues

When there is an emergency vehicle waiting , anEmergency_Stop message is sent so that the controller atthe other side can stop accepting cars onto the bridge andyields turns sooner

Introducing new connectors between two controllers fromemergency_stop signal

Using copy receive ports (instead of remove receive ports) tocheck if there is an emergency vehicle waiting

The Single-lane Bridge Example Version 1: At each turn, exactly N cars from the

current direction can enter the bridge No communication is needed between two controllers

Version 2: At each turn, up to N cars from thecurrent direction can enter the bridge Turns can be yielded immediately if no more cars are

waiting before the total number reaches N Controllers need to use nonblocking receive instead of blocking

receive A controller has to notify the other controller of the actual

number of cars that have entered the bridge Introducing new connectors between two controllers Introducing new ports for controllers

C1

C2

C5 C4

C3

Standard Component Interfaces – The first step to “plug-and-play”

Publish/subscribeRPC

Componentinterfaces

C1

C2

C5 C4

C3


Message passingRPC

A different interaction mechanism

Componentinterfaces

C1

C2

C5 C4

C3


RPC

A variation of themessage passinginteraction mechanism

Message Passing

Componentinterfaces

Ports and Channels

C1

C2

C5 C4

C3

RPC

MP

Componentinterfaces

Ports

Channel

architectural building blocks for plug-and-play system...

Documents