Eva Kühn

Stefan Craß

Gerson Joskowicz

Alexander Marek
email: amarek@complang.tuwien.ac.at

Thomas Scheller

Peer-based Programming Model for Coordination Patterns

Modern distributed software systems must integrate in neartime parallel processes and heterogeneous information sources provided by active, autonomous software systems. Such lively information sources are e.g. sensory data, weather data, traffic data, or booking data, operated by independent distributed sites. The complex integration requires the coordination of these data flows to guarantee consistent global semantics. Design, implementation, analysis and control of distributed concurrent systems are notoriously complex tasks. Petri Nets are widely used to model concurrent activities. However, a higher-level programming abstraction is needed. We propose a new programming model for modeling concurrent coordination patterns, which is based on the idea of "peer workers" that represent re-usable coordination and application components. These components encapsulate behavior, structure distributed data and control flow, and allow integration of pre-existing service functions. A domain-specific language is presented. The usability of the peerbased programming model is evaluated with the Split/Join pattern.

Introduction

A common problem in software projects is the tightrope walk between design and implementation. While the designer's focus is to keep the system clean and verifiable under all possible operating conditions, the developer's main intent is getting things done while dealing with exceptional conditions in later refinements. The Peer Model that we introduce in this paper tries to bridge this gap, at least within a specified problem domain, by providing a domain-specific modeling language to design, analyze, and implement system integration patterns in distributed environments using predefined and application-specific components.

The need for methodologies that connect verifiable designs and implementations occurs especially in systems where a multitude of autonomous systems are cooperating to fulfill a specific task. One example that illustrates these problems is in the realm of distributed firewall configuration: firewalls belong to different organizations and the rollout of a new configuration must guarantee that no inconsistencies take place. Errors occur during the rollout process when sites are down, the network is unavailable, local configuration constraints are violated, access rights are not granted etc. A modeling tool is required to specify the configuration process. It must allow modeling when a valid state is reached, and at which time and under which conditions new configurations may become active in the entire network or in parts of it. This will be the case if e.g., a certain number or a majority of firewall sites reported back that they have implemented the updates. Network configuration is a dynamic and quite complex task with many different error situations. Failure impact analysis shall be possible for all different configuration possibilities. It is therefore desirable that this process can be modeled, verified, and executed. A service-oriented security concept for the coordination of such firewalls has been proposed in [START_REF] Craß | Securing a space-based service architecture with coordination-driven access control[END_REF], whereas in this paper, we investigate a new model for specification and implementation of complex coordination and integration patterns.

A further example that motivated the design of the Peer Model is from the rail traffic management domain. Here, measurement systems -like wheel sensors or RFID sensors -along the tracks generate information about approaching trains. This data is transported over mesh networks. A use case is for example a traffic control center that queries distributed sensors, collects answers, and aggregates them to a gain a sufficiently consistent view about the technical status of a train. As sensors are low cost components, wireless communication is error prone, and field conditions are harsh, many failure situations must be coped with.

Both examples have a basic pattern in common that consists of the following steps: 1) splitting of a task into individual subtasks to be executed by different nodes (firewalls resp. sensors), and 2) joining of received answers according to complex rules and under the assumption of failures, in order to derive a global decision. We term this recurring situation the Split/Join pattern and will use it as an example throughout this paper.

Many modeling methodologies for the purpose of designing concurrent software systems have been proposed, such as Petri Nets [START_REF]IEC 15909. High-level petri nets -concepts[END_REF], Reo [START_REF] Arbab | Reo: a channel-based coordination model for component composition[END_REF] and UML MARTE [START_REF] André | Modeling time(s)[END_REF]. These methodologies are general and not domain-specific, as they are used to solve almost any software problem. On the one hand, that is what makes them powerful as the designer can model everything, but on the other hand, the designer also does have to model everything and cannot assume any functionality to be present.

As the Peer Model is targeted at modeling coordination patterns in distributed environments, it can make several assumptions on the target system. For example, it assumes a tuple space-based communication middleware to be present and can therefore resort to transactional transmissions of data between communicating components and to coordination mechanisms for accessing distributed data structures. Additionally, it follows a component-based approach and assumes several predefined, reusable components to be present. Designers can also structure their scenario-specific coordination logic into new reusable components, rearranging the resulting models more clearly and providing better scalability when additional logic is added. New components can also be created by combining existing components and using them as sub-components, thus leading to a nested component structure. It is important to note that only coor-dination logic is modeled, not business logic. One weakness in Petri Net models of concurrent systems is that the resulting models mix business logic and coordination logic, thus reducing their readability and maintainability. For that reason our model strictly forbids defining arbitrary business logic within the model. Rather, it integrates and connects external services, thereby separating clearly concurrency, parallelism and distribution mechanisms of the collaborating components from the business logic.

The contribution of this paper is a higher-level programming and design model termed "Peer Model", or "PM" for short, aiming to ease the design and implementation of complex integration patterns in distributed environments. We introduce its Domain Specific Language (DSL), meta-model and graphical notation, but not its implementation itself and prove our claims by using its DSL to model a well-known pattern and comparing the resulting model to equivalent ones using Reo [START_REF] Arbab | Reo: a channel-based coordination model for component composition[END_REF] and Colored Petri Net [START_REF] Jensen | Coloured petri nets and CPN tools for modelling and validation of concurrent systems[END_REF] notation.

In Section 2 we introduce the Peer Model along with its graphical notation, Section 3 introduces the pattern used for evaluation purposes, Section 4 gives an overview of the Peer Model's meta-model and DSL. In Section 5 we compare our resulting model of the pattern with those of other modeling languages and Section 6 finally points out our conclusion and future work.

Peer Model

The Peer Model is a novel programming model targeted at developers of highly concurrent applications. Its design is inspired by asynchronous message queue or tuple space communication, staged event-driven architecture, and data-driven workflow. In the Peer Model, space containers realize stages; a construct termed peer is introduced that represents a structured, re-usable, addressable component. It is modeled by means of two stages for input and output. Between them the internal logic of the peer takes place. Inter-peer collaboration occurs between output stage and a foreign peer's input stage. Stages thus mark end-points of distribution. Wirings model the flow between stages within and between peers. Data belonging to the same flow is marked with a unique flow identifier.

The conception of the Peer Model assumes a tuple-space [START_REF] Gelernter | Generative communication in Linda[END_REF] to bootstrap the model. Space-based middleware lets autonomous components coordinate themselves in a highly decoupled way. We use a space as described in [START_REF] Craß | Algebraic foundation of a data model for an extensible space-based collaboration protocol[END_REF], which provides shared containers that support configurable coordination mechanisms [START_REF] Kühn | Introducing the concept of customizable structured spaces for agent coordination in the production automation domain[END_REF], and a flexible and extensible API for accessing them, although other spaces with similar functionality may also be used to bootstrap the Peer Model.

Data and requests are modeled as entries maintained in containers. An entry has an application-and a coordination-specific data part, termed app-data resp. co-data. The latter holds meta-information for system-internal mechanisms like entry selection and transactions, and is identified by labeled properties. The entry type is explicitly modeled by a type property, which is also queryable codata. Note that the entry type differs from the type of the app-data transported by this entry. The entry type serves for coordinating the flow in the system. A container is referenced by a URI in the network. It provides (1) put operations that write new entries into a container, and (2) get operations that read or take entries. The coordination principle (e.g. first-in-first-out order, key, template matching, SQL-like query etc.) by which entries are administrated and queried in the container is controlled by the entries' meta information. Read and take operations select entries according to the chosen coordination principle. They wait within the given timeout for the query to complete. In addition, take also removes the entries from the container. Put and get operations are carried out in transactions; both support bulk data processing. The write operation puts entries into a container in a single step. Read and take retrieve a certain amount of entries which is controlled by a counter specification as explained below.

The container is a basic building block for the specification of the Peer Model. Special capabilities of the container implementation like persistency and authorization [START_REF] Craß | A coordination-driven authorization framework for space containers[END_REF][START_REF] Craß | Securing a space-based service architecture with coordination-driven access control[END_REF] influence the quality of the Peer Model with respect to reliability, consistency and security. However, these issues are out of the scope of this paper. For the following, we only assume two very basic coordination laws: (i) selection of entries by means of their type property, and (ii) specification of the amount of entries required to fulfill a query, otherwise the operation will block. The amount of required entries is expressed as a relation that represents the exact number ("="), a minimum (">", ">=") or a maximum ("<", "<=") of required entries. The semantics is to always take as much entries as possible.

Peer

A peer P is the main resource of the Peer Model. The graphical notation for the basic form of a peer is shown in Figure 1.a. It controls the execution of services. A peer possesses a name (URI), an input space termed peer-in-container (PIC ), and an output space termed peer-out-container (POC ). Via the PIC it receives request entries, takes them out of the PIC, processes them, and finally puts replies into the POC. The PIC restricts the entries it accepts to pre-defined types. The behavior of a peer is modeled by means of nested sub-peers, wirings and services (see Section 2.2). A sub-peer is a peer that is created in the scope of a peer. A wiring allows incorporating zero or more services into a peer. It waits until a defined selection of entries is available, invokes services, and moves or copies entries between the peer's PIC, its POC, and/or PICs and POCs of direct sub-peers. Therefore, wirings are the only active part of the system.

Major peer derivatives are: A space peer (SPA) as shown in Figure 1.b is a specialized peer that models the functionality of a space container. Its PIC and POC are melted into one place where all incoming entries are stored using the write operation, and from which they can be read or taken. A SPA is used to store data that are shared between concurrent threads and/or processes, i.e. it serves as medium for communication and synchronization. In the Split/Join pattern example (see Section 3, Figure 5.b) it will be used to collect the workers' answers to be merged by a join peer. A coordination peer (COP) is a predefined system peer encapsulating re-usable coordination logic; examples are lookup, routing and filtering peers. An application peer (APP) includes application-specific logic provided by developers in form of service methods. Together, all peers of a site form a "Peer Space", whose runtime environment is bootstrapped via a runtime peer (RTP), the name of which refers to the URI of the local site. It enables the dynamic creation and deletion of peers and their composition through wirings and services at the local site.

Wiring

Wirings are the active part of the system: They are the transport system within the Peer Model, controlling the movement of entries between PIC and POC containers of peers with the help of get and put space operations. A wiring has a name and consists of three sections: a guard, which defines the conditions under which the wiring activates, optionally followed by service calls, and an action that defines how to dispose the resulting entries. A guard resp. action section consists of 0, 1, or more link operations. As an extra condition, a guard must contain at least one consuming get operation (i.e. take).

The graphical notation of the control part of a wiring named "W" is represented in Figure 2.a, which illustrates a wiring with one input and one output link that are represented by dotted arrows. Figure 2.b shows a wiring with multiple input and output links that also calls a service. The notation for entries consists of a type query in the upper part and a counter query in the lower part of the circle. Filled circles on an input link denote the take operation, whereas unfilled ones -like the entry with query "type = T 2 | count >= 0" on the second input link in Figure 2.c -model the read operation. This query selects all available entries of type T 2. Details on the query mechanism are explained in [START_REF] Craß | Algebraic foundation of a data model for an extensible space-based collaboration protocol[END_REF]. The operator "|" behaves like the pipe operator in the UNIX shell in that it streams the results of the query at its left side to the query at its right side. Entry specifications on output links involve the write operation, i.e. these entries are written to the specified destination container (neither source nor destination containers are shown in Figure 2). Therefore, in Figure 2.a, exactly one entry of type T1 is removed from some container and written into another one. This simple "move" behavior is the default behavior of a wiring and Figure 2.c depicts the graphical short cut for it, which omits the wiring control symbol and uses a filled line. By using bulk operations on containers, get and put operations can transport more than one entry across one link in a single step.

For simplicity we assume that all sections of W are committed in one atomic step at the end of the wiring, but may optionally already commit after the guard or the service phase. Early commits are beneficial for unblocking other wirings that wait for the same resource. Considering a long running service, the wiring could remove read locks on get links before the service completes, so that other wirings requiring the same entry are not blocked for the complete execution time of the service. A wiring implicitly is associated with a transaction, dubbed wiring transaction. Each wiring transaction possesses a configured timeout, after which the transaction automatically aborts. In addition, the RTP configuration specifies how often and in which interval a failed wiring transaction retries to process entries of the same flow.

The functioning of a wiring is: 1) Fulfill all input links sequentially in the specified order, leading to an entry collection (EC) which can be understood as an internal space container only visible to this wiring1 . All input links must succeed. If one cannot be fulfilled, the entire guard blocks. 2) Call all services in the given order and pass them the current entry collection from which the services may read and take entries and into which they may write other entries which represent the results of the service. These operations resemble the get and put operations of a space with the difference that blocking mode is forbidden on EC. After service execution has completed, EC has been filled with all results of the services. 3) Finally execute the output links. The task of the output links is to distribute the entries of EC to PIC and/or POC containers of the own peer or to PIC containers of sub-peers. In contrast to the input links, not all output links must succeed. The semantics is to execute one after the other in the given order: if it is satisfiable then perform it, otherwise skip it and proceed with the next one. E.g. in Figure 2.b the wiring collects one entry of type T1 and all available entries of type T2, which it passes to the service that in turn may change the wiring's internal EC. Let us assume that the service consumes all entries of type T2, and adds two of type T3. So at this point in time, EC is a multi-set EC = {E T 1 , E T 3 , E T 3 } of three entries E type (note that the app-data of the two entries E T 3 might differ). Output link 1 gets the entry of type T1 from EC and writes it to some container (not shown in the picture). Output link 2 delivers both entries of type T3. Output link 3 is tried, but its query cannot be fulfilled and thus it is skipped. This link only works if an entry of type T4 is emitted by the service. After the action section, the effects of the wiring are automatically committed, and remaining entries are removed from EC. The functionality of wirings is modeled via UML-like sequence diagrams. The objects between which messages are exchanged are: PICs and POCs of peers, the wiring box itself, and service methods. These objects are quoted by means of their respective graphical notation plus a life line. Messages between objects represent link operations. Figure 3 shows a sequence diagram for the example wiring in Figure 2.b. It assumes a sub-peer P2, and lets W get entries E T 1 and E T 2 from its own peer's PIC, i.e. from P1/PIC, call the service, put E T 1 to P2/PIC, and finally all entries E T 3 and E T 4 to P1/POC.

Wirings are the necessary mechanism to integrate pre-existing service functionality. The entry collection models a flexible interface for the invocation of arbitrary services. By using the features of the underlying space-based middleware, wirings dynamically connect peers and services in a data-driven way that provides high decoupling. Conceptually, all wirings whose guards are fulfilled run concurrently. The model allows for an arbitrary number of instances of the same wiring in parallel. This means that within a peer, the same service could run many times in concurrent threads. The coordination law of the containers can also be used to determine the concurrency. By default, arbitrarily many instances of W may be active at the same time, but it could also be beneficial to enforce a strict sequential execution. However, this requires slightly more complex coordination mechanisms than simple type queries. To control the concurrency level, our Java implementation of the Peer Model -termed "Peer Space" -provides system configurations for maximum thread pool sizes.

Flow Identifier

The entirety of all wirings that constitute an integration pattern is called a flow. In terms of enterprise systems it refers to a workflow. A flow involves a number of wiring executions that together solve a global task. A flow is identified by a unique flow identifier (FID) that is generated at its creation time by the Peer Space. A flow is started by emitting a first entry into the Peer Space. The initial status of a flow is "active". A flow can end under different circumstances: through an explicit success or failure result, or after the flow has reached a maximum time-to-live (TTL). Eventually all entries belonging to this flow will be recognized by wirings and automatically removed. If the developer creates an entry, s/he indicates to which flow this entry belongs. The entry automatically carries the TTL with it. A wiring will not treat an entry when its TTL has expired, but will wrap it into an error entry and put this entry into its own POC. For error entries, automatic wirings exist that let the error "roll back" up in the system until it ends at the client who originated the flow. Each wiring must only fetch entries in its guard that belong to the same flow.

Split/Join Integration Pattern

As an example use case, the Split/Join integration pattern [START_REF] Van Der Aalst | Workflow patterns[END_REF] is chosen. The pattern's objective is to split a task of type X into several sub-tasks, distribute the execution of the sub-tasks to an arbitrary number of workers, wait for all executions, and aggregate and return the results. Developers must provide the logic how to split the original task, which worker to assign and how to join the results. All other parts are pure coordination logic. The challenge is to clearly separate application from coordination logic. The Split/Join problem is decomposed into several patterns: Two of them are predefined by the system, termed send and receive proxy patterns. They are pure coordination patterns and modeled as two coordination peers (COPs) termed SendPXY (see Figure 4.a) and ReceivePXY (see Figure 4.b). SendPXY assumes a built-in service called send() that takes as input the ID of a peer, and an entry E T of a configured type T. Let P be a local or remote peer to which the ID resolves. SendPXY writes E T into P/PIC. ReceivePXY is the analogous counterpart: It uses the built-in system service receive() to take one entry from a remote peer's P/POC, where P's ID is the input entry of the pattern.

Two further patterns are Split and Join in Figure 5, both modeled as application peers (APPs) that require application specific logic. The Split peer has a wiring W1 with a guard that expects one task entry of type X as input, and passes it to the splitAndAssignTasks() method which is a user-programmed service that produces an arbitrary amount of sub-tasks and adds them to the internal entry collection of this wiring instance together with a multi-set of peer worker IDs that shall execute sub-tasks. If the same ID is generated twice the same worker must process two sub-tasks; however, which ones is irrelevant. Sub-task entries are also added to the entry collection. Finally, in the action section, the wiring puts a control entry, all IDs, and all sub-tasks into Split/POC. The control entry holds in its application data part specific control information needed for the join, e.g. how many results are needed, which quality is required etc. The Join peer's first wiring is a default wiring that moves one control entry of type Ctrl into a local space peer termed SPA, which serves as local memory for the joinResults() service. Its wiring W1 waits until at least one intermediary result of a worker peer has arrived. It then takes all already available result entries of type Res from worker peers as input, takes the control entry from SPA and also an entry of type Sum (if here) and passes all these entries to the joinResults() service method provided by the developer. The method checks control and result entries, and merges them into the sum entry (or generates one after the first invocation of W1 for this flow). If the service decides that enough results are here, it writes Sum to Join/POC. Otherwise, it writes Sum and Ctrl back into its local SPA, commits and continues its next iteration.

In addition, the user must provide the implementation of worker peers which are not detailed in the example. A worker peer takes one task of type X as input, then performs its specific application logic, and finally generates one output of type Res that it puts into its POC.

All these peer components are composed towards the Split/Join pattern depicted in Figure 6. It starts with applying the Split pattern on input entry X, which outputs many peer IDs, one control entry and many sub-tasks of type X. Wiring W1 is an inter-peer wiring and is executed for pairs of ID and X entries. Its guard requires one ID and one X entry and uses the ID entry to initialize the SendPXY peer as well as the ReceivePXY peer. In addition, the sub-task entry is written into SendPXY/PIC. SendPXY writes the entry of type X to the corresponding worker peer. In parallel, ReceivePXY waits for the result of this worker peer, takes the results from the worker peer's POC and returns it in ReceivePXY/POC. From there a default move wiring transports it to the Join peer, which also gets the control entry from Split/POC into its Join/PIC as input. The Join peer now waits until enough results are received, merges them and returns the final output which is the aggregated sum of all obtained results. This sum entry is transported to the SplitJoin/POC and from there it is delivered to the originator of the flow. Many flows may run concurrently. Their entries are automatically correlated by the unique identifier (FID) of the flow.

The design of the pattern is resistant against adding more or different, local or remote worker peers. The pattern flexibly supports new requirements and challenges like changed logic for how to join the results: e.g., use only the best results, or stop after a certain amount of results, or stop if a certain condition is met. Only the corresponding joinResults() service must be rewritten. If the FID is invalidated, all still running processes of the flow will eventually stop. All other parts and components of the Split/Join pattern remain unaffected.

Meta Model and Domain Specific Language

The intention of the Peer Model is to provide a sound mechanism for modeling integration patterns. We have implemented the system with Promela [START_REF] Holzmann | Spin model checking: an introduction[END_REF] to achieve a runnable specification and lay the basis for future work on verifying certain properties by means of the SPIN model checker. In addition, a Java version has been implemented to get first experiences with an object-oriented Peer Model API. A presentation of this API is beyond the scope of this paper. We will instead outline the Domain Specific Language for the Peer Model (PM-DSL) that was implemented with Promela. First a meta-meta-model is built, consisting of data structures that model peer types. Then the meta-model that describes the functionality of all peers in a specific Peer Space is derived from the meta-meta-model. The space container operations are implemented by means of (blocking) channel operations. The PM-DSL provides the following operations: defPeerType(P eerT ypeN ame, P eerT ypeID); addSubPeer(P eerT ypeID, P eerT ypeN ame, P eerN ame); addWiring(P eerT ypeID, W iringN ame, W iringID); addGuardLink(W iringID, F romP eerN ame, F romContainerN ame, ReadOrT ake, T ypeQuery, Count, CountDetails); addService(W iringID, ServiceN ame, N Args, Arg1, Arg2, ...); addActionLink(W iringID, T oP eerN ame, T oContainerN ame, T ypeQuery, Count, CountDetails); createPeer(P eerT ypeN ame, P eerN ame, P eerID); startPeer(P eerID); containerWrite(P eerID, ContainerN ame, EntryT ype, AppData, CoData);

First the meta-meta-model must by initialized. For this, PM-DSL provides the following operations: defPeerType() specifies a new peer type of given type name and in the second argument returns the id by which this type is referenced in the following; addSubPeer() adds a peer given by a peer type to another peer type (given by id) and names it; addWiring() adds a named wiring to a peer type and returns its id; addGuardLink() adds an input link to a wiring by saying from which peer's PIC or POC with which query entries shall be read or taken; addService() adds a service to a wiring -there exist some built-in services with defined names resp. the developer may program own services and refer to them by their name -and here one can configure static arguments (e.g. the number of sub-tasks to be produced by the Split peer) of the service; addActionLink() adds one output link to a wiring and says to which peer's PIC or POC which entries shall be put. "THIS PEER" refers to the own peer.

As an example, the SplitJoin peer pattern of Figure 6 is modeled with the PM-DSL. We show only parts of the specification of the meta-model for the SplitJoin peer; and we assume that the other peer types already exist. For creation of the meta-model the PM-DSL offers the operation createPeer() which creates a new peer with given name and initializes its meta-model from the specified peer type, including all resolved wirings. It recursively also creates all sub-peers. Their names must be resolved in the right scope, i.e. the name of a sub-peer is only visible to its super and sibling peers. Only through lookup mechanisms these names become visible to other peers. Description of lookup peers is straight forward, as existing peer-to-peer algorithms can be applied. The Peer Model can now be started with Promela's run operation calling startPeer() which starts the wirings of all peers as concurrently running processes. For each wiring multiple instances are assumed to exist concurrently (cf. "bang" operator in [START_REF] Milner | The polyadic pi-calculus: a tutorial[END_REF]). Creation of flows takes place through injection of entries into the system with containerWrite() whereby the FID is contained in the co-data part of the entry. Coming back to our use case, the final steps to start the pattern are: createPeer(SPLIT JOIN PEER TYPE, SPLIT JOIN PEER, peerID); run startPeer(peerID); containerWrite(peerID, PIC, X TYPE, /* task */, /* FID etc. */);

Related Work

An approach related to Split/Join has been undertaken with Reo [START_REF] Clarke | Partial connector colouring[END_REF] termed Synchronous Merge Connector (see Figure 7). Flows are modeled by means of different connector types. The example starts with an exclusive router that nondeterministically selects one output which can be either service A or service B. From there three walkthroughs become possible: service A, service B, or both. The exclusive router is also used to control the joining of the execution. Reo supports composition of software components using a channel-based coordination model. In contrast to the Peer Model, Reo is oblivious to any coordination and concurrency inside the component instances; also the used communication mechanisms are of no interest [START_REF] Arbab | Reo: a channel-based coordination model for component composition[END_REF], whereas the Peer Model builds upon tuple space-based middleware and allows for nesting of components.

Colored Petri Nets (CPN) [START_REF] Jensen | Coloured petri nets and CPN tools for modelling and validation of concurrent systems[END_REF][START_REF]IEC 15909. High-level petri nets -concepts[END_REF] are a graphical language for modeling concurrent and often also distributed systems. However, they can be applied in almost any thinkable domain2 . Typically it is used for testing and performance analysis [START_REF] Jensen | Coloured petri nets and CPN tools for modelling and validation of concurrent systems[END_REF]. As the modeling is quite low-level and does not make any assumptions on the domain, it is very powerful; but on the other hand it does not provide any higher-level abstractions. We used CPN-Tools [START_REF] Ratzer | CPN tools for editing, simulating, and analysing coloured petri nets[END_REF] to model the Split/Join use case of Section 3 in two variants: Figure 8.a without requiring the underlying Petri Net to allow for complex inscriptions on input and output arcs, and Figure 8.b making use of advanced features of the ML language used by CPN. For Figure 8.a the pattern was modeled with two services A and B, and every way through the network is controlled by an explicit transition. The other variant uses ML lambda expression to specify more complex arc conditions (Figure 8 Next, we increased the design up to 4 services. Figure 9.a shows the basic variant, and Figure 9.b the one employing ML's expressiveness. Both figures demonstrate how complex these designs become. The latter needs less places, but the condition on the output link of the Merge transition becomes more complicated if more services are assumed. Moreover, the control logic is spread among the network. If services are added, the type definitions for the control token must be adapted, as well as for the Start and CTRL place. For each service two places and one transition, plus four arcs must be added explicitly, because the network is static. Two of these arcs must have a special condition. In summary, the comparison shows that Petri Nets do not scale because they are static. Every new component must be modeled explicitly. The main advantages of the Peer Model approach in contrast to more general and static tools like CPNs and REO are:

Design scalability. The Peer Model allows modeling of large patterns and scales naturally to any number of services, without exponential complexity. In the example this is accomplished by a send and a receive proxy peer, which (de-)multiplex sub-tasks to/from arbitrary worker peers addressed via their IDs. Dynamic addition of workers and increasing the number of sub-tasks is possible.

Dynamics. During runtime, new peers can be added on-the-fly. Also, peers can be changed in that, e.g., wirings are added dynamically.

Composability. The Peer Model design allows to break down a problem into smaller, re-usable patterns that can be composed to larger ones. CPNs also support hierarchically nested modules, but the composition requires global names for the "fusion" places.

Transparent remoting. The physical distribution of processes to other sites does not cause a difference in design compared to local processes.

Architecture agility. The model is robust against changes due to new requirements. We have termed this "architecture agility" in [START_REF] Mordinyi | Towards an architectural framework for agile software development[END_REF] and shown that the space-based architectural style helps to avoid costly architecture limiters or even breakers. The Peer Model extends this idea by not only considering passive data, but also modeling the active part, i.e. processes that access the data.

Conclusion

The Peer Model is a design tool for the specific domain of programming parallel and distributed applications. In contrast to other widespread modeling tools like Colored Petri Nets it is less general as it takes specific assumptions on its domain. More precisely, it requires a coordination middleware whose features have an impact on the quality of the Peer Model. At least, access to shared data by means of blocking operations, local transactions, and type-based queries with cardinality specification are required. The process space is structured into so-called peers which are framework components. They separate coordination from application logic to achieve software architecture agility. Application logic is integrated in form of service methods. Peers are reusable components that implement coordination patterns. Wirings control the entry flow between and within peers. Flow-identifiers automatically correlate entries of the same flow, thus allowing many instances of different flows to be processed concurrently.

We have presented the basic concepts of the Peer Model, its graphical notation, and domain specific language which is based on a formal model. Its conception is intended as foundation for real implementations. The usability of the Peer Model was evaluated with respect to design scalability, composability, remoting, architecture agility, and support of dynamics. Our future work will concern implementation of a designer tool, mappings to the Colored Petri Net formalism, and extending the mechanisms of how to model concurrency.

Fig. 1 .

 1 Fig. 1. (a) Peer. (b) Space Peer.

Fig. 2 .

 2 Fig. 2. Wirings.

Fig. 3 .

 3 Fig. 3. Example: Wiring modeling with UML-like sequence diagram.

Fig. 4 .Fig. 5 .

 45 Fig. 4. (a) Send Proxy Peer. (b) Receive Proxy Peer.

Fig. 6 .

 6 Fig. 6. Split/Join Peer.

Fig. 7 .

 7 Fig. 7. Reo with 2 services: Synchronous Merge Connector, Fig. 1 from [4].

  .b).

Fig. 8 .

 8 Fig. 8. CPN for 2 services with (a) weak, and (b) complex arc logic assumptions.

Fig. 9 .

 9 Fig. 9. CPN for 4 services with (a) weak, and (b) complex arc logic assumptions.

EC access need not be modeled explicitly by Peer Model users, which provides an abstraction of this mechanism. However, it is modeled explicitly in the formal model.

Examples of Industrial Use of CP-nets: http://cs.au.dk/cpnets/industrial-use/

Acknowledgements. The work is partially funded by the Austrian Federal Ministry for Transport, Innovation and Technology, FFG-BRIDGE project no. 834162 "LOPONODE" (Coordination Middleware for Wireless Networks of Low Power Nodes).


Soguy Mak

Karé Gueye

Noël De Palma
email: noel.depalma@imag.fr

Eric Rutten
email: eric.rutten@inria.fr

Component-based Autonomic Managers for Coordination Control

Keywords: Adaptive and autonomic systems, Coordination models and paradigms, Software management and engineering, Discrete control

The increasing complexity of computing systems has motivated the automation of their administration functions in the form of autonomic managers. The state of the art is that many autonomic managers have been designed to address specic concerns, but the problem remains of coordinating them for a proper and eective global administration. In this paper, we dene controllable autonomic managers encapsulated into components, and we approach coordination as their synchronization and logical control. We show that the component-based approach supports building such systems with introspection, adaptivity and reconguration. We investigate the use of reactive models and discrete control techniques, and build a hierarchical controller, enforcing coherency properties on the autonomic managers at runtime. One specicity and novelty of our approach is that discrete controller synthesis performs the automatic generation of the control logic, from the specication of an objective, and automata-based descriptions of possible behaviors. Experimental validation is given by a case-study where we coordinate two self-optimization autonomic managers and self-repair in a replicated web-server system.

executed, using as actuators the administration functions oered by the system API. Self-management issues include self-conguration, self-optimization, self-healing (fault tolerance and repair), and self-protection. In this work we consider AMs for self-optimization and self-repair.

Complex and complete autonomic systems feature numerous dierent loops for dierent purposes, managing dierent dimensions. This is causing a problem of co-existence, because it is hard to avoid inconsistencies and possible interferences. Therefore, coordination is recognized as an important challenge, not completely solved by present research, and requiring special attention [START_REF] Kephart | Autonomic computing: The rst decade[END_REF]. Coordinating AMs can be seen as the problem of synchronization and logical control of administration operations that can be applied by AMs on the MEs in response to observed events. Such an additional layer, above the individual administration loops, constitutes a coordination controller. AMs are considered as being MEs themselves, with an upper-level AM for their coordination. The state of the art in designing these hierarchical coordination controllers is to develop them, e.g., using metrics dedicated to the aspect around which coordination is dened, like energy and performance [START_REF] Das | Autonomic multi-agent management of power and performance in data centers[END_REF]. As a hand-made methodology, this remains complex and error-prone, and hard to re-use.

Coordination as discrete control of components

Our contribution is an automated methodology for the coordination control of autonomic managers. A novelty is that it provides for concrete design assistance, in the form of the automatic generation, from a Domain-Specic Language (DSL), of the control logic, for a class of coordination problems expressed as invariance properties on the states of the AMs. The benet is manifold: the designer's work is eased by the automatic generation, the latter is done based on formal techniques insuring correctness of the result, and the re-use of designs is facilitated by the automated generation of the control logic.

We identify the needs for the coordination of AMs, which have to be instrumented in order to be observable (e.g., current state or execution mode) and controllable (e.g., suspend activity), so that they can be coordinated. For this, component-based approaches provide us with a well-structured framework. Each component is dened separately, independently of the way it can be used in assemblies. They also have to be equipped with a model of their behavior, for which we use Finite state Machines (FSM), also called automata.

We specify the coordination policy as a property between the states of the AMs, like for example mutual exclusion, which must be kept invariant by control. Given this control objective, and the behavioral model FSMs, we use techniques stemming from Control Theory to obtain the controller. Such techniques have recently been applied to computing systems, especially using classical continuous control models, typically for quantitative aspects [START_REF] Hellerstein | Feedback Control of Computing Systems[END_REF]. The advantage is that they ensure important properties on the resulting behavior of the controlled system e.g., stability, convergence, reachability or avoidance of some evolutions. We use discrete control techniques, especially Discrete Controller Synthesis (DCS) [START_REF] Cassandras | Introduction to Discrete Event Systems[END_REF], well adapted for logical or synchronization purposes. In this work, we focus on software engineering and methodology; formal aspects available elsewhere [START_REF] Delaval | Contracts for modular discrete controller synthesis[END_REF] are not in the scope of this paper. Our work in this paper builds upon previous preliminary results [START_REF] Gueye | Coordinating energy-aware administration loops using discrete control[END_REF] where we had considered a specic experiment in coordinating two administration loops (self-sizing and DVFS), implemented and tested as a simple prototype. Here, our new contributions are:

1. a generalized method, leveraged to the level of a component-based approach, to design controllable AMs, with a DSL for describing administration behavior as automata, with controllable points at the interfaces; 2. a method for the specication and generation of coordination controllers enforcing invariance properties, based on the formal DCS technique; 3. a fully implemented experimental validation of a case-study coordinating self-optimization autonomic managers (self-sizing and DVFS), completed with a new one for self-repair; we thus demonstrate reusability by combining the same sizing loop in a new context, with a new coordination policy.

In the remainder of the paper we will make recalls in Section 2 on componentbased approaches, and the reactive language BZR. The kernel of our contribution is rst in Section 3 where we describe the method for instrumenting a basic AM component in order to become an ME itself; and then in Section 4 where we propose construction methods on these bases for composite components, where coordination of the AMs is managed. An additional contribution is the experimental validation by the case study in Section 5, with self-optimization and self-repair autonomic managers in a replicated web-server system.

2 Background: components and reactive control

Component Model

In classical component models, a component is a run-time entity that is encapsulated, and that has a distinct identity. A component has one or more interfaces. An interface is an access point to a component, that supports a nite set of service. Interfaces can be of two kinds: (i) server interfaces, which correspond to access points accepting incoming service calls, and (ii) client interfaces, which correspond to access points supporting outgoing service calls. Communication between components is only possible if their interfaces are connected through an explicit binding. A component can be composite, i.e. dened as an assembly of several subcomponents, or primitive, i.e. encapsulating an executable program. The above features (hierarchical components, bindings between components, strict separation between component interfaces and component implementation) are representative of a classical component model.

Reexive component models extend these features to allow well scoped introspection and dynamic reconguration capabilities over component's structure. They perfectly match our needs since they are endowed with controllers, which provide access to component internals, allowing for component introspection and control of their behavior. These general reexive component-based concepts = a1, s1, a2, s2 enforce not (a1 and a2) with c1, c2 have a number of particular instances, amongst which Fractal [START_REF] Bruneton | The fractal component model and its support in java[END_REF]. This reexive component model comes with several useful forms of controllers, which can be combined and extended to yield components with dierent control interfaces. This includes controllers for: (i) attributes, which are congurable through getter and setter methods, (ii) bindings, to (dis)connect client interfaces to server interfaces, (iii) contents, to list, add and remove subcomponents and (iv) lifecycle, to give an external control over component execution, including starting and stopping execution. Figure 1 shows an example of a composite component with: functional and control interfaces, a content built from two subcomponents (C1 and C2) that implement the functional interfaces and, a controller that implements the control interfaces. The controller in the composite can react e.g., to a reconguration access by removing subcomponent C2: i.e., stopping it, unbinding it from C1 and from the composite's client interface, re-binding C1's client to the composite, and uninstalling C2's code. The experimental validation in Section 5 relies on the Java-based reference implementation of Fractal (Julia): in this framework, a component is represented by a set of Java objects.

(a1, s1) = delayable(r1, c1, e1) ; (a2, s2) = delayable(r2, c2, e2)

Reactive languages and BZR

Automata and data-ow nodes We briey introduce, with examples, the basics of the Heptagon language; due to space limitations, formal denitions are not recalled [START_REF] Delaval | Contracts for modular discrete controller synthesis[END_REF]. It supports programming of nodes, with mixed synchronous data-ow equations and automata, with parallel and hierarchical composition.

The basic behavior is that at each reaction step, values in the input ows are used, as well as local and memory values, in order to compute the values in the output ows for that step. Inside the nodes, this is expressed as a set of equations dening, for each output and local, the value of the ow, in terms of an expression on other ows, possibly using local ows and state values from past steps. Figure 2(a) shows a small program in this language. It programs the control of a delayable task, which can either be idle, waiting or active. When it is in the initial Idle state, the occurrence of the true value on input r requests the starting of the task. Another input c can either allow the activation, or temporarily block the request and make the automaton go to a waiting state. Input e noties termination. The outputs represent, resp., a: activity of the task, and s: triggering starting operation in the system's API.

Such automata and data-ow reactive nodes can be reused by instantiation, and composed in parallel (noted ";") and in a hierarchical way, as illustrated in the body of the node in Figure 2(b), with two instances of the delayable node. They run in parallel: one global step corresponds to one local step for every node, with possible communication through share ows. The compilation produces executable code in target languages such as C or Java, in the form of an initialisation function reset, and a step function implementing the transition function of the resulting automaton, which takes incoming values of input ows gathered in the environment, computes the next state on internal variables, and returns values for the output ows. This function is called at relevant instants from the infrastructure where the controller is used.

Contracts and control BZR (http://bzr.inria.fr) extends Heptagon with a new behavioral contract [START_REF] Delaval | Contracts for modular discrete controller synthesis[END_REF]. Its compilation involves discrete controller synthesis (DCS), a formal operation [START_REF] Cassandras | Introduction to Discrete Event Systems[END_REF] on a FSM representing possible behaviors of a system, its variables partitioned into controllable ones and uncontrollable ones. For a given control objective (e.g., staying invariantly inside a subset of states, considered "good"), the DCS algorithm automatically computes, by exploration of the state graph, the constraint on controllable variables, depending on current state, for any value of the uncontrollables, so that remaining behaviors satisfy the objective. This constraint is inhibiting the minimum possible behaviors, therefore it is called maximally permissive. Algorithms are related to model checking techniques for state space exploration; they are exponential in the states, but can manage our models built at coarse grain abstraction level.

Concretely, the BZR language allows for the declaration, using the with statement, of controllable variables, the value of which are not dened by the programmer. These free variables can be used in the program to describe choices between several transitions. They are then dened, in the nal executable program, by the controller computed by DCS during compilation, according to the expression given in the enforce statement. BZR compilation invokes a DCS tool, and inserts the synthesized controller in the generated executable code, which has the same structure as above: reset and step functions.

Figure 2(b) shows an example of contract coordinating two instances of the delayable node of Figure 2. The twotasks node has a with part declaring con-trollable variables c 1 and c 2 , and the enforce part asserts the property to be enforced by DCS. Here, we want to ensure that the two tasks running in parallel will not be both active at the same time: not (A1 and A2). Thus, c 1 and c 2 will be used by the computed controller to block some requests, leading automata of tasks to the waiting state whenever the other task is active. The constraint produced by DCS can have several solutions: the BZR compiler generates deterministic executable code by favoring, for each controllable variable, value true over false, in the order of declaration in the with statement.

3 Designing controllable AMs

Design of an AM

Controllable AM components have to share features of an AM, as well as of an ME, as we recall here. Basic features required for a system to be an ME managed in an autonomic fashion have been identied in previous work e.g., in the context of component-based autonomic management [START_REF] Sicard | Using components for architecture-based management: the self-repair case[END_REF]. It must be observable and controllable, and we need to know its possible behaviors, for which we use automata models. Observability goes through a capacity of introspection, exhibiting internals to the outside world, particularly to an AM in charge of management, in a context with other MEs. In the autonomic framework, it corresponds to the sensors. In components as in Figure 1, it is in introspection interfaces that can be called from outside. At implementation level, it can be for example get functions accessing internal variables. Controllability is dened by the capacity to change features inside the ME from the outside. In the autonomic framework, it corresponds to the actuators. In components, it corresponds to reconguration actions e.g., mode switching, or attribute updating, as mentioned in Section 2.1. At implementation level, it can be done in dierent ways, from interceptors on the interfaces in Java, to actions modifying the structure as with Fscript [START_REF] David | FPath and FScript: Language support for navigation and reliable reconguration of fractal architectures[END_REF]. In short, the system is equipped with a library of sensors/monitors and actions, with an API given by the system, and programmed by the designer.

The AM is a reactive node, transforming ows of sensor observations into ows of reconguration actions. Internally, it features decision-making mechanisms, which can range from simple threshold triggers to elaborate MAPE-K. They can involve quantitative measures and continuous control, or logical aspects modeled as FSMs. Therefore a reactive language such as BZR can be used as a DSL for the decision part on the AMs: it oers high-level programming, as well as formal tools to bring safe design and guaranteed behaviors. In components, the AM is the controller in Figure 1, or it can be an additional component in the assembly of MEs, bound with the appropriate control interface of other subcomponents. At implementation level, it reacts to notications by treating them, depending on applications, in FIFO order or considering most recent values. It calls the action functions of the controlled MEs as above, or modies the composite by ME additions or removals.

We aim at combining the two, to have AMs which can be manipulated as MEs, which involves the same features: making AMs observable and controllable.

Controllable AMs

To make an AM observable, relevant states of the component are exhibited to the outside. They convey information necessary for coordination decisions. Automata represent states of components, w.r.t their activity and/or ability to be coordinated, but independently of the coordination policy. The most basic case, for an AM as for any ME, is to distinguish only idle state (where the AM is not performed) and activity (with actual eect on the ME). Beyond this, one can have a more rened, grey box model, distinguishing states corresponding to phases in a sequence, where the AM can be stopped or suspended without loss of consistency. States support monitoring e.g., to explicitly represent that some bound is reached, such as minimum number of a resource, or maximum capacity.

To make an AM controllable, we use the transitions between states, which are guarded by conditions, and can re reconguration actions. They represent possible choices oered by the AM between dierent reactions, in order for an external coordinator to choose between them. They oer control points to be used according to a given policy. Hence they give the controllability of the AM.

Figure 3(a) shows how an FSM can be an instantiation of the general autonomic loop, with knowledge on possible behaviors represented as states, and analysis and planning as the automaton transition function. In the autonomic framework observability comes through additional outputs, as shown by dashed arrows in Figure 3(a) for an FSM AM, exhibiting (some) of the knowledge and sensor information. Controllability corresponds to having the AM accept additional input for control. Its values can be used in the guards to guide choices between dierent transitions. Such automata are specied in BZR, beneting from its modular structures and compiler. In BZR, a transition with a condition e and c, where e is a Boolean expression, will be taken only if c is true: it can inhibit or enable the transition.

In components, automata are associated with the component controller in the membrane as in Figure 3(b), and are updated at runtime to reect the current state of component. Automata outputs trigger actions in reconguration control interfaces, such as "stop AM", or convey information to upper layers.

At implementation level, the modular compilation of BZR generates for each node two methods (in C or Java): reset and step. reset initializes internal variables and is called only once. step makes the internal variable reect continuously We now present how such controllable AMs can be assembled in composites, where the coordination is performed in a hierarchical framework. The AMs and other components involved in the coordination (which can be composites themselves, recursively) are grouped into a composite. It orchestrates their execution, using the possibilities oered by each of them, through control interfaces, in order to enforce a coordination policy or strategy. We base our approach on the hierarchical structure in Figure 4: the top-level AM coordinates lower-level ones. We describe the problem with one level of hierarchy, but it can be recursive.

The rst thing is to construct a model of the global behavior of the assembly of components. This is done using the local automata from each of the concerned subcomponents: they are composed in parallel in a new BZR node: we then have a model of all the possible behaviors in the absence of control. Controllable variables must be identied and designated i.e., the possible choice points, which will be the actuators oered to the discrete controller to enforce the coordination. Specication of the coordination policy is done by associating a BZR contract to this global behavior. It can make reference to the information explicitly exhibited by subcomponents, and to inputs of the coordinator. The control objective is to restrict possible behaviors to states where a Boolean expression will remain invariantly true, whatever the sequences of uncontrollables.

Once we have a global automaton model of the behavior, a list of controllables, and a control objective, we manually encode the control problem into the BZR language as a contract. The BZR language compiler, and its associated DCS tool, solves the control problem by automatically computing the controller ensuring, by automated formal computation, a correct behavior respecting the contract. It must be noted that as in any control or constraint problem, it may happen that the system does not oer enough controllability for a solution to exist. Either it lacks actuators, or sensors, or explicit states to base its decisions on. In these cases, the DCS fails, which constitutes a diagnostic of non-existence of a solution for the current coordination problem. Then the system has to be redesigned, either by relaxing the contract, or by augmenting controllability. Another meaningful point is that the BZR language features hierarchical contracts [START_REF] Delaval | Contracts for modular discrete controller synthesis[END_REF], where the synthesis of a controller can use knowledge of contracts enforced by sub-nodes, without needing to go into the details of these nodes. This favors scalability by decomposing the synthesis computation. It also corresponds very closely to the hierarchical structure proposed here, and can be exploited fully.

Hierarchical architecture

In the autonomic framework our approach denes a hierarchical structure as shown in Figure 4. Given that AMs have additional outputs exhibiting their internals, and additional inputs representing their controllability, an upper-level AM can perform their coordination using their additional control input to enforce a policy. Considering the case of FSM managers makes it possible to encode the coordination problem as a DCS problem. The transition function of this upperlevel AM is the controller synthesized by DCS.

In components, this translates to a hierarchical structure where a composite features a controller, bound with the outside and with subcomponents, through control interfaces. This way it can use knowledge on life-cycles of subcomponents in order to decide on reconguration actions to execute for their coordination.

At implementation level, there is an o-line phase, where the BZR compilation is used. It involves extracting the relevant automata from AMs descriptions : to each of them is associated a BZR node. These nodes are used to compose a new BZR program, with a contract, declaring controllable variables in the with statement. The policy has to be specied in the enforce statement. The complete BZR program is compiled, and code is generated as previously described. The resulting step function is integrated at the coordinator component level, calling steps from sub-components. At run-time, in our implementation, the controller in the composite component is responsible of executing the step method call: it gathers the necessary information from the sub-components, then executes the step, which interacts with the local step functions in subcomponents. It then triggers and propagates reconguration commands to sub-components based on the returned result, as discussed before.

Change coordination policy

This separation of concerns, between description of possible behaviors, and coordination policy, favors the possibility to change policy without changing the individual components. For example, if we wanted to change priorities between AMs, this would impact the contract but not the individual components. On the other hand, if for the same overall policy we wanted to use other components with a dierent implementation of the same management, we can switch an AM by another one and recompute the coordination controller. The fact that our approach is modular, and that it uses automated DCS techniques, facilitates reuse of components, and also the modication of systems, by re-compilation. [START_REF] Cassandras | Introduction to Discrete Event Systems[END_REF] Case study: coordinating administration loops

Description of the case study

We consider the coordination of two administration loops for resource optimization (self-sizing) and server recovery (self-repair) for the management of a replicated servers system based on the load balancing scheme.

Self-sizing. It addresses the resource optimization of a replication-based system. It dynamically adapts the degree of replication depending on the CPU load of the machines hosting the active servers. Its management decisions rely on thresholds, Minimum and Maximum, delimiting the optimal CPU load range. It computes a moving average of the collected CPU load (Avg_CPU) and performs operations if the average load is out of the optimal range: Adding operations (Avg_CPU >= Maximum), removal operations (Avg_CPU <= Minimum).

Self-repair. It addresses fail-stop failure of a machine hosting a single or replicated server. Its management decisions rely on Heartbeat. When the machine hosting the server becomes non-responsive, it redeploys the server towards another machine selected from an unused machine pool. Then it updates the new server conguration from the conguration of the failed server and starts it.

Co-existence and coordination problem. Failures can trigger incoherent management decisions by self-sizing. The failure of the load balancer can cause an underload of the replicated servers since the latter do not receive requests until the load balancer is repaired. The failure of a replicated server can cause an overload of the remaining servers because they receive more requests due to the load balancing. A strategy to achieve an ecient resource optimization could be to (1)avoid removing a replicated server when the load balancer fails, and [START_REF] Alvares De Oliveira Jr | Synchronization of multiple autonomic control loops: Application to cloud computing[END_REF] avoid adding a replicated server when one fails.

Modelling and control for coordinating the AMs

We pose the coordination problem as a discrete control problem, rst modeling the behaviors of AMs with automata, then dening controllables and a control objective, in order to nally apply DCS. Modelling AMs. Figure 5 shows the automata modelling both the behaviors and the control of the self-sizing manager. The two external ones model the control of the adding (resp. removal) operations. This is done with the local ows disU (resp. disD), which, when true, prevent transitions where output add (resp. rem) triggers operations. The center one models the behaviors. Initially in the UpDown state, when an Overload occurs and adding operations are allowed, the manager requests a new server, and goes to the Adding state and can no longer perform operations. It awaits until the server becomes active (node_added is true), and returns back to the UpDown state or goes to the Down state if the degree of replication is maximal. The Down state is left once one server is removed upon an Underload event. The Up state is the state in which the degree of replication is minimal. The manager cannot remove server but can add server upon Overload event if allowed.

Figure 5 shows the automata modelling the behaviors of the self-repair managers for the load balancer (LB) and the replicated servers (S). The right automaton concerns servers, and is initially in OkS. When failS is true, it emits repair order rS and goes to the RepS state, where repS is true. It returns back to OkS after repair termination (Sr is true). Repair of the LB is similar.

Coordination controllers The automata are composed in order to have the global behavior model, and a contract species the coordination policy. Automata in Figure 5 are composed. The policies (1) and (2) in Section 5.1 give a contract as follows: enforce ((repLB implies disD) and (repS implies disU)) with Cu,Cd With implications, DCS keeps solutions where disU, disD are always true, correct but not progressing; but BZR favors true over false (Section 2.2) for cU, cD, hence enabling Sizing when possible.

Compilation The BZR compiler generates the corresponding Java code of the BZR program. Two main methods allow to interact with the program: reset for initializing it and step. The latter takes as parameters all the automata inputs and returns all the automata outputs.

Experiments

We apply our approach for coordinating one instance of self-sizing and two instances of self-repair managers for the management of a replicated-based system. The system is composed of one Apache server (self-repair) and replicated Tomcat servers (self-sizing and self-repair). Homogeneous machines are used to host the Tomcat servers. Initially during each execution, the system is started with one Apache server and one Tomcat server. We inject a workload in two phases, a ramp-up workload followed by a constant workload. We wait until there are two active Tomcat servers before injecting a failure. Figure 6(a,b) shows executions in which the Apache server fails, which causes a decrease of the CPU utilization of the machines hosting the Tomcat servers. In the uncoordinated execution (Figure 6(a)), this leads to the removal of a Tomcat but once the Apache is repaired another Tomcat is added. In the coordinated execution (Figure 6(b)) the decrease does not lead to the removal of a Tomcat since the coordination controller inhibits removal operations because of the failure. Figure 6(c,d) shows executions in which a Tomcat server fails, which causes an increase of the CPU utilization of the remaining Tomcat servers. While in the uncoordinated execution (Figure 6(c)) this increase leads to adding a new tomcat (which is removed after the repair), in the coordinated execution (Figure 6(d)) no adding operation is performed. The adding operations are inhibitted by the coordination controller which is aware of the Tomcat failure.

Reusability of models: Integrating the Dvfs manager

We consider the management of the CPU frequency for more resource optimization. Each machine hosting a replicated server is equipped with a Dvfs manager. This latter dynamically increases or decreases the CPU-frequency of the machine depending on the CPU load. Its management decisions, like self-sizing, rely on thresholds, Minimum and Maximum, delimiting the optimal CPU load range. In a context where Dvfs are activated, a strategy to improve resource optimization could be to delay as long as possible adding a new server when the machines hosting active servers are not in their maximum CPU frequency: (3)avoid adding unless all machines are at maximum speed.

We model the global states of the set of Dvfs in Figure 7(a). Initially in the Normal state, when the input min_freq (resp. max_freq) is true, it goes to the Min (resp. Max) state when the CPU frequency of all machines hosting replicated servers is minimal (resp. maximal) and the output min (resp. max) is true. It returns back the Normal state if the CPU frequency of at one of the machines is neither maximal nor minimal. Coordinating the three AMs consists in adding the automaton for the Dvfs in the composition with the following contract to be enforced: (not max implies disU ) representing the policy (3), as shown in Figure 7(b), with Obj i representing policy (i) (i = 1, 2, 3).

Related work and discussion

The general question of coordinating autonomic managers remains an important challenge in Autonomic Computing [START_REF] Kephart | Autonomic computing: The rst decade[END_REF] although it is made necessary in complete systems with multiple loops, combining dimensions and criteria. Some works propose extensions of the MAPE-K framework in order to allow for synchronization [START_REF] Vromant | On interacting control loops in self-adaptive systems[END_REF], which can be e.g., through the access to a common knowledge [START_REF] Alvares De Oliveira Jr | Synchronization of multiple autonomic control loops: Application to cloud computing[END_REF]. A distinctive aspect of our approach is to rely on FSM-based behavioral models, amenable to formal techniques like verication or DCS. Coordination of multiple energy management loops is done in various ways, e.g., by dening power vs. performance tradeos based on a multi-criteria utility function in a non-virtualized environment [START_REF] Das | Autonomic multi-agent management of power and performance in data centers[END_REF]. These approaches seem to require modifying AMs for their interaction, and to dene the resulting behavior by quantitative integration of the measure and utilities, which relies on intuitive tuning values, not handling logical synchronization aspects. We coordinate AMs by controling their logical state, rather than modifying them.

Component-based frameworks are classically associated with implementations oering APIs for sensing and actuating. For example FScript [START_REF] David | FPath and FScript: Language support for navigation and reliable reconguration of fractal architectures[END_REF] is a mid-dleware layer oering relatively high level support for programming complex reconguration actions. However, there is no support in expressing explicitly and directly the set of congurations or modes, and the switches between them: they have to be managed by tedious manual programming with side eects. Our work proposes higher level programming of control aspects, with rst-class language constructs explicitly representing control states and events. The formally based semantics of our language support enables concrete use of verication and synthesis techniques. Relating component-based frameworks and formal models is widely done, e.g. relying on process calculi for abstract reasoning on composition constructs. Closer to the concrete modeling of behavioral aspects, some modeling approaches oer access to verication as model checking [START_REF] Barros | Behavioural Models for Distributed Fractal Components[END_REF]. We specically concentrate on reconguration control, not on the general component approach, and it relates this aspect of Fractal with the synchronous approach to reactive systems, and its support for correct program design, particularly DCS. [START_REF] Aldinucci | LIBERO: a framework for autonomic management of multiple non-functional concerns[END_REF] proposes a framework allowing multiple autonomic managers for the management of a Behavioral Skeleton. The coordination of the managers is ensured through consensus which seems to be manually implemented, which can become complex. [START_REF] Liu | A component based programming framework for autonomic applications[END_REF] proposes a component-based programming framework to build an autonomic application as the composition of autonomic components, with agents based on rules with priority level for conicting decisions resolution.

Concerning decision and control, some approaches rely upon Articial Intelligence and planning [START_REF] Sykes | Plan-directed architectural change for autonomous systems[END_REF] which has the advantage of managing situation where congurations are not all known in advance, but the corresponding drawback of costly run-time exploration of possible behaviors, and lack of insured safety of resulting behaviors. Our work adheres to the methodology of control theory, and in particular DES, applied to computing systems [START_REF] Hellerstein | Feedback Control of Computing Systems[END_REF]. Compared to traditional error-prone programming followed by verication and debugging, such methods bring correctness by design of the control. Particularly, DCS oers automated generation of the coordination controller, facilitating design eort compared to hand-writing, and modication and re-use (see Section 4.3). Also, maximal permissivity of synthesized controllers is an advantage compared to over-constrained manual control, impairing performance even if correct. Applications of DCS to computing systems have been rare until now e.g. to address deadlock avoidance [START_REF] Wang | The theory of deadlock avoidance via discrete control[END_REF]. Compared to this, we consider more user-dened objectives.

Conclusion

We address the problem of coordinating multiple AMs using a componentbased approach. We dene a method for the componentization of AMs as MEs, equipped with automata-based behavioral models. The control of coordinated AMs is based on a formal control technique : DCS, which performs automatic generation. It support addition of new AMs, without re-designing the whole system, and is encapsulated in a design process for non-expert users. A fully implemented case-study, for sizing and repair AMs, gives experimental validation.

Fig. 1 .

 1 Fig. 1. A composite component.

  , e1, r2, e2)

Fig. 2 .

 2 Fig. 2. Delayable task: (a) graphical syntax ; (b) exclusion contract.

Fig. 3 .

 3 Fig. 3. Controllable AM: (a) case of a FSM manager; (b) wrapped component.

Fig. 4 .

 4 Fig. 4. Autonomic coordination for multiple administration loops.

Fig. 5 .

 5 Fig. 5. Managers models : self-sizing (left) and self-repair (right).

Fig. 6 .

 6 Fig. 6. Apache (a,b) and Tomcat (c,d) server failure uncoordinated and coordinated.

Fig. 7 .

 7 Fig. 7. DVFS model, and its Coordination with sizing and repair.

In perspective, we are busy evaluating our approach for coordination of a variety of autonomic administration loops in the context of an industrial datacenter. We have ongoing work on managing coordination in a multi-tier system, involving intra-tier and inter-tier coordination, hierarchically. We consider using more elaborate control techniques, with DCS for optimal control, or the distribution of the controllers. Finally, we have ongoing work on programming language support for our methodology, integrating the whole approach in the compilation process of a component-based language.

This work is supported by the ANR INFRA project Ctrl-Green.