component-based design and connector synthesis (lecture 1) massimo tivoli email:...

Component-based design and connector synthesis(Lecture 1)

Massimo TivoliEmail: [email protected]

GSSI PhD in Computer Science L’Aquila, ItalyNov 11th, 2013

Roadmap of this lecture

•CBSE basic principles

•What is a component?

•Object-oriented design vs component-based design

•What is a connector?

•Connector synthesis•background notions•synthesis of centralized coordinators [SCP08]•synthesis of distributed coordinators [JSS08]

(very briefly)

What is CBSE and why?

•CBSE was born at the end of 90’s as a reuse-based software engineering approach•huge number of software applications available•OO development was found to be less appropriate•time-to-market

•Focus on reuse of third-party software entities and their integration according to a certain goal

CBSE essentials

•Independent components

•Component standards

•Middleware

•Development process

CBSE’s open issues

•Component trust

•Component certification

•Emergent properties prediction

•Requirement tradeoffs

CBSE’s open issues

• Component trust• black-box nature• unexpected internal behavior• malicious behavior

• Component certification• in case a component does not behave as expected, it is very difficult to

establish responsibilities• conformance check against a formal specification is not of much

interest for the industry

• Emergent properties prediction• although one could use trustworthy and certified components, once

they are put together in an uncontrolled way, the resulting system can exhibit some issues or undesired properties

• automated or systematic methods to solve integration issues are crucial to effectively support correct-by-construction component assembly

• Requirement tradeoffs• it is very frequent that the available components do not completely

reflect the specified local requirements• systematic tradeoff analysis methods are highly needed

This is the main focus of my 2 lectures on“Component-based design and connector synthesis”

What is a component?

• In the literature there exist several definitions of the component concept (indeed, too many!)

•“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition.” [C. Szyperski, Component Software – Beyond Object Oriented Programming, Addison Wesley, 1998]

•“A component is a unit of distributed program structure that encapsulates its implementation behind a strict interface comprised of services provided by the component to other components in the system and services required by the component and implemented elsewhere. The explicit declaration of a component's requirements increases reuse by decoupling components from their operating environment.” [S. Crane, Component Interaction in Distributed Systems, ICCDS’98]

So, what is a component?(a revised version of Michael Stal’s definition - http://www.softwareresearch.net/fileadmin/src/docs/publications/J010.pdf)

•A component is a self-contained black-box entity that provides (resp., requires) functionalities to (resp., from) its environment by defining its interfaces, hence making them public (i.e., accessible from outside)

•An interface defines the syntax and (as much as possible) the semantics of the functionalities it comprises and, hence, represents a contract between the component and its environment

•In order to build an assembly, components may support their composition with other components by providing “quasi-reflective” mechanisms (such as introspection, controllability, configuration management, etc.)

OO design•Objects fit together like

pieces in a jigsaw puzzle

•System interaction mechanisms can be designed into the objects

CB design•Components are really

loosely-coupled

•Interaction mechanisms left out of the individual components

•The interaction mechanisms a component rely on depend on the context and its environment

Object-oriented design vs component-based design

Component-based design

•The components that comprise a system typically do not exactly fit together as pieces of a jigsaw puzzle

•They leave significant integration gaps that must somehow be filled with additional code

•Such integration code is often referred to as “assembly code” and is typically highly special purpose and specific

•Thus, by simplifying matters, a component-based system consists of component instances and their connectors (i.e., the “assembly code”)

What is a connector?

•Architectural element that models

•Simple interactions

•Complex & semantically rich interactions

•Each connector provides

What is a connector?

•Connector Component

•Interaction abstraction and/or parameterization

•Specification of complex interactions

•Connectors allow to realize component independence

Software connector roles

•Locus of interaction among set of components

•Protocol specification (sometimes implicit) that defines its properties

•(some) Roles•communication•coordination•mediation/adaptation

Connectors as communicators

•Focus on the middleware layer

•Support for defining•different communication mechanisms•constraints on communication structure/direction•constraints on quality of service

•Separates communication from computation

•May influence non-functional system characteristics

Connectors as coordinators

•Focus on the application layer

•Determine computation control

•Control delivery of data

•Separates the control-flow from the computation

•Orthogonal to communication and mediation/adaptation

Connectors as mediators/adapters

•Focus on both the application layer and the middleware layer

•Enable interaction of independently developed, mismatched components

•Mismatches based on interaction







(very briefly)

Automated connector synthesis

•CBSE promotes the extensive and dynamic reuse of heterogeneous and independent software components

•Heterogeneous components may be willing to cooperate in order to reach some common goal even though they meet dynamically and do not have a priori knowledge of each other

•Challenge: how to automatically achieve the interoperability between heterogeneous components?

Modeling the component observable behavior aka component protocol

•The term protocol refers to interaction protocols or observable protocols

•We consider application-layer protocols (as opposed to middleware-layer protocols)•behavior of a component in terms of the sequences of messages

at the interface level, which it exchanges with other components• the notion of protocol abstracts from the content of the

exchanged messages, i.e., values of method/operation parameters, return values, etc.

•Our focus is on harmonizing the behavioral protocol (e.g., scheduling of operation calls) of heterogeneous components rather than performing mediation of communication primitives or of data encoding/decoding (i.e., middleware-layer connectors)

Modeling application-layer protocols: an example

•By using Labeled Transition Systems (LTSs)

Input actions, e.g., open,model - methods that can be called;- receiving messages;- return values.

Output actions, e.g., ack,model- method calls;- message transmission;- exceptions.

openwrite read

close

ack

FileHandler

Interoperability

• The ability of heterogeneous protocols to interact and correctly coordinate to achieve their goal(s)

• Interaction expressed as synchronization• two protocols interact if they are able to synchronize on common

actions• for application-layer protocols, it goes beyond single basic

synchronizations and may require a well defined sequence of synchronization to be achieved (a primary from of coordination)• E.g., sendItems <-> receiveItems (simple case)

sendItems <-> receiveItem … receiveItem (more complex case)

• Coordination expressed as the achievement of a specified goal• two protocols succeed in coordinating if they interact through

synchronization according to the achievement of their goal(s)

• Goal usually specified in some automata-based or temporal logic formalism

The interoperability problem

• It concerns the problem of both enabling interaction and achieving correct coordination (w.r.t. the specified goal)

• Solution: automatic synthesis of application-layer connectors

• Automatic coordinator synthesis (my past research)• the main focus is on addressing correct coordination by assuming

the interaction problem already solved

• Automatic mediator synthesis (my recent research in the CONNECT EU project)• it focuses on the whole interoperability problem, i.e., addressing

interaction + correct coordination

The need for coordinators

Component 1 Component 3

Component 2

already interacting black-boxcomponents

desired behaviorspecification

their interaction may deadlock……or violate a specified desiredbehavior

the coordinator is an additional component synthesized so as to intercept all component interactions in order to prevent deadlocks and those interactions that violate the specified desired behavior


Component 2

Coordinator

solution

The need for coordinators: the shared resource scenario

AlternatingProtocol desiredbehavior specification

Screenshots from the SYNTHESIS tool. I’ll give a short demo of it.

Deadlock!

The need for mediators: scenario 1 of the SWS challenge (http://sws-challenge.org/wiki/)

• Two components implemented using different standards and protocols: the Moon Client (MC) and the Blue Service (BS)

MOONClient(MC)

Login CreateOrder SelectItem SetItemQuantity

CloseOrderConfirmItemClose PayThirdParty

Login CreateOrder SelectItem SetItemQuantity

PayThirdParty

Close

ConfirmItemCloseOrder

BLUEService

(BS)StartOrder AddItemToOrder GetConfirmation PlaceOrder Quit

GetConfirmation

StartOrderAddItemToOrder

AddItemToOrder

Quit

GetConfirmation

PlaceOrder

Interactionmismatches concernthe semantics andgranularity of protocolactions

http://sws-challenge.org/wiki/







(very briefly)

Automatic synthesis of Failure-Free Coordinators (FFC)

•Interaction issues are assumed to be already solved• protocols are already able to synchronize, although deadlocks in

their interaction can occur or their interaction could not satisfy specified behavioral properties

•A specific instance of the interoperability problem• given a set of interacting components, C, and a set of behavioral

properties, P, automatically derive a deadlock-free assembly, A, of these components which guarantees every property in P, if possible

• A is a composition of the components in C plus a synthesized coordinator

• the coordinator is an additional component that controls the message exchange to prevent possible deadlocks and those interactions violating the properties in P

•Two different approaches (following slides)• centralized coordinators• distributed coordinators

Automatic synthesis of centralized FFC: basic Idea

•A simple software architecture structure which exploits the separation between functional behavior and interaction behavior

•Extra information at component level: component assumptions

•Our approach•detect software anomalies•prevent software anomalies•guarantee given coordination policies (behavioral properties)

Automatic synthesis of centralized FFC: modeling

•Component behaviour modelled using finite state machines

•Assembly through parallel composition of component models

•In the context of CCS• Components: sequence and choice operators

E.g. FileHandler = open.(read + write)*.close.FileHandler

• Assembly: parallel composition and restriction operators E.g. (C1 | C2 | ... | Cn) / L

•Deadlock: (C1 | C2 | ... | Cn) / L can reach a state where no

actions are possible

Automatic synthesis of centralized FFC: assumptions

•Component requirement on its environment in order to guarantee a property in a specific integration context

•In a sense we are enhancing component semantics

•In our case we use: “My context never blocks me” or in other words “If I can perform action a, my context must be able to perform action a”

•Assumptions modeled in the same way as components

Automatic synthesis of centralized FFC: background notions (cont’d)

•Coordinator Free Architecture (CFA)

Component 1

Component 2 channel

Component 3

channel

a Coordinator Free Architecture (CFA) is a set ofcomponents directly connected in a synchronous way

in CCS : (C1 | C2 | ... | Cn) \ Ui=1..n Acti

Automatic synthesis of centralized FFC: background notions

•Coordinator Based Architecture (CBA)

RE

QU

ES

TN

OTIFIC

ATIO

N

Coordinatortop

bottom

Component 1

top

bottomchannel 1

Component 2top

bottom

channel 2

Component 3top

bottom

channel 3

in CCS:(C1[f1] | C2 [f2] | ... | Cn[fn] | K) \U i=1..n Acti[fi]

K is the synthesized connector, fi a suitable relabeling function

Automatic synthesis of centralized FFC: component local views

How to model all the local views from the componentperspective?

AC-Graph: the inner knowledgemsg1 msg2

msg3

Knowing the composition mechanism and the property

AS-Graph: assumptions on the environment msg1 msg2

msg3Knowing the characteristics of the coordinator

EX-Graph: assumptions on the coordinatormsg1? msg1C msg2C msg2?

msg3C

msg3?

coordinatorgraph obtainedby the unificationof the EX-Graphs

msg1C1

msg1C2

msg1C3

msg1C3

msg2C3

msg2C1

msg2C2

msg1C1

msg1?

msg2?

msg2C1msg1C2

msg1?

msg2?

msg2C2

msg1?

msg1C3

msg2C3

msg2?

C1 C2

C3

Coordinator

is based on ausual first-orderunification algorithm

Automatic synthesis of centralized FFC: component local views unification

•Dining Philosophers Problem

Coordinator Free Architectural View

• component Philosopher1 requests and gets the resource of component Fork1;

• component Philosopher2 requests and gets the resource of component Fork2;

• component Philosopher1 requests and waits for the resource of component Fork2;

• component Philosopher2 requests and waits for the resource of component Fork1;

Deadlock Scenario:

by assigning a deadlock-freerouting policy to the coordinator,

it is possible to avoid the deadlockscenario

Table

Coordinator Based Architectural View

Coordinator

Table

Automatic synthesis of centralized FFC: deadlock freedom

40


Component 2

Coordinator Free Architecture

Coordinator Based Architecture


Component 2

(no-op) Coordinator

local views of each component

deadlock-freeness

Component 1

Deadlock-free Coordinator Based Architecture

Component 3

Component 2

Deadlock-free Coordinator Coordination policy

Component 1

Failure-free Coordinator Based Architecture

Component 3

Component 2

Failure-free CoordinatorCoordinator code(assembly code)

Automatic synthesis of centralized FFC: 3-step method

CFA

C

P

Automatic synthesis of centralized FFC: running example

C1 and C2 has to interact byfollowing an Alternating InteractionProtocol

No-op Coordinator

Deadlock-free Coordinator

Automatic synthesis of Centralized FFC: running example

- The Failure-free Coordinator is a refinementof the deadlock-free one that obeys the alternating protocol specified by P

-It is obtained by performing a suitable notionof synchronous product between P and thedeadlock-free coordinator


•By visiting the LTS modeling the FFC protocol, the actual code implementing the coordinator component is automatically derived

•C++ implementation for COM/DCOM component-based systems (centralized FFC) – in this example…

•AspectJ implementation for J2EE applications, i.e., EJB component-based systems (distributed FFC) – in the following slides…

C1

C2

COORDINATOR COMPONENT

C3

These interfaces exportthree services:- method1 (affected by the policy)- method2 (affected by the policy)- method3 (a simple delegation)


HRESULT method1(S_DA da) { if(sLbl == 0) { if((chId == 1) && (pState == 0)) { pState = 1; sLbl = 9; return c3Obj->method1(da); } } … /* other if-statements for each FFC state in which it is possible to perform method1 */ …

return E_Handle;}

class K : public IC3 { // stores the current state of the coordinator private static int sLbl;

// stores the current state of the // property automaton private static int pState;

// stores the number of clients private static int clientsCounter = 0;

// channel's number of a client private int chId;

// COM smart pointer; is a reference to // the inner C3 object private static C3* c3Obj; ...

// the constructor K() { sLbl = 0; pState = 0; clientsCounter++; chId = clientsCounter; c3Obj = new C3(); ... }

?C3.method1_1

!C3.method1_3

?C3.retValue1_3

!C3.retValue1_1

(k0,p0)

(k9,p1)







(very briefly)

black-box components

synchronous channels

coordinationwrappers

standard communicationadditional communication

asynchronous channels

f3 f4

f1 f2

Distributed CBA

a demo for this approach, and related SYNTHESIS tool,will be given later…

Automatic Synthesis of distributed FFC: the reference architectural style

Centralized Coordinator-Based Architecture Centralized Coordinator-Based Architecture (Centralized CBA)(Centralized CBA)

C1C1 C2C2

C3C3 C4C4

Centralized CoordinatorCentralized Coordinator

Coordinator-Free Architecture (CFA)Coordinator-Free Architecture (CFA)

based on the previous approach

Automatic synthesis of distributed FFC: first step of the method

C1C1 C2C2

C3C3 C4C4

Centralized Coordinator Centralized Coordinator (LTS)(LTS)

Desired behaviorDesired behavior specification: specification: LTS-based notationLTS-based notation

1) Deadlock-freedom1) Deadlock-freedom analysisanalysis

P

Centralized CBACentralized CBA

2) Desired behavior2) Desired behavior analysis analysis

Automatic synthesis of distributed FFC: second step of the method

Distributed CBADistributed CBA

C1C1 C2C2

C3C3 C4C4

Centralized CoordinatorCentralized CoordinatorW1W1 W2W2

W3W3 W4W4

Distributed CoordinatorDistributed Coordinator((i.e.i.e., set of wrappers), set of wrappers)

» Deadlock freeDeadlock free

» Desired behavior Desired behavior satisfyingsatisfying

(automatically (automatically distributed by distributed by SynthesisSynthesis))

P

Automatic synthesis of distributed FFC: second step of the method

+

network of interactingcomponents (LTSs)

desired behavior LTS

(i.e., actual code of the component local

wrappers)

synthesis of the actual distributed and

correct coordinator

C1C1 C2C2

C3C3 C4C4

C1C1 C2C2

C3C3 C4C4

C1C1 C2C2

C3C3 C4C4

W1W1 W2W2

W3W3 W4W4

synthesis of the centralized

coordinator LTS

P

Automatic synthesis of distributed FFC: summing up

C1 C2

C3 C4

A possible deadlock can occur if both C3 and C4 perform the action at the right of the initial state s0

P

C3 cannotaccess resourceC2 without performingauthentication, first

Automatic synthesis of distributed FFC: running example

Red nodes represent possible occurring deadlocks


{}1

LCCF

pCSF LCC .1!2

4

{}2

LCCF

1.2!123

pCSF LCC

when C3 is willing toperform action p1, itswrapper, FC3, mustask permission to theother wrappers in order todiscover whether theglobal state is different fromS12 (C3 is allowed to performp1) or not (C3 is not allowedto perform p1)

E.g., S12 = <S3,S0,S0,S9>,FC3 will ask to FC1, FC2, andFC3, if their supervisedcomponents are in, or willreach, the states S3, S0, andS9, respectively


FC4

UA

S0 * S0 * *

S1 !C1.p S1 * *

S1 !C2.p1 S1 * *

S1 !C1.FreeP S1 * *

S1 !C2.FreeP1 S1 * *

FC3

UA

S0 !C2.Connect S1 * *

S1 !C1.p S1 * *

S1 !C2.p1 S1 * *

S1 !C1.FreeP S1 * *

S1 !C2.Connect S1 * *

S1 !C2.FreeP1 S0 * *

*****1

UACF *****

2UA

CF

each wrapper knowswhat are the propertystates from which it isallowed to perform someaction, which action, andthe related target states


•A wrapper FC establishes when its controlled component

C can move (by cooperating with the other wrappers FH):• The component C must be active (with respect to P)• Before moving by means of action a, FC checks in FC

LC if a is an action that can lead

to forbidden states• If it is, FC has to ask the permission to the other component wrappers before performing a

• If not, FC allows C to perform a without asking anything

• If C is allowed to perform action a, FC has to check in FCUA whether a makes P

change its state or not• If it does, FC has to send a block message to all the wrappers whose supervised component

cannot move (with respect to P) and an unblock message to all the ones whose supervised component was blocked, but now can move because of the new state of P

• When FC asked, to some FH, for the permission of performing an action• FH answer to FC whenever FH is in, or will reach, a state different from the one for which FH

has been enquired by FC

• otherwise, FH does not answer hence attempting to block FC

Automatic synthesis of distributed FFC: wrapper pseudo-code

• for each action, a pointcut is defined in order to intercept the corresponding method call

• for each action, an advice after() is defined in order to update the current local state (i.e., state), the property state (i.e., ps), and to inform all the other wrappers of the updated current local state (i.e., Notify())

For instance, the wrapper for C3 (i.e., for Client1) is anAspect instrumenting the .class of C3 as follows:

e.g., pointcut Connect_action() : call(int Server2.Connect(..));

e.g.,after() returning (int res) : Connect_action() { if((state.intValue() == 0) && (res != -1)) state = new Integer(0); if((ps.read() == 0) && (res != -1)) ps.write(1); Notify();}


•an advice around() is used to enforce the specified desired behavior, it is defined for any component action that is a negative action on the property automaton

• for each action a stored into the last chance states table, an advice before() is defined in order to eventually unblock possible wrappers still waiting for the permission to proceed and, in turn, ask for the permission to proceed on a

e.g.,int around() : FreeP1_action() { if((ps.read() == 0)) { return -1; } return proceed();}

e.g.,int around() : p1_action() { if((ps.read() == 0)) { return -1; } return proceed();}

e.g.,before() : p1_action() { Notify(); AmIAllowed();}


Bibliography

•[SCP08] M. Tivoli and P. Inverardi, Failure-free coordinators synthesis for component-based architectures (2008), in: Science of Computer Programming, 71:3(181-212)

•[JSS08] M. Autili, L. Mostarda, A. Navarra and M. Tivoli, Synthesis of decentralized and concurrent adaptors for correctly assembling distributed component-based systems (2008), in: Journal of Systems and Software, 81:12(2210-2236)

Component-based design and connector synthesis(Lecture 1)

Thank you for your attention!

Any questions?

GSSI PhD in Computer Science L’Aquila, ItalyNov 11th, 2013

Massimo TivoliEmail: [email protected]

component-based design and connector synthesis (lecture 1) massimo tivoli email:...

Documents

software component

component software

component concept

component interaction

unit of composition

thirdparty composition

decoupling components

components requirements