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]
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]
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]
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]
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
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)
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 1 Component 3
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
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)
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 1 Component 3
Component 2
Coordinator Free Architecture
Coordinator Based Architecture
Component 1 Component 3
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
Automatic synthesis of centralized FFC: running example
•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)
Automatic synthesis of centralized FFC: running example
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)
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)
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
Automatic synthesis of distributed FFC: running example
{}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
Automatic synthesis of distributed FFC: running example
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
Automatic synthesis of distributed FFC: running example
•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();}
Automatic synthesis of distributed FFC: running example
•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();}
Automatic synthesis of distributed FFC: running example
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]