Jean-Claude Martin
email: martin@limsi.fr

Céline Clavel

Tailored, Multimodal and Opportune Interactions on a Wearable Sport Coach: the WE-nner Framework

Keywords: Wearables, Embedded Computing, Physical Activity, Personalization, Multimodal Interaction, Sport Coach

A growing body of evidence from Psychology and Sport Sciences shows that physical activity can be a cost-effective and safe intervention for the prevention and treatment of a wide range of mental and physical health problems.

Research in domains such as the Internet of Things (IoT), wearables and persuasive technologies suggest that a coach intended to promote physical activities needs to provide personalized interaction. In this paper we introduce the WEnner (pronounce "winner") framework for designing an automated coach promoting physical activity which supports interactions between the user and a smart wearable that are: 1) personalized to the user, 2) dynamic (e.g. occurring during a physical activity), and 3) multimodal (e.g. combine graphics, text, audio and touch). We explain how we implemented this framework on a commercial smartwatch and provide illustrative examples on how it provides dynamic personalized and multimodal interactions considering features from user's profile. Future directions are discussed in terms of how this framework can be used and adapted to consider theories and models from Psychology and Sport Sciences.

Introduction

Researchers are designing automated exercise coaches for health [START_REF] Bickmore | Context Awareness in a Handheld Exercise Agent[END_REF][START_REF] Bickmore | A Randomized Controlled Trial of an Automated Exercise Coach for Older Adults[END_REF] and sport experts or beginners [START_REF] Chen | A Wearable Virtual Coach for Marathon Beginners[END_REF]. A growing body of evidence from Psychology and Sport Sciences shows that physical activity can be a cost-effective and safe intervention for the prevention and treatment of a wide range of mental and physical health problems [START_REF] Ekkekakis | Routeledge Handbook of Physical Activity and Mental Health[END_REF]. Yet, the design of virtual health agents faces multiple challenges such as [START_REF] Brinkman | Virtual Health Agents for Behavior Change: Research Perspectives and Directions[END_REF]: [START_REF] Ekkekakis | Routeledge Handbook of Physical Activity and Mental Health[END_REF] interpreting the situation and people's intentions, (2) intervention reasoning, (3) generating informative, educative, persuasive computer behavior, and (4) engineering generic solutions. Research in domains such as the Internet of Things (IoT), wearables and persuasive technologies [START_REF] De Vries | Persuasive Technology: Development and implementation of personalized technologies to change attitudes and behaviors[END_REF] does suggest that a coach intended to promote physical activities needs to provide tailored interaction [START_REF] Bjarne | Personalized Activity Intelligence (PAI) for Prevention of Cardiovascular Disease and Promotion of Physical Activity[END_REF][START_REF] Noar | Does Tailoring Matter? Meta-analytic Review of Tailored Print Health Behavior Change Interventions[END_REF], personalized messages and bring into play persuasive strategies that depend on gender and personality [START_REF] De Vries | A Word of Advice: How to Tailor Motivational Text Messages Based on Behavior Change Theory to Personality and Gender[END_REF], and stage of be-havior change [START_REF] De Vries | Crowd-Designed Motivation: Motivational Messages for Exercise Adherence Based on Behavior Change Theory[END_REF]. The use of persuasive technologies and virtual coaches for promoting physical activity might help stress management [START_REF] Sano | HealthAware: An Advice System for Stress, Sleep, Diet and Exercise[END_REF], but adhesion might also depend on aspects of the self [START_REF] Strachan | Identities, Schemas and Definitions: How Aspects of the Self Influence Exercise Behavior[END_REF][START_REF] Mcauley | Physical Activity and Personal Agency: Self-Efficacy as a Determinant, Consequence and Mediator[END_REF]. Thus tailoring information is significantly more effective when it provides specific details on how to improve the performance, rather than when it just indicates whether the performance is correct or not [START_REF] Bangert-Drowns | The instructional effect of feedback in test-like events[END_REF]. When tailoring information involves emotional dimension, interaction becomes more attractive, increasing student engagement and motivation [START_REF] Afzal | Designing for Automatic Affect Inference in Learning Environments[END_REF][START_REF] D' Mello | Toward an Affect-Sensitive AutoTutor[END_REF]. Finally, when users manage the tailoring process, Kim et al [START_REF] Kim | Information tailoring and framing in wearable health communication[END_REF] observe in a positive attitude toward the conveyed information.

Although lots of people still use a phone for collecting data during a physical activity, smartwatches display several advantages over mobile phones: they are closer to the body, safer to use than the mobile phone when moving, and they are designed to have a longer battery life. Using smartwatches to support affective interaction nevertheless rises challenges in terms of human-computer interaction. Multiple commercial wearables for sport activities are available. We claim that in order to become smart, an automated coach requires to provide via a smartwatch: 1) interactions that are personalized to the user, 2) dynamic support occurring not only before and after a physical activity but also during a physical activity, and 3) multimodal interactions (including subtle and complementary use of embedded graphics, audio and touch).

In this paper, we introduce WE-nner, a framework for the design of a coach supporting personalized interaction for physical activities. We illustrate how we implemented this coach using a commercial platform for embedded programming. We discuss how this framework impacts the relation between users and computing devices (smartwatch, mobile phone, web site) and may improve the relationships between users and computing devices.

WE-nner framework

Brinkman [START_REF] Brinkman | Virtual Health Agents for Behavior Change: Research Perspectives and Directions[END_REF] proposes a research framework for behavior change support systems that brings into play situation interpretation, intervention reasoning (using personal and population data ; possibly calling for remote assistance from human health professionals), and the generation of informative, educative and persuasive behaviors. In our framework we focus on this last step which requires that the system handles relevant features of user's profile and is able to use it dynamically during a physical activity to generate personalized and multimodal interactions.

Multimodal interaction during physical activity

The WWHT framework [START_REF] Rousseau | A Framework for the Intelligent Multimodal Presentation of Information[END_REF] describes how to present multimodal information to users along several questions: What is the information to present? Which modalities should we use to present this information? How to present the information using these modalities? How to handle the evolution of the resulting presentation? Few studies about multimodal interaction were conducted with smartwatches during physical activity. Lee et al. designed multimodal and mobile interaction between a user and a sport-watch while the user is walking on a treadmill [START_REF] Lee | Vouch: Multimodal Touch-and-Voice Input for Smart Watches under Difficult Operating Conditions[END_REF].

Interaction with a sport-watch can be personalized along several dimensions:

 Time: interaction can take place with the user at different timescales around a physical activity, for example several days before an activity, just before the activity starts, during the activity, just after the end of the activity, and several hours or days after the activity. One might expect that interactions at these different times would have different goals and results  Modality: information can be presented to the user on several channels and modalities: on the visual channel (graphics, text messages, text menus: displayed on the screen), touch (vibrations), and audio signals  Content: technical messages, motivating message, warning messages,  Goal: the task of coaching a user involves several components and use cases (e.g. weekly burnt calories)

Currently, user's profile include the user's name, gender, history of activities and weekly goal in terms of burnt calories.

Software implementation

Few smartwatches provide a software Development Kit and a programming language that enables embedded computing on the smartwatch. This is nevertheless required to dynamically customize the interaction with users. This allows to design customized interactions that fit between minimal interactions available on other commercial wearables and full symbiosis that are investigated in research. We implemented the WE-nner framework using the GARMIN Connect IQ environment and its MonkeyC object oriented programming language. GARMIN is one of the few smartwatch manufacturer that provides a Software Development Kit that enables to develop a program on a PC and to upload and embed the software on the watch itself. GARMIN offers a dedicated programming environment called Connect IQ1 which enables to program and upload several kinds of applications on a smartwatch (face, widget, data field and apps). Different types of applications have different degrees of access to the sensors and actuators of the watch and allow for different types of interactive capabilities. GARMIN wearables support four types of interactions components:

 WatchFaces provide personalized "passive" displays of the main screen. Users are able to choose and download the watch face they prefer and add any information they like.  Widgets provide at-a-glance information to the user that meets the individual customization. They are usually small practical tools like a compass or a weather report and are limited in terms of interaction capabilities.  DataFields are fields displaying data which is computed or available at runtime (e.g. speed, time). The expert user can select the fields that she wants to be displayed and their order of presentation. DataFiels do not support any interaction.

 Apps are the most interactive components that can be uploaded on the watch. They can contain menus, data, textual and graphical messages that can be selected and combined at runtime. An app is explicitly started from the main menu of the watch.

Interaction with advanced sport smartwatches such as a GARMIN watch can be quite tricky for the ordinary user. Furthermore, even apps available on the GARMIN store do not provide flexible and personalized multimodal interactions.

We implemented our WE-nner framework as a Connect IQ App in order to benefit from the maximum access to sensors and actuators. Fig. 1 illustrates how the WE-nner software uploaded on the GARMIN Fenix 5 smartwatch provides interaction that is personalized at runtime before an activity starts. The smartwatch collects information from an .xml file detailing user's profile (e.g. user name, user birth date, activity history). The menus as well as the responses of the different physical buttons that surround the watch can be completely changed at runtime to cope with a given user. Interaction can also be personalized during a physical activity. For example, a warning text, audio and tactile message (vibrations) can be generated dynamically by WEnner when the heart rate frequency goes beyond a given percentage of the current user's maximum heart rate frequency (Fig. 2).

Finally, WE-nner also enables to personalize interaction after the end of the activity, and display for example a congratulation message that embeds user's name and information about the current achievements in terms of burnt calories (Fig. 3).

Software architecture

The smartwatch provides sensors, screen and loudspeaker that enables a user to track her daily physical activities. The activity information that includes time, duration, speed, distance, calories burned and heart rate is mostly saved in .FIT binary files. The GARMIN connect web site enables a user to login and visualize the data related to his/her recorded activities and health status. The GARMIN Connect Mobile Application is required to synchronize the data between the watch and the web site.

We have developed an Android application called WEnnerMobile. It enables a user to view his activity history, visualize his heart rate records by curve chart, and test his/her pressure level by a answering a questionnaire. It will also provide a virtual coach to give the user personal advice on exercises. The user can choose a FIT or CSV fitness file stored in the phone memory. When a FIT file is chosen, it is be decoded into a CSV file, and the data can be processed and displayed in tables and charts.

Finally a website is used (WEnnerWeb) to store data collected with the watch and the mobile phone. The administrator of this web site can define the sport types, user's initial preferences of the sport and the target training time. Each time when an activity is finished, the WEnnerWatch app can collect Ecological Momentary Assessment and ask the user to self report on her mood (e.g. "Positive", "Negative" or "Neutral"). Such information can be exploited to tailor and adapt follow-up sessions.

.

Conclusions and Future Directions

We introduced the WE-nner technological framework for designing a coach that supports physical activity and enables personalized, multimodal and dynamic interactions between a user and a wearable. We explained and illustrated how this framework was implemented using a commercially available software development kit for smartwatches. The next step is to define the specifications of the personalized multimodal coach. We will go through a requirement analysis involving users with different levels of physical activities practice. This requirement analysis will identify the desired functions of the coach as well as its multimodal interaction capacities. This includes the selection of opportune motivational interactions delivery timing [START_REF] Sano | Designing Opportune Stress Intervention Delivery Timing using Multi-modal Data[END_REF].

Next steps include the modeling and implementation of relevant personality and inter-individual differences features in the WE-nner user's profile. We are considering two theories from Psychology: the OCEAN personality traits and the regulatory focus theory. These two theories because they have an impact either in terms of physical activity itself or in terms of persuasiveness. The OCEAN / Big Five personality traits, also known as the five factor model (FFM), is a model based on common language descriptors of personality [START_REF] Mccrae | An introduction to the five-factor model and its applications[END_REF]. The five factors have been defined as openness to experience, conscientiousness, extraversion, agreeableness, and neuroticism, often represented by the acronym OCEAN. Relations have been found between the OCEAN personality traits and motivation to learn [START_REF] De Feyter | Unraveling the impact of the Big Five personality traits on academic performance: The moderating and mediating effects of self-efficacy and academic motivation[END_REF], but also with physical exercise (see [START_REF] Rhodes | Personality correlates of physical activity: a review and metaanalysis[END_REF] for a review). For example, Tolea et al. found [START_REF] Tolea | Associations between personality traits, physical activity level, and muscle strength[END_REF] found some associations between personality traits and physical activity level. Saklofske et al. observed that self-report emotional intelligence mediated the relationship between personality and exercise behavior [START_REF] Saklofske | Personality, emotional intelligence and exercise[END_REF].

The second theory that we are considering is the regulatory focus [START_REF] Higgins | Beyond pleasure and pain[END_REF]. Regulatory focus has been shown to influence how individuals make judgments and decisions [START_REF] Cesario | Regulatory Fit and Persuasion: Basic Principles and Remaining Questions[END_REF]. We have already regulatory focus in our MARC virtual agent platform [START_REF] Faur | A Socio-cognitive Approach to Personality: Machine-learned Game Strategies as Cues of Regulatory Focus[END_REF][START_REF] Faur | Measuring Chronic Regulatory Focus with Proverbs: the Developmental and Psychometric Properties of a French Scale[END_REF]. Regulatory focus is also being used for the generation of persuasive messages [START_REF] Corrégé | Persuasive Dialogue System for Energy Conservation[END_REF]. Individuals are either gain-oriented ("promotion-focused") or loss-oriented ("prevention-focus"). Framing messages influence individuals' cognitive processing of messages [START_REF] Lee | Bringing the Frame Into Focus: The Influence of Regulatory Fit on Processing Fluency and Persuasion[END_REF].

In terms of interaction, we will extend our framework for supporting the dynamic selection of output modalities and their combinations (e.g. complementarity, redundancy) to achieve an appropriate integration of the senses by users. This requires considering contextual information (e.g. if the user is on the move, a vibration can be used to inform the user that she should stop and look at an important message on the watch). Frameworks for multimodal output generation will be considered [START_REF] Rousseau | A Framework for the Intelligent Multimodal Presentation of Information[END_REF]. We will also consider the design of consistent interactions between the smartwatch, the mobile phone and a web site in order to support the relation between the user and her personalized coach which is in fact dispatched over several devices (possibly including other sensors and wearables).

We are also considering on how an animated and expressive agent displayed on the smartphone (and simple representations of it on the watch) can motivate the user based on affective reasoning and data [START_REF] Callejas | A Virtual Coach for Active Ageing Based on Sentient Computing and m-health[END_REF]. These dimensions of personality and multimodal interaction will be considered as input for the modelling and implementation of the coach using the WEnner technological framework introduced in this paper.

Long term user studies need to be conducted to test if this wearable and its personalized and multimodal interactions do induce engagement and behavior change, and to assess how much they are impacted by aspect of the self [START_REF] Strachan | Identities, Schemas and Definitions: How Aspects of the Self Influence Exercise Behavior[END_REF][START_REF] Mcauley | Physical Activity and Personal Agency: Self-Efficacy as a Determinant, Consequence and Mediator[END_REF]. Ethics and privacy are also considered since personal data is collected and can induce behavior change.

Finally, sport coaching will be articulated with another coach in charge of stress management so that both coaches can exchange information in order to fine-ture and tailor consistent interactions.

Fig. 1 .

 1 Fig. 1. Screendumps showing personalized interaction before an activity starts: a) WE-nner displays a personalized message including user's name, b) it suggests several activities (which can consider user's history of previous activities), c) the user is able to select the activity she wants to do, and d) the activity is ready to start.

Fig. 4 Fig. 2 .Fig. 3 .

 423 Fig.2. Screendumps showing personalized interaction during an activity: a) at some point during an activity, a multimodal (graphics, audio, vibrations) personalized message is dynamically computed and displayed including user's name and considering a threshold of heart rate frequency that is specific to this user.

Fig. 4 .

 4 Fig. 4. Personalized messages displayed on the smartwatch during an outdoor test.

Fig. 5 .

 5 Fig. 5. Devices and software architecture of the WEnner framework.

https://developer.garmin.com/connect-iq/


Giovanni Ciatto
email: giovanni.ciatto@unibo.it

Stefano Mariani
email: stefano.mariani@unimore.it

Maxime Louvel
email: maxime.louvel@bag-era.fr

Andrea Omicini
email: andrea.omicini@unibo.it

Franco Zambonelli
email: franco.zambonelli@unimore.it

Twenty Years of Coordination Technologies: State-of-the-Art and Perspectives

Keywords: coordination technologies, middleware, survey

Since complexity of inter-and intra-systems interactions is steadily increasing in modern application scenarios (e.g., the IoT), coordination technologies are required to take a crucial step towards maturity. In this paper we look back at the history of the COORDINATION conference in order to shed light on the current status of the coordination technologies there proposed throughout the years, in an attempt to understand success stories, limitations, and possibly reveal the gap between actual technologies, theoretical models, and novel application needs.

Scope, Goal, and Method

Complexity of computational systems, as well as their impact on our everyday life, is constantly increasing, along with the growing complexity of interactioninter-and intra-systems. Accordingly, the role of coordination models should expectedly grow, along with the relevance of coordination technologies within ICT systems: instead, this is apparently not happening-yet.

Then, it is probably the right time -now, after twenty years of the COOR-DINATION conference -and the right place -the COORDINATION conference itself -to take a a step back and reflect on what happened to coordination models, languages, and (above all) technologies in the last two decades. That is why in this paper we survey all the technologies presented and discussed at COOR-DINATION, examine their stories and their current status, and try to provide an overall view of the state-of-the art of coordination technologies as emerging from twenty years of work by the COORDINATION community. The main goal is to provide a sound basis to answer questions such as: Are coordination technologies ready for the industry? If not, what is currently missing? Which archetypal models lie behind them? Which are the research areas most/least explored? And what about the target application scenarios?

Structure & Contribution of the Paper

Section 2 first provides an overview of the data about papers published in the conference throughout the years (Subsection 2.1), as collected from the official SpringerLink website and its companion BookMetrix service, with the aim of emphasising trends concerning (i) the number of papers published in each volume, (ii) the number of citations generated by each volume, (iii) the number of downloads generated by each volume, (iv) the most cited paper of each volume, and (v) the most downloaded paper of each volume.

Then, the scope of our analysis narrows down to those papers bringing a technological contribution, in the sense of describing a software artefact offering an API exploitable by other software to coordinate its components. Accordingly, Subsection 2.2 provides an overview of all the technologies born within the COORDINATION conference series. For each one, the reference model implemented, and the web URL where to retrieve the software -if any -are given.

Then, a brief description of all the software for which no working implementation could be found is reported for the sake of completeness, whereas technologies still available are thoroughly described in Subsection 2.3. There, each selected technology was downloaded and tested to clearly depict its health status:

-date of last update to the source code (or project web page, if the former is not available) -whether the software appears to be actively developed, in maintenance mode, or discontinued -whether suitable documentation is available -whether the source code is publicly available -whether the build process of the software artefact is reproducible -whether the software artefact, once built, executes with no errors For the latter two items, in case of failures, an explanation of the problem and, if needed, the steps undertaken in the attempt to overcome it, are provided too. In particular, the latter test is not meant to measure performance, or, to provide a benchmark for comparisons: its purpose is to assess whether the technology is usable, that is, executable on nowadays software platforms and by nowadays programming languages. For instance, a library requiring an obsolete third-party libraries that hinders smooth deployment is considered not usable. Accordingly, each technology is tested either running provided example code, or developing a minimal working example of usage of the API.

Section 3 discusses the data collected so as to deliver insights about: (i) the evolution of technologies as they are stemming from a few archetypal models (Fig. 5), (ii) the relationships between the selected technologies, as a comparison of their features (Fig. 6), and (iii) the main goal and reference scenario of each technology (Fig. 7). Also, a general discussion is provided, reporting about success stories, peculiarities, and opportunities.

Finally, Section 4 concludes the paper by summarising the results of the survey and providing some perspectives for the future of coordination technologies.

Method

The scope of this survey is indeed the COORDINATION conference series. There, we focus on coordination technologies intended as software implementing a given coordination model, language, mechanism, or approach with the goal of providing coordination services to other software applications. In other words, our focus is on technologies implementing some form of coordination middleware or API -analysed in Subsection 2.2. We nevertheless include in our overview other technologies produced within COORDINATION (Subsection 2.1), such as simulation frameworks, model-checking tools, and proof-of-concept implementations of process algebras-which are only described in short.

Starting from the COORDINATION conference proceedings available online from SpringerLink 1 , the survey proceeds as follows:

1. for each conference year, papers describing a coordination-related technology were gathered manually into a Google Spreadsheet 2. for each collected paper, we checked whether the paper was actually proposing some software package-papers failing the test are omitted 3. for each paper passing the test, we verified the health status of the technologyas described in Subsection 1.1 4. then, for each paper featuring at least a usable distribution -meaning a downloadable version of the software -the corresponding software was downloaded and tested-i.e., installation & basic usage

The Survey

Although the focus of this paper are coordination technologies, we believe an overview of the whole conference proceedings is due to give context to the survey itself. Accordingly, Subsection 2.1 summarises and analyses all the data officially available from Springer-concerning, for instance, citations and downloads of each volume and paper. Then, Subsection 2.2 accounts for all the coordination technologies mentioned in COORDINATION papers, regardless of their actual availability, while Subsection 2.3 reports about the core of this survey: the status of the coordination technologies nowadays publicly available.

Overview

The COORDINATION conference series has been held 19 times since its first edition in 1996 in Cesena (Italy), and generated as many conference proceedings volumes-all available online 1 . Data about the number of published papers, the number of citations and downloads per year of each volume, as well as the most cited and most download paper have been collected from SpringerLink and its companion service BookMetrix The trend over time of the number of papers, the citations of the volumes, and their downloads, are plotted in Fig. 1 and Fig. 2, respectively, along with their trend line. A few significant trends can be spotted in spite of the high variability between different editions of the conference. For the number of published papers, the trend is clearly descending: the first five editions featured an average of 32 papers, whereas the latest five an average of 15. As far as the number of citations per year generated by each volume of the proceedings is concerned, a few oscillations can be observed:

-a first phase (from the 1 st edition to the 4 th ) shows a decreasing number of citations, from 3.32 down to 0.11 (the all-time-low ) -then, in a second phase (from the 5 th to the 10 th edition) the number of citations increases, up to 10.70 in 2008 -finally, after a brief fall in 2009 and 2010, the number of citations per year kept increasing up to the all-time-high of 2016 (14.00)

For the number of downloads per year, two phases can be devised out in Fig. 2:

-in the first period, from the 1 st edition to the 13 th (2011), the trend is quite stable, oscillating between 140 and 538.57 -in the second one instead, from 2012 up to latest edition, there is a sharp increase up to the all-time-high of 2355.00 in 2016

Finally, Fig. 3 and Fig. 4 show the most cited paper and the most downloaded paper per year, respectively. Besides noting (i) the highly irregular trend regarding the most cited papers, oscillating from 6 to 22 through approximately three epochs again during 2010-2017), and (ii) the increasing number of downloads in recent years: in the four years between 2010 and 2013 the most downloaded papers combined generated more downloads than the most downloaded papers of all the previous years combined (2281 vs. 2216), it could be interesting to check how many of such papers are related to technology, if any. Overall, in the 19 editions of COORDINATION held until now, the most cited / downloaded paper is about technology -in the broadest acceptation of the term -in slightly less then a half of them: 7 papers amongst the most cited ones, and 8 amongst the most downloaded ones.

By extending the analysis to all the papers published in the proceedings, instead, out of all the 390 papers published, only 47 (just 12.05%) -based on authors' inspection of the papers -convey a technological contribution. And, such an estimate is somehow optimistic, since we counted papers just for merely mentioning a technology, with no means to access it-see Table 2 The early days. The first few years of COORDINATION (1996COORDINATION ( -2000) ) saw a flourishing of successful technologies: some of the ideas introduced back then are still alive and healthy. For instance, ACLT [START_REF] Denti | An extensible framework for the development of coordinated applications[END_REF] adopted first-order logic terms as Linda tuples, an intuition shared by the µ 2 Log model and its language, MultiBinProlog [START_REF] De Bosschere | µ2Log: Towards remote coordination[END_REF]. Also, ACLT allowed agents to dynamically program tuple spaces via a specification language, enabling definition of computations to be executed in response to some events generated by interacting processes. Both features influenced the TuCSoN model and infrastructure [START_REF] Cremonini | Coordination in context: Authentication, authorisation and topology in mobile agent applications[END_REF], one of the few technologies to be still actively maintained nowadays.

Similarly, the IWIM coordination model and its corresponding language, Manifold [START_REF] Arbab | The IWIM model for coordination of concurrent activities[END_REF], were introduced back in 1996 and survived until present days by evolving into Reo [START_REF] Arbab | Coordination through channel composition[END_REF]. IWIM came by recognising a dichotomy between exogenous and endogenous coordination, and exploiting channel composition as a means to build increasingly complex coordination patterns.

Finally, Moses [START_REF] Ao | Law-Governed Internet communities[END_REF] was presented to the COORDINATION community as an infrastructure reifying the Low Governed Interaction (LGI) model. The technology is still alive and inspectable from its homepage, even if apparently no longer maintained. Analogously, the Piccola composition language presented in [START_REF] Achermann | Scripting coordination styles[END_REF] clearly relies on a coordination technology which reached stability and robustness, even if it seems to be no longer maintained, too.

Besides these success stories, many other papers at that time proposed a technology, but either they only mentioned the technology without actually providing a reference to a publicly available software, or such a reference is no longer reachable (i.e. the link is dead and no reference to the software have been found on the web). For instance: Sonia [12] -a Linda-like approach supporting human workflows, therefore stressing aspects such as understandability of the tuple and template languages, time-awareness and timeouts, and security by means of access control Laura [START_REF] Tolksdorf | Coordinating services in open distributed systems with Laura[END_REF] -a language attempting to steer Linda towards service-orientation, where tuples can represent (formal descriptions of) service requests, offers, or results, thus enabling loosely coupled agents to cooperate by means of Linda-like primitives MESSENGERS [START_REF] Fukuda | Intra-and inter-object coordination with MESSENGERS[END_REF] -following the Navigational Programming methodology [START_REF] Fukuda | Intra-and inter-object coordination with MESSENGERS[END_REF], where strongly-mobile agents -a.k.a. Messengers -can migrate between nodes. Here, coordination is seen as "invocation [of distributed computations] and exchange of data" and it "is managed by groups of Messengers propagating autonomously through the computational network" Blossom [START_REF] Van Der Goot | Safer tuple spaces[END_REF] -a Linda variant focusing on safety, which is provided by supporting a type system for tuples and templates, and a taxonomy of access patterns to tuple spaces, aimed at supporting a sort of "least privilege" principle w.r.t. access rights of client processes Bonita [START_REF] Rowstron | Using asynchronous tuple-space access primitives (bonita primitives) for process co-ordination[END_REF] -another Linda-like technology -as its successor WCL [START_REF] Rowstron | WCL: A co-ordination language for geographically distributed agents[END_REF] focusing on asynchronous primitives and distribution of tuple spaces, which can also migrate closer to their users Berlinda [START_REF] Tolksdorf | Berlinda: An object-oriented platform for implementing coordination languages in Java[END_REF] -providing a meta-model -along with a Java implementation -for instantiating different Linda-like models SecOS [START_REF] Bryce | A coordination model for agents based on secure spaces[END_REF] -a Linda variant focusing on security and exploring the exploitation of (a)symmetric key encryption Messengers [START_REF] Varela | A hierarchical model for coordination of concurrent activities[END_REF] -not to be confused with [START_REF] Fukuda | Intra-and inter-object coordination with MESSENGERS[END_REF] despite its name, which focusses on message exchange by means of migrating actors MJada [START_REF] Rossi | Internet-based coordination environments and documentbased applications: a case study[END_REF] -an extension of the Jada language [START_REF] Ciancarini | Jada: Coordination and communication for Java agents[END_REF], focusing on coordinating concurrent (possibly distributed) Java agents by means of Linda-like tuple spaces with an extended primitive set and object-oriented tuples Clam [86] -a coordination language based on the IWIM model [START_REF] Arbab | The IWIM model for coordination of concurrent activities[END_REF] Truce [START_REF] Jamison | TRUCE: Agent coordination through concurrent interpretation of role-based protocols[END_REF] -a scripting language aimed at describing protocols to which agents must comply by enacting one or more roles CoLaS [START_REF] Cruz | A group based approach for coordinating active objects[END_REF] -a model and its corresponding language providing a framework where a number of participants can join interaction groups and play one or more roles within the scope of some coordination protocol. In particular, CoLaS focuses on the enforcement of coordination rules by validating and constraining participants behaviour

The millenials. After year 2000, technologies are less present amongst COOR-DINATION papers, but not necessarily less important. For instance, Reo made its first appearance in 2002 [START_REF] Arbab | Coordination through channel composition[END_REF], its name written in Greek (P ω). Reo provides an exogenous way of governing interactions between processes in a concurrent and possibly distributed system. Its strength is due to its sound semantics, enabling researchers to formally verify system evolution, as well as to the availability of software tools. The technology is indeed still alive and actively developed.

Recent implementations are more easily available on the web. Out of 22 coordination technologies, just 6 were not found on the web during the survey:

OpenSpaces [START_REF] Ducasse | Openspaces: An object-oriented framework for reconfigurable coordination spaces[END_REF] -focussing on the harmonisation of the Linda model with the OOP paradigm and, in particular, with the inheritance mechanism Scope [63] -analogously to Lime, it provides multiple distributed tuple spaces cooperating by means of local interactions when some process attempts to access a tuple, thus providing a sort of federated view on the tuple space SpaceTub [94] -successor of Berlinda, it aims at providing a meta-framework where other Linda-like frameworks can be reproduced WikiRecPlay / InFeed [80] -a pair of tools (browser extensions, no longer available) aimed at extracting and manipulating information from web applications to record them and later replay, enabling the definition of sequences of activities that can be synchronised with each other. The goal here is to augment social software with coordination capabilities. LINC [START_REF] Louvel | LINC: A compact yet powerful coordination environment[END_REF] -a coordination environment implementing the basic Linda primitivesout, in, rd -in a setting in which each tuple space (called bag) could implement the primitives differently (still preserving semantics), a convenient opportunity when dealing with physical devices (i.e. in the case of deployment to IoT scenarios) or legacy systems (i.e. databases). It provides transactions to alleviate to developers the burden of rolling back actions in the case of failures, and a chemical-reaction model inspired to Gamma [START_REF] Banȃtre | Gamma and the chemical reaction model: Fifteen years after[END_REF] for enacting reaction rules. Several tools [START_REF] Louvel | Development tools for rule-based coordination programming in LINC[END_REF] All the others are still publicly available, thus further analysed in next section. For instance, the O'Klaim language presented in [START_REF] Bettini | O'Klaim: A coordination language with mobile mixins[END_REF] evolved into the X-Klaim project [START_REF] Bettini | Mobile distributed programming in X-Klaim[END_REF] which is still alive, even if apparently no longer maintained. Similar considerations can be made for Limone [START_REF] Fok | A lightweight coordination middleware for mobile computing[END_REF] and CRIME [START_REF] Mostinckx | Fact Spaces: Coordination in the face of disconnection[END_REF], which both stem from the idea of opportunistic federation of transient tuple spaces introduced by LIME [START_REF] Murphy | LIME: A coordination model and middleware supporting mobility of hosts and agents[END_REF], and improve it with additional features such as lightweightness and orientation to ambient-programming.

Analogously, the CiAN [START_REF] Sen | CiAN: A workflow engine for MANETs[END_REF] model and middleware, targeting the coordination of distributed workflows over M obile Ad-hoc Networks (MANETs), comes with a mature implementation, although no longer maintained. An extension to Session Java [START_REF] Hu | Session-based distributed programming in Java[END_REF] is proposed in [START_REF] Ng | Safe parallel programming with Session Java[END_REF] to explicitly tackle synchronisation issues such as freedom from deadlock via multi-channel session primitives, Whereas the implementation was discontinued in 2011 4 , the source code is still available from GoogleCode archive. JErlang [START_REF] Plociniczak | JErlang: Erlang with Joins[END_REF], a Java-based implementation of Erlang extended with constructs borrowed from the Join-Calculus [START_REF] Fournet | The reflexive CHAM and the Join-calculus[END_REF], appears to be no longer maintained too as explicitly stated in its home page 5 , although a couple of implementations are still available and (partially) working.

Also RepliKlaim [START_REF] Andrić | Replica-based high-performance tuple space computing[END_REF], an implementation of Klaim [START_REF] Bettini | An infrastructure language for open nets[END_REF] aimed at optimising performance and reliability through replication of tuples and tuple spaces, received updates until 2015 as far as we know, thus appears to be discontinued. Likewise, 2015 is the year when both Statelets [START_REF] Liptchinsky | Statelets: Coordination of social collaboration processes[END_REF] and IIC [START_REF] Proença | Interactive interaction constraints[END_REF] received their last known update: the former is a programming model and language aimed at integrating social context and network effects, derived from social networks analysis, as well as semantic relationships amongst shared artefacts in, i.e. groupware applications, into a single and coherent coordination model, while the latter proposes Interactive Interaction Constraints (IIC) as a novel framework to ground channel-based interaction -à la Reo -upon constraints satisfaction, interpreting the process of coordinating components as the execution of a constraints solver.

Next section briefly focuses on those technologies-that is, coordination technologies that can be actually installed and used nowadays-step §4 in Section 1.2. -Smrl requires ancient software to run-that is, an old version of Eclipse requiring in turn an ancient version of the Java runtime (1.4) -CaSPiS [START_REF] Bettini | Implementing session centered calculi[END_REF] (or better, JCaSPiS, namely the Java-based implementation of CaSPiS) was not found anywhere-neither in the author personal pages, nor in their account profiles on Github, nor in the web pages of the SENSORIA project mentioned in the paper. Nevertheless, the IMC model and framework allegedly grounding its implementation is still accessible 6 . Then we proceeded to download it looking for the CaSPiS code, without success. It is worth to be mentioned, anyway, that the IMC framework code appears to be broken, since compilation fails unless a restricted/deprecated Java API is used 7 , and even in the case of instructing the compiler to allow for it 8the attempt to run any part of the software failed without informative error messages-just generic Java exceptions. -LeanProlog is not usable as a coordination technology as defined in Section 1.2: it is a Prolog engine with low-level mechanisms for handling multithreading, and provides no API for general purpose coordination -Session Java, as explicitly stated in its home page, requires an ancient version of the Java runtime to run, that is, 1.4 -Statelets is explicitly tagged as being in "pre-alpha" development stage, and, upon inspection, revealed to be only partially developed There is no publicly available code repository, thus no information about latest commits.

Analysis of selected technologies

Table 3. Overview of the working coordination technologies presented at COORDINATION. Column "Health" denotes the status of the software, for instance whether it is still actively developed, only in mainteinance mode, or actually discontinued, column "Build" is filled whenever source code is available and denotes whether build steps (i.e. compilation into binaries and dependencies resolution) were successful, column "Deployment" indicates whether the software has been successfully executed. It is worth to emphasise that LINC has been left out since it is part of commercial solutions sold by the Bag-Era company, thus no further inspection of the software was possible.

TuCSoN. Although TuCSoN [START_REF] Cremonini | Coordination in context: Authentication, authorisation and topology in mobile agent applications[END_REF] appeared at COORDINATION in 1999, its roots date back to the first edition of the conference, as the ACLT model [START_REF] Denti | An extensible framework for the development of coordinated applications[END_REF].

TuCSoN is a coordination model adopting Linda as its core but extending it in several ways, such as by adopting nested tuples (expressed as first-order logic terms), adding primitives (i.e. bulk [START_REF] Rowstron | Bulk Primitives in Linda Run-Time Systems[END_REF] and uniform [START_REF] Mariani | Coordination mechanisms for the modelling and simulation of stochastic systems: The case of uniform primitives[END_REF]), and replacing tuple spaces with tuple centres [START_REF] Omicini | From tuple spaces to tuple centres[END_REF] programmable in the ReSpecT language [START_REF] Omicini | Formal ReSpecT in the A&A perspective[END_REF]. It comes with a Java-based implementation providing coordination as a service [START_REF] Viroli | Coordination as a service[END_REF] in the form of a Java library providing API and a middleware runtime, especially targeting distributed Java process but open to rational agents implemented in tuProlog [START_REF] Denti | tuProlog: A light-weight Prolog for Internet applications and infrastructures[END_REF]. The TuCSoN middleware is publicly available from its home page 9 , which provides both the binaries (a ready-to-use Java jar file) and a link to the source code repository. From there, also documentation pages are available, in the form of a usage guide and a few tutorials providing insights into specific features. Finally, a few related sub-projects are therein described too, such as TuCSoN4Jade [START_REF] Mariani | Models of autonomy and coordination: Integrating subjective & objective approaches in agent development frameworks[END_REF] and TuCSoN4Jason [START_REF] Mariani | Multi-paradigm coordination for MAS: Integrating heterogeneous coordination approaches in MAS technologies[END_REF], which are both Java libraries aimed at integrating TuCSoN with Jade [START_REF] Bellifemine | JADE-a FIPA-compliant agent framework[END_REF] and Jason [START_REF] Bordini | Programming Multi-Agent Systems in AgentSpeak using Jason[END_REF] agent runtimes, respectively, by wrapping TuCSoN services into a more convenient form which best suites those developers accustomed to programming in those platforms.

As far as technology is concerned, TuCSoN is still actively developed, being the latest commit in 2017, when also the latest related publication has been produced-an extension to the ReSpecT language and toolchain exploited to program tuple centres in TuCSoN [START_REF] Ciatto | Programming the interaction space effectively with ReSpecTX[END_REF]. Also, it is actively exploited as the infrastructural backbone for other projects -e.g., the smart home logic-based platform Home Manager [START_REF] Calegari | Building Smart Spaces on the Home Manager platform[END_REF] -and industrial applications-e.g., the Electronic Health Record solution [START_REF] Dubovitskaya | A multiagent system for dynamic data aggregation in medical research[END_REF]. Nevertheless, TuCSoN is the results of many years of active development by many different people with many different goals. Thus, despite some success stories, TuCSoN would require some substantial refactoring and refinement before it can become a truly commercially-viable product.

Moses. Moses [START_REF] Ao | Law-Governed Internet communities[END_REF] is the technology implementing the Law Governed Interaction (LGI) coordination model [START_REF] Minsky | Law-Governed Linda as a coordination model[END_REF], which aims at controlling the interaction of agents interoperating on the Internet. In LGI, each agent interacts with the system by means of a controller, that is, a component exposing a fixed set of primitives allowing agents to exchange messages with other agents. The controller is in charge of intercepting invocations of primitives by interacting agents to check if they are allowed according to the law currently adopted by that controller.

Laws are shared declarative specifications dictating how the controller should react when it intercepts events of interest. Laws are expressed either in a Prologlike language or as Java classes. Each controller has its own state which can be altered by reactions to events and can influence the effect of future reactions. Non-allowed activities are technically prohibited by the controller which takes care of aborting the forbidden operation-for instance, by not forwarding a message to the intended receiver if some conditions are met.

The project home page 10 is well-organised and provides a number of resources focussed on Moses/LGI such as reference papers, manuals, tutorials, JavaDoc, examples. The page also provides an archive with the compiled versions of the Moses middleware, the latest one dating back to 2017-suggesting that the project is actively maintained and/or developed, and representing another success story born within the COORDINATION series. We were able to successfully compile and execute the code: however, no source code is provided, and some poriontof the web page, such as the JavaDoc, are not updated w.r.t. the current Moses implementation. Finally, Moses still bounds to deprecated technologies such as Java Applets, which we believe may hinder its adoption.

JErlang. JErlang [START_REF] Plociniczak | JErlang: Erlang with Joins[END_REF] is an extension of the Erlang language for concurrent and distributed programming featuring joins as the basic synchronisation constructas borrowed from the Join-Calculus [START_REF] Fournet | The reflexive CHAM and the Join-calculus[END_REF]. The web page mentioned in the paper 11 is no longer accessible; by searching JErlang and the authors' names on the web, a GitHub repository with the same broken reference popped up 12 , apparently tracking the development history of the JErlang technology. There, however, JErlang is described as an implementation of Erlang/OTP on the JVM. Also, another apparently very similar technology is therein referenced: Erjang.

Anyway, JErlang installation and usage instructions are nowhere to be found, and, when trying to build the project through the provided Maven pom.xml file, the build fails due to many errors related to obsolete dependencies-which we were not able to fix. Instead, Erjang GitHub repository -with no clue about its links to the paper -provides installation instructions, however building fails due to a Java compilation failure for a "bad class file" error 13 . We feel then free to declare the implementation as discontinued. [START_REF] Proença | Interactive interaction constraints[END_REF] is a sort of "spin-off" of Reo introduced in 2013 [START_REF] Proença | Interactive interaction constraints[END_REF]. The original approach of implementing Reo connectors as interaction constraints is extended to allow interaction to take place also between rounds of constraints satisfaction. This extends the expressive reach of IIC beyond Reo, and makes the whole process of constraints satisfaction transactional w.r.t. observable behaviour.

IIC. Interactive Interaction Constraints (IIC)

The IIC software is distributed as a Scala library providing an handy syntax which eases definition of Reo-like connectors. The Scala library source code is distributed by means of a GitHub repository 14 where the latest commit dates back to 2015. The library ships with a SBT configuration, allegedly supporting automatic building. Nevertheless, we were not able to reproduce the compilation process since the provided SBT configuration depends on an ancient SBT version. Therefore, we consider IIC a no longer maintained but still usable fullfledged coordination technology.

Reo. Reo was firstly introduced to the COORDINATION community in [START_REF] Arbab | Coordination through channel composition[END_REF], its name in Greek letters (P ω). Similarly to the IWIM model, Reo adopts a paradigm for exogenous coordination of concurrent and possibly distributed software components. According to the Reo model, components are the entities to be coordinated, representing the computations to be performed, while connectors are the asbtraction reifying coordination rules. The only assumption Reo makes about components is that they have a unique name and a well-defined interface in the form of a set of input ports and output ports. Conversely, connectors are composed by nodes and channels, or other connectors. A number of coordination schemes can be achieved by combining the different sorts of nodes and channels accordingly. This allows to formally specify how, when, and upon which conditions data may flow from the input to the output ports of components.

Diverse research activities originated from Reo throughout the years, mostly aimed at (i) analysing the formal properties of both Reo connectors and constraints automata [START_REF] Baier | Modeling component connectors in reo by constraint automata[END_REF], which are the computational model behind Reo semantics; and (ii) supporting web services orchestration [START_REF] Jongmans | Orchestrating web services using Reo: from circuits and behaviors to automatically generated code[END_REF], composition, and verification [START_REF] Kokash | Reo + mCRL2: A framework for modelchecking dataflow in service compositions[END_REF] by means of code generation and verification tools.

Several technologies are available from the Reo tools homepage 15 , collectively branded as the Extensible Coordination Tools (ECT). They consist of various Eclipse IDE plugins, such as a graphical designer for Reo connectors, and a code generator which automatically converts the graphical description into Java sources in which developers may inject applicative logic. Nevertheless, the generated code comes with no explicit support for distribution.

According to their home page, ECT are allegedly compatible with any Eclipse version starting from 3.6; while we were not able to reproduce its installation in that version (due to a dependency requiring an higher version of Eclipse), we succeeded in installing it on Eclipse version 4.7 (the latest available), but the code generator appears buggy and unstable -thus hindering further testing -because of several non-informative error messages continuously appearing when trying to use the Reo model designer-which is a required step for code generation.

The ECT source code is available from a Google Code repository 16 -last commit dating back to 2013. In [START_REF] Proença | Dreams: A framework for distributed synchronous coordination[END_REF] a novel implementation is proposed, named Dreams, implemented in Scala and aimed at closing the gap between Reo and distributed systems. Nevertheless, its binary distribution seems unavailable and no documentation is provided describing how to compile or use it, thus we were not able to further test this novel Dreams framework.

TripCom. TripCom [START_REF] Simperl | A coordination model for triplespace computing[END_REF] is essentially a departure from the Linda model where the tuple space abstraction is brought towards the Semantic Web vision [START_REF] Hendler | Agents and the Semantic Web[END_REF] and web-based semantic interoperability in general. The former is achieved by employing the Resource Description Framework (RDF) -that is, a representation of semantic information as a triple "subject-predicate-object" -as the tuple representation language, and by considering tuple spaces as RDF triplets 15 http://reo.project.cwi.nl/reo/wiki/Tools 16 https://code.google.com/archive/p/extensible-coordination-tools/source containers. Also, Linda primitives have been consequently re-thought under a semantics-oriented perspective-that is, by adopting an ad-hoc templating language enabling expression of semantic relationships. The latter is achieved by making triple spaces accessible on the web as SOAP-based web-services.

The implementation is hosted on a SourceForge repository 17 and it is apparently discontinued, provided that the last commit dates back to 2009, and the home page lacks any sort of presentation or reference to publications or documentation. Nevertheless, the available source code appears well engineered and is well documented. It can be easily compiled into a .war file and then deployed on a Web Server (i.e. Apache Tomcat).

Once deployed, the web service is accessible via HTTP -making it is virtually interoperable with any programming language and platform -and can be tested by means of a common web browser. Additionally, the service exposes a WSDL description of the API needed to use it, which implies that a client library (aka stub) may be automatically generated using standard tools for serviceoriented architectures. Nevertheless, this WSDL description is the only form of documentation when it comes to actually interact with the web-service.

CiAN. Collaboration in Ad hoc Networks (CiAN) [START_REF] Sen | CiAN: A workflow engine for MANETs[END_REF] is a Workflow Management System (WfMS) enabling users to schedule and execute their custom workflow over MANETs. It comes with a reference architecture and a middleware. The middleware keeps track of the workflow state in a distributed way, and takes into account routing of tasks' input/output data, on top of a dynamic network topology where nodes communication is likely to be opportunistic.

Workflows in CiAN are modelled as directed graphs whose vertices represent tasks, and edges represent the data-flow from a task to its successors: when a task is completed, a result value is transferred through its outgoing edges. Conditions may be specified within task definitions stating, for instance, weather a task should wait for all its inputs or just for one of them.

Users can encode their workflow descriptions via a XML-based language to be endowed to an initiator singleton node, distributing the workflow to a number of coordinator nodes in charge of allocating tasks to the available worker nodes.

While the middleware is implemented in Java, tasks logic can be implemented virtually by means of any language since CiAN only assumes the application logic to interact with the middleware by means of the SOAP protocol, which provides great interoperability. Both the middleware's source code and its compiled version are distributed through CiAN website 18 , together with detailed documentation and some runnable examples. The source code can be easily compiled, and both the obtained binaries and those publicly available can be run smoothly. The code is well documented and engineered. Nevertheless, the source code and documentation both date back to 2008: we therefore consider the project to be mature and usable, but no longer maintained.

Piccola. Piccola [START_REF] Achermann | Scripting coordination styles[END_REF] is in its essence a composition language. It provides simple yet powerful abstractions: forms as immutable, prototype-like, key-value objects; services as functional forms which can be invoked and executed; agents as concurrent services; and channels as inter-agent communication facilities. Virtually any interaction mechanism can be built by properly composing these abstractions, such as shared variables, push and pull streams, message-passing, publish-subscribe, and so on.

Nevertheless, a limitation is due to the fact that not solely the coordination mechanisms are to be programmed with the Piccola language, but also the coordinated entities. There is thus no possibility of integration with mainstream programming languages, which is a severe limitation for adoption. Additionally, even if Piccola comes with networking capabilities virtually enabling deployment to a distributed setting, there is no middleware facility available and no opportunity with integration with others is given, which is another factor likely to hinder Piccola adoption within the scope of distributed programming and coordination.

Piccola home page 19 is still available and collects a number of useful resources such as documentation pages and implementation. This comes in two flavours: JPiccola, based on Java, which reached version 3.7, and SPiccola, based on Smalltalk, which reached version 0.7. Source code is provided for the Java implementation only, which correctly compiles and executes.

Nevertheless, the project appears to be discontinued, given that the last commit on the source repository dates back to 2006. CRIME. CRIME adheres to the Fact Spaces model, a variant of Linda which absorbs transient federation of tuple space from Lime [START_REF] Murphy | LIME: A coordination model and middleware supporting mobility of hosts and agents[END_REF] for implementing mobile fact spaces-tuple spaces where tuples are logic facts and each tuple space is indeed a logic theory. Federated fact spaces are therefore seen as distributed knowledge bases.

In this sense, CRIME has some similarities with TuCSoN, which exploits firstorder logic tuples both as the communication items and as the coordination laws. In this context, Linda out and in primitives collapse into logic facts assertions and retractions, respectively.

Suspensive semantics is not regarded as being essential within the scope of the Fact Spaces model, since the focus is about programming fact spaces to react to information insertion/removal (or appearance/disappearance in case of transient federation). Accordingly, users can register arbitrary logic rules by means of a Prolog-like syntax. The head of such rules represent propositions which may be proved true (activated) or unknown (deactivated) given the current knowledge base by evaluating the body of the rule. Users can then plug arbitrary application logic reacting to (de)activation of these rules.

Implementation of CRIME is available on the project home page 20 and consists of an archive shipping pre-compiled Java classes with no attached source code. The software is apparently no longer maintained : the web page has been updated last in 2010, and the archive dates back to 2006. Nevertheless, the archive provides a number of example applications which have been tested and are still correctly working. No support is provided to application deployment and no documentation has been found describing how to deploy CRIME to an actual production environment.

Klava-With notation Klava-we refer to the family of models and technologies stemming from Klaim [START_REF] Bettini | An infrastructure language for open nets[END_REF] -such as O'Klaim [START_REF] Bettini | O'Klaim: A coordination language with mobile mixins[END_REF] and MoMi [START_REF] Bettini | Coordinating mobile object-oriented code[END_REF] -which nowadays evolved into the X-Klaim/Klava framework [START_REF] Bettini | X-Klaim and Klava: Programming mobile code[END_REF].

X-Klaim consists of a domain-specific language and its compiler, which produces Java code by accepting X-Klaim sources as input. The produced code exploits the Klava library in turn, that is, the Java library implementing the middleware corresponding to the Klaim model.

The overall framework explicitly targets code mobility, thus allowing both processes and data to migrate across a network. To do so, X-Klaim and Klava provide a first-class abstraction known as locality. Localities are of two sorts: either physical, such as network nodes identifiers, or logical, such as symbolic references to network nodes having a local semantics. Each locality hosts its own tuple space, and the processes therein interacting. The Linda primitives supported by Klava are always explicitly or implicitly related to the tuple space hosted on a specific locality. Furthermore, processes are provided with primitives enabling them to migrate from a locality to another in a strong manner, that is, along with their execution state.

Both X-Klaim and Klava are distributed by means of the Klaim Project home page 21 , providing well detailed documentation. For what concerns X-Klaim, its C++ source code -dating back to 2004, date of the last edit, visible right below the title -is publicly available along with a self-configuring script meant to ease compilation. Nevertheless, we were not able to reproduce the compilation process on modern Linux distributions, seemingly due to some missing (and undocumented) dependency. No clues about how to fix the self-configuration process when it fails is provided, neither we were able to find some sort of documentation explicitly enumerating the compilation dependencies.

Conversely, the Klava library -actually implementing the coordination middleware -is distributed as a single .jar file containing both Java sources and the binaries. The .jar file dates back to 2004 likewise for X-Klaim, so it is apparently no longer developed, but further testing showed how the Klava library is still functioning, since it is self-contained and targets Java versions 1.4+.

Limone. Limone [START_REF] Fok | A lightweight coordination middleware for mobile computing[END_REF] is a model and middleware meant to improve scalability and security in Lime [START_REF] Murphy | LIME: A coordination model and middleware supporting mobility of hosts and agents[END_REF] through access control, and explicitly targeting distributed mobile systems and, in particular, agents roaming across ad-hoc networks built on top of opportunistically interconnected mobile devices.

Once two or more devices enter within their respective communication range and thus establish a connection, the agents running on top of them are (potentially) enabled to interact by means of transient sharing of their own tuple spaces. But, for some agents to be actually able to communicate, Limone states they should specify their engagement policies. An agent A's engagement policy determines which agents are allowed to interact with it and to which extent, that is, which primitives are allowed to be invoked. Agents satisfying the policy are registered within A's acquaintance list. So, each agent only has to care about its acquaintance list, thus reducing the bandwidth requirements for the middleware.

A reactive programming mechanism completes the picture, enabling agents to inform their peer about their interest in tuples matching a given template, in order to be informed when such tuples becomes available.

The Limone technology is distributed by means of the project web page 22 in the form of a compressed archive containing the Java source code (dated back in 2004) and a Makefile for automatic build. Nevertheless, the code strictly requires to be compiled against a Java version prior to 1.5, and modern Java compilers do not support such an ancient version 23 . For these reasons, we could not proceed to further test the technology and we consider it to be no longer maintained nor actually usable.

RepliKlaim. RepliKlaim [START_REF] Andrić | Replica-based high-performance tuple space computing[END_REF] is a variant of Klaim [START_REF] Bettini | An infrastructure language for open nets[END_REF] introducing first-class abstractions and mechanisms to deal with data locality and consistency, so as to give programmers the ability to explicitly account for and tackle these aspects when developing parallel computing applications. Specifically, the idea is to let the programmer specify and coordinate replication of data, and operate on replicas with a configurable level of consistency. This enables the programmer to adapt data distribution and locality to the needs of the application at hand, especially with the goal of improving performance in terms of concurrency level and data access speed-in spite of latencies due to distribution.

Most of the abstractions and mechanisms, as well as syntax elements and semantics, of RepliKlaim are exactly as in Klaim, such as data repositories, processes, locations, and many actions. When due, actions are extended to explicitly deal with replication aspects, such as in the case of an out primitive putting multiple copies of the same tuple in multiple localities, or an in primitive removing all replicas from all locations at once. Also, various degrees of consistency among replicas in the same or different locations are achieved depending on whether primitives are synchronous (namely, atomically executed) or asynchronous.

There exists a prototype implementation of RepliKlaim on top of Klava, the Java implementation of Klaim, available for direct download from a URL 24 given in its companion paper [START_REF] Andrić | Replica-based high-performance tuple space computing[END_REF]. From there, a .rar archive is provided, containing a version of Klava and the source files implementing RepliKlaim, which can be easily compiled and run successfully.

Nevertheless, as stated in the paper describing RepliKlaim, its implementation currently relies on encoding its model in the standard Klaim model, thus, on the practical side the code provided only features examples about how to translate RepliKlaim primitives into Klava. No higher-level API directly providing to developers the replica-oriented operations of RepliKlaim is provided. In other words, there exists no RepliKlaim Java library which can be imported to other java projects in order to exploit its provided coordination services.

Discussion

In this section we aim at providing further insights about the technologies described in Subsection 2.3, especially to understand (i) whether they stem from a common archetypal coordination framework (Fig. 5), (ii) their relationships in terms of the features they provide (Fig. 6), and (iii) which goal mostly motivated their development and which application scenario they mostly target (Fig. 7).

A family tree. Fig. 5 depicts a sort of "family tree" of the selected coordination technologies, emphasising how they stem from a few archetypal coordination models/languages, and how they are built on each other. It makes thus apparent how most of the technologies still available stem from two archetypal models: Linda [START_REF] Gelernter | Generative communication in Linda[END_REF] and IWIM [START_REF] Arbab | The IWIM model for coordination of concurrent activities[END_REF]. Nevertheless, whereas in the case of Linda many heterogeneous extensions have been proposed throughout the years, focussing on different features and thus diverging from Linda in many diverse ways, the evolution of the IWIM model appears much more homogeneous, featuring descendants which "linearly" extend their ancestors' features. Summing up, from Linda stem the TuCSoN family, the Klaim [START_REF] Bettini | An infrastructure language for open nets[END_REF] family -including Klava and RepliKlaim -, the Lime [START_REF] Picco | LIME: Linda meets mobility[END_REF] family -with Limone and CRIME -, besides the lone runners LINC and TripCom, whereas from the IWIM root stems the Reo family-completed by Manifold, Clam, and the latest extension IIC.

Apart from these two big family trees, we have the LGI model, along with its implementation, Moses, and a small group of "lone runners" with unique features: Piccola, CiAN, and JErlang. While the former inspired some features of technologies stemming from other models -for instance, its programmable laws inspired essentially any other technology or model having reactive rules of some sort, such as LINC -, the latter remained mostly confined to itself.

It is interesting to notice how "the IWIM family" and "the Linda family" remained well-isolated one from each other over all these years. Whereas this can be easily attributed to the fundamental difference in the approach to coordination they have -data-driven vs. control-driven, as also emphasised in Fig. 6 on page 23 -it seems odd that nobody tried to somewhat integrate these two extremely successful coordination models, in an attempt to improve the state of art by cherry-picking a few features from both to create a novel, hybrid coordination model [START_REF] Omicini | Hybrid coordination models for handling information exchange among Internet agents[END_REF], with "the best of two worlds". To some extent, the TuCSoN model, along with its coordination language, ReSpecT, pursues this path: Re-SpecT in fact can be regarded as a data-driven model because coordination is based on availability of tuples, as in Linda, but, at the same time, coordination policies are enforced by declarative specifications which control the way in which the coordination medium behaves, thus, ultimately, how the coordinated components interact-as typical for control-driven models like IWIM.

We believe that the path toward integration could be the key in further perfecting and improving coordination models and languages, by complementing data-driven models elegance and flexibility with control-driven models finegrained control and predictability.

Families marriage. Fig. 6 enriches the family tree just described with relationships indicating differences (red and green arrows) and similarities (blue arrows) in features provided-notice that w.r.t. Fig. 5 Piccola, CiAN, and JErlang have been removed because they are so unique that no clear relationship may be found with other technologies. As already mentioned for Fig. 5, Linda has been taken as the common ground for many technologies which are instead very heterogeneous in the aim pursued: if ACLT , TuCSoN, and LINC have a Linda core enriched with many other features -such as programmability, transactionality, and novel primitives -, the Klaim family and the Lime one diverge more, by changing the way in which primitives behave -as in the case of localities in Klaim -, or the way in which the interacting processes see each others' tuple spaces-as for Lime transient federation.

Nevertheless, technologies which may appear as being far apart from each other have interesting similarities, as in the case of the interaction rules of LGI, thus Moses, which strongly resembles ACLT and TuCSoN reactions, or the fact that both the Reo family and Moses are based on message passing. Or, the fact that both CRIME and TuCSoN rely on logic tuples so as to leverage on the inference capabilities of interacting agents, while Reo and both Lime and Klaim take into account mobility of processes and coordination abstractions (tuple spaces vs. channels) as a first-class citizen. It is worth emphasising here that Fig. 6 highlights the features to which more attention has been devoted throughout the years: programmability, access control, and mobility. We believe that these features, possibly extended with scalability and inference capabilities, are crucial for widening applicability of coordination technologies to real-world scenarios. For instance, the Internet of Things (IoT) [START_REF] Atzori | The Internet of Things: A survey[END_REF] -along with its variants Web of Things [START_REF] Heuer | Toward the Web of Things: Applying Web technologies to the physical world[END_REF] and Internet of Intelligent Things [START_REF] Arsénio | Internet of Intelligent Things: Bringing artificial intelligence into things and communication networks[END_REF] -is a very good fit for testing coordination technologies, and requires precisely the aforementioned features.

Goals & preferred scenarios. Finally, Fig. 7 relates the selected technologies with the main aim pursued which motivates their extension in a particular direction, along with the applications scenario they best target.

From the description of the selected technologies we gathered, two are the main goals motivating their evolution: (i) providing flexibility so as to deal with the majority of heterogeneous application scenarios possible, and (ii) focussing on first-class abstractions for better supporting space-awareness of both the coordination abstractions and the interacting processes.

In fact, TuCSoN / ACLT , LINC, and Moses all provide means to somewhat program the coordinative behaviour of the coordination medium, thus aim at making it configurable, adaptable, malleable, even at run-time, and/or provide additional coordination primitives to expand the expressive reach of the coordination technology. The Klaim family, the Reo family, and the Lime family instead, are geared toward some forms of space-awareness, be it by promoting mobility or by providing location-sensitive primitives. Besides these, two more main goals can be devised, peculiar to specific technologies: (iii) supporting humans-in-the-loop, in the case of CiAN, and (iv) provide a semantic representation of data items, in the case of TripCom.

About the application scenarios explicitly declared as of particular interest for the technology, the most prominent one is service composition, which is especially interesting for Piccola, JErlang, the Reo family, the Klaim family, and TripCom-besides being naturally applicable to all other technologies too. Then, whereas technologies such as LINC and the Lime family are mainly tailored to the IoT landscape, being meant to cope with the requirements posed by small, possibly portable, possibly embedded devices with low resources, Workflow Management (WfMS) is peculiar to CiAN, while also considered by TuCSoN [START_REF] Ricci | Virtual enterprises and workflow management as agent coordination issues[END_REF]. Besides these application scenarios, there are many technologies without a specific focus, although they have been applied to many different ones, such as TuCSoN itself, LINC, Moses, and TripCom: these have been associated with the generic "General purpose" scenario.

We believe that the goals and application scenarios just highlighted strengthen our previous consideration that the IoT could be the "killer-app" for coordination technologies. In fact, flexibility (there including programmability and configurability), space-awareness (there including mobility and location-awareness), and semantics (there including interoperability of data representation formats) are all necessary ingredients for any non-trivial IoT deployment: the former helps in dealing with uncertainty and unpredictability typical of the IoT scenarios, the latter is required for building open IoT systems, and some form of spaceawareness is a common feature of many IoT deployments, from retail to industry 4.0. Also, the fact that service composition has been already thoroughly explored is a great advantage and the perfect starting point for tackling IoT challenges: both the IoT and the Web of Things vision foster a world where connected objects provide and consume services, which can be composed in increasingly high-level ones.

Conclusion

The main aim of this paper is to provide insights about the state-of-the-art of coordination technologies after twenty years of the COORDINATION conference series, and to stimulate informed discussion about future perspectives. Overall, apart from some notable success stories -i.e. the commercial success of LINC along with the active development of TuCSoN and Reo -most coordination technologies have gone through a rapid and effective development at the time they were presented, then lacked further improvements or even maintenance of its usability, thus never reached a wider audience-i.e. outside the COORDINATION community or in the industry. Obviously, something also happens outside the COORDINATION boundaries. For instance, coordination technologies are surveyed in [START_REF] Papadopoulos | Models and technologies for the coordination of Internet agents: A survey[END_REF], whereas [START_REF] Rossi | Tuple-based technologies for coordination[END_REF] focuses on tuple-based technologies. However, mostly of the technological developments reported here just happened after those survey were published, in 2001 [START_REF]Coordination of Internet Agents: Models, Technologies, and Applications[END_REF].

Although we acknowledge that researchers are usually mostly concerned with providing scientifically-relevant models rather than production-ready software, we also believe that backing up models and languages with more then proof-ofconcept software is crucial to promote wider adoption of both the technology itself and the models, which in turn may provide invaluable feedback to researchers for further developing and tuning models. The next decade will probably tell us more about the actual role of coordination technologies in the development of forthcoming application scenarios: the IoT, for instance, is at the "peak of inflated expectations" according to Gartner's hype cycle for 2017, and is expected to reach the plateau in 2 to 5 years. This means the time is ripe for pushing forward the development of coordination technologies, so as to have them ready when the IoT will be mature enough to actually benefit from their added value.

Besides coordination technologies, we believe the COORDINATION conference is quite healthy: although the number of published papers is decreasing, citations and downloads grows (modulo too recent years), and contributions conveying technological advancements still represent almost a half of all the contributions.

Fig. 1 .

 1 Fig. 1. Number of papers in the volume and number of citations per year (computed as described in text) of the volume.

Fig. 2 .

 2 Fig. 2. Number of downloads per year (computed as described in text) of the volume.

Fig. 3 .

 3 Fig. 3. Most cited paper per year with average values & standard deviation.

  3 (few citations during 1996-2002, more citations during 2003-2009, few3 Excluding the most recent editions, which had less time to generate citations.

Fig. 4 .

 4 Fig. 4. Most downloaded paper per year with average values & standard deviation.

Fig. 5 .

 5 Fig. 5. Lines of evolution of selected technologies (below the dashed line), as stemming from a few archetypal coordination model (above the dashed line).

Fig. 6 .

 6 Fig. 6. Main differences (in green and red) and similarities (in blue) amongst selected technologies. Arrows indicate what it takes (in green, add something; in red, remove something) to go from one technology (the source) to another (the destination).

Table 1 .

 1 2 -and are reported in Table1on page 4 (last checked February 9th, 2018). Highest values for each column are emphasised in bold. Overall data directly available online from Springer regarding the COORDINATION conference series. To compute citations (downloads) per year, the number of citations (downloads) was divided by the number of years the publications is available since. MCP stands for "Most Cited Paper" whereas MDP stands for "Most Downloaded Paper".

	Edition	No. of papers	Citations/Year	Downloads/Year	MCP	MDP
	1996		3.32	140.00	16	124
	1997		2.86	140.48	14	149
	1999		2.05	205.26	6	154
	2000		0.11	-	6	158
	2002		2.81	301.88	7	180
	2004		4.07	197.86	19	146
	2005		3.00	261.54	9	214
	2006		6.25	312.50	22	297
	2007		8.27	341.82	14	308
	2008		10.70	391.00	13	227
	2009		7.44	370.00	13	259
	2010		3.25	507.50	6	536
	2011		4.00	538.57	6	675
	2012		5.50	1081.67	6	523
	2013		8.20	1314.00	7	547
	2014		10.50	792.50	10	299
	2015		6.67	1453.33	11	336
	2016		14.00	2355.00	4	350
	2017		2.00	1930.00	1	245
	Avg.	20.53	5.53	701.94	10*	301.42*
	Std. Dev.	7.57	3.60	658.47	5.42*	160.16*

  .

	Name	Year	Model	(Closest) Web page & Notes
	CoLaS [29]	1999	novel (protocols + roles)	no implementation found
	OpenSpaces [38]	2000	OO Linda	no implementation found
	Piccola [2]	2000	novel	http://scg.unibe.ch/research/piccola
	Moses [4]	2000	LGI [4]	http://www.moses.rutgers.edu
	Scope [63]	2000	Linda + mobility + space federation	no implementation found
	P ω [6]	2002	IWIM [5]	http://reo.project.cwi.nl/reo evolved into Reo
	SpaceTub [94]	2002	Linda	no implementation found
	O'Klaim [15]	2004	OO Linda + mobility	http://music.dsi.unifi.it/xklaim evolved into X-Klaim
	Name Manifold [5] Limone [40] CRIME [65]	Year 1996 2004 2007	Model Linda + mobility + spaces federation IWIM [5] Lime [34]	(Closest) Web page & Notes http://mobilab.cse.wustl.edu/projects/limone http://projects.cwi.nl/manifold no link to implementation http://soft.vub.ac.be/amop/crime/introduction
	Sonia [12]	1996	Linda + access control	no implementation found
	Laura [92]	1996	service-oriented Linda	no implementation found
	MultiBinProlog [31]	1996	µ 2 Log [31]	http://cseweb.ucsd.edu/ ∼ goguen/courses/230/pl/art.html dead links
	MESSENGERS [42]	1996	Navigational Programming [42]	http://www.ics.uci.edu/ ∼ bic/messengers dead links
	ACLT [35]	1996	Linda + programmable tuple spaces	evolved into TuCSoN
	Blossom [46] Session Java [68]	1997 2011	Linda + coordination patterns Session Types [50]	no implementation found http://www.doc.ic.ac.uk/ ∼ rhu/sessionj.html
	Bonita [84] WikiRecPlay /InFeed [80]	1997 2012	asynch Linda BPM	no implementation found no implementation found
	Berlinda [93] Statelets [57]	1997 2012	Linda novel	no implementation found http://sourceforge.net/projects/statelets
	SecOS [22] IIC [77]	1999 2012	Linda Reo [6]	no implementation found http://github.com/joseproenca/ip-constraints
	Messengers [95] LINC [58]	1999 2015	CmPS + mobility [52] Linda [44]	http://osl.cs.illinois.edu/software/ no mention of "Messengers" implementation not available for commercial reasons see http:// bag-era.fr/ index en.html#about
	MJada [82] RepliKlaim [3]	1999 2015	OO Linda Klaim [19]	no reference to MJada http://www.cs.unibo.it/cianca/wwwpages/macondo/ http://sysma.imtlucca.it/wp-content/uploads/2015/03
	Logic Fragments [30]	2014	Sapere [97]	no implementation found
	STL++ [87]	1999	ECM [87]	no implementation found
	Clam [86]	1999	IWIM [5]	no implementation found
	TuCSoN [28]	1999	novel (many extensions to Linda)	http://tucson.unibo.it/
	Truce [53]	1999	novel (protocols + roles)	no implementation found

Table 2

 2

	: Overview of the coordination technologies presented
	at COORDINATION. "Name" denotes the technology, whereas
	"Model" makes explicit the model taken as reference for the im-
	plementation. The last column points to the web page where the
	software is available -if any -and provides for additional notes.

  are provided to help developers debug the rules, and to generate rules from high level specifications. The LINC software is nevertheless not publicly available because it is exploited by the Bag-Era company. Accordingly, it is not further analysed in Subsection 2.3, but it is included in Section 3 as an example of industrial success.

Logic Fragments

[START_REF] De Angelis | Logic Fragments: A coordination model based on logic inference[END_REF]

-a chemical-based and programmable coordination model likewise Sapere

[START_REF] Zambonelli | Developing pervasive multi-agent systems with nature-inspired coordination[END_REF]

-to which it is inspired -enriched with a logicbased one through the notion of Logic Fragments, which are combinations of logic programs defining on-the-fly, ad-hoc chemical reactions -similar to Sapere eco-laws -that apply on matching tuples to manipulate other tuples or to produce new Logic Fragments. The aim is to guarantee data consistency, favour knowledge representation of partial information, and support constraints satisfaction, thanks to verification of global properties enabled by the logic nature of the framework.

Table 3

 3 overviews the working technologies we were able to somewhat successfully test, that is, only those technologies listed in Table2which successfully surpassed test §4 described in Section 1.2-a software artefact exists and is still working.It is worth noting that, w.r.t. Table2, a few technologies are not included in this section despite the corresponding software is available from the reference web page therein referenced. The reason is:

  Selected technologies per main goal pursued (top, blue arrows) and preferred application scenario (bottom, red arrows).

	Flexibility	Humans-in-the-loop	Space-awareness	Semantics
	ACLT LINC Moses	Manifold	Klava	Lime	TripCom
	Piccola	CiAN	JErlang
			Clam	RepliKlaim
	TuCSoN		Reo	Limone	CRIME
			IIC
	General purpose	WfMS	IoT	Service composition
	Fig. 7.

http://link.springer.com/conference/coordination

http://www.bookmetrix.com/

TripCom[START_REF] Simperl | A coordination model for triplespace computing[END_REF] 2007 Triple Space Computing[START_REF] Fensel | Triple-space computing: Semantic web services based on persistent publication of information[END_REF] http://sourceforge.net/projects/tripcom CiAN [88] 2008 novel http://mobilab.cse.wustl.edu/Projects/CiAN/Home/Home.shtml Smrl [1] 2008 Pepa [45] http://groups.inf.ed.ac.uk/srmc/download.html CaSPiS [18] 2008 IMC [17] http://sourceforge.net/projects/imc-fi LeanProlog [91] 2008 novel http://www.cse.unt.edu/ ∼ tarau/research/LeanProlog JErlang [75] 2010 Join-Calculus [41] http://github.com/jerlang/jerlang

Year of latest commit: https://code.google.com/archive/p/sessionj.

http://jerlang.org/

https://sourceforge.net/projects/imc-fi/

A class uses a deprecated API, and another one requires breaking access restrictions.

See https://goo.gl/pdWCsx.

http://tucson.unibo.it

https://sourceforge.net/projects/tripcom

http://mobilab.cse.wustl.edu/Projects/CiAN/Software/Software.shtml

http://scg.unibe.ch/research/piccola

http://soft.vub.ac.be/amop/crime/introduction

http://music.dsi.unifi.it/klaim.html

http://mobilab.cse.wustl.edu/projects/limone

As stated here: https://docs.oracle.com/javase/9/tools/javac.htm#JSWOR627

http://sysma.imtlucca.it/wp-content/uploads/2015/03/RepliKlaim-test-examples. rar