Coordination of Software Components with BIP: Application to OSGi Simon Bliudze Anastasia Mavridou Radoslaw Szymanek Rigorous System Design Rigorous System Design Crossing-Tech S.A. Laboratory EPFL Laboratory EPFL 1015 Lausanne, Switzerland 1015 Lausanne, Switzerland 1015 Lausanne, Switzerland radoslaw.szymanek@crossing- simon.bliudze@epfl.ch anastasia.mavridou@epfl.ch tech.com Alina Zolotukhina Rigorous System Design Laboratory EPFL 1015 Lausanne, Switzerland alina.zolotukhina@epfl.ch ABSTRACT 1. INTRODUCTION Coordinating component behaviour and access to resources When building large concurrent systems, one of the key is among the key difficulties of building large concurrent sys- difficulties lies in coordinating component behaviour and, in tems. To address this, developers must be able to manipu- particular, concurrent access to resources. Native mecha- late high-level concepts, such as Finite State Machines and nisms such as, for instance, locks, semaphores and monitors separate functional and coordination aspects of the system allow developers to address these issues. However, such so- behaviour. OSGi associates to each bundle a state machine lutions are complex to design, debug and maintain. Indeed, representing the bundle's lifecycle. However, once the bun- coordination primitives are mixed up with the functional dle has been started, it remains in the state Active| the code, forcing developers to keep in mind both aspects simul- functional states are not represented. Therefore, this mech- taneously. Finally, in concurrent environments, it is difficult anism is not sufficient for coordination of active components. to envision all possible execution scenarios, making it hard In this paper, we present a methodology for functional to avoid common problems such as race conditions. component coordination in OSGi by using BIP coordination The coordination problem above calls for a solution that mechanisms. BIP allows us to clearly separate the system- would allow developers to think on a higher abstraction level, wide coordination policies from the component behaviour separating functional and coordination aspects of the system and the interface that components expose for interaction. behaviour. For instance, one such solution is the AKKA li- By using BIP, we show how the allowed global states and brary [15] implementing the Actor model. An actor is a state transitions of the modular system can be taken into component that communicates with other components by account in a non-invasive manner and without any impact sending and receiving messages. Actors process messages on the technology stack within an OSGi container. atomically. The state of an actor cannot be directly ac- cessed by other actors, avoiding such common problems as Categories and Subject Descriptors data races. However, component coordination and resource management are still difficult. Fairly complex message ex- D.2.1 [Software Engineering]: Requirements/Specifications| change protocols have to be designed, which are spread out Methodologies; D.2.2 [Software Engineering]: Design Tools across multiple actors. Any modification of the coordination and Techniques|Modules and interfaces, State diagrams policy calls for corresponding modifications in the behaviour of several actors, potentially leading to cascading effects and General Terms rendering the entire process highly error-prone. Our approach relies on the observation that the behaviour Design, Reliability of a component can be represented as a Finite State Machine (FSM). An FSM has a finite set of states and a finite set of Keywords transitions between these states. Transitions are associated BIP, OSGi, Component coordination, Concurrency to functions, which can be called to force a component to take an action or to react to external events coming from the environment. Such states and transitions usually have intu- itive meaning for the developer. Hence, representing com- Permission to make digital or hard copies of all or part of this work for ponents as FSMs is a good level of abstraction for reasoning personal or classroom use is granted without fee provided that copies are about their behaviour. In our approach, the primitive coor- not made or distributed for profit or commercial advantage and that copies dination mechanism is the synchronisation of transitions of bear this notice and the full citation on the first page. To copy otherwise, to several components. This mechanism gives the developers a republish, to post on servers or to redistribute to lists, requires prior specific powerful and flexible tool to manage component coordina- permission and/or a fee. MiSE ’14, June 2 - June 3, 2014, Hyderabad, India tion. This allows a clear separation between the component Copyright 14 ACM 978-1-4503-2849-4/14/06 ...$15.00. provide classes and services that can be used by other bun- dles. A service is defined by the Java interface it implements. A state machine representing the bundle's lifecycle (Figure 1) is associated to each bundle. A bundle can be in one of the states Installed, Resolved, Active, etc. However, once the bundle is started, it remains in the state Active| the func- tional states are not represented. Hence, this mechanism is not applicable for coordination of active components. Figure 1: Bundle lifecycle in OSGi. 2.2 The BIP framework BIP [6] is a component framework encompassing rigor- ous system design. In BIP, systems are constructed by su- behaviour and system-wide coordination policies. perposing three layers of modelling: Behaviour, Interaction, For coordination scenarios that require a global state in- and Priority. Behaviour consists of a set of components formation, dedicated monitor components can be added in modelled by FSMs that have transitions labelled with ports. straightforward manner. This allows to centralise all the in- Ports form the interface of a component and are used to formation related to the coordination in one single location, define interactions with other components. instead of distributing it across the components. Further- The second layer models interaction between components. more, it considerably simplifies the system maintenance and Interaction models define allowed synchronization between improves reusability of components. Indeed, components do components and can be represented in many equivalent ways. not carry coordination logic based on the characteristics of Among these are the Algebra of Connectors [10] and boolean any specific execution environment. formulæ on variables representing port participation in in- An observable trend in software engineering is that de- teractions [11]. Connectors are most appropriate for graph- sign becomes more and more declarative. Developers pro- ical design and interaction representation, whereas boolean vide specifications of what must be achieved, rather than formulæ are most appropriate for manipulation and efficient how this must be achieved. These specifications are then encoding. When several interactions are possible, priorities interpreted by the corresponding engines, which generate | can be used as a filter. Interaction and Priority layers are often on the fly | the corresponding software entities. Thus, collectively called glue. In this paper, we only consider in- it is not always possible to instrument or even access the ac- teraction models and leave priorities for future work. tual source code. Furthermore, it is usually not desirable The BIP framework comprises a language and an associ- to modify such code, since this can lead to a considerable ated tool-set supporting the Rigorous Design Flow [6]. The increase of the maintenance costs. Our approach is based on BIP language allows building complex systems by specify- a non-invasive mechanism relying, for the interaction with ing the coordination between a set of atomic components. the controlled components, on existing API. The execution of a BIP system is driven by the BIP Engine We present a methodology for functional component co- applying the following protocol in a cyclic manner: ordination by using BIP coordination mechanism and its implementation based on OSGi that: 1. Upon reaching a state, each component notifies the BIP Engine about the possible outgoing transitions; • allows clear separation between component behaviour and system-wide coordination policies; 2. The BIP Engine picks one interaction satisfying the glue specification and notifies the involved components; • improves component usability and simplifies system maintenance; 3. The notified components execute the functions associ- ated to the corresponding transitions. • does not require access to the source code. Our work is based on implementing functional component The paper is structured as follows. Section 2 provides coordination by using the BIP coordination mechanisms. background information about OSGi and BIP. Section 3 However, the BIP language and tools mentioned above are presents the models of the Camel routes use case. Section 4 not used in this approach. shows how the proposed methodology is applied in practice. Section 5 describes the implemented software architecture. Section 6 discusses related work and Section 7 concludes the 3. CAMEL ROUTES USE CASE paper. Using BIP allows taking into consideration the structure of the controlled software and the coordination constraints 2. BACKGROUND imposed by the safety properties. BIP coordination exten- sion for OSGi has been implemented and tested in Con- 2.1 The OSGi standard nectivity FactoryTM1, the flagship product of Crossing-Tech S.A. The main use-case