SmartSociety Hybrid and Diversity-Aware Collective Adaptive Systems When People Meet Machines to Build a Smarter Society
Grant Agreement No. 600584
Deliverable 7.3 Working Package 7
Integrated Programming Framework Dissemination Level 1 (Confidentiality): Delivery Date in Annex I: Actual Delivery Date Status2 Total Number of pages: Keywords:
1
PU 31/12/2016 January 10, 2017 F 34 programming, programming model, hybridity, orchestration
PU: Public; RE: Restricted to Group; PP: Restricted to Programme; CO: Consortium Confidential as specified in the Grant Agreeement 2 F: Final; D: Draft; RD: Revised Draft
c SmartSociety Consortium 2013-2017
2 of 34
Deliverable 7.3
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable 7.3
Disclaimer This document contains material, which is the copyright of SmartSociety Consortium parties, and no copying or distributing, in any form or by any means, is allowed without the prior written agreement of the owner of the property rights. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the SmartSociety Consortium as a whole, nor a certain party of the SmartSocietys Consortium warrant that the information contained in this document is suitable for use, nor that the use of the information is free from risk, and accepts no liability for loss or damage suffered by any person using this information. This document reflects only the authors’ view. The European Community is not liable for any use that may be made of the information contained herein.
Full project title:
Project Acronym: Grant Agreement Number: Number and title of workpackage: Document title: Work-package leader: Deliverable owner: Quality Assessor: c SmartSociety Consortium 2013-2017
SmartSociety: Hybrid and Diversity-Aware Collective Adaptive Systems: When People Meet Machines to Build a Smarter Society SmartSociety 600854 7 Programming Models and Frameworks Integrated Programming Framework Hong-Linh Truong, TUW Hong-Linh Truong Michael Rovatsos, UEDIN 3 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
List of Contributors Partner Acronym TUW UEDIN UH
4 of 34
Contributor Ognjen Scekic, Svetoslav Videnov, Hong-Linh Truong Zhenyu Wen, Michael Rovatsos Tommaso Schiavinotto, Iacopo Carreras, Daniele Miorandi
http://www.smart-society-project.eu
Deliverable 7.3
c SmartSociety Consortium 2013-2017
Executive Summary This document is the final deliverable (D7.3) of the Work Package 7 (WP7). In the first part, we briefly summarize the various scientific contributions of the work package in the three years (Y2-Y4) of its activity within the project. The contributions are all centered around the topics relevant for progrgamming HDA-CAS, namely (i) virtualization of hybrid peers and uniform communication with and among them, (ii) ad-hoc provisioning of collectives, (iii) designing metrics for monitoring human participation in hybrid collectives, and, most importantly, (iv) the direct and indirect controllability methods for hybrid collectives – automated incentive management and a general framework for programming collective collaborations. In the second part of this deliverable, we present the final contribution of the Work Package – the programming framework ; most specifically, reporting on the outcomes of the Y4 (T7.3, High-Level Programming languages and T7.4, Integrated Programming Framework ) in terms of implemented functionality and integration effort. We describe the principal functionalities and characteristics of the implemented programming model, framework’s usage context, runtime environment, integrations and deployment. The final part of this document presents the qualitative evaluation of the framework. The functionalities and properties of the programming model that the framework implements are evaluated against a set of fundamental HDA-CAS design requirements in a set of implemented scenarios in order to validate the proposed design and showcase the implementation and integration effort.
c SmartSociety Consortium 2013-2017
5 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
Table of Contents 1 Introduction
7
1.1
Research Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2
Implementational Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2 Programming Framework
10
2.1
State-of-the-Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2
Usage Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3
Runtime Environment & Execution Model . . . . . . . . . . . . . . . . . . . 14
2.4
Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4.1
Task Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2
Collective Management . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3
Peer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.4
Communication Management . . . . . . . . . . . . . . . . . . . . . . 19
2.4.5
Incentive management . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5
Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6
Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Evaluation 3.1
25
Qualitative Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.1
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.3
Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.4
Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Conclusions and Future Work
6 of 34
30
http://www.smart-society-project.eu
Deliverable 7.3
1
c SmartSociety Consortium 2013-2017
Introduction
In the three years during which it was active, the WP7 has always maintained a strong dual focus – a research one, putting the emphasis on the design of novel forms of human-machine virtualization and controllability; and an implementational one, embodying some of the research outcomes in concrete languages, programming models and middlewares to be used in the SmartSociety software toolkit. As the final deliverable of WP7, this Deliverable 7.3 (D7.3) will first briefly revisit the different contributions of the work package throughout the years Y2-4, and then focus on describing the concrete implemented artifacts and integrational effort which took up most of the Y4 effort.
1.1
Research Outcomes
The WP7 research effort was structured around the two main objectives: • Virtualization and communication in diverse, hybrid (human-machine) collectives • Programming models for effectively managing such collectives (at scale, in dynamic environments). To this end, consider the advantages of service-oriented computing models, we have designed a model of Service Unit (SU) [1] which served as the theoretical basis for virtualizing individual humans and machines (e.g., web services, sensors) as uniform elements for the purposes of communication and programmatic management. Building upon the Service Unit, we investigated the collective virtualization and management of teams of individual service units. The collective virtualization model was named the Social Compute Unit (SCU) 3 [2]. It allowed automated elastic provisioning and adaptation of collective’s members based on the global optimization over specified elasticity metrics. Both the provisioning algorithms, as well as the various metrics needed to reflect the specificity of hybrid human-machine teams, and take into account the volatility of human participation and social relationships, requiring us to develop new or alter existing algorithms [3] and metrics [4] to deal with the new reality. The introduced concept of elasticity allowed us to handle the various aspects of diversity of individual peers (e.g., in skills, trust, effort 3
Subsequently, in order to harmonize the terminology across the project partners, we adopted the terms peer and collective, instead of the respective corresponding WP7-specific terms Service Unit and Social Compute Unit.
c SmartSociety Consortium 2013-2017
7 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
and social relationships [5]) on the collective level, thus effectively virtualizing the union of individuals into a programmatically-tractable collective element. The introduced concepts served as the theoretical foundation for designing a stack of progressively more abstract models of peers and collectives that additionally had to take into account the specific design and integrational requirements of the Smart Society project, such as privacy, orchestration models, incentive management. The stack of models (referred to jointly as programming model [6, 7]) was designed to be actionable, with the high end presenting a simple privacy-preserving model and API to the developer, while dealing with the highly specific communication, orchestration and privacy issues at the low end. The programming model is a modular design and task-agnostic, making it a general scientific contribution which can be implemented in different variations (one of which is presented in the remainder of this document), and extended to support novel collaborative models, controllability and orchestration algorithms, monitoring and social governance mechanisms. The programmatic management of humans in social computing and sharing-economy platforms is often criticized as exploitative and inhumane, as reducing the human peers to mere processing units executing instructions, reducing their creativity and severely undermining self-organization, creativity and team-work. To contrast this perception, our programming model aims to shield both parties (peers and users of their services) from exploitation and to offer a truly collaborative, non-imposing participation environment, leaving space for future research efforts and improvements in this area. Along this line of ‘humanization’ of digital platforms, a significant part of our effort effort was also dedicated to researching indirect controllability models and mechanisms targeting humans within hybrid collectives. Such mechanisms (rewards, incentives, promotions, volunteering) motivate the humans and influence (rather than explicitly control) the participation and effort of human peers in a collective in a more subtle and natural way in comparison to instructions. For this purpose, we developed a comprehensive methodology for modeling and enacting various real-world incentive and motivational mechanisms [8, 9] that can be used in parallel along our programming model, or be tightly integrated with it. Our approach complements the work done in WP5, which focused on modeling, designing and evaluating the efficiency of different kinds of incentive mechanisms and strategies, while we focused on designing the operational/supporting software tools to enact and apply the incentive mechanisms on peers in different HDA-CAS or social computing platforms. 8 of 34
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable 7.3
Contribution Individual virtualization of hybrid elements Collective hybrid virtualization Programming models for HDA-CAS Indirect Controllability Models for HDA-CAS Future Applications and Developments
Publications [1], [4] [2], [10], [3], [5] [6], [7], [11], [12], [13] [8], [9] [14], [15]
Table 1: Overview of WP7 contributions and publications Table 1 presents the overview of the principal contributions and associated publications.
1.2
Implementational Outcomes
The theoretical contributions presented in the previous section have been implemented and validated through a number of simulations and prototypes, such as RAHYMS4 (the platform for elastic provisioning and simulation of Social Compute Units), or PRINGL5 (an executable framework and DSL for incentive management). However, the two principal technical contributions of the work package that have been integrated into the SmartSociety Toolkit are the Communication and Virtualization Middleware SmartCom (introduced in D7.1) and the SmartSociety Programming Model (introduced in D7.2). The SmartCom middleware implements the theoretical concepts of the service unit to virtualize individual peers and presents a number of technical solutions for message routing, delivery and transformation, taking into account the heterogeneity and possible scale of the collectives and the diversity of peers in terms of specified privacy and delivery preferences. The Programming Model was implemented as a set of Java libraries providing a number of actionable models, exposed to the developer through a programming API acting upon two first-class entities – Collective and Collective-Based Task (CBT). Transparently to the developer, the programming model provisions the collectives, orchestrates them, incentivizes them, and ultimately executes the task collectively. Each of these complex functionalities are provided by external components, usually by the different components of the SmartSociety software toolkit, making the programming model a gateway for the developer to indirectly access the functionality of the partner components. These two technical contributions were designed and partially implemented as separate components within the tasks T7.1 and T7.2, but the full implementation and integration 4 5
https://github.com/tuwiendsg/RAHYMS https://github.com/tuwiendsg/PRINGL
c SmartSociety Consortium 2013-2017
9 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
was performed, as planned, within the tasks T7.3 and T7.4. Although still maintaining the ability to be used separately, in order to produce a functional system, the two components have been tightly integrated into a programming framework. The said framework is presented in the subsequent sections of this document. In order to prevent repetition, the functionality of individual framework components is not presented in detail6 . Rather, we present the functionality, deployment, integrations and evaluation of the framework as a whole.
2
Programming Framework
2.1
State-of-the-Art
In the Deliverables 7.1 and 7.2 we gave a detailed overview of the state-of-the-art/related work in managing hybrid/human participation in the related areas of computer science. We reviewed the currently most advanced classes of agent-based systems, workflow systems and socio-technical/crowdsourcing platforms, and analyzed the the way they combine human and machine/software elements for performing complex collaborative activities. In this deliverable, we therefore only briefly recap the principal differences between the existing state-of- the-art and our approach (Table 2).
TurKit CrowdDB AutoMan Jabberwocky Turkomatic CrowdLang
Task agnosticity partial no no partial partial no
CrowdSearcher partial CrowdComputerfull SmartSociety full
Workflow/ Execution static static static static dynamic partially dynamic static static dynamic
Hybridity
Collectiveness
Orchestration
no yes no yes no no
no no no no no no
software software software software human software
no yes yes
no no yes
software software software and human
Table 2: Comparative overview of the state-of-the-art and the SmartSociety programming framework Another important conclusion we drew from the comparison with the other approaches served as the main motivator for our work; We were able to observe two general approaches when designing socio-technical systems – modeling machine peers to resemble human peers, and modeling humans to be able to cooperate with software peers. 6
As already provided within deliverables D7.1 and D7.2 and associated technical reports.
10 of 34
http://www.smart-society-project.eu
Deliverable 7.3
c SmartSociety Consortium 2013-2017
The former approach is typical of agent-based systems, where complex software peers are modeled to imitate human peers in an effort to simulate or delegate human behavior/functionality. However, such approaches need to make a large number of assumptions regarding the communication, representations, computational and coordination mechanisms in order to bootstrap the collaborative activity. We end up with elaborate computational agents, which are, however, restricted exclusively to the foreseen, application-specific collaboration scenarios. The latter approach models the humans as machine elements in an attempt to include humans into existing workflow/orchestration platforms (e.g., as services for integrations into BPEL engines). Through this simplification and reduction of human peers to an API, we willingly renounce the extraordinary cognitive and creative capabilities that a human can provide in order to include it in an existing system. Such approaches are able to support complex collaborative activities if the execution plan (execution steps, execution order and conditions, executing roles) is known at design-time. Both approaches seem to lack the versatility required when attempting to manage collective collaborations spanning both human and software elements in the physical world, where the environment, peers and the workflow itself are volatile. Therefore, the grand challenge of WP7 was to design an HDA-CAS programming model that would be appropriate for such environments. We formulate the challenge as a set of design requirements for our programming framework: a) Collectiveness – Individual peer is secondary to the group/team. The collective will be the first-class entity managed by the programming framework. b) Hybridity – The framework will support a mixture of different types of peers (humans, software services, devices) working in concert within the same collective. c) Diversity – The framework will be able to manage heterogeneous peers towards a common collective goal, by composing or aligning their individual diverging characteristics, abilities and goals. d) Adaptivity – The framework will able to dynamically compose and execute runtime (ad-hoc) workflows, as opposed to executing static, predefined workflows. e) Human orchestration – Closely related to the previous point, the human orchestration refers to possibility of human peers determining and actively influencing (adapting) the workflow at runtime. This is especially important for solving cognitive, creative, artistic, ad-hoc problems. f ) Privacy compliance – The framework discloses as little private information about the peers as required to take part in the collective activity. c SmartSociety Consortium 2013-2017
11 of 34
c SmartSociety Consortium 2013-2017
2.2
Deliverable 7.3
Usage Context
In order to understand the subsequently described functionalities and implementation of the programming framework, we present a canonical platform (Figure 1) composed of a subset of components available from the Smart Society Software Toolkit7 . The platform represents one possible possible setup of the Smart Society components that allows showcasing and evaluating the outcomes of WP7. When used in this document, the term platform will refer to this canonical setup. In the remainder of this section, we briefly describe the platform’s (and programming framework’s) intended usage context. The platform is intended for use by the following user roles: users
application containers
JVM program code
Incentive Server (IS)
developers
Knowledge Bases (KBs) peer profiles
privacy policies
Android cloud msg. Facebook connector Twitter connector Dropbox connector Email connector REST APIs
Peer-store PeerManager (PM)
Programming model libraries
Orchestration Manager
SmartSociety Program
different int’fs
SmartSociety Application Comm. Middleware (SMARTCOM)
User App
REST API
SmartSociety Platform
comm. channels
human/machine peers
Figure 1: SmartSociety platform users and architecture. Programming framework elements outlined. 1. Users – external human clients or applications who need a complex collaborative human-machine task performed. 2. Peers – human or machine entities participating in task executions managed by a platform application. 3. Developers – external individuals providing the business logic in form of programming code that is compiled and executed on the platform as a platform application. The platform acts as intermediary between users and peers, providing a collaborative 7
http://www.smartcollectives.com/
12 of 34
http://www.smart-society-project.eu
Deliverable 7.3
c SmartSociety Consortium 2013-2017
task execution environment and workforce management functionality. Note that a same physical person can at the same time be in the role of both user and a peer. The platform is not limited to a particular class of tasks. Supported task complexity ranges: from simple, independent crowdsourcing tasks (e.g., translation); over inter-dependent complex tasks (e.g., collaborative question answering and refinement); over team-based tasks (e.g., predictive maintenance [10]); to the fully human-driven collaborations involving non-trivial execution plans with constraint matching and human negotiations (e.g., ride-sharing). However, implementing the desired collaborative effort specification is entirely left to the developers in the context of a particular SmartSociety platform application. The platform facilitates this process by offering a variety of commonly used coordination, orchestration, communication and incentivization mechanisms as ready-made concepts exposed through the programming API.
Interested human peers register their profiles with the platform and enlist for performing different professional activities. The platform uses this data for locating and engaging peers into different collaborative efforts. In case of human peers, the platform asks for an explicit approval, enabling the peer engagement under a short-term contractual relationship. In case of a software peer, the services are contracted under conventional service-level agreements (SLAs). Registered users are the basis from which appropriate peers are selected into collectives participating in executions of collaborative tasks. A collective is composed of a team of peers along with a collaborative environment assembled for performing a specific task. The collaborative environment consists of a set of software communication and coordination tools. For example, as described in [10], the platform is able to set up a predefined virtual communication infrastructure for the collective members and provide access to a shared data repository (e.g., Dropbox folder). The complete collective lifecycle is managed by the platform in the context of a SmartSociety platform application (Fig. 1). A platform application consists of different modules, one of which is a SmartSociety program – a compiled module containing the externally provided code that: a) implements the desired business logic of the user; b) manages the communication with the corresponding user applications; and c) relies on libraries implementing the programming model to utilize the full functionality of the platform. Through a user application users submit task requests to the platform. The user application communicates with the corresponding platform application. c SmartSociety Consortium 2013-2017
13 of 34
c SmartSociety Consortium 2013-2017
user apps
Deliverable 7.3
peers
programming model libraries
SmartSociety program
:TaskRequest applicationspecific business logic (arbitrary code)
negotiate CollB
... arbitrary code ...
execute - communicate, reward - monitor -
SmartSociety Platform
compose CollA
APIs
Collective-based task
provision
Collective-based task :TaskResult
Figure 2: Using the SmartSociety programming framework.
2.3
Runtime Environment & Execution Model
The developer who wishes his/her application deployed on the SmartSociety platform provides a set of classes (Application, TaskRequestDefinition, TaskRunner, SmartSocietyApplicationContext) in a Java jar file. The provided classes specify: a) actual business logic of the new application; b) the runtime context of the application (e.g., initialization and configuration parameters for handlers (Sec. 2.4.1, loading of predefined collective kind definitions); c) the logic for interpreting and (un)marshalling the requests and responses. Whenever a request is received via the URL endpoint it is interpreted according to the TaskRequestDefinition to produce a new TaskRequest which represents the main input for our programming model. Figure 2 illustrates this process. For each request a thread is started, executing the application’s arbitrary business logic from the TaskRunner class. When this logic requires some collaborative processing the developer uses the programming model library constructs to create and concurrently execute a Collective-based Task (CBT) – an object encapsulating all the necessary logic for managing complex collective-related operations on the SmartSociety platform: team provisioning and assembly, execution plan composition, human participation negotiations, and finally the execution itself. During the lifetime of a CBT, various Collectives related to the CBT are created and exposed to the developer for further (arbitrary) use in the remainder of the code outside of the context 14 of 34
http://www.smart-society-project.eu
Deliverable 7.3
c SmartSociety Consortium 2013-2017
of the originating CBT or its lifespan. Developer can communicate with the collectives, incentivize them, persist them, and combine them to produce new collectives to pass as inputs to other CBTs at a later point.
2.4 2.4.1
Functionality Task Management
A collective-based task (CBT) is the element of the programming model keeping the state and managing the lifecycle of a collective task. A CBT instance is always associated with a TaskRequest containing input data and possibly a TaskResult containing the outcome of the task. Both are very generic interfaces meant to hide from the programming model the application-specific format of the input and output data, respectively. In fact, the programming model is designed to be task-agnostic. This is in line with the general HDA-CAS principle that unconstrained collaboration should be supported and preferred when possible. This design choice was made to allow subsequent support of different task models which will be interpretable by the application-specific Orchestration Manager, or by human peers directly. A CBT can be processed in one of the two collaboration modes – (on demand and open call ); or a combination of the two, as specified by the developer. At CBT’s core is a state machine consisting of states representing the eponymous phases of the task’s lifecycle: provisioning, composition, negotiation and execution. An additional state, continuous orchestration, is used to represent a process combining composition and negotiation under a specific collaboration mode. Each state consumes and produces input/output collectives during its execution. All these collectives get exposed to the developer through appropriate language constructs (Listing 5) and are subsequently usable in general program logic. Each state is associated with a set of handlers with predefined APIs that needs to be executed upon entering the state in a specific order. The handlers registered for a specific application are assumed to know how to interpret and produce correct formats of input and output data, and wrap them into TaskRequest and TaskResult objects. By registering different handler instances for the states the developer can obtain different overall execution of the CBT. For example, one of the handlers associated with the execution state is the ‘QoR’ (quality of result) handler. By switching between different handler instances, we can produce different outcomes of the execution phase. Similarly, by registering a different c SmartSociety Consortium 2013-2017
15 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
handler, an OM instance with different parameters can be used. The programming model libraries provide a set of default handlers exposing the ground platform functionalities, such as orchestration and negotiation algorithms provided by the Orchestration Manager or provisioning algorithms (e.g., [3]). Concrete handlers are registered at initialization for each CBT type used in the application. Adaptation policies are used to enable re-doing of a particular subset of CBT’s general workflow with different functionality and parameters, by changing/re-attaching different/new handlers to the CBT’s states, and enabling transitions from the failure states back to active states. Adaptation policies allow for completely changing the way a state is executed. For example, by registering a new handler for the provisioning state a different provisioning algorithm can be used. Similarly, a new handler installed by the adaptation policy can in a repeated negotiation attempt use the “majority vote” pattern for reaching a decision, instead of the previous “consensus” pattern. 2.4.2
Collective Management
The notion of “collective” sometimes denotes a stable group or category of peers based on the common properties, but not necessarily with any personal/professional relationships (e.g., ‘Java developers’, ‘students’, ‘Vienna residents’); in other cases, the term refers to a team – a group of people gathered around a concrete task. The former type of collectives is more durable, whereas the latter one is short-lived. Therefore, we make following distinction in the programming model: Resident Collective (RC) is an entity defined by a persistent peer-store identifier, existing across multiple application executions, and possibly different applications. Resident collectives can also be created, altered and destroyed fully out of scope of the code managed by the programming model. The control of who can access and read a resident collective is enforced solely by the ‘peer-store’ (in our case the PeerManager component). For those resident collectives accessible from the given application, a developer can read/access individual collective members as well as all accessible attributes defined in the collective’s profile. When accessing or creating a RC, the programming model either passes to the peer store a query and constructs the corresponding object from returned peers, or passes an ID to get an existing peer-store collective. In either case, in the background, the programming model will pass to the peer-store its credentials. The peer store then decides based on the privacy rules which peers to expose (return). For example, for the requested collective with ID ‘ViennaResidents’ we may get all Vienna residents who are willing to 16 of 34
http://www.smart-society-project.eu
Deliverable 7.3
c SmartSociety Consortium 2013-2017
participate in a new (our) application, but not necessarily all Vienna residents from the peer-store’s DB. By default, the newly-created RC remains visible to future runs of the application that created it, but not to other applications. The peer-store can make them visible to other applications as well. At least one RC must exist in the application, namely the collective representing all peers visible to the application. Application-Based Collective (ABC). Differently than a resident collective, an ABC’s life cycle is managed exclusively by the SmartSociety application. Therefore, it is not possible (and is meaningless) to access an ABC outside of the application’s execution context. The ABCs are instantiated: a) implicitly – by the programming model libraries as intermediate products of different states of CBT execution (e.g., ‘provisioned’, ‘agreed’); or b) explicitly – by using dedicated collective manipulation operators to clone a resident collective or as the result of a set operation over existing Collectives. Also differently than resident collectives, ABCs are atomic and immutable entities for the developer, meaning that individual peers cannot be explicitly known or accessed/modified from an ABC instance. The ABCs embody the principle of collectiveness, making the collective an atomic, first-class citizen in our programming model, and encouraging the developer to express problem solutions in terms of collectives and collective-based tasks, rather than single activities and associated individuals. Furthermore, as collective members and execution plans are not known at design time, this enhances the general transparency and fairness of the virtual working environment, eliminating subjective bias. One of the reasons for introducing the concept of collectives with the described properties is to prevent the User/Developer from using individual human peers as mere computing/processing nodes being assigned activities to perform, instead favoring a more ethical (teamwork) approach. Furthermore, the distinction and existence of both RC and ABC Collective models (Fig. 3) allows a trade-off between hand-picking the team members and the flexibility offered between a platform-managed collective provisioned based on user’s requirements. The rationale in the latter case is similar to cloud computing – the user specifies the infrastructural requirements and constraints and the platform takes care to provision this infrastructure, without letting the user care about which particular VM instances are used and changed. Different use-cases, privacy and fairness policies may dictate or favor the choice of one Collective type over the other. For example, when assembling an input collective of experts for a CBT, the User may require to use as source the RC representing the peers with whom the User had positive previous experiences with. Although this seems like a reasonable request, over time the peer community might start c SmartSociety Consortium 2013-2017
17 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
RC
a b
c - members visible -
d e developer
- CBT-geneated -
ABC
a b d
a
ďƒˆ
c
explicit manipulation
=
a b c
d
Peer store ABCs
RCs
application/platform privacy & fairness policies individual peer privacy policies
a
b
c
d
e
z peers
Figure 3: Differences between RCs and ABCs. ABCs are atomic to the Developer, although the Developer is able to manipulate and create new descending ABCs. exhibiting the characteristics of a scale-free network due to the preferential attachment method of choosing the collective members [16]. This, in turn, may lead to discouragement of less prominent peers, and in overall, increase the attrition rate. To prevent this, the fairness policy of the application/platform enforced at the peer store may prevent handpicking of peers, and impose the use of ABCs provisioned transparently to the Developer/User in accordance with the fairness policy (e.g., round-robin or random peer assignment with reputation threshold). This is important for establishing attractive and competitive virtual crowd marketplaces [17]. 2.4.3
Peer Management
In order to fulfill the HDA-CAS design requirement of privacy compliance, the programming framework inherits the privacy features of the PeerManagr component described in [18]. It allows the programming framework to fetch peer profiles from the peer-store through a privacy-enforcing PM API containing only the data (possibly semantically obfuscated) previously approved by the user himself (upon signing up and creating the profile) for use by that particular application. By performing the queries through the PM intermediary, the programming framework is not allowed to access nor can it perform queries over non-approved peer/collective attributes. The most of the privacy-assurance responsibility 18 of 34
http://www.smart-society-project.eu
Deliverable 7.3
c SmartSociety Consortium 2013-2017
is thus delegated to the PM. However, this convenience comes with a price when accessing any collective attributes/metrics that are not originally addressed in PM’s profiles but are crucial for the application’s business logic which might change more often, and cannot rely on peers updating their profiles. We call such attributes user attributes. For example, in a ride-sharing scenario, the developer wants to know and store crucial collective metrics, such as count of the passengers in a ride. For the sake of argument, let us assume that this attribute is not originally provided in the PM’s collective profile. In this case, since the collectives are exposed to the developer as ABCs, this metric cannot be calculated directly by the developer’s application code, which has no access to the collective’s members. In order to circumvent this problem, the developer needs to specify in advance the definitions of user attributes that (s)he will need to access/calculate, and delegate this task to the programming framework which internally has access to individual peers. The attribute definitions are provided within the collective kind. It is a set of collective attribute descriptors supplied at the application registration time and subject to approval by the platform operator. If approved, the collective kinds used by the application are referenced in the SmartSocietyApplicationContext class that is used to initialize the application. Thereafter, the developer can access those attributes directly from the application’s code through the ABC.get/setAttribute() methods. Note that the use of these methods cannot override the original privacy settings – originally obfuscated/hidden data is still not accessible, and setting a user attribute cannot override an original attribute. For the purposes of testing and usage in non-privacy-critical environments, the programming framework additionally implements a local MongoDB-based peer-store implementing the same PM API but without privacy enforcement. The local peer-store can also be used to cache the PM peer profiles for faster access. 2.4.4
Communication Management
The programming framework now fully incorporates SmartCom, allowing it to perform advanced collective communication in the background transparently to the developer. By supporting a single communication endpoint model, but different delivery channels, the framework is able to communicate with heterogeneous peers during the various CBT lifecycle phases (e.g., inviting peers at provisioning, task acceptance during negotiations, termination determination during execution). Each individual peer can use personally stipulated communication protocols and modes to interact with the framework/application, e.g., a human peer can communicate via email and Twitter interchangeably, receive c SmartSociety Consortium 2013-2017
19 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
task descriptions and track progress through a web application, and communicate with other peers within the collective through a dedicated mobile app. Human peers can make use of software peers in the collective, serving as collaborative and utility tools. For example, a software service like Dropbox can be used as a common repository for sharing artifacts. This rich communication model is regulated through the use of privacy and delivery policies. Each peer can individually define a set of privacy policies which regulate: a) times at which the platform may communicate with the peer (e.g., working days 0917h); and b) blacklisted message senders (to avoid becoming a member of collective with unwanted peers). On the other hand, the developer or the programming framework can stipulate different delivery policies for peers and collectives. The policy determines what constitutes a successful delivery: in case of peers – with respect to different delivery channels; in case of collectives – with respect to collective members. The programming framework supports out of the box a number of basic policies, such as best effort (TO ANY) or exhaustive (TO ALL). In practice, the delivery policies allow us to fine-tune the sensitivity and reliability of the communication with collectives. For example, we can consider that a whole collective has been notified if a single member (perhaps the leader) has been notified of an event; we can request delivery reports, or repeat delivery attempts. Taken together, the privacy and delivery policies are a versatile mechanism to combine and match the preferences of both peers and the developer. They are both storable both in the local as well as in the PM peer-store. 2.4.5
Incentive management
The programming model has been designed to allow interoperability with different external incentive management frameworks, as long as they share a common peer base. One possible candidate for integration is the PRINC/PRINGL framework [9], which allows the developer to specify a tailored incentive scheme in a domain-specific language by adapting and parameterizing library incentive elements. The scheme can then executed (applied) upon target collectives. The exact mechanism of incentive application will be the matter of the future integration work, as it exceeds the scope of the WP7. The other candidate for the integration was the Incentive Server (IS) component from the WP5. Being a principal SmartSociety project component, the IS was chosen as the canonical proof-of-concept representative of an incentive management component, offering a simple clean-cut interface for integration. 20 of 34
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable 7.3
The IS is an independent component that monitors and motivates peer participation through controlled intervention [19, 20]. It supports two ‘modes of operation’: a) Sustained incentivization over a longer period of time where the IS algorithms monitor participation and through machine learning determine optimal intervention times and types of incentive messages that are sent to peers; and b) Per-task incentivization, where the IS relies on external components for providing the incentivization logic and application conditions, and limits itself to providing the delivery of motivational messages in a privacy and ethicallycompliant way. The programming model relies on the IS’s per-task incentivization mode by prompting incentivization via IS but determining by itself the target group and, optionally, the intervention times. This allows that the IS be used in arbitrary scenarios/applications, unlike the sustained incentivization mode, when IS functions as a fully independent, but application-specific component that needs to be manually set up. 1 { " t a r get_collective_ID " : 4853 , 2 " timestamps " : [ T1 , T2 , ... Tn ] , # optional 3 " inc_type " : [ " someID " , { incentive - specific params }] }
Listing 1: Setting up an incentive intervention through IS.
Due to the high scenario-specificity of incentives, the programming framework currently does not itself provide any incentive logic and management capabilities. Instead, in order to remain task agnostic, the responsibility for specifying the type of incentives, the target peers, and the intervention timing is left to the developer using the programming API, who can explicitly trigger the incentive campaign over a certain collective when deemed appropriate: cbt.incentivize(incType [, times]) The currently active collective of the CBT upon invocation of incentivization is considered as the target collective (e.g., the initial input collective if the CBT is in the provisioning state). Therefore, the developer has to use the methods to test the CBT state first, instead of declaratively defining the incentivization conditions. If no timings are specified (as a sequence of timestamps), a single immediate intervention is triggered. In the future, a finer grained and automated timing specification will be implemented, allowing to declaratively specify incentive strategies to coincide with the execution of specific CBT handlers, as incentives often need to be focused to a specific phase and collective of the CBT’s life cycle (e.g., at repeated execution of provisioning, or only during the negotiation/execution). Alternatively, the developer can invoke the incentivization directly on a c SmartSociety Consortium 2013-2017
21 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
collective: targetCollective.incentivize(incType [, times]) In order to invoke the IS incentivization intervention (Listing 1) the PM is assumed as intermediary, not only to uniquely identify the collective’s members via the collective ID, but also to prevent unsolicited incentivization messages to the peers that have opted out. Internally, the IS also uses a private SmartCom instance to handle communication with the peers. Here are two incentivization examples to illustrate the current incentivization capabilities: 1) CBT is executing and we are at 80% of the allowed execution time, but a certain subset of the agreed peers has not performed their part of the job. Isolate only those as the target collective and try to motivate them to contribute. 2) CBT has finished executing successfully, and the developer wants to foster future relationship with the peers that took part by instructing the IS to issue reminders about how appreciated their contribution was 3x within next 6 months, as he believes that would make it more likely for them to return again.
2.5
Deployment
Figure 4 shows the deployment of the canonical platform running the programming framework and the deployment of a SmartSociety application on it. The Developer provides the implementation of a small number of predefined Java classes packaged in a JAR file, through which he supplies the arbitrary business logic of the applications, as well as the necessary parameters and initialization options. Ideally, there would be a developers’ portal where the developer would register a new SmartSociety Platform Application, upload the JAR, and wait for the approval, upon which the application would be issued an application ID. After the application has been approved and is ready to be run, a set of Docker containers are created. The main one will be the one running the application. The submitted JAR is injected into this container. Remaining containers are created for deploying other platform components (e.g., Orchestration Manager, peer-store), depending on the initialization configuration. The application is then registered in the peer store as a peer with special access privileges to the application’s peer data and the data of other platform components. Finally, the programming framework’s runtime initializes the context, the application-specific URL endpoint, and starts the application. While running, the application is delivered each request that comes via the application-specific URL endpoint. 22 of 34
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable 7.3
Application ... +init(Config c): void +createTaskRunner(TaskRequest)
<< Runnable >> TaskRunner +run():void +getStateDescriptor(): JSON @Override public void run(){
application developers
// ... arbitrary business logic code ... // CBT cbt = ctx.getCBTBuilder("AskAndShare") .from(TaskDefinition) .asContinuousOrchestration() .forInputCollective(c) .build(); cbt.start(); // behaves as Java Future<TaskResult>
Smart Society Platform Runtime (WP8)
// ... arbitrary business logic code ... // result = cbt.get(); }
application users
Programming Model & Libs (WP7)
Programming API (WP7)
Platform Application (developer)
User App
Smart Society Platform API (WP8)
application container
JVM
RESTful APIs platform components OM, TEM, Inc. Server, ProvS
Figure 4: Deployment of the programming framework and SmartSociety applications Subsequent processing of the request from this point on is the responsibility of the applicationâ&#x20AC;&#x2122;s arbitrary business logic. As previously explained, the functionality provided by the programming framework can be used as needed via the Programming API (described in D7.2).
2.6
Integration
Internally to WP7, the programming framework now fully incorporates the SmartCom middleware, using it as the principal subcomponent to offer transparent group communication functionality with hybrid peers both to the internal libraries, as well as to the developer. With respect to the other components, the integration APIs described initially in the c SmartSociety Consortium 2013-2017
23 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
D7.2 have been implemented, allowing the programming framework to integrate and expose the functionality of the Orchestration Manager (WP6), Peer Manager (WP4) and the Incentive Server (WP5) to the developer indirectly, through the programming model exposed by the programming API. The examples presented in Section 3 showcase these integrations. The programming framework was also explicitly designed to support a future direct integration with the Task Execution Framework (WP3), but currently the integration is achieved indirectly, via the Orchestration Manager; exactly as in the case of the Provenance Server (WP2). Figure 5 visualizes these integrations. The Programming Framework
Prog. Language Constructs & API (WP7)
SMARTCOM Middleware (WP7)
Programming Model Libraries (WP7)
Orchestration Manager (WP6)
Peer Manager (WP4)
Task Execution Manager (WP3)
Incentive Service (WP5)
Provenance & Reputation Svc. (WP2)
Figure 5: Partial Smart Society component dependency graph showcasing the integration with the programming framework.
24 of 34
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable 7.3
3
Evaluation
The implementation of the programming framework refers to the two principal elements – the programming API (described in D7.2) and the programming model libraries (including the various subcomponents required to integrate the functionality of other SmartSociety platform components). For evaluating the programming model qualitatively, we analyze the fulfillment of the the HDA-CAS design requirements formulated at the beginning of Section 2 by presenting and discussing an example suite (Sec. 3.1.1 – 3.1.4) covering the said properties. This type of evaluation is common during the development and prototyping phase [21, 22] when the immaturity of the implemented prototype would affect the quantitative metrics measuring improved productivity and user experience. The evaluation of the expressiveness and functionality of the programming API itself was already presented in the D7.2 and will thus be skipped in this deliverable. As the programming framework in its usable, integrated form was completed at the end of Y4, it was not feasible to perform the evaluation of productivity and subjective satisfaction in an established community of regular users. We will closely monitor the community that we expect will form around this open-source project, and update the website with the usage data, especially as we anticipate that the code-base will be useful for future research efforts. However, an approximate quantitative insight into the productivity improvements can be given by considering the lines of code (LOC) metric for the two scenarios that were previously implemented by the project partners without the use of the programming framework (PF) – the RideSharing and the AskSmartSociety!, and comparing them with the functionally equivalent Examples 2 and 3 (Sec. 3.1.2 and 3.1.3) developed for the purpose of evaluating the programming framework. As shown in Table 3, the use of the programming API drastically reduces the amount of newly-written code, which is usually concurrent and error-prone, often boilerplate and repetitive. As a consequence, the principal business logic can be encoded in a concise and easily understandable, human-readable manner, further simplifying debugging and subsequent changes, as well as integration with legacy code. Scenario AskSmartSociety! RideSharing
LOC without PF ∼ 3.5K ∼ 40K
LOC with PF < 0.5K < 1K
improvement > 7× > 40×
Table 3: Overview of conciseness and productivity improvements expressed in Lines of Code (LOC) metric, obtained through the use of the Programming Framework (PF) when implementing the core business logic of the two listed scenarios. c SmartSociety Consortium 2013-2017
25 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
The source code of the programming framework, as well as the presented examples are provided via our repository8 .
3.1
Qualitative Evaluation
Table 4 shows the coverage of HDA-CAS design requirements by the evaluation examples that are presented in the continuation. Hybridity Diversity Adaptivity Collectiveness Privacy-compliance Human orchestration
Ex. 1 X
Ex. 2 X
Ex. 3
Ex. 4
X
X
X X X
X
X X
X X
X
Table 4: Coverage of HDA-CAS design requirements.
3.1.1
Example 1
A user posts a question to the platform about restaurants with specific eating options in the vicinity. The question is processed by the platform application representing our example and returned to the user. The processing collective is hybrid, as it involves software services (Google/Yelp) that are queried for restaurants as well as human peers queried via email or Twitter in accordance with their personal delivery and privacy policies. The orchestration (plan composition) is software-managed â&#x20AC;&#x201C; the workflow is predetermined, and there is no need for negotiation. The workflow prescribes how the queries are dispatched and how the replies are aggregated (e.g., preference for human replies if high reputation or multiple matching answers from more than two peers; otherwise, preference for the software peer reply). The relevant application code for performing such a task is short and straightforward (Listing 2). Note that the code for collective provisioning and execution (aggregation) is already packaged within the CBT handlers, which form part of the programming library, meaning that the developer only needs to provide the parameters to use them. While the collective itself is hybrid, there is no direct collaboration (collectiveness) between the peers. This scenario therefore simulates the conventional crowdsourcing scenarios, where a task is solved through microtask parallelization with a predefined workflow without human orchestration. 8
https://gitlab.com/smartsociety/programming-framework/tree/demo
26 of 34
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable 7.3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
/* Initialize and parameterize provided library handlers : */ pH1 = new ... pf . cbthandlers . provisioning . A s k S m a r t S o c i e t y P r o v H a n d l e r ( N ) eH1 = new ... pf . cbthandlers . execution . A s k S m a r t S o c i e t y E x e c H a n d l e r () cH1 = new ... pf . cbthandlers . composition . A s k S m a r t S o c i e t y E x e c H a n d l e r (5 , T ) TaskRequest taskReq = ... ; Collective nearbyPeers = ABC . cr ea t eF ro m Qu er y ( new C o ll ec ti v eQ ue ry ( requestor . location , ...)); T a s k F l o w D e f i n i t i o n tfd = T a s k F l o w D e f i n i t i o n . o n D e m a n d W i t h O p e n C a l l ( pH1 , cH1 , null , eH1 ) . w i t h I n p u t C o l l e c t i v e ( nearbyPeers ); C o l l e c t i v e B a s e d T a s k cbt = CBTBuilder . from ( tfd ). w i th Ta s kR eq ue s t ( taskReq ). build (); cbt . start (); return cbt . get (10 , TimeUnit . MINUTES );
Listing 2: Hybrid crowdsourced answering with SmartSociety.
3.1.2
Example 2
In this example, we extend the previous example to include adaptivity and human orchestration. The scenario remains the same, except that now we do not want that the aggregation workflow is static and orchestrated by software. Instead, if possible a local human restaurant expert (e.g., a Google maps Local guide) picks out the best suggestion out of the gathered ones. However, this scenario is more likely to fail due to unavailability or response latency of the guide. In such cases, we need a failover strategy. The programming model offers 2 possibilities in this case: a) detect the delay/failure through the use of the CBT API and do an arbitrary corrective action, e.g., create a new CBT with different parameters, perhaps along with an incentivization intervention to increase the likelihood of success, or simply apologize to the user for failing; or b) define an adaptation policy to take an automated corrective action (in our case failover to the scenario from Example 1). Listing 3 shows the relevant code snippets variant b). 1 2 3 4 5 6 7 8 9 10 11 12
/* Initialize library handlers -- pH2 , cH2 , eH1 , eH2 . * eH2 uses human orchestration . Failover handler eH1 ( from Ex . 1). */ TaskRequest taskReq = ... ; Collective nearbyPeers = ...; pH2 = pH2 . onFail ( Ad a p t a t i o n P o l i c y . REPEAT , Ph1 ); T a s k F l o w D e f i n i t i o n tfd = T a s k F l o w D e f i n i t i o n . o n D e m a n d W i t h O p e n C a l l ( pH2 , cH2 , null , eH2 ) . w i t h I n p u t C o l l e c t i v e ( nearbyPeers );
c SmartSociety Consortium 2013-2017
27 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
13 C o l l e c t i v e B a s e d T a s k cbt = 14 CBTBuilder . from ( tfd ). wi th Ta s kR eq ue s t ( taskReq ). build (); 15 16 cbt . start (); 17 18 /* ... */
Listing 3: Human orchestration and adaptation.
3.1.3
Example 3
This example simulates a simplified ride-sharing application. Each interested party submits ride requests to the application, either as a driver offering a ride, or as a passenger seeking to take a ride and share the costs. A ride request contains the following information: [driver/passenger, origin, destination, departure time, arrival time, price/contribution, seats offered/requested]. Upon each submission of a ride request, the platform re-runs the composition algorithm that creates new feasible ride plans in terms of timing/seats/route constraints being met. Viable plans are then put on negotiation between potential peer participants. After each individual ride request, acceptation, non-responding or refusal new plans can be generated or existing ones invalidated/undecided. The platform, therefore, needs to continuously adjust the state. As described in Section 2.4.1, in the course of the SmartSociety project a fully-fledged set of algorithms were developed for handling particular this class of problems [23]. They are made readily available to any developer through the programming API, i.e., through the CBT’s continuous orchestration mode, making the necessary developer-side coding extremely simple (Listing 4). The developer initializes the appropriate CBT type, by specifying a library-provided handler for continuous orchestration. Upon each new ride request, a new instance of this CBT is instantiated. In the background, the parameters of the requested ride are forwarded to the OM, triggering anew the ride matching, plan generations and possible new negotiation. Ultimately, some rides and the corresponding CBTs will succeed (with ‘agreed’ collective representing the passengers), while others will fail. It is up to the developer to decide what will be the arbitrary application logic in both cases (e.g., updating the user reputation, charging for the ride). 1 /* Initialize the library handler for continuous orchestration coH3 2 * coH3 delegates orchestration to the platform component OM */ 3 4 TaskRequest rideRequest = new RideRequest . parseJSON ( input ); 5 6 C o l l e c t i v e B a s e d T a s k cbt = 7 CBTBuilder . from ( T a s k F l o w D e f i n i t i o n . u s i n g C o n t i n u o u s O r c h e s t r a t i o n ( coH , null ))
28 of 34
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable 7.3
8 . wi th T as kR eq u es t ( rideRequest ) 9 . build (); 10 11 cbt . start (); 12 if ( cbt . get () != null ) {...}
Listing 4: Ride-sharing scenario.
Compared to the previous two examples, this one is not characterized by hybridity. Namely, only 2 peer types are present and both are human peers. On the other hand, the peers are characterized by a great diversity in goals (destination, times, acceptable costs). These types of optimization problems are inherently difficult for humans to handle, as they involve too many variables to consider. For this reason, the platform is taking over this complex computational burden and leaving it to the developer to provide the remainder of the application’s business logic suited to his needs. On the other hand, the platform is not actively searching for humans and engaging them, but merely reacting to human requests. In this respect, the execution is truly human-orchestrated at runtime. 3.1.4
Example 4
Example 4 (Listing 5) illustrates another important class of tasks – intellectually-challenging (engineering, creative) collective tasks. A programming (software engineering) task is the prime example of such a problem. The simplified scenario used in this example assumes submitting a natural language description of a Java software artifact that the platform application needs to produce for an external user. The software artifact is produced by a simplified 2-stage methodology – the artifact is first coded by collective members submitting to a joint repository, then tested against externally provided unit tests. Since they involve primarily human experts with diverse skills, such tasks are not characterized by much hybridity but by a high diversity. In order to solve such a task successfully, the team first needs to be carefully assembled to contain compatible expert roles. This means that the provisioning phase needs to offer advanced matching algorithms. In our case, we make use of the in-house developed algorithm [3] for fuzzy skill matching inside the provisioning handler, hiding the collective formation complexity from the developer. The TaskRequest swImplTaskReq needs to contain the requested number of experts and natural-language (fuzzy) descriptions of the required skills (e.g., <"Java EE developer", "very good">). Unlike the previous examples, here we deal with a purely on-demand task – a problem at hand that needs to be solved by peers actively located and engaged by the platform. c SmartSociety Consortium 2013-2017
29 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
This implies that peers cannot self-initiatively apply for participation, nor is there a plan composition phase. Instead, the plan is determined collectively by the provisioned peers through unmanaged (direct) communication based on the understanding of the task as provided in the task request, implying that the overall orchestration is human-driven. In order to support the communication requirement, the programming framework puts at peersâ&#x20AC;&#x2122; disposal the collective communication capabilities described in Section 2.4.4. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
/* Initialize library handlers pH4 , nH4 , eH4dev , eH4test */ // parameterize handlers nH4 = nH4 . withArguments ( N e g o t i a t i o n P a t t e r n . AGREEMENT_THRESHOLD , 0.5); Collective javaDevs = R e s i d e n t C o l l e c t i v e . c re at eF r om Qu e ry ( myQuery ( " JAVA_DEV " ); C o l l e c t i v e B a s e d T a s k progTask = CBTBuilder . from ( T a s k F l o w D e f i n i t i o n . o n D e m a n d W i t h o u t O p e n C a l l ( pH4 , nH4 , eH4dev ) . w i t h I n p u t C o l l e c t i v e ( javaDevs )) . wi th T as kR eq u es t ( swImplTaskReq ). build (); progTask . start (); /*
... assume negotiation on progTask done
... */
Collective testTeam ; // will be ABC if ( progTask . isAfter ( C o l l e c t i v e B a s e d T a s k . State . NEGOTIATION )) { // out of provisioned devs , use other half for testing testTeam = Collective . complement ( progTask . g e t C o l l e c t i v e P r o v i s i o n e d () , progTask . g e t C o l l e c t i v e A g r e e d () ); } while (! progTask . isDone ()) { /* do stuff or block */ } nH4 = nH4 . withArguments ( N e g o t i a t i o n P a t t e r n . AGREEMENT_THRESHOLD , 1.0); C o l l e c t i v e B a s e d T a s k testTask = CBTBuilder . from ( T a s k F l o w D e f i n i t i o n . o n D e m a n d W i t h o u t O p e n C a l l ( null , nH4 , eH4test ) . w i t h I n p u t C o l l e c t i v e ( testTeam )) . wi th T as kR eq u es t ( new TaskRequest ( progTask . get ())) . build (); if ( testTask . get (). QoR () < 0.7) return TaskResponse . FAIL ;
Listing 5: Software engineering scenario.
4
Conclusions and Future Work
This document is the final deliverable of the WP7. In the first part, it briefly presents the scientific contributions of the work package in the three years of its activity within the project. The contributions are all centered around the topics relevant for HDA-CAS and collaborative work, and are focused on virtualization of hybrid peers and uniform 30 of 34
http://www.smart-society-project.eu
Deliverable 7.3
c SmartSociety Consortium 2013-2017
communication with and among them, ad-hoc provisioning of collectives, designing metrics for monitoring human participation in hybrid collectives, but most importantly, the direct and indirect controllability methods for hybrid collectives â&#x20AC;&#x201C; automated incentive management and a general framework for programming collective collaborations. The document puts the listed contributions in the perspective of the overall project research direction, and then focuses in the second part on the final contribution of the work package â&#x20AC;&#x201C; the programming framework; most specifically reporting on the outcomes of the Y4 of WP7 in terms of functionality and integration, while omitting the low level implementational details, which were outlined in the previous deliverables, and are described in the documentation provided along the source code of the programming framework in the publicly accessible repository together with the executable usage examples. The implemented programming frameworkâ&#x20AC;&#x2122;s importance is twofold: Firstly, it represents an environment incorporating the functionalities of the other platform components and exposing them to the developer for use, thus facilitating the exploitation of the developed Smart Society software components, and speeding up the creation of different (flavors of) collective/commercial platforms. Secondly, its modular design allows easy integration of various novel algorithms, prototypes and components in different phases of collective formation and task execution, at the same time relieving the researcher of writing much of the non-trivial connective and boilerplate code for profile and privacy management, collective management, task lifecycle management and the communication and virtualization functionality. All this will help speed up the time required to test and evaluate novel contribution prototypes, and hopefully uniformize the evaluation environment. As such, the programming framework represents a useful tool for future academic work. Finally, we believe that the introduced concepts, enabling large-scale engagement and management of heterogeneous humans, services and devices, will blend in naturally into the Smart City ecosystem, where the platforms built on principles pioneered by Smart Society and other cognate research efforts will drive the paradigm shift towards a citizendriven Smart City, where humans actively shape the environment in both the physical, political and digital sphere through collective action [14].
c SmartSociety Consortium 2013-2017
31 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
References [1] H.-L. Truong, S. Dustdar, and K. Bhattacharya, “Conceptualizing and programming hybrid services in the cloud,” International Journal of Cooperative Information Systems, vol. 22, no. 04, 2013. [2] H.-L. Truong, H. Dam, A. Ghose, and S. Dustdar, “Augmenting complex problem solving with hybrid compute units,” in Service-Oriented Computing ICSOC 2013 Workshops, ser. Lecture Notes in Computer Science, A. Lomuscio, S. Nepal, F. Patrizi, B. Benatallah, and I. Brandic, Eds.
Springer International Publishing,
2014, vol. 8377, pp. 95–110. [Online]. Available:
http://dx.doi.org/10.1007/
978-3-319-06859-6 9 [3] M. Z. C. Candra, H.-L. Truong, and S. Dustdar, “Provisioning quality-aware social compute units in the cloud,” in ICSOC’13.
Springer, 2013.
[4] M. Riveni, H.-L. Truong, and S. Dustdar, “On the elasticity of social compute units,” in Advanced Information Systems Engineering, ser. LNCS, M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, and J. Horkoff, Eds. Springer, 2014, vol. 8484, pp. 364–378. [5] M. Riveni,
H. L. Truong,
and S. Dustdar,
“Trust-aware elastic social
compute units,” in 2015 IEEE TrustCom/BigDataSE/ISPA, Helsinki, Finland, August 20-22, 2015, Volume 1.
IEEE, 2015, pp. 135–142. [Online]. Available:
http://dx.doi.org/10.1109/Trustcom.2015.367 [6] O. Scekic, D. Miorandi, T. Schiavinotto, D. Diochnos, A. Hume, R. Chenu-Abente, H.-L. Truong, M. Rovatsos, I. Carreras, S. Dustdar, and G. F., “Smartsociety – a platform for collaborative people-machine computation,” in Proc. of the 8th IEEE International Conference on Service Oriented Computing and Applications (SOCA’15), Rome, Italy, October 2015. [7] O. Scekic, T. Schiavinotto, D. Diochnos, M. Rovatsos, H.-L. Truong, I. Carreras, and S. Dustdar, “Programming model elements for hybrid collaborative adaptive systems,” in Proc. 1st IEEE Int. Conf. on Collab. and Internet Comp. (CIC’15), Hangzhou, China, Oct 2015. 32 of 34
http://www.smart-society-project.eu
c SmartSociety Consortium 2013-2017
Deliverable 7.3
[8] O. Scekic, H.-L. Truong, and S. Dustdar, “Managing incentives in social computing systems with pringl,” in Web Inf. Systems Engineering (WISE’14), ser. LNCS, B. Benatallah, A. Bestavros, Y. Manolopoulos, A. Vakali, and Y. Zhang, Eds.
Springer,
2014, vol. 8787, pp. 415–424. [9] ——, “Pringl a domain-specific language for incentive management in crowdsourcing,” Computer Networks, July 2015. [10] P. Zeppezauer, O. Scekic, H.-L. Truong, and S. Dustdar, “Virtualizing communication for hybrid and diversity-aware collective adaptive systems,” in Proc. of 10th Intl. Workshop on Engineering Service-Oriented Applications, ser. WESOA’14. Springer, 11 2014, pp. 56–67. [11] O. Scekic, T. Schiavinotto, S. Videnov, M. Rovatsos, H.-L. Truong, D. Miorandi, and S. Dustdar, “A programming model for hybrid collaborative adaptive systems,” IEEE Trans. on Emerging Topics in Computing (TETC), (under review). [12] M. Z. C. Candra, H. L. Truong, and S. Dustdar, “Analyzing reliability in hybrid compute units,” in IEEE Conference on Collaboration and Internet Computing, CIC 2015, Hangzhou, China, October 27-30, 2015.
IEEE, 2015, pp. 150–159. [Online].
Available: http://dx.doi.org/10.1109/CIC.2015.30 [13] ——, “On monitoring cyber-physical-social systems,” in IEEE World Congress on Services, SERVICES 2016, San Francisco, CA, USA, June 27 - July 2, 2016, R. Bahsoon and L. Zhang, Eds. IEEE Computer Society, 2016, pp. 56–63. [Online]. Available: http://dx.doi.org/10.1109/SERVICES.2016.14 [14] S. Dustdar, S. N. Nastic, and O. Scekic, Smart Cities - The Internet of Things, People, and Systems.
Springer, 2017.
[15] D. Martin, M. Hartswood, O. Scekic, and M. Jirotka, “Socio-digital practices of collective action in online labour platforms,” Jun. 2016. [16] J. Kleinberg, “The convergence of social and technological networks,” Comm. ACM, vol. 51, no. 11, pp. 66–72, Nov. 2008. [17] A. Kittur, J. V. Nickerson, M. Bernstein, E. Gerber, A. Shaw, J. Zimmerman, M. Lease, and J. Horton, “The future of crowd work,” in Proc. CSCW ’13, ser. CSCW ’13.
ACM, 2013, pp. 1301–1318.
c SmartSociety Consortium 2013-2017
33 of 34
c SmartSociety Consortium 2013-2017
Deliverable 7.3
[18] M. Hartswood, M. Jirotka, R. Chenu-Abente, A. Hume, F. Giunchiglia, L. A. Martucci, and S. Fischer-H¨ ubner, “Privacy for peer profiling in collective adaptive systems,” in Privacy and Identity Mgmt. for Future Internet (IFIP’14), 9 2014, pp. 237–252. [19] A. Segal, Y. K. Gal, E. Kamar, E. Horvitz, A. Bowyer, and G. Miller, “Intervention strategies for increasing engagement in crowdsourcing: Platform, predictions, and experiments,” in IJCAI’16, New York, USA, 2016, pp. 3861–3867. [20] A. Segal, Y. K. Gal, R. J. Simpson, V. Victoria Homsy, M. Hartswood, K. R. Page, and M. Jirotka, “Improving productivity in citizen science through controlled intervention,” in Proceedings of the 24th International Conference on World Wide Web, ser. WWW ’15 Companion.
New York, NY, USA: ACM, 2015, pp. 331–337.
[Online]. Available: http://doi.acm.org/10.1145/2740908.2743051 [21] P. Mohagheghi and Ø. Haugen, “Evaluating domain-specific modelling solutions,” in Advances in Conceptual Modeling, ser. LNCS, J. Trujillo et al., Eds. Springer, 2010, vol. 6413, pp. 212–221. [22] A. Seffah, M. Donyaee, R. B. Kline, and H. K. Padda, “Usability measurement and metrics: A consolidated model,” Software Quality Control, vol. 14, no. 2, pp. 159–178, Jun. 2006. [23] D. I. Diochnos and M. Rovatsos, “Smartsociety consortium, deliverable 6.2 - static social orchestration: implementation and evaluation,” 2015. [Online]. Available: http://www.smart-society-project.eu/publications/deliverables/D 6 2/
34 of 34
http://www.smart-society-project.eu