Component-based design and connector synthesis (Lecture 1)

Component-based design and connector synthesis(Lecture 1) GSSI PhD in Computer Science L’Aquila, Italy Nov 11th, 2013 • Massimo Tivoli • Email: massimo.tivoli@univaq.it

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 compositionwith 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.)

Object-oriented design vs component-based design OO design 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 • Objects fit together like pieces in a jigsaw puzzle • System interaction mechanisms can be designed into the objects

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

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) FileHandler • Input actions, e.g., open, • model • methods that can be called; • receiving messages; • return values. open write read • Output actions, e.g., ack, • model • method calls; • message transmission; • exceptions. close ack

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 desired behavior specification already interacting black-box components their interaction may deadlock… …or violate a specified desired behavior Component 1 Component 3 Component 2 solution Component 1 Component 3 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 Coordinator Component 2

The need for coordinators: the shared resource scenario AlternatingProtocol desired behavior specification Deadlock! Screenshots from the SYNTHESIS tool. I’ll give a short demo of it.

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) Login CreateOrder SelectItem SetItemQuantity Close MOON Client (MC) Login SetItemQuantity CreateOrder SelectItem PayThirdParty Close ConfirmItem CloseOrder Interaction mismatches concern the semantics and granularity of protocol actions CloseOrder PayThirdParty ConfirmItem GetConfirmation PlaceOrder BLUE Service (BS) GetConfirmation AddItemToOrder StartOrder GetConfirmation Quit PlaceOrder AddItemToOrder Quit AddItemToOrder StartOrder

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) a Coordinator Free Architecture (CFA) is a set of components directly connected in a synchronous way in CCS : (C1 | C2 | ... | Cn) \ Ui=1..n Acti • Coordinator Free Architecture (CFA) Component 1 Component 2 channel channel Component 3

Automatic synthesis of centralized FFC: background notions top Component 1 bottom channel 1 REQUEST top NOTIFICATION Coordinator bottom channel 3 channel 2 top top Component 2 Component 3 bottom bottom • Coordinator Based Architecture (CBA) 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 AC-Graph: the inner knowledge msg1? msg1C msg2C msg2? msg1 msg2 msg2 msg1 Knowing the composition mechanism and the property msg3? msg3C AS-Graph: assumptions on the environment msg3 msg3 Knowing the characteristics of the coordinator EX-Graph: assumptions on the coordinator How to model all the local views from the component perspective?

Automatic synthesis of centralized FFC: component local views unification C1 C2 Coordinator C3 msg2C2 msg2C1 msg2? msg1C2 msg1C1 msg1? msg1? msg1? msg1C3 msg2? msg2? msg2C3 coordinator graph obtained by the unification of the EX-Graphs msg1C1 msg1C3 msg2C1 msg2C3 msg1C2 msg2C2 msg1C3 is based on a usual first-order unification algorithm

Table Table Deadlock Scenario: • 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; Coordinator Coordinator Free Architectural View Coordinator Based Architectural View Automatic synthesis of centralized FFC: deadlock freedom • Dining Philosophers Problem by assigning a deadlock-free routing policy to the coordinator, it is possible to avoid the deadlock scenario

Automatic synthesis of centralized FFC: 3-step method local views of each component Component 1 Component 3 Component 1 Component 1 Component 3 Component 3 Coordinator code (assembly code) (no-op) Coordinator Coordination policy deadlock-freeness Failure-free Coordinator Deadlock-free Coordinator Component 2 Component 2 Component 2 Coordinator Based Architecture Deadlock-free Coordinator Based Architecture Failure-free Coordinator Based Architecture Coordinator Free Architecture Component 1 Component 3 Component 2

Automatic synthesis of centralized FFC: running example CFA P C C1 and C2 has to interact by following an Alternating Interaction Protocol

Automatic synthesis of Centralized FFC:running example Deadlock-free Coordinator No-op Coordinator

Automatic synthesis of centralized FFC: running example • - The Failure-free Coordinator is a refinement • of the deadlock-free one that obeys the • alternating protocol specified by P • It is obtained by performing a suitable notion • of synchronous product between P and the • deadlock-free coordinator

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(); ... } Automatic synthesis of centralized FFC: running example (k0,p0) ?C3.method1_1 • These interfaces export • three services: • - method1 (affected by the policy) • method2 (affected by the policy) • method3 (a simple delegation) !C3.method1_3 ?C3.retValue1_3 !C3.retValue1_1 (k9,p1) C1 C3 C2 COORDINATOR COMPONENT 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; } • 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…

Automatic Synthesis of distributed FFC: the reference architectural style black-box components standard communication synchronous channels coordination wrappers asynchronous channels additional communication f1 f2 Distributed CBA f3 f4 a demo for this approach, and related SYNTHESIS tool, will be given later…

Automatic synthesis of distributed FFC: first step of the method Centralized Coordinator-Based Architecture (Centralized CBA) Coordinator-Free Architecture (CFA) C1 C2 Centralized Coordinator C3 C4 based on the previous approach

Automatic synthesis of distributed FFC: second step of the method Centralized CBA C1 C2 1) Deadlock-freedom analysis Centralized Coordinator (LTS) 2) Desired behavior analysis C3 C4 Desired behaviorspecification: LTS-based notation

Automatic synthesis of distributed FFC: second step of the method Distributed CBA • Distributed Coordinator(i.e., set of wrappers) • Deadlock free • Desired behavior satisfying • (automatically distributed by Synthesis) C1 C2 W2 W1 Centralized Coordinator W3 W4 C3 C4

C1 C1 C2 C2 C3 C4 C1 C2 C3 C4 W1 W2 W3 W4 C3 C4 Automatic synthesis of distributed FFC: summing up

Component-based design and connector synthesis (Lecture 1)