We present in this paper the Eclipse Coordination Tools (ECT), a set of visual tools for modeling, testing

and executing Reo connector in the Eclipse development environment

Arbab, F. (Farhad)

Krause, , (Christian) C. (born Köhler, , C.)

Maraikar, Z. (Ziyan)

Moon, Y.-J. (Young-Joo)

Proença, J.M.P. (Jose)

English

We present in this paper the Eclipse Coordination Tools (ECT), a set of visual tools for modeling, testing
\nand executing Reo connector in the Eclipse development environment

Krause, , (Christian) C. (born K\xc3\xb6hler, , C.)

Proen\xc3\xa7a, J.M.P. (Jose)

CWI's Institutional Repository

Replace this file with prentcsmacro.sty for your meeting,or with entcsmacro.sty for your meeting. Both can befound at the ENTCS Macro Home Page.Modeling, Testing and ExecutingReo Connectors with theEclipse Coordination Tools 2F. Arbab, C. Koehler1, Z. Maraikar, Y.-J. Moon, J. ProencaCWI, P.O. Box 94079, 1090 GB Amsterdam, The NetherlandsAbstractWe present in this paper the Eclipse Coordination Tools (ECT), a set of visual tools for modeling, testingand executing Reo connector in the Eclipse development environment.Keywords: Reo, Eclipse Coordination Tools1 IntroductionCoordination models and languages are a way of dealing with the growing com-plexity of concurrent systems by separating the active parts performing the com-putations, i.e. components or services, from those parts that glue these pieces ofsoftware together, i.e. component or service connectors. The task of connectors isto coordinate the interaction of the components, by enforcing some kind of protocolfrom outside, which is also referred to as exogenous coordination. The coordina-tion language Reo [?] instantiates these very abstract notions with a compositionalchannel-based calculus. As a counterpart to this formal framework we present inthis paper the Eclipse Coordination Tools [?]: a set of integrated tools for Reo,implemented as plug-ins for the Eclipse 3 development environment.The rest of this paper is organized as follows. We introduce Reo briefly inSection 2. An overview of the tools is given in Section 3. Conclusions and futurework are presented in Section 4.1 Corresponding author, e-mail: christian.koehler@cwi.nl.2 The work in this paper is supported by NWO/GLANCE projects WoMaLaPaDIA and SYANCO.3 Eclipse platform: http://www.eclipse.orgc©2009 Published by Elsevier Science B. V.Arbab, Koehler, Maraikar, Moon, Proenca2 Reo OverviewReo is a channel-based coordination language wherein channels are primitive, user-defined entities that have two ends which can be either sources or sinks. Source endsaccept data into and sink ends dispense data out of channels. Each channel typeimposes its own constraints on the possible data flow at its ends, e.g. synchronyor mutual exclusion. For instance, the Sync channel ( ) synchronously readsdata items from its source end and writes it to its sink end without buffering them.The LossySync ( ) behaves similarly, except that it looses the data when noone is ready to read it from its sink end. While these two channels are both un-buffered, the FIFO1 ( ) can store a single data item and release it again whensomeone tries to read from it. The SyncDrain ( ) has–unlike the channelsintroduced so far–two source ends and hence is not directed. If there are data itemsavailable at each of its ends, this channel consumes both of them synchronously.Channels can be composed by joining them into nodes. Such a composite struc-ture is called a connector in Reo and has some similarities with electrical circuits.As mentioned before, channels are user-defined. However, nodes have a fixed be-haviour in Reo. A node atomically does a destructive read at one of the sink endsand replicates the data item at all of its attached source ends. With this simplebehaviour of nodes and a small set of basic channels, complex protocols can beimplemented compositionally, i.e. by just plugging together channels and nodes.Fig. 1. a) exclusive router, b) ordering connector.For instance, the exclusive router, shown in Fig. 1a, routes data from A toeither B or C. If both, B and C, are able to receive data the choice is madenondeterministically. The mutual exclusion that is implemented by this connectoris due to the fact that the internal node I allows input only from exactly one of itssink ends. The second connector, shown in Figure 1b, imposes an ordering on thedata flow from the input nodes A′ and B′ to the output node C ′. The SyncDrainsynchronises the two inputs and the FIFO1 delays the items from B′.The minimalistic set of core concepts that Reo introduces is surprisingly power-ful. A number of formalisms have been invented to model the different facets of Reoconnectors (see, e.g., [?,?,?]). These formalisms are not only nice from the theoret-ical point of view, but they further serve as a strong basis for implementing Reo.This includes tools for the modeling and verification of connectors (i.e. interactionprotocols) as well as actual runtime engines.2Arbab, Koehler, Maraikar, Moon, Proenca3 ToolsThe tool suite for Reo consists of development tools for designing and verificationof connectors on the one hand and runtime engines for multiple platforms on theother. The development tools are implemented as plug-ins for the Eclipse platform.Front-ends of these plug-ins are referred to as views in following. We now introducethe core tools separately and give references for further reading where possible.EditorOne of the key tools in our framework is the graphical Reo editor, which is depictedin Fig. 2. It not only allows us to design connectors by simple drawing operations,but it serves also as a bridge to a number of other tools that can be either invokedfrom the context menu or directly interact with it. Reo files are saved using anXML format. The model classes and the parser for this format can be used also instand-alone applications which is possible for most of the tools presented here.Fig. 2. Valve connector in the Reo editor. This connector models a synchronous communication channelthat can be opened and closed by a third party.AnimationThe animation view generates Flash animations of connectors on-the-fly. Fig. 3depicts the connector that was shown in the editor before in the animation view.The parts of the connector with synchronous data flow are highlighted. Tokens movealong these synchronous regions. On the left side there is a list of possible animationsfor this connector and the attached writers and readers (white boxes), modeling theenvironment of the connector. The underlying formalism for the synthesis of suchanimations is an extension of the colouring semantics [?], introduced by Clarke et al.Fig. 3. Valve connector in the animation view. In this state, the communication channel is open and dataflows through it.3Arbab, Koehler, Maraikar, Moon, ProencaModel checkerFor model checking, connectors are translated to a semantic model, called Con-straint Automata [?], which elegantly describe the synchronisation performed byconnectors depending on their internal states. Moreover, these automata are com-positional in the sense that it is possible to derive the automaton of a connectorby composing the automata of its constituent channels. The core automata toolsinclude a graphical editor and a conversion tool to generate them from connectors.Our model checker uses a symbolic model and a CTL-like logic as specificationformat. Properties like deadlock-freeness and behavioural equivalence of connectorscan be verified as well. The model checker for Reo has been implemented by thegroup of Christel Baier at the Technical University of Dresden [?] and is integratedinto the rest of the ECT as a model checker view.Performance analysisAnother semantic model for connectors is the Quantitative Intentional Automata(QIA), which are an extension of Constraint Automata with quantitative properties,such as arrival rates at ports and average delays of dataflows between ports. Forperformance analysis, these automata are translated to Continuous-Timed MarkovChains [?] and fed into the PRISM model checker [?]. With this approach, wecan reason about properties like average response times and meetings of deadlines,and further analyse worst/best case scenarios. Moreover, the QIA model is compo-sitional and the generated Markov Chains are very compact, enabling an efficientmodel checking. As an example, the QIA of the Ordering is shown in Fig. 4.Fig. 4. Quantitative Intentional Automata of the Ordering connector.Code generationConstraint automata are not only used for model checking, but they also serve asthe basis for generating executable Java code. Similar to the model checker, thecode generation is a two-step process. First, the connector is translated to a con-straint automaton. Then, the automaton is used to generate a Java state-machinecoordinator. A runtime library implements constraint automaton ports as blockingzero-length buffers. Additionally, a graphical wiring editor lets users connect Javacomponents to the coordinator by pairing corresponding ports together. Althoughthe existing code-generator is limited to Java, a new retargetable generator capableof generating C, BPEL, etc. is currently under construction. The new framework4Arbab, Koehler, Maraikar, Moon, Proencaalso supports loading and interpreting constraint automata at runtime, which isuseful for deploying Reo coordinators in Java application servers etc.Distributed implementationA distributed Reo engine allows for the creation of Reo primitives within thatengine, and can be connected to primitives in other distributed Reo engines. Thisis performed automatically by allowing a single node to be scattered in more thanone engine. The synchronisation aspect inherent in Reo requires these primitives toplay an active role when searching for an agreement on the global behaviour of thedistributed connector. The deployment view provides the possibility of interactingwith the Reo engines, deploying channels on different engines, and reconfiguringdeployed systems. Higher level operations, such as the discovery of the best enginefor each subpart of a Reo connector, are still out of the scope of this plug-in.ReconfigurationWe follow an approach to modeling reconfigurations, i.e., changes in the topology ofReo connectors using algebraic graph transformation [?]. The reconfiguration modeland engine are already implemented together with a basic reconfiguration view. Upto now, reconfiguration rules are used only inside the editor and for dynamic creationof connectors from templates. An integration with the distributed engine is plannedin our future work for dynamic reconfiguration triggered by data flow.4 ConclusionThe Eclipse Coordination Tools is a powerful tool suite for Reo. Key features areits versatility and strong underlying formal models. Future work includes a formalcomparison and integration of these models, the further development of the existingtools and an integration with modelling languages such as UML and BPMN.5

Modeling, Testing and Executing Reo Connectors with the Eclipse Coordination Tools

Abstract

Similar works

Full text

Available Versions

CWI's Institutional Repository