d7.1 - virtualization techniques and prototypes

SmartSociety

Hybrid and Diversity-Aware Collective Adaptive SystemsWhen People Meet Machines to Build a Smarter Society

Grant Agreement No. 600584

Deliverable 7.1 Working Package 7

Virtualization Techniques and Prototypes

Dissemination Level(Confidentiality):1

PU

Delivery Date in Annex I: 31/12/2014Actual Delivery Date January 8, 2015Status2 FTotal Number of pages: 138Keywords: hybrid compute units, software-based

services, human-based services, virtu-alization, communication, SmartCom

1PU: Public; RE: Restricted to Group; PP: Restricted to Programme; CO: Consortium Confi-dential as specified in the Grant Agreeement

2F: Final; D: Draft; RD: Revised Draft

c© SmartSociety Consortium 2013-2017 Deliverable 7.1

2 of 138 http://www.smart-society-project.eu

Deliverable 7.1 c© SmartSociety Consortium 2013-2017

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: SmartSociety: Hybrid and Diversity-Aware CollectiveAdaptive Systems: When People Meet Machines toBuild a Smarter Society

Project Acronym: SmartSociety

Grant Agreement Number: 600854

Number and title of work-package:

7 Programming Models and Frameworks

Document title: Virtualization Techniques and Prototypes

Work-package leader: Hong-Linh Truong, TUW

Deliverable owner: Hong-Linh Truong

Quality Assessor: Daniele Miorandi, UH

c© SmartSociety Consortium 2013-2017 3 of 138


List of Contributors

Partner Acronym ContributorTUW Philipp Zeppezauer, Ognjen Scekic, Hong-Linh TruongUEDIN Dimitrios Diochnos, Michael RovatsosUH Tommaso Schiavinotto, Iacopo Carreras, Daniele Miorandi



Executive Summary

This report represents the outcome of the activities carried out within task T7.1, Virtu-

alization Techniques and Prototypes during the first year of the WP7 effort (M13–M24)

in terms of investigating the virtualization and communication techniques for abstracting

capabilities and communications of human/machine units (peers) and their collectives to

enable programming these units and collectives.

The document first describes the research problems of virtualizing human computing

components together with software components for Hybrid and Diversity-aware Collec-

tive Adaptive Systems (HDA-CAS). A review of existing literature is presented, covering

different types of systems where human computing elements were involved, such as socio-

technical systems, human-based services, crowdsourcing systems, and workflow systems.

These approaches are compared with the approaches virtualizing purely machine-based

elements, such as service-oriented computing.

The document describes the key abstract concepts enabling the virtualization of both

machine and human peers by leveraging the service-oriented computing and cloud com-

puting models. Peers and their collectives are abstracted under the concept of service

unit with clear interfaces and capabilities to enable the virtualization and communication.

The concept was devised to meet some of the elicited requirements and facilitate the de-

sign of the communication and virtualization middleware’s architecture and functioning

principles.

The document goes on to present a high-level architecture of the middleware compo-

nent of the SmartSociety platform. The architecture design implements in practice the

abstract concept of the service unit. Concretely, the architecture is described in terms of

structure of exchanged message, inner components, their functionality and interconnect-

edness. The different components enable the conventional middleware communication

functionalities in a HDA-CAS environment. Finally, the document presents the outcomes

of the integration process between WP7 and other components in SmartSociety.



Table of Contents

1 Introduction 7

2 State of the Art 9

2.1 Social Computing Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Cognate HDA-CAS Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Enterprise Service Busses (ESBs) . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Software and Human Virtualization 13

3.1 Virtualizing Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Provisioning of Human- and Software-based Services . . . . . . . . . . . . . 16

3.2.1 Capabilities and Connectedness . . . . . . . . . . . . . . . . . . . . . 16

3.2.2 Non-functional Properties . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Communication Middleware for HDA-CAS 18

4.1 Requirements Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.2 Relations to other SmartSociety Platform Components . . . . . . . . 19

4.2 Service Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3 SmartCom Design & Architecture . . . . . . . . . . . . . . . . . . . . . . . 23

4.3.1 Messaging and Routing . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3.2 Message Transformation . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.3 Message Persistence and Other Functionalities . . . . . . . . . . . . 26

4.3.4 External APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Programming Communications with in SmartSociety Platform 30

5.1 SmartSociety Platform Integration . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Usage and Application Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1 Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.2 Ask SmartSociety! . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Conclusions 33



1 Introduction

The term ‘virtualization’ as used in SmartSociety refers to the process of modeling hy-

brid (human and software) peers in a uniform way to allow their programmatic lifecycle

management from the SmartSociety’s programming model. The lifecycle management in-

cludes, among others, the phases of locating of peers, provisioning/adapting of collectives,

execution of the tasks, monitoring and subsequent rewarding. Therefore, the virtual (dig-

ital) entities representing the physical peers must be able to support these virtualization

aspects. In this deliverable we are looking into different virtualization techniques required

to support these aspects. As interaction with peers is inherent to all of the listed life-

cycle phases, virtualization of communication becomes an additional fundamental aspect

that needs to be researched. For this reason, throughout the document, virtualization of

communication is considered in much more detail.

From the communication perspective, contemporary approaches to virtualizing hu-

man computing elements for the purposes of integration into hybrid collective systems

either rely on the service-oriented approach or on the natural language communication

(Section 2). The advantage of the former approach is the reuse of existing standards

and technologies for matching, invoking and describing possible messages and quality of

services. This allows integration of human-provided services into business processes that

are known and formalized in advance. However, these approaches are not suitable for

executing ad-hoc tasks, where the actual peer collective and/or the exact steps of the

collaboration are not known in advance. In the latter approach informal task descriptions

are provided by task submitters and passed on to the human computing elements for in-

terpretation. This approach is currently used by the commercial crowdsourcing platforms,

where the described problems with ad-hoc tasks are solved by reverting to mostly unstruc-

tured collaboration patterns, sacrificing the task complexity in favor of simple tasks and

coordination patterns, managed through natural language communication with human

peers.

From the programming model perspective, the virtualization is dependent on the

labour model it needs to support. The two most common labour models are: (i) pas-

sively proposing tasks and waiting for human input; and (ii) actively finding and binding

human capabilities into applications. The first model allows more flexible collaboration

patterns, but relying on the peers to drive the collaborative effort, forming and provision-

ing a suitable collective to perform more complex or intellectually challenging tasks may



prove difficult. The second approach is more adept to executing complex tasks, but only

if the execution steps are known at design time.

The labour model (i) usually exploits individual capabilities and is platform-specific.

This is the typical approach used in today’s conventional crowdsourcing platforms, such

as Amazon Mechanical Turk, CrowdFlower or Clickworker. The virtualization in this case

is very loose (often relying on unconstrained human communication), and often highly

system-specific (defined by the concrete crowdsourcing platform), and thus not appropriate

for a general HDA-CAS platform like SmartSociety. The virtualization approaches for

labour model (ii) are typical of workflow-based solutions in which the workflow engine can

find suitable human or software services and assign the tasks to them. In this case, the

virtualization must be codified more formally, as the locating and provisioning of peers is

driven by the system and not the peers. Since the maturity offered by the existing Web

Service models is proven in practice, in this deliverable we show how a similar, service

model approach can be used for virtualizing human peers.

From the WP7 perspective, the goal of the SmartSociety platform is to try to con-

verge the above-described virtualization approaches into a system managing provisioning,

collaboration (composition, orchestration and orchestration) and communication in a pro-

grammable way, allowing a profitable trade-off between the complexity offered by pro-

grammable collaboration patterns, and the flexibility offered by collectives involving free

interaction among human and machine-based peers. In order to support this requirement,

we virtualize human capabilities under the service model, so that they can be programat-

ically discovered, matched, composed with other software and human services into hybrid

collectives and proactively invoked. This is the primary scientific novelty and the con-

tribution of this deliverable. At the same time, the proposed virtualization concepts do

not prevent unconstrained and informal communication and collaboration with/among hu-

man and software peers. This dual approach will allow the programming model to support

the task execution in such a way that parts of the execution flow can be predetermined

(workflow-driven), while other parts can human-driven, and thus unconstrained.

In line with the DOW, part of the introduced virtualization concepts (in particular

those relating to the virtualization of communication) have been implemented as Smart-

Com – the middleware for virtualization of communication with hybrid collectives consist-

ing of human and software peers (T7.1). The remaining virtualization concepts introduced

in this deliverable will rely on SmartCom’s communication functionalities and form the

foundation of the programming model (T7.2). Currently, they have been implemented as



research prototypes, described in the referenced papers.

The remainder of this deliverable is organized as follows: Section 2 presents the ex-

isting state of the art in related research areas. Section 3 presents the key virtualization

concepsts, related to communication and provisioning. Section 4 presents the SmartCom

communication middleware, including its design requirements, architecture, implementa-

tion, integration, evaluation and usage scenarios. Section 6 reviews the achieved results

and concludes the main part of the document. Appendix includes the published papers,

co-authored by the project members, containing the research background for the presented

virtualizations concepts. Along with the deliverable, a technical report is provided present-

ing in more detail the internal design and algorithms used in SmartCom implementation,

as well as exposed APIs. This technical report is also meant as reference material for

project partners wishing to integrate SmartCom. The report also describes performance

evaluation setup and results.

2 State of the Art

The focus of this section will be in reviewing the virualization approaches in existing

systems and research involving human and software-based peers involved in collaborative

efforts. To this end, we will review the existing state-of-the art in social computing plat-

forms, involving virtualized human peers performing given tasks and cognate HDA-CAS

research efforts. Since a significant portion of the T7.1 effort was dedicated to virtual-

ization of communication, and building a prototype of the SmartCom communication

middleware for the SmartSociety platform, the final part of this section reviews the cur-

rent versions of the leading commercial Enterprise Service Busses (ESBs). Although ESBs

work with conventional Web Service technologies, many technical aspects are shared with

SmartCom. In this respect, the review serves to elicit shared design requirements (Sec-

tion 4.1) and identify novel ones, needed specifically for HDA-CAS systems.

2.1 Social Computing Platforms

In D1.1 (Appendix III.14) and D6.1 (Sec. 7.2 and 7.3) we described a number of socio-

technical systems involving human and machine peers that are virtualized as entities ex-

ecuting activities in workflows, and/or invoked as web services. However, in these deliv-

erables the focus is on execution and orchestration aspects of these systems, while here

we take the look at some of the same systems from communication and virtualization



perspective.

Jabberwocky [1] is platforms utilizing human capabilities to solve problems. Jabber-

wocky’s computing stack consists of Dormouse, ManReduce and Dog. Dormouse provides

the functionality to interact with humans and machines using a platform-independent

programming environment that sits on top of other crowdsourcing platforms. ManReduce

follows the MapReduce paradigm but enables the programmer to decide whether to use

a human or machine in both, the map and the reduce phase. Finally Dog is a high-level

scripting language that makes use of ManReduce and has been created to increase the

flexibility of the programming environment. [1]

Amazon provides a web service called Amazon Mechanical Turk3 that offers to clients

to issue small human tasks, so called Human Intelligent Tasks (HITs). Human workers can

solve those tasks and will get a monetary reward after finishing successfully. Usually those

tasks are independent of each other and can be created and solved in parallel. Turkit [2]

provides a programming environment on top of Amazon’s Mechanical Turk that enables

the programmer to define a workflow of tasks. It is able to collect the results of finished

tasks and create further tasks based on those results. [2]

CrowdLang [3] brings in a number of novelties in comparison with the other systems,

primarily with respect to the collaboration synthesis and synchronisation. It enables

users to (visually) specify a hybrid machine-human workflow, by combining a number

of generic collaborative patterns (e.g., iterative, contest, collection, divide-and-conquer),

and to generate a number of similar workflows by differently recombining the constituent

patterns, in order to generate a more efficient workflow. The use of human workflows also

enables indirect encoding of inter-task dependencies.

All the described social computing systems, while differing in ways they enact the

collaborative effort of peers share a similar approach to virtualization. As all these sys-

tems are frameworks/components/libraries layered on top of existing human-computation

commercial platforms (such as Amazon Mechanical Turk, Clickworker, CrowdFlower) this

implies that fundamentally, the virtualization and communication on the lowest level is

determined by the functionalities offered by the underlying platform. For each workflow

action the underlying platform’s API is used to offer the corresponding human task to the

crowd. In this respect, to a platform user, the virtualized concept of the peer in these

systems is a programming language construct describing peer’s capabilities, constraints,

and promised rewards which are passed on to the underlying platform which ultimately

3http://www.mturk.com/


http://www.mturk.com/


provisions the peers to perform the task. Differently than the SmartSociety platform, these

systems do not allow explicitly modeling the relationships between people and machines,

or uniform virtualization of the two concepts. The concept of collective is not supported,

nor the unconstrained peer-to-peer communication. Furthermore, these systems do not

consider other virtualization aspects, such as elasticity.

2.2 Cognate HDA-CAS Systems

The ALLOW Ensembles project deals with the concept of cell ensembles [4]. These en-

sembles consist of cells that are given a declaratively-defined behaviour, but the actual

workflows, that they execute, adapts during runtime depending on the collective (en-

semble) goal. The focus here is on adaptation of workflows to achieve the adaptability

of CAS, whereas the virtualization and communication with human and machine ele-

ments is performed through standardized Web Service (WS–*) technologies. They use

BPEL4Chor [5] for inter-cellular choreography. Using WS-BPEL4People [6] or Adaptive

Pervasive Flows [7] one can also incorporate human activities.

The ASCENS project focuses on the peer-to-peer approach in machine-only ensem-

bles/collectives (e.g., robots, vehicles, storage nodes) [8]. In order to deal with collectivity,

the notion of ensemble compositionality is introduced and expressed through the notion

of Service Components (SC), where SCs are described as: ”nodes that can cooperate,

with different roles, in possibly open and nondeterministic environments. These basic

properties, already satisfied by, e.g., contemporary service-oriented architectures, will be

enriched by new properties of awareness” [9]. The concept of awareness here refers to the

node’s ability to ”determine that there is a (...) difference between the expected result

of their action and the actual result; e.g., spinning the wheels should lead to movement

in a certain direction, but did not influence their position at all.” [9] The collectivity is

achieved by each node separately evaluating whether its action is helpful for reaching the

ensemble’s overall goals. Similarly to SmartSociety, the ASCENS models the fundamen-

tal constructs as service-based components, however, due to the specificity of coordination

languages they use, at the communication layer they use Pastry [10] and extend it with the

SCRIBE protocol [11] to support message routing and delivery in a peer-to-peer fashion

via any- and multi-casts [12]. This behaviour differs from our approach since we provide

a centralized middleware for message exchange, while relying on an adaptive concept of

centrally managed collective.



2.3 Enterprise Service Busses (ESBs)

An Enterprise Service Bus (ESB) [13] is a software architecture that aims to handle the

communication and integration between various software applications and components of

a system (e.g., in an enterprise) in a service-oriented architecture. The following discussion

of popular open-source ESBs is based on the comparison in [14] in 2011 with respect to the

currently available versions. Due to the requirements for virtualization of communication

in an HDA-CAS, this section will only take a look at messaging, integration with adapters,

privacy and delivery policies, access control, and multi-tenancy of Mule ESB (3.5.0) [15],

Apache ServiceMix (5.1.1) [16], JBoss ESB (4.12) [17], and WSO2 ESB (4.8.1) [18].

MuleESB provides patterns for message routing but does not provide message nor-

malization within the ESB, messages are translated only as needed. As many other

ESBs MuleESB does also support custom adapters and is shipped with many prede-

fined adapters. It fully supports different security protocols for access control. The ESB

does also provide some kind of multi-tenancy but does not enforce any policies at run-

time. [15, 14]

Apache ServiceMix provides various patterns for message routing and uses normalized

messages to integrate components. By using Apache Camel4 various adapters can be used

by Apache ServiceMix to integrate components, furthermore it is possible to define custom

adapters to adopt the ESB to new technology. Apache ServiceMix does not support any

privacy or delivery policies that can be applied to specific components and it seems that

it does not provide multi-tenancy as well. The ESB provides different security methods

using JAAS to provide access control to the system. [16, 14]

JBoss ESB also provides various patterns for message routing and uses normalized

messages too. It also supports the creation of custom adapters but they are not as flexible

due to some restrictions compared to other ESB providers. JBoss ESB provides access

control for different components and also a (limited) support for policies. The ESB does

also provide some kind of multi-tenancy. [17, 14]

WSO2 ESB does support all functionality mentioned above except the dynamically

enforcement of policies and is - considering only the discussed requirements - the most

advanced ESB available. [18, 14]

In general all discussed middlewares provide adapters to communicate with compo-

nents and custom adapters to adopt to new technology advancement. All ESBs, except

4http://camel.apache.org/


http://camel.apache.org/


MuleESB, use normalized messages internally for the messaging and routing. In general

none of the presented ESBs comes with support of addressing of collectives. Furthermore

the support of humans interacting with the system is generally not considered.

3 Software and Human Virtualization

In deliverable D1.1 (Sec. 2.6.3 and 4.4) we introduced the principal idea of human and

machine elements virtualized under the concept of service units. In this section we further

develop these concepts and summarize the virtualization aspects needed to expose human

capabilities under the service model, allowing seamless integration of human and machine-

based computing elements.5 The two key virtualization aspects regard: (a) virtualization

of communication with/among peers; and (b) virtualization of human capabilities in such

a way as to allow provisioning of human-based computing elements under a service model.

In the remainder of the section we will use the terms ‘human-based service’ (HBS) and

‘software-based service’ (SBS) to denote virtualized entities corresponding to individual

human and machine peers, respectively. Figure 1 shows a conceptual architecture of a

system providing virtualization of hybrid SBS/HBS’s, allowing layering of a programming

model on top of it.

3.1 Virtualizing Communication

Conceptually, we can assume that a HBS abstracting human capabilities can provide

different communication interfaces to handle tasks based on a request and response model.

Requests can be used to describe tasks/messages that an HBS should perform or receive.

In SBS, specific request representations (e.g., based on XML) are designed for specific

software layers (e.g., application layer, middleware layer, or hardware layer). In HBS we

can assume that a single representation can be used, as HBS does not have similar layer

structures seen in SBS (at the end only humans will understand and process the messages),

while the message content can be defined based on application needs. Requests in HBS

can, therefore, be composed and decomposed into different (sub)requests. The use of the

request/response model will facilitate the integration between SBS and HBS via similar

service APIs. Unlike SBS, where communication can be synchronous or asynchronous,

with HBS all communication is asynchronous. The reason is that semantics of the human-

5The virtualization elements are presented here in a summarized form. They are described in greaterdetail in the published papers [19, 20].



Figure 1: Conceptual architecture for virtualizing hybrid software-based (SBS) andhuman-based (HBS) services.

level communication messages, the way how humans take the messages, and the high

latency of communication between a requester (whether it is a HBS or SBS) to a HBS

prevent synchronous communication in which an HBS is expected to process the messages

and send responses at the same time.

HBS intercommunication can be modeled using the well-known message passing and

shared memory models:

• Message passing: message-passing in which two HBS’s can directly exchange re-

quests: hbsi →request

hbsj . One example is that hbsi sends a request via SMS to hbsj .

Similarly, an SBS can also send a request directly to an HBS.

• Shared memory: shared-memory in which two HBS can exchange requests via a SBS.

For example, hbsi stores a request into a Dropbox directory and hbsj obtains the

request from the Dropbox directory. Similarly, an SBS and HBS can also exchange

requests/responses via an SBS or an HBS (e.g., a software can be built atop Dropbox

to trigger actions when a file is stored into a Dropbox directory (e.g., see 6)).

6http://www.wappwolf.com


http://www.wappwolf.com


Figure 2: Message passing and shared memory communication models for SBS/HBS col-lectives.

Figure 2 describes possible message passing and shared-memory communication mod-

els for services in a collective of HBS and SBS. Message-passing middleware can be further

divided into different channels implemented by different services, e.g., Short Message Ser-

vice (SMS) and Instant Messaging (IM) are dedicated for humans, while Message-oriented

Middleware (MOM) can be used for both SBS and HBS. Similarly, the shared-memory

middleware can be built based on different services, offering different types of “shared-

memory”, such as file-based shared memory, like Dropbox and Amazon S3, and database-

based shared memory, like MongoDB and Amazon DynamoDB. Both message-passing and

shared-memory communication middleware can be used internally for services within a col-

lective or externally for the communication between service consumers and the HBS/SBS

peers. Similarly to machine instances which offer facilities for remote job deployment and

execution, an HBS communication interface can be used to run requests/jobs on HBS. In

both communication models, the structure of messages sent to HBS are designed for human

comprehension. The communication middleware is supposed to perform the transforma-

tion of messages to/from human and machine-comprehensible formats transparently to

the consumers and peers themselves. In Section 4 we present the model and implementa-

tion of a communication middleware supporting both shared-memory and message-passing

paradigms, allowing asynchronous communication with collectives (clouds) of virtualized

HBS/SBS peers.



3.2 Provisioning of Human- and Software-based Services

The term ‘provisioning’ refers to the process of automated locating and (de-)instantiating

of HBS/SBS’s, scaling based on current consumer needs.7,8 It is performed not only dur-

ing the initial collective assembly, but also for subsequent adaptations of the collective,

allowing the collective to scale to consumer’s needs. The process of provisioning needs to

consider the elasticity capabilities and as well as different non-functional properties of the

peers and the collective as a whole (cf. D1.1, Sec. 4.4).

3.2.1 Capabilities and Connectedness

Human Power Unit (HPU)

In order for provisioning algorithms to locate appropriate HBS’s, human peers offering

the HBS need to be described by a set of ‘elastic capabilities’. For example, in [20] we

defined the notion of the Human Power Unit (HPU) as an aggregate metric for expressing

the notion of ‘computing power’ (one possible elastic capability) based on the skills of

peer members of a HBS-based collective. Although there is no standard way to compare

skills and skill levels described and/or verified by different people and organizations, it is

feasible to establish a common set of comparable skills for a particular collective of HBS.

Different evaluation techniques can be enforced upon collective members to ensure that

any HBS in it will declare skills and skill levels in a collective-wide consistent manner.

This is similar to some crowdsourcing systems which require entry tests to verify claimed

skills. Different benchmarks can also be used to test and validate skills and skill levels.

This approach is similar to Amazon which uses benchmarks to define its elastic compute

unit. Finally, different skills from different sources can be mapped into a common view

consistent within the scope of collective.

Connectedness

In order for humans to collaborate on performing a complex task it is necessary to im-

pose different communication topologies and collaboration patterns [21]. Communication

7Provisioning should not be confused with the process of ‘composition’, as defined in WP6. Composi-tion refers to the process where peers actively participate in describing a future workflow, by posting taskrequests, negotiating on them, and finally executing them. Therefore, composition happens in the contextof the approach (i) described in Section 1, where human peers are proposed tasks and expected to acton them. Provisioning, on the other hand, refers to the described approach (ii), where peers are activelylocated and engaged. The two approaches can co-exist as complementary on a single platform.

8Discussion on locating and provisioning of SBS’s is out of scope of this deliverable, as it is a well-known concept, used in practice in commercial cloud-based systems on different levels (IaaS, PaaS, SaaS).However, provisioning of HBS’s is a novel concept, as the provisioning models for humans differ from thosefor software services.



topologies specify which communication channels, tools and APIs are used for communica-

tion between HBS’s, but also times at which communication can happen (due to irregular

availability of HBS’s). An example of a communication pattern is a star topology, where

each peripheral node is allowed to communicate only with the central node, using a pre-

defined communication technology. In case of the shared-memory communication model,

the central node can play the role of the shared repository (e.g., Dropbox). Collaboration

patterns specify which roles an HBS takes. For example, a tree topology of managerial

relations can be imposed to mimic the command and responsibility chains within a col-

lective. Custom delegation patterns can be defined to obtain replacement peers for an

unavailable HBS. In [22] we investigate provisioning of collectives with optimized social

connectedness (e.g., based on friendship or past collaboration relationships).

3.2.2 Non-functional Properties

Monitoring metrics

In addition to skills and skill levels, other metrics can also been taken into consideration

when provisioning HBS’s, such as effort, productivity, reputation, willingness. Defining a

generally applicable set of metrics is not feasible. However, as the provisioning is managed

by a dedicated middleware, a set of metrics can be defined on collective level or spanning

multiple similar metrics. In [23] we investigate a number of different metrics suitable for

a distributed software development scenario, and show how the introduced metrics can be

used in algorithms for provisioning and adapting composition of HBS collectives.

Pricing model

SBS’s are generally provisioned under specific cloud pricing models [24], although some

of them are also provided for free, in particular in volunteering, crowdsourcing and peer-

to-peer computing scenarios. In the case of HBS’s, different pricing models, specific to

humans, need to be identified. In [20] we proposed a numbered of possible pricing factors

that can be taken into account for building pricing models appropriate for HBS’s.

Incentives

Differently than SBS’s, a HBS must be (additionally) motivated to perform a task well

by suitable (also non-monetary) incentives. We investigated incentive models suitable

for inclusion into the programming model in [25]. In order to implement these models,

techniques must be developed to support billing and incentive enforcement. Such billing

and incentive enforcement can be decoupled and offered as service. For example, when an

HBS is utilized and we need to apply a reward, the consumer or the provider can send



its results to an incentive system, which calculates and performs payments. In [26] we

presented one such decoupled incentive management system for HDA-CAS.

4 Communication Middleware for HDA-CAS

In this section we showcase the results of WP7 research in virtualizing communication for

HBS’s and SBS’s in HDA-CAS, as described in Section 3.1, and present the design, imple-

mentation and evaluation of SmartCom, a communication middleware acting as the basic

layer necessary for implementing other virtualization services described in Section 3.2, as

well as a general communication facility for other SmartSociety platform components.

4.1 Requirements Specification

4.1.1 Functional Requirements

SmartCom needs to support the following functionalities, typical of service buses:

• Heterogeneity – supporting various types of communication channels (protocols)

between the platform and (among) HBS/SBS units. This also includes supporting

indirect communication through third-party tools (e.g., Dropbox).

• Communication – providing primitives for: message transformation, routing and

delivery both on individual and collective level.

• Persistence – message persistence and querying.

• Security – handling authentication and encryption, as well as preventing message

flooding.

• Scalability – ability to handle large number of intermittently available service units.

In addition to these features, the distinguishing novelty of SmartCom is its require-

ment of native support for virtualizing peers and collectives thereof, expressed through

the following sub-requirements:

• Adaptivity – hiding the communication complexity with/within a collective of un-

known composition.

• Programmability – handling passing of instructions to collectives from the Smart-

Society platform, in order to manage the collective as a first-class, programmable

entity.



• Hybridity – communicating with collective members (peers) transparently to the

SmartSociety platform, regardless of whether they are human (HBS) or machine-

based (SBS).

• Context-awareness – supporting a single peer (human, sensor or software service)

endpoint to participate in different collectives concurrently, acting as a different

service unit with different context (e.g., SLA, delivery and privacy policies).

The formulated requirements are in line with the overall SmartSociety platform re-

quirements, defined in D8.1. Concretely, the requirements presented here map to the

following overall requirements: CR–1-2, HT–1-4, SEC–4, and PR–1.

4.1.2 Relations to other SmartSociety Platform Components

Using SmartCom the orchestration components (WP6) and the future execution en-

gine built to support the programming model (WP7 – T7.2 and T7.3) are able to send

messages/instructions to collectives and individual peers identified by a unique identifier

(peer/collective ID). The mapping of the IDs and the actual addresses/communication

channels is handled by SmartCom with the assistance of the Peer Manager (WP4).

SmartCom does not provide an environment for task execution to the peers, nor does it

aim to be the only communication means for peers participating in the task execution.

However, due to the support both of REST-based communication as well as of third-

party, human-centric communication and collaboration tools, it can lend itself well as a

communication platform for other WPs as well.

Relying on the Peer Manager as the only authority for managing collective composition

and individual peer profiles (including the personal information relating to their commu-

nication channels) decouples SmartCom from the responsibility of managing personal

user information. The peers can specify in their peer profiles the preferred communication

channels through which they want to be used in different contexts, fulfilling an important

privacy aspect. The API that can be used to send messages through the middleware is gen-

eral enough to be used by other SmartSociety platform components, e.g., for supporting

incentives (WP5).

In order to support provenance management (WP2), SmartCom offers a message per-

sistence functionality, and exposes the access to this database internally to other Smart-

Society components through the API. Through this API the interested components can

access the exchanged messages and perform further analysis.



Unless a specific implementation is provided (cf. Adapters, Sec. 4.3) SmartCom itself

does not read the contents of the passed message and is agnostic to its internal structure,

wrapping it into an internal representation for routing and delivery purposes. This allows

the other components to deliver their message structures independently of SmartCom,

e.g., different task requests.

4.2 Service Units

SmartSociety Platform (HDA-CAS)

SmartSociety Applications

App1 module

App2 module

App3 module

Compiler

SMA

RTC

OM

Mid

dle

wa

re

AppN module

Smar

tSo

ciet

y A

PIs

Provenance

Orchestration

Elasticity

Incentives

etc.

°°°

developers

users

SU

Human Peer

SU

Machine Peer (e.g. Web Service)

SU

Human Peer

E.g., Smart CityMaintenance

Provider

User App A

User App B

context

Execution Context

Incentives

QoS

Communication Adapter

or

or

Service Unit (SU)

Figure 3: Virtualizing communication with HBS/SBS peers to the rest of the SmartSoci-ety platform through SmartCom middleware. SmartCom components are outlined inblue. A conceptual representation of a Service Unit (SU) is shown enlarged (top right).Remaining SUs are displayed collapsed.

The Service Unit (SU) is a conceptual entity that virtualizes communication with a

single human or machine computing element (peer) participating in task executions man-

aged by the SmartSociety platform. Figure 3 shows the operating context of SmartCom

and how the SU abstraction is used to represent hybrid peers for different SmartSociety

application execution contexts. The concept of Service Unit as used in this section is based

on the concepts of HBS or SBS-based Individual Compute Units (ICU) from [20]. While



the referenced paper discusses the concept primarily from the programming model per-

spective, here we take the look at the same concept from the communication perspective.

An SU consists of: i) Peer – a human, a machine, a thing (e.g., a sensor), or a collective

thereof, performing the computation or executing a task; ii) Context – a set of parameters

describing the execution context of the particular SmartSociety application in which the

SU is participating.

The peer is represented by its physical addresses. A physical address is any set of

technology-specific parameters required for SmartCom to communicate with the peer,

possibly indirectly via third-party tools. For example, in case of a REST-based software

peer the physical address is represented by the URL and the HTTP action; in case of a

human peer with a dedicated Android application contacted via Google Cloud Messaging9,

the physical address is the API key which allows SmartCom to push notifications to the

peer’s device; in case of collective with a collaboration workspace provided on Dropbox,

the physical adress is a combination of a username and an API key, granting access to a

specific Dropbox folder mapped to the shared workspace.

In order for SmartCom to know which physical address to use for a particular inter-

action with the peer/collective, a communication context (embodied in the SmartCom

component Communication Adapter, Sec. 4.3.2) is associated with the current execution

context. The execution context is a subset of peer preferences related to peer’s participation

in the given SmartSociety application, stored in the peer profile within the PeerManager

(WP4) component. A Communication Adapter instance is created based on the prefer-

ences specified in the execution context. The preferences currently include delivery and

privacy policies, effectively allowing peers to control over which physical channels they

can be contacted by a specific SmartSociety application, transparently to the application

itself. However, the design of the adapters is extensible, which should allow inclusion and

honoring of additional peer preferences, such as those related to privacy once the privacy

management design for the SmartSociety platform has been finalized.

The execution and communication context are parts of the more general notion of

SU’s context (Fig. 3), which additionally can include also a set of monitoring metrics as

well as pricing and incentive mechanisms relating to a particular execution, to support

on-demand provisioning of service units and elastic adaptations of collectives as described

in Section 3.

The lifecycle of communication adapters is fully managed by SmartCom, while the

9https://developer.android.com/google/gcm/index.html


https://developer.android.com/google/gcm/index.html


communication respects the peer’s preferences, hiding the communication complexity, elas-

ticity and privacy handling from the SmartSociety application, thus effectively virtualiz-

ing communication with peers and collectives for the SmartSociety platform components,

which only need to use the API (see Sec. 4.3.4) that SmartCom exposes to with peer-

s/collectives and vice versa. This is in line with the PU–1 requirement from D8.1. The

functionality offered by SmartCom corresponds to the basic communication primitives

necessary to support programmable hybrid HBS/SBS collectives, described in [20].

Both the ‘message passing based communication’ and the ‘shared memory communi-

cation’ described in the referenced paper are supported. ‘Push’ and ‘pull’ primitives are

implemented through corresponding SmartCom adapter types, while the communication

medium itself can belong to a third party. For example, SmartCom-provided push and

pull adapters can be used with Dropbox to emulate a shared-memory communication

between peers. Depending on peer’s preferences on which communication channel(s) to

use, specified for the execution context, SmartCom will use proper primitives for the

given type of channel. For example, consider a use-case within an imaginary SmartSo-

ciety application ‘PhotoContest’ where peers are asked to provide a photo of a specific

object. Peer Alice sets in her communication context that her only communication chan-

nel for providing the results is Dropbox, while peer Bob sets his communication context to

use the dedicated Android/Web application for sending photos. During the execution of

the ‘PhotoContest’ application SmartCom manages a pull-based input adapter instance

which regularly polls Alice’s Dropbox folder for new photos while a push-based input

adapter exposing a REST service is used to receive photos sent from Bob’s application.

In either case, SmartCom notifies the ‘PhotoContest’ application that a new photo is

available, hiding from it how the message was obtained, while allowing peers to choose

preferred communication channels via their SU contexts. Since peers can alter their execu-

tion and communication contexts at any time, different privacy and convenience patterns

can be obtained. For example, a peer can switch off certain communication channels

during the weekend or out of working hours. Similarly, a single peer can define different

communication contexts for different execution contexts, thus posing as a different SU in

a different SmartSociety application. In this way, distinguishing between professional and

leisure participation can be honored.



SMARTCOMPeer Adapters

Human

Software

Mobile App

Human

FTP

Feedback Adapters

Communication Engine

Messaging and Routing Manager

Adapter Manager

Message Info Service

HDA-CAS Platform

(e.g., Smart Society)

App1

App2

App3

Adapter Execution

Engine

Adapter Handler

Address Resolver

MessageHandler

RoutingRule

Engine

Feedback Handler

Message Query Service

Mail Adapter

MobileApp Adapter

Email

REST Adapter

Email

<<REST>>

Dropbox Adapter

FTPAdapter

Mailinglist Adapter

Dropbox

Collective#1

Mes

sage

Bro

ker

Figure 4: Simplified architecture of the SmartCom middleware.

4.3 SmartCom Design & Architecture

Figure 4 shows the conceptual architecture of the SmartCom middleware. The HDA-CAS

Platform components (e.g., executing application modules) pass the messages intended for

collectives to the Communication Engine through a public API. The task of the Commu-

nication Engine is to effectively virtualize the notions of ‘collective’ and ‘service unit (SU)’

for the HDA-CAS platform. This means that the communication with different service

units and collectives has to be handled transparently to the HDA-CAS platform, inde-

pendent of unit’s actual type and availability. In the following sections, for brevity, when

referring to the communicational aspect of SU’s functionality we will use the short term

“peer” denoting the computing human/machine element within the SU that is the sender

or receiver of information/data; and the term “adapter” denoting the middleware com-

ponent in charge of handling the communication. Due to space constraints, a detailed

description of the described architectural components and their implementation, as well

as the full API specification is provided in the SmartCom Technical Report.

4.3.1 Messaging and Routing

All communication between the peers and the platform is handled asynchronously using

normalized messages. A queue-based Message Broker is used to decouple the execution



of SmartCom’s components and the communication with peers. SmartCom supports

unicast as well as multicast messages. Therefore, multiple peers can also be addressed

as collectives and the SmartCom will take care of sending the message to every single

member of the collective.

The Messaging and Routing Manager (MRM) is SmartCom’s principal entry point

for HDA-CASs. It consists of the following components: 1) The Message Handler takes

incoming messages from HDA-CAS and transforms them into an internal representation,

sending it to the receiver via a determined peer output adapter. If the receiver of the

message is a collective, it resolves the current member peers and their preferred communi-

cation channels, determining a set of output adapters to use; 2) The Routing Rule Engine

then determines the proper route to the peers, invoking the Adapter Manager to instan-

tiate appropriate adapters in order to complete the route, if needed (see below); 3) The

Feedback Handler waits for feedback messages received through feedback (input) adapters

and passes them to the Message Handler. Afterwards they will be handled like normal

messages again, and re-routed where needed, e.g., back to the HDA-CAS. A route may

include different communication channels as delivery start-/endpoints. Figure 5 shows the

conceptual overview of SmartCom’s routing. For each message the route will be deter-

mined by the Routing Rule Engine using the pipes-and-filters pattern, determining the

route based on the message properties: receiver ID, message type and message subtype,

with decreasing priority. Note that there may be multiple routes per message (e.g., a

single peer can be contacted using a mobile app and email concurrently).

Pa P1

Pa

P2

Fa

HDA-CAS

P3

Fa

Routing Engine

Dropbox

Sensor

FaP4

P5

Figure 5: Messages are routed to Output Adapters (Pa) which forward the messages tothe corresponding Peers (P1 to P5). Feedback is sent back by human peers, software peers(e.g., Dropbox) and sensors using Input Adapters (Fa). The HDA-CAS Platform can alsosend and receive messages.

4.3.2 Message Transformation

In order to use a specific communication channel, an associated Communication Adapter

(or simply adapter) needs to be instantiated. The communication between peers and



the adapters is unidirectional — output adapters (also: peer adapters) are used to send

messages to the peers; input adapters (also: feedback adapters ) are used to receive mes-

sages from peers. SmartCom originally provides some common input/output adapters

(e.g., SMTP/POP, REST, Dropbox). The role of adapters should be considered from the

following two perspectives: 1) functional; and 2) technical.

Functionally, the adapters allow for: a) Hybridity – by enabling different communi-

cation channels to and from peers; b) Scalability – by enabling SmartCom to cater to

the dynamically changing number of peers; c) Extensibility – new types of communication

and collaboration channels can easily be added at a later stage transparently to the rest

of the HDA-CAS platform; d) Usability – human peers are not forced to use dedicated

applications for collaboration, but rather freely communicate and (self-)organize among

themselves by relying on familiar third-party tools; e) Load Reduction and Resilience –

by requiring that all the feedback goes exclusively and unidirectionally through external

tools first, only to be channelled/filtered later through a dedicated input adapter, the

SmartCom is effectively shielded from unwanted traffic load, delegating the initial traffic

impact to the infrastructure of the external tools. At the same time, failure of a single

adapter will not affect the overall functioning of the middleware.

Technically, the primary role of adapters is to perform the message format trans-

formation. Optional functionalities include: message filtering, aggregation, encryption,

acknowledging and delayed delivery. Similarly, the adapters are used to interface Smart-

Com with external software services, allowing the virtualization on third party tools as

common software peers. The Adapter Manager is the component responsible for man-

aging the adapter lifecycle (i.e., creation, execution and deletion of instances), elastically

adjusting the number of active instances from a pool of available adapters. This allows

scaling the number of active adapter instances out as needed. This is especially impor-

tant when dealing with human peers, due to their inherent periodicity, frequent instability

and unavailability, as well as for managing a large number of connected devices, such as

sensors. The Adapter Manager consists of following subcomponents:

• Adapter Handler : managing adapter instance lifecycle. It handles the following adapter

types: i) Stateful output adapters – peer adapters that maintain conversation state

(e.g., login information). For each peer a new instance of the adapter will be created;

ii) Stateless output adapters – peer adapters that maintain no state. An instance of an

adapter can send messages to multiple peers; iii) Input pull adapters – adapters that



actively poll software peers for feedback. They are created on demand by applications

running on the HDA-CAS platform and will check regularly for feedback on a given

communication channel (e.g., check if a file is present on an FTP server); iv) Input push

adapters – adapters that wait for feedback from peers.

• Adapter Execution Engine: executing the active adapters.

• Address Resolver : mapping adapter instances with peers’ external identifiers (e.g.,

Google/Dropbox username) in order to initiate the communication.

Feedback messages from peers (e.g., subtask results) or external tools (e.g., Dropbox file

added, email received on a mailing list) are consumed by the adapters either by a push

notification or by pulling in regular intervals.

4.3.3 Message Persistence and Other Functionalities

All sent and received messages as well as internal messages are persisted in a NoSQL

database. Stored messages can be queried and analyzed through the MessageQuery public

API (e.g., to derive metrics or identify conditions for applying incentives). Since messages

can be of arbitrary subtype and contain an arbitrary payload, human peers (and their local

third-party applications) might not know how to interpret the message. The MessageIn-

foService provides: a) The semantic meaning/description of message type and contents

in a human-readable way; b) Dependencies to other messages; c) Timing constraints (e.g.,

expiry, priority). This is especially useful in application contexts (e.g., task acceptance

negotiations), where human peers are required to fully understand the message meaning

and send back valid answers. Currently, the service annotates the message field types,

provides a natural-language description of the expected fields contents and provides a

state-machine description describing the allowed message exchange sequence with respect

to dependency and timing constraints.

SmartCom supports specifying and observing delivery and privacy policies on mes-

sage, peer and collective level: Delivery policies stipulate how to interpret and react to

possible communication exceptions, such as: failed, timed out, unacknowledged or re-

peated delivery. Privacy policies restrict sending or receiving messages or private data

to/from other peers, collectives or HDA-CAS applications under different circumstances.

Apart from offering predefined policies, SmartCom also allows the users to import cus-

tom, application- or peer-specific policies. As noted, both types of policies can be specified



at different levels. For example, a peer may specify that he can be reached only by peer

‘manager’ via communication channel ‘email’, from 9am to 5pm in collective ‘Work’. The

same person can set to be reachable via ‘SMS’ any time by all collective members ex-

cept ‘manager’ in collective ‘Bowling’. Similarly, a HDA-CAS platform application could

specify the collective delivery policy stating that when sending instructions to a collective

it suffices that the delivery to a single member succeeds to consider the overall delivery

successful on the collective level. SmartCom takes care of combining and enforcing these

policies transparently to the HDA-CAS user in different collective contexts.

Peer authentication is handled externally. Before instantiating the corresponding

adapter, SmartCom requires the peers to authenticate with the external tool and ob-

tains from the tool the token that is used to authenticate messages from/to the peer.

More information is provided in the supplement materials.

4.3.4 External APIs

This section briefly describes the interfaces exposed by SmartCom. Clients in this case

are both internal SmartSociety components that may want to use SmartCom to perform

communication with collectives or other components, or peers themselves, to communicate

with platform components or other peers/collectives. The APIs are presented in more

detail in the SmartCom Technical Report.

• Communication – Acting as a single point of access for internal SmartSociety plat-

form components wishing to use SmartCom’s communication functionality. The

API is used to pass messages that need to be delivered to collectives/components.

The same API is used to register callbacks in order to receive reply messages. Ad-

ditionally, the API offers registering new adapters and routing rules.

• InputPushAdapter – Interface exposed by input adapters that receive messages from

peers via push-based mechanism. This API can be used by peers or peer applications

to actively send messages to the SmartSociety platform components or collectives,

subject to prior authentication.

• InputPullAdapter – Interface exposed by input adapters that receive messages from

peers via pull communication, i.e., by querying the corresponding endpoint in regular

intervals. This API can be used by peers or peer applications that produce results of

a computation to register a callback that will be used by the adapter implementing

the API to occasionally poll for new/updated computations results.



• MessageInfoService – A service that can provide information on a specific message

type, i.e. how to interpret the message and the relationship to other messages.

The service allows the applications to store a human-readable interpretation and/or

machine-interpretable description of the fields of the message (which is application-

specific), and related semantic constraints. This, in turn, allows the end recipient of

the message to understand the message properly and know what are the expected

responses. For example, when a human peer receives a message during the task

negotiation phase, by querying this service the peer can find out in which way to

respond to the message to accept the task, reject it, ask for more information, ask for

another offer, suggest a replacement. The provided choices are in this case dependent

on the specific negotiation pattern used. However, the message interpretation can be

used generally in any message exchange where message ordering or particular field

values have associated semantics.

In addition, the service could facilitate building of peer applications. For example,

upon each received message from the SmartSociety platform, the peer application

could query the service to obtain the information on expected responses, offering

automatically appropriate GUI to compose responses, and integrating into the GUI

forms the descriptions of message fields retrieved from the MessageInfoService, pos-

sibly translated into user’s native tongue.

• MessageQueryService – Service that allows to querying persisted messages. Default

setting is that all messages transported by SmartCom get persisted. However, de-

pending on the privacy guidelines, service can also filter the messages or particular

fields that get persisted. The service is accessible only internally to the SmartSo-

ciety components. The primary motivation for the introduction of this service was

to allow access to the data necessary for provenance (WP2) and incentive (WP5)

management. The messages get internally stored in a MongoDB database. The API

offers the querying functionality analogous to the to JPA Criteria API10 returning

a collection of matching messages.

4.3.5 Evaluation

The planned contribution of T7.1 is not to build a performance-oriented communication

middleware, but to design a middleware capable of functionally responding to SmartSo-

10http://docs.oracle.com/javaee/6/tutorial/doc/gjitv.html


http://docs.oracle.com/javaee/6/tutorial/doc/gjitv.html


ciety platform requirements of hybridity, diversity, collective-centrality. Therefore, the

performance comparison with commercial middleware systems, such as those described in

Section 2, is out of scope of this document, not least because SmartCom’s performance

is effectively limited by the properties of the commercial de-facto standard technology at

its core (Apache ActiveMQ) for doing the queuing heavy work.

In this respect, we formulated the requirements in Section 4.1, and in Section 4.3 jus-

tified how the presented design fulfils those parameters. Each of the stated functionalities

is covered by unit tests and realistic integration tests simulating multiple remote peers

using all the technologies for which we provide the adapters to connect to the middleware

(mail, Dropbox, dedicated Android app), provided in the code repository11. Furthermore,

SmartCom is used in the WP8-led ”Ask SmartSociety!” M24 demo (Section 5.2.2) show-

casing a real-world example scenario integrating SmartCom with other WP components

(WP4 PeerManager, and WP6 Orchestration Manager).

In addition, we ran simulation-based scalability experiments with SmartCom showing

that it can handle up to 5000 messages per second on average (subject to limitation of

ActiveMQ). We tested it with up to 1000 concurrent peers, a load of 1 · 106 messages

uniformly distributed to peers on a very resource-limited laptop with satisfactory results.

Scaling the number of peers has not proven problematic, while the throughput of 5000ms-

g/sec is expected to cover typical peak loads we will encounter within the project’s scope,

considering that most of peers are humans. The throughput limitation applies to a single

SmartCom instance, and multiple SmartCom instances can be deployed to balance the

load if needed, sharing the database and PeerManager access. The evaluation setup and

results are presented in the SmartCom Technical Report.

11https://github.com/tuwiendsg/SmartCom


https://github.com/tuwiendsg/SmartCom


5 Programming Communications with in SmartSociety Plat-form

5.1 SmartSociety Platform Integration

SmartCom represents the primary interface towards peers and application end-users. It

supports dynamic selection of the most appropriate communication channel to interact

with a single peer and/or a collective, including e.g., mobile application, Dropbox, emails,

social media, etc.. The following dynamic view details how an application will be using

the SmartSociety platform in order to perform a hybrid computation and shows how

SmartCom is interacting with the other platform components and with (in this case:

human) peers. In particular, SmartCom is used during the orchestration phase for (i)

connecting to peers for recruitment (for the execution of a given task/composition); and

(ii) interacting with the peers during the actual execution of the task.

Figure 6: Dynamic view of interactions among SmartSociety platform components: focuson SmartCom.

SmartCom is then interfacing with the PeerManager for retrieving the necessary in-

formation for interacting with Peers. This includes the preferred interaction channel of any



given peer when available. Examples of preferred interaction channels are email, Dropbox,

mobile application, social media, etc. This is typically based either on the preferences ex-

pressed explicitly by the peer, or on previous interactions with that given peer or based

on the actual context the user is in. It is worth remarking that a peer can be human, a

machine or a combination thereof. In addition, SmartCom handles the scalability of the

platform by maintaining different conversations, whereas each conversation is initiated by

the composition manager.

5.2 Usage and Application Scenarios

5.2.1 Orchestration

Orchestration of SmartSociety applications follows a RESTful document-driven paradigm

as described in D6.1 and D6.2. In the context of T7.1, the primary roles of orchestration

are described below:

1. Trigger composition events as a consequence of new task requests that arrive in

the platform, potentially communicating with the peer manager, the reputation

service, and the incentives manager depending on the composition policy followed

on a specific application. These composition events give rise to new tasks where

different collectives (teams) are formed per task.

2. Synchronisation between the composed tasks and the associated task requests.

3. Enforcing negotiation policies and allowing negotiation between the peers in the

collective of each task.

4. Synchronisation of the tasks, the associated task requests, as well as among tasks

(potentially affecting the negotiation of unrelated peers in other collectives), as ne-

gotiation is taking place.

5. Allowing and synchronising information that is generated during the execution of a

task and is stored in the appropriate task record.

Based on the above, we present four examples of how SmartCom can be used in

orchestration to deliver messages to various users or peers of a SmartSociety application:

1. Upon completion of a composition event, the set of associated negotiable tasks turns

from empty to non-empty for a set of task requests. SmartCom notifies the appro-

priate collectives that there are tasks where negotiation can take place.



2. Depending on the negotiation policy applied on a specific application, certain peers

may need to negotiate before others. For example, in a Ridesharing scenario, the

negotiation policy may require that the drivers first select the task that they find

more attractive and only then allow commuters to continue the negotiation on the

same task. In such cases, SmartCom is used to provide guidance to the various

peers indicating that there are tasks where they may be able to agree.

3. When an agreement is reached on a task (given the negotiation policy at hand),

SmartCom notifies the participants of the task that execution may now start.

4. Reaching agreements and finalising the formation of collectives on tasks is of utmost

importance for Smart Society applications. In certain applications the agreement

on a task may invalidate ongoing negotiations on other tasks. In this case, the

participants of such tasks need to be notified that they can no longer negotiate on

the invalidated tasks and perhaps need to start over the negotiation process on a

different task that is available. For example, in a Ridesharing application, consider a

scenario where we have two drivers d1 and d2 and two commuters c1 and c2. Assume

that d1 initiates negotiation with c1 and c2, and d2 with c2 alone. Then, c1 agrees

to the trip (d1, c1, c2) and c2 agrees to the trip (d2, c2). Since the latter trip has

been finalised, the trip (d1, c1, c2) is rendered invalid and SmartCom can be used

to send a notification to the driver d1 that a new trip should be selected (e.g. the

one involving c1 alone).

A positive effect of using SmartCom in orchestration activities, such as previously

described ones, is the reduction of the polling requests from the client applications.

5.2.2 Ask SmartSociety!

Ask SmartSociety! is a Q&A service enabled by the SmartSociety platform, which will be

used as a basis for developing demonstration scenarios, in particular with focus on tourism,

the reference domain for validating the SmartSociety vision. Ask SmartSociety! will be a

service where users can post questions in natural languages and peers can provide answers.

Peers providing answers can be humans (individuals or collectives) as well as machines

(intelligent software agents). Peers can compose (forming collectives, hybrid or not) to

provide answers. Answers can be ranked based on the reputation of the peers or on

community ranking. In some instances the user issuing the question can select an answer



and provide feedback on the peer providing it. An example (grounded in the tourism

application scenarios) to help in understanding the features of the Ask SmartSociety!

service is the following:

Next week Peter will fly to Venice. He will be busy in meetings during the

day but wants to explore some ‘hidden’ places at night. He could well explore

various online tourist sites but he prefers to ask experts and local people. He

could also google for relevant content, but he does not actually need an answer

right away, he just needs to get it in one week. And having one system which

allows him to query local experts, web-based recommendation services and

incoming tourism institutions looks definitely appealing to him!

The Ask SmartSociety! has been developed in the form of a mobile application, where

users can send a question to the SmartSociety platform through a simple user interface.

After the question is submitted the composition phase takes places: peers that have regis-

tered to the application and agreed to answer to a given topic are selected. In this scenario

there is no ’real’ negotiation for each single question because agreement is considered im-

plicit at the moment of the registration (the application should make it clear in the terms

of service). Once the list of peers is available SmartCom is used to send them the actual

question. In this case, SmartCom is used to send the question to be answered by the

various peers. A conversation is established with each peer, while waiting for an answer

from each one of them. When the peer answers (or produces an answer), the mobile appli-

cation returns a response directly to the application12. In this specific case, the following

SmartCom adapters have been used:

• REST: for sending the question to two machine peer: one posting the question on

Twitter, the other one looking for an answer on Google.

• GCM: for sending the question through Google Cloud Messaging to Android users

that have installed the Ask SmartSociety! application for replying.

6 Conclusions

In this deliverable we have introduced the founding principles of virtualization of human

or machine-based peers necessary for supporting uniform communication between the

12For this specific service no instance of the task executor is actually employed.



SmartSociety (or indeed any similar HDA-CAS) platform and the virtualized peers (T7.1)

and subsequent integration of virtualized peers into the programming model (T7.2). The

virtualization of individual peers of different types is a necessary step in achieving the

hybridity requirement of the SmartSociety platform. The theoretical virtualization con-

cepts presented in Section 3 allow provisioning of human or machine-based peers under the

service model, and their incorporation into elastic, scalable collectives which can be char-

acterized by specific metrics, pricing and incentive characteristics. Particular attention

was paid to the communication virtualization. The introduced theoretical concepts have

been implemented within the prototype of the communication middleware SmartCom

whose internal design and exposed functionalities have been described in Section 4.3.

SmartCom natively supports working with collectives of peers, thus taking over the

burden of keeping track of collective’s composition and single peer communication pref-

erences from middleware’s clients. SmartCom’s exposed functionality allows it to be

used by other SmartSociety platform components. Personal peer preferences and collec-

tive information are not managed by SmartCom directly, but obtained from the WP4

PeerManager, meaning that other platform components which already make use of the

centralized peer profile management and communicate directly with peer can efficiently

transition to SmartCom while keep using the peer profile IDs if they need more advanced

communication capabilities. SmartCom exposes the low-level communication primitives

necessary for enacting various negotiation, collaboration and communication patterns that

will be described in the programming model (T7.2). As such, this document also serves

to observe the enabling and limiting factors in defining the expressiveness of the program-

ming model patterns. It also serves as a guidance document for other WPs which may

want to integrate SmartCom’s functionality.



References

[1] S. Ahmad, A. Battle, Z. Malkani, and S. Kamvar, “The jabberwocky programming

environment for structured social computing,” in Proceedings of the 24th annual ACM

symposium on User interface software and technology. ACM, 2011, pp. 53–64.

[2] G. Little, L. B. Chilton, M. Goldman, and R. C. Miller, “Turkit: tools for iterative

tasks on mechanical turk,” in Proceedings of the ACM SIGKDD workshop on human

computation. ACM, 2009, pp. 29–30.

[3] P. Minder and A. Bernstein, “CrowdLang: programming human computation sys-

tems,” University of Zurich, Tech. Rep., 2012.

[4] V. Andrikopoulos, A. Bucchiarone, S. G. Saez, D. Karastoyanova, and C. A. Mezzina,

“Towards modeling and execution of collective adaptive systems,” in Service-Oriented

Computing–ICSOC 2013 Workshops. Springer, 2014, pp. 69–81.

[5] G. Decker, O. Kopp, F. Leymann, and M. Weske, “Bpel4chor: Extending bpel for

modeling choreographies,” in Web Services, 2007. ICWS 2007. IEEE International

Conference on. IEEE, 2007, pp. 296–303.

[6] O. C. Specification, “Ws-bpel extension for people (bpel4people) specification version

1.1,” http://docs.oasis-open.org/bpel4people/bpel4people-1.1.html, 2010.

[7] A. Bucchiarone, A. L. Lafuente, A. Marconi, and M. Pistore, “A formalisation

of adaptable pervasive flows,” in Proceedings of the 6th International Conference

on Web Services and Formal Methods, ser. WS-FM’09. Berlin, Heidelberg:

Springer-Verlag, 2010, pp. 61–75. [Online]. Available: http://dl.acm.org/citation.

cfm?id=1880906.1880910

[8] F. Zambonelli, N. Bicocchi, G. Cabri, L. Leonardi, and M. Puviani, “On Self-

adaptation, Self-expression, and Self-awareness in Autonomic Service Component

Ensembles,” in 2011 International Conference on Self-Adaptive and Self-Organizing

Systems Workshops. Ann Arbor (MC): IEEE CS Press, October 2011.

[9] “Objectives of the ascens project,” http://www.ascens-ist.eu/objectives, accessed:

2014-11-20.


http://docs.oasis-open.org/bpel4people/bpel4people-1.1.html

http://dl.acm.org/citation.cfm?id=1880906.1880910

http://dl.acm.org/citation.cfm?id=1880906.1880910

http://www.ascens-ist.eu/objectives


[10] A. Rowstron and P. Druschel, “Pastry: Scalable, decentralized object location, and

routing for large-scale peer-to-peer systems,” in Middleware 2001. Springer, 2001,

pp. 329–350.

[11] M. Castro, P. Druschel, A.-M. Kermarrec, and A. I. Rowstron, “Scribe: A large-

scale and decentralized application-level multicast infrastructure,” Selected Areas in

Communications, IEEE Journal on, vol. 20, no. 8, pp. 1489–1499, 2002.

[12] P. Mayer, A. Klarl, R. Hennicker, M. Puviani, F. Tiezzi, R. Pugliese, J. Keznikl, and

T. Bure, “The autonomic cloud: a vision of voluntary, peer-2-peer cloud computing,”

in Self-Adaptation and Self-Organizing Systems Workshops (SASOW), 2013 IEEE

7th International Conference on. IEEE, 2013, pp. 89–94.

[13] D. Chappell, Enterprise service bus. O’Reilly Media, Inc., 2004.

[14] C. consortium, “Immigrant paas technologies: Scientific and technical re-

port.” http://4caast.morfeo-project.org/wp-content/uploads/2011/02/D7.1.

1-M14-PU-Immigrant-PaaS-technologies-Scientific-and-technical-report.pdf, 2011.

[15] MuleSoft, “Mule ESB,” http://www.mulesoft.com/platform/soa/

mule-esb-open-source-esb, [Online; accessed September 2014].

[16] A. S. foundation, “Apache ServiceMix,” http://servicemix.apache.org/, [Online; ac-

cessed September 2014].

[17] R. H. JBoss, “JBoss ESB,” http://jbossesb.jboss.org/, [Online; accessed September

2014].

[18] W. Inc, “WSO2 Enterprise Service Bus,” http://wso2.com/products/

enterprise-service-bus/, [Online; accessed September 2014].

[19] 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


http://4caast.morfeo-project.org/wp-content/uploads/2011/02/D7.1.1-M14-PU-Immigrant-PaaS-technologies-Scientific-and-technical-report.pdf

http://4caast.morfeo-project.org/wp-content/uploads/2011/02/D7.1.1-M14-PU-Immigrant-PaaS-technologies-Scientific-and-technical-report.pdf

http://www.mulesoft.com/platform/soa/mule-esb-open-source-esb

http://www.mulesoft.com/platform/soa/mule-esb-open-source-esb

http://servicemix.apache.org/

http://jbossesb.jboss.org/

http://wso2.com/products/enterprise-service-bus/

http://wso2.com/products/enterprise-service-bus/

http://dx.doi.org/10.1007/978-3-319-06859-6_9

http://dx.doi.org/10.1007/978-3-319-06859-6_9


[20] H.-L. Truong, S. Dustdar, and K. Bhattacharya, “Conceptualizing and programming

hybrid services in the cloud,” International Journal of Cooperative Information Sys-

tems, vol. 22, no. 04, 2013.

[21] O. Scekic, M. Riveni, H.-L. Truong, and S. Dustdar, “Social interaction analysis

for team collaboration,” in Encyclopedia of Social Network Analysis and Mining,

R. Alhajj and J. Rokne, Eds. Springer New York, 2014, pp. 1807–1819. [Online].

Available: http://dx.doi.org/10.1007/978-1-4614-6170-8 257

[22] M. Candra, H.-L. Truong, and S. Dustdar, “Provisioning quality-aware social

compute units in the cloud,” in Service-Oriented Computing, ser. Lecture Notes

in Computer Science, S. Basu, C. Pautasso, L. Zhang, and X. Fu, Eds.

Springer Berlin Heidelberg, 2013, vol. 8274, pp. 313–327. [Online]. Available:

http://dx.doi.org/10.1007/978-3-642-45005-1 22

[23] M. Riveni, H.-L. Truong, and S. Dustdar, “On the elasticity of social

compute units,” in Advanced Information Systems Engineering, ser. Lecture

Notes in Computer Science, M. Jarke, J. Mylopoulos, C. Quix, C. Rolland,

Y. Manolopoulos, H. Mouratidis, and J. Horkoff, Eds. Springer International

Publishing, 2014, vol. 8484, pp. 364–378. [Online]. Available: http://dx.doi.org/10.

1007/978-3-319-07881-6 25

[24] S. Qanbari, F. Li, S. Dustdar, and T.-S. Dai, “Cloud asset pricing tree (capt) -

elastic economic model for cloud service providers.” in CLOSER, 2014, pp. 221–229.

[Online]. Available: http://dx.doi.org/10.5220/0004849702210229

[25] O. Scekic, H.-L. Truong, and S. Dustdar, “Incentives and rewarding in social

computing,” Commun. ACM, vol. 56, no. 6, pp. 72–82, Jun. 2013. [Online].

Available: http://doi.acm.org/10.1145/2461256.2461275

[26] ——, “Managing incentives in social computing systems with pringl,” in Web

Information Systems Engineering WISE 2014, ser. Lecture Notes in Computer

Science, B. Benatallah, A. Bestavros, Y. Manolopoulos, A. Vakali, and Y. Zhang,

Eds. Springer International Publishing, 2014, vol. 8787, pp. 415–424. [Online].

Available: http://dx.doi.org/10.1007/978-3-319-11746-1 30


http://dx.doi.org/10.1007/978-1-4614-6170-8_257

http://dx.doi.org/10.1007/978-3-642-45005-1_22

http://dx.doi.org/10.1007/978-3-319-07881-6_25

http://dx.doi.org/10.1007/978-3-319-07881-6_25

http://dx.doi.org/10.5220/0004849702210229

http://doi.acm.org/10.1145/2461256.2461275

http://dx.doi.org/10.1007/978-3-319-11746-1_30


Appendix


2nd Reading

December 24, 2013 11:8 WSPC/S0218-8430 111-IJCIS 1341003

International Journal of Cooperative Information SystemsVol. 22, No. 4 (2013) 1341003 (28 pages)c© World Scientific Publishing CompanyDOI: 10.1142/S0218843013410037

CONCEPTUALIZING AND PROGRAMMING HYBRID

SERVICES IN THE CLOUD

HONG-LINH TRUONG∗ and SCHAHRAM DUSTDAR†

Distributed Systems Group, Vienna University of TechnologyArgentinierstrasse 8/184-1, A-1040 Vienna, Austria

∗[email protected]†[email protected]

KAMAL BHATTACHARYA

IBM Research, Nairobi, Kenya, [email protected]

Received 10 March 2013Accepted 28 October 2013

Published 24 December 2013

For solving complex problems, in many cases, software alone might not be sufficient andwe need hybrid systems of software and humans in which humans not only direct thesoftware performance but also perform computing and vice versa. Therefore, we advocateconstructing “social computers” which combine software and human services. However,to date, human capabilities cannot be easily programmed into complex applications in asimilar way like software capabilities. There is a lack of techniques to conceptualize andprogram human and software capabilities in a unified way. In this paper, we explore anew way to virtualize, provision and program human capabilities using cloud computingconcepts and service delivery models. We propose novel methods for conceptualizing andmodeling clouds of human-based services (HBS) and combine HBS with software-basedservices (SBS) to establish clouds of hybrid services. In our model, we present com-mon APIs, similar to well-developed APIs for software services, to access individual andteam-based compute units in clouds of HBS. Based on that, we propose a frameworkfor utilizing SBS and HBS to solve complex problems. We present several programmingprimitives for hybrid services, also covering forming hybrid solutions consisting of soft-ware and humans. We illustrate our concepts via some examples of using our cloud APIsand existing cloud APIs for software.

Keywords: Hybrid services; cloud computing; human-based computation; service com-puting.

1. Introduction

Recently the concept of building “social computers” has emerged, in which the main

principle is to combine human capabilities and software capabilities into composite

applications solving complex problems.1,a In such types of computers, both software

∗Corresponding author.aThe Social Computer — Internet-Scale Human Problem Solving. socialcomputer.eu. Last access:3 May 2012.

1341003-1

2nd Reading


H.-L. Truong, S. Dustdar & K. Bhattacharya

and humans play equally roles: they direct/coordinate as well as perform tasks,

dependent on their capabilities and specific context. For example, (i) a software

can analyze an image and direct scientists to carry out a quality assessment of the

analysis result before sending the result to another software or (ii) a scientist can

direct a software to analyze high quality of images while asking another scientist

to judge if it makes sense to continue the analysis of images of low quality. While

such a combination in complex systems is not new, to build and program such

systems capable of supporting pro-active, highly-interactive, team-based human

computation under different elastic, pay-per-use models with on-demand (cloud)

software services in a unified way remains challenging.

To date, concrete technologies have been employed to provide human capabili-

ties via standard, easy-to-use interface, such as Web services and Web platforms2,3,b

and some efforts have been devoted for modeling and coordinating flows of human

works in the process/workflow level.4,5 In all these works, a fundamental issue is

how to utilize human capabilities. We observed two main approaches in utilizing

human capabilities: (i) passively proposing tasks and waiting for human input,

such as in crowd platforms,3 and (ii) actively finding and binding human capabili-

ties into applications. While the first one is quite popular and has many successful

applications,3,6–9 it mainly exploits individual capabilities and is platform-specific.

In the second approach, it is difficult to proactively invoke human capabilities in

Internet-scale due to the lack of techniques and systems supporting proactive uti-

lization of human capabilities.1 From a programming perspective, currently, most

techniques concentrate on workflow-based solutions in which the workflow engine

can find suitable humans and assign the tasks to them. However, many complex

problems requiring both humans and software cannot be solved by using current

workflow-based solutions, as these problems demand flexible interactions among

humans and software services.

In this paper, we conceptualize human capabilities under the service model and

combine them with software to establish clouds of hybrid human- and software-

based services (HBS and SBS). This enables the provisioning of a large-scale number

of HBS together with SBS. Our approach aims at exploring novel ways to actively

program and utilize human capabilities in a similar way to software services and to

provision human capabilities using cloud service and deployment models for high

level frameworks and programming languages to build “social computers”.

1.1. Motivation

Several works have shown that we need to integrate further humans and software

under the service model.1,10 Hybrid services, in our notion, include SBS and HBS.

We argue that we could provide a cloud of HBS working in a similar manner to

bWS-BPEL Extension for People (BPEL4People) Specification Version 1.1, November 2009.http://docs.oasis-open.org/bpel4people/bpel4people-1.1-spec-cd-06.pdf.

1341003-2

2nd Reading


Conceptualizing and Programming Hybrid Services in the Cloud

contemporary clouds of SBS (such as Amazon services and Microsoft Azure ser-

vices) so that HBS can be invoked and utilized in a proactive manner, rather than

in a passive way like in existing crowdsourcing platforms. Furthermore, HBS can

be programmed together with SBS in a composite application, enabling complex,

dynamic interactions between SBS and HBS, instead of being used separately from

SBS as in contemporary crowdsourcing platforms and workflows without/with little

interactions.

Our goal is to program HBS and SBS together in an easier way because several

complex applications need to utilize SBS and HBS in a similar way. For example,

several Information Technology (IT) problems, such as in incident management for

IT systems, software component development, and collaborative data analytics, can

be described as a dependency graph of tasks in which a task represents a unit of work

that should be solved by a human or a software. Solving a task may need to con-

currently consider other relevant tasks in the same graph as well as introduce new

tasks (this, in turns, expands the task graph). Utilizing team and hybrid services is

important here as tasks are interdependent, but unlike crowdsourcing scenarios in

which different humans solving different tasks without the context of teamwork and

without the connectedness to SBS. Teamwork is crucial as it allows team members

to delegate tasks when they cannot deal with the task as well as newly tasks can be

identified and created that need to be solved. SBS for teamwork is crucial for team

working platforms in terms of communication, coordination, and analytics. There-

fore, it is crucial to have solutions to provision individual- and team-based human

capabilities under clouds of human capabilities, in parallel with the provisioning

of SBS.

These clouds require novel service models and infrastructures to provide and

support on-demand and elastic HBS provisioning. We need solutions allowing us to

buy and provision human capabilities via simple interfaces in a similar way to buy-

ing and provisioning virtual machines in contemporary clouds of Infrastructure-as-a-

Service (IaaS) and Software-as-a-Service (SaaS). By doing so, we could incorporate

human capabilities in programming paradigms for “social” computers. However, so

far, to our best knowledge, there is no proposed solution towards a cloud model for

human capabilities that enables us to acquire, program, and utilize HBS in a similar

way to that of IaaS, Platform-as-a-Service (PaaS) and SaaS. Existing technologies

are not adequate, for example, workflow and language extensions and social comput-

ing platforms are focused too much on crowdsourcing models. The way to program

human capabilities in contemporary workflows and crowdsourcing platforms is that

either tasks are published for humans to bid them (e.g. in most crowdsourcing

platforms) or tasks are directly mapped to humans by the workflow engines (e.g.

in human-centric workflows). While the first mechanism allows people to select the

task, it do not encourage people to interact together to solve the task. In the second

mechanism, it is possible that the workflow engine actively matches suitable people

to tasks, (although currently such workflow engines are not popular and they tend

to search people only within local organizations). However, still human capabilities

1341003-3

2nd Reading



are utilized in a passive way, e.g. humans are assigned to tasks or perform simple

control activities (e.g. approving a task). Furthermore, with current workflows, it is

difficult to utilize large-scale human capabilities in a dynamic, selective way due to

the lack of APIs to invoke human services. Furthermore, workflow-based solutions

exploiting human capabilities focus on the way to define how the tasks should be

done but not how can we provision humans and software in a unified manner so

that both humans and software can act as computing units of a single “social com-

puter”. Overall, programming flexible and dynamic relationships among software

and humans are not well supported, thus hindering the incorporation of human

services into programming paradigms.

1.2. Approach

To incorporate humans into programming paradigms, our approach aims at tackling

the following issues from different aspects:

• Programming languages: First of all, we need to abstract human capabilities under

compute units and provision them under service units10 so that they can be

easily incorporated into high-level program elements and constructs. Second, we

can extend existing programming languages to support human compute units.

Finally, we need to enable different data and control flows among software and

human service units via extensible APIs and develop new APIs to support other

types of flows among software and human service units.

• Multiple programming models: By utilizing human service units as programming

elements/constructs, we could support different programming models, such as

shared memory, message passing, and artifact-centric models via APIs working

atop the service unit abstraction. Furthermore, contemporary workflow languages

can be extended to exploit large-scale HBS.

• Execution environments: We will need to develop several components for man-

aging provisioning of HBS and the interaction of humans with HBS abstracting

them. First computing capability/profile management will allow us to concep-

tualize and define computing power, pricing and incentive models. We need to

monitor and enforce incentives/rewards, quality of results, availability, to name

just a few. Several way of communication between different structures of HBS

and SBS must be supported.

In this paper, we will focus on abstracting and conceptualizing HBS and clouds

of HBS, providing APIs and presenting basic programming techniques for hybrid

services.

1.3. Contributions and paper structure

We concentrate on conceptualizing the cloud of HBS and how clouds of HBS and

SBS can be programmed for solving complex problems. Our main contributions

1341003-4

2nd Reading



are:

• a novel model for clouds of HBS and hybrid services provisioning,

• a framework for solving complex problems using clouds of hybrid services,

• programming primitives for hybrid services.

To illustrate our work, we present several examples of how to program software-

based services and HBS in a unified way. This paper substantially extends the work

described in Ref. 11. We have added our approach (Sec. 1.2), substantially detailed

the concepts of hybrid services and extended them to cover also other aspects like

archetypes and incentives (in Sec. 2). We have added a conceptual architecture

of IaaS of hybrid services (in Sec. 2.5). We also extend programming primitives by

detailing our techniques, discuss how our framework can be used to implement HBS

provisioning platforms, and elaborate the related work.

The rest of this paper is organized as follows. Section 2 discusses our model of

clouds of hybrid services. Section 3 describes a generic framework utilizing hybrid

services. Section 4 presents programming primitives utilizing clouds of hybrid ser-

vices. Section 5 discusses related work. Section 6 concludes the paper and outlines

our future work.

2. Conceptualizing Clouds of Hybrid Services

2.1. Clouds of hybrid services

In our work, we consider two types of computing elements: software-based comput-

ing elements and human-based computing elements. In software-based computing

elements, different types of services can be provided to exploit machine capabilities

and we consider these types of services under the SBS category. Similarly, human-

based computing elements can also offer different types of services under the HBS

category.

Definition 2.1 (Cloud of HBS). A cloud of HBS includes HBS that can be pro-

visioned, deployed and utilized on-demand based on different pricing and incentive

models.

Models for SBS and their clouds are well defined.12 By combining SBS with our

model for HBS, we consider a cloud of hybrid services as follows:

Definition 2.2 (Cloud of hybrid services). A cloud of hybrid services includes

SBS and HBS that can be provisioned, deployed and utilized on-demand based on

different pricing and incentive models.

In principle, a cloud of hybrid services can also be built atop clouds of SBS and

clouds of HBS (by employing concepts for federated clouds). As SBS and clouds of

SBS are well researched, in the following we will discuss models for clouds of HBS

and of hybrid services.

1341003-5

2nd Reading



2.2. Models for HBS

Human capabilities can be provisioned under the service model, e.g. our previous

work introduced techniques for offering individual human capabilities under Web

services.2 However, at the moment, there exists no cloud system that the con-

sumer can program HBS in a similar way like IaaS (e.g. Amazon EC) or data (e.g.

Microsoft Azure Data Marketplace). Before discussing how clouds of hybrid services

can be designed and used, we propose a conceptual model for clouds of HBS that

cover the following aspects: (i) communication interfaces, (ii) human power unit

(HPU), (iii) HBS archetypes, and (iv) pricing and incentive models.

2.2.1. HBS communication interfaces

Humans have different ways to interact with other humans and ICT systems. Con-

ceptually, we can assume that HBS (and corresponding HBS clouds) abstracting

human capabilities can provide different communication interfaces to handle tasks

based on a request and response model. Requests can be used to describe tasks/mes-

sages that an HBS should perform or receive. In SBS, specific request representa-

tions (e.g. based on XML) are designed for specific software layers (e.g. application

layer, middleware layer, or hardware layer). In HBS we can assume that a single

representation can be used, as HBS does not have similar layer structures seen in

SBS (at the end only humans will understand and process the messages), while the

message content can be defined based on application needs. Requests in HBS can,

therefore, be composed and decomposed into different (sub)requests. The use of the

request/response model will facilitate the integration between SBS and HBS as via

similar service APIs.

Unlike SBS in which communication can be synchronous or asynchronous, in

HBS all communication is asynchronous. Clearly, the reason is that the semantics

of human-level communication messages, the way of how the human takes the

messages, and the high latency of communication between a requester (whether

it is a HBS or SBS) to a HBS prevent synchronous communication in which an

HBS is expected to process the messages and send responses at the same time. In

general, the upper bound of the communication delay in and the internal request

processing mechanism in HBS are unknown (and these issues are not in the focus

of this paper). However, HBS intercommunication can be modeled using the well-

known message passing and shared memory models:

• Message passing: Message-passing in which two HBS can directly exchange

requests: hbsi →request

hbsj . One example is that hbsi sends a request via SMS

to hbsj. Similarly, an SBS can also send a request directly to an HBS.

• Shared memory: Shared-memory in which two HBS can exchange requests via

a SBS. For example, hbsi stores a request into a Dropboxc directory and hbsj

cwww.dropbox.com.

1341003-6

2nd Reading



Fig. 1. Message passing and shared-memory communication models for services in clouds of HBSand SBS.

obtains the request from the Dropbox directory. Similarly, an SBS and HBS can

also exchange requests/responses via an SBS or an HBS (e.g. a software can

be built atop Dropbox to trigger actions when a file is stored into a Dropbox

directory (see http://www.wappwolf.com)).

Figure 1 describes possible message passing and shared-memory communication

models for services in cloud of HBS and SBS. Message-passing middleware can be

further divided into different channels implemented by different services, e.g. Short

Message Service (SMS) and Instant Messaging (IM) are dedicated for humans, while

Message-oriented Middleware (MOM) can be used for both SBS and HBS. In par-

ticular, the implementation of communication channels for HBS — among humans

and cloud middleware — can benefit from well-researched collaboration services.13

Similarly, the shared-memory middleware can be built based on different services,

offering different types of “shared-memory”, such as file-based shared memory, like

Dropbox and Amazon S3,d and database-based shared memory, like MongoDBe

and AmazonDynamoDB.f Both message-passing and shared-memory communica-

tion middleware can be used internally for services within a cloud or externally for

the communication between service consumers and services within clouds. Concep-

tually, we could have all of these middleware under the same set of APIs. In both

communication models, the structures of messages sent to HBS are designed for

human comprehension.

Similarly to machine instances which offer facilities for remote job deployment

and execution, an HBS communication interface can be used to run requests/jobs

on HBS.

2.2.2. Human power unit (HPU)

The first issue is to define a basic model for describing the notion of “computing

power” of HBS. Usually, the computing capability of a human-based computing

dhttp://aws.amazon.com/s3/.ehttp://www.mongodb.org/.fhttp://aws.amazon.com/dynamodb/.

1341003-7

2nd Reading



element is described via human skills and skill levels. Although there is no standard

way to compare skills and skill levels described and/or verified by different people

and organizations, we think that it is feasible to establish a common, comparative

skills for a particular cloud of HBS.

• The cloud can enforce different evaluation techniques to ensure that any HBS in

its system will declare skills and skill levels in a cloud-wide consistency. This is,

for example, similar to some crowdsourcing systems which have rigorous tests to

verify claimed skills.

• The cloud can use different benchmarks to test humans to validate skills and skill

levels. Each benchmark can be used to test a skill and skill level. This is, e.g.

similar to Amazon which uses benchmarks to define its elastic compute unit.

• The cloud can map different skills from different sources into a common view

which is consistent in the whole cloud.

We define HPU for an HBS as follows:

Definition 2.3 (Human Power Unit). HPU is a value describing the computing

power of an HBS measured in an abstract unit. A cloud of HBS has a pre-defined

basic power unit, hpuθ, corresponding to the baseline skill bsθ of the cloud.

Without the loss of generality, we assume hpuθ = f(bsθ). A cloud C provisioning

HBS can support a set of n skills SK = {sk1, . . . , skn} and a set of m cloud skill

levels SL = {1, . . . , m}. C can define the HPU wrt ski for slj as follows:

hpu(ski, slj) = hpuθ × f

(ski

bsθ

)× slj. (1)

Here f( ski

bsθ) indicates a way to determine a weighted factor when comparing the skill

ski against the baseline bsθ. For the cloud C, f( ski

bsθ) is known and pre-defined (based

on the definition of SK). For example, let bsθ the basic Testing skill, ski be the basic

UnitT esting skill and skj be the basic IntegrationTesting skill, f(UnitTestingTesting ) = 2

and f( IntegrationTestingTesting ) = 8 could be very simple examples.

Given the capability of an hbs – CS(hbs) = {(sk1, sl1), . . . , (sku, slu)} – the

corresponding HPU can be calculated as follows:

hpu(CS(hbs)) =

u∑

i=1

hpu(ski, sli). (2)

Note that two HBS can have the same hpu value, even if their skills are different.

To distinguish them, we propose to use a set of “architecture” types (see Sec. 2.2.3).

Given a human offering her capabilities to C, she can be used exclusively or shared

among different consumers. In case an hbs is provisioned exclusively for a particular

consumer, the hbs can be associated with a theoretical utilization u — describing

the utilization of a human — and CS(hbs); its theoretical HPU would be u ×hpu(CS(hbs)). In case a hbs is provisioned for multiple consumers, the hbs can

be described as a set of multiple instances, each has a theoretical power as ui ×

1341003-8

2nd Reading



hpu(CSi(hbs)) where u =∑

(ui) ≤ 1 and CS(hbs) = CS1(hbs) ∪ CS2(hbs) ∪ · · · ∪CSq(hbs) .

Using this model, we can determine theoretical power for individual HBS as well

as for a set of individual HBS. Note that the power of a set of HBS may be more than

the sum of power units of its individual HBS, due to teamwork. However, we can

assume that, similar to individual and cluster of machines, theoretical power units

are different from the real one and are mainly useful for selecting HBS and defining

prices. Given a human offering her capabilities to C, she can be used exclusively or

shared among different consumers.

2.2.3. HBS archetype

As an HBS can potentially offer different capabilities, similar to SBS, an HBS can

be considered to offer a set of types of solutions for a set of domains. For example,

an HBS can offer a set of solutions as

SO = {({WebDataAnalytics, TwitterAnalytics}, DataAnalytics),

({DataCleansing, DataEnrichment}, DataQualityImprovement)},

where

{WebDataAnalytics, TwitterAnalytics, DataCleansing, DataEnrichment}are types of solutions and {DataAnalytics, DataQualityImprovement} are

domains. Therefore, an HPU of an HBS can be associated with types of solutions

and domains to indicate the processing capability of the HBS for a specific solution

in a specific domain. To allow this association, we propose to use a set of common

“architecture” types, called Archetype, to indicate the type of solutions in a partic-

ular domain that the HPU is determined. This is similar to, e.g. different types of

instruction set architectures (such as ×86, SPARC, and ARM).

2.2.4. Pricing and incentive models

As we have observed, SBS often comes with pricing models but many of SBS are

also given free, in particular, in volunteering and peer-to-peer computing systems,14

due to different incentives. Similarly, in crowdsourcing, free human efforts are quite

popular.15–18 In the case of HBS, it is obvious that pricing models will need to

be identified for HBS, e.g. by the HBS cloud provider in agreement with the HBS

provider or other methods.19 However, an HBS can also declare itself as a free

service while it may require rewards when using it via some incentive models.g

gIn literature, many incentive models give rewardss of monetary values. Furthermore, in volun-teering computing, there exits the concept of “pay for participation”. For the sake of simplicity,we consider all monetary values under pricing models because, although in principle unlike ser-vices with commercial intention, these services impose some monetary pricing models that onehas to pay when using the services. In other words, incentive models in our cloud HBS rewardsnon-monetary values, such as reputation.

1341003-9

2nd Reading



Therefore, in our model, each HBS will be associated with a set of pricing

models and incentive models. This is different from SBS which is associated with

pricing models, but not with incentive models. Note that for pricing and incentive

models, there must be techniques to support billing and incentive enforcement.

However, similar to software systems, such billing and incentive enforcement can

be decoupled. For example, when an HBS is utilized and we need to reward it,

the consumer or the provider can send its results to an incentive system, which

calculates and performs payments.

2.3. HBS instances provisioning

2.3.1. Types of HBS instances

For HBS we will consider two types of instances:

Definition 2.4 (Individual Compute Unit instances (iICU)). iICU describe

instances of HBS built atop capabilities of individuals. An individual can provide

different iICU. Analogous to SBS, an iICU is similar to an instance of a virtual

machine or a software.

Definition 2.5 (Social Compute Unit instances (iSCU)). iSCU describe

instances of

HBS built atop capabilities of multiple individuals and SBS. Analogous to SBS,

an iSCU is similar to a virtual cluster of machines or a complex set of software

services.

In our approach, iICU is built based on the concept that an individual can

offer her capabilities via services2 and iSCU is built based on the concept of Social

Compute Units20 which represents a team of individuals.

2.3.2. HBS instance description

Let C be a cloud of hybrid services. All services in C can be described as follows:

C = HBS ∪ SBS where HBS is the set of HBS instances and SBS is the set of

SBS instances. The model for SBS is well known in contemporary clouds and can

be characterized as SBS(capability, price). The provisioning description models for

HBS instances are proposed as follows:

• For an iICU its provisioning description includes (CS, HPU, price, incentive,

utilization, location, APIs).

• For an iSCU its provisioning description includes (CS, HPU, price, incentive,

utilization, connectedness, location, APIs).

From the consumer perspective, iSCU can be offered by the cloud provider or the

consumer can build its own iSCU . In principle, in order to build an SCU, the

provider or the consumer can follow the following steps: first, selecting suitable

1341003-10

2nd Reading



iICU for an iSCU and, second, combining and configuring SBS to have a working

platform for iSCU . The connectedness reflects the intercommunication topology

connecting members of iSCU , such as ring, star, and master-slave, typically con-

figured via SBS. APIs describe how to communicate to and execute requests on

HBS. Moreover, similar to SBS, HBS can also be linked to user rating information,

often managed by third-parties.

2.3.3. Pricing factors

Similar to existing SBS clouds, we propose clouds of HBS to define different pricing

models for different types of HBS instances. The baseline for the prices can be based

on hpuθ. We propose to consider the following specific pricing factors:

• Utilization: Unlike individual machines whose theoretical utilization when selling

is 100%, ICU has much lower theoretical utilization, e.g. normal full time people

have a utilization of 33.33% (8 h per day). However, an SCU can theoretically

have 100% utilization. The real utilization of an HBS is controlled by the HBS

rather than by the consumer as in machine/software instances.

• Offering communication APIs: It is important that different communication capa-

bilities will foster the utilization of HBS. Therefore, the provider can also bill con-

sumers based on communication APIs (e.g. charge more when SMS is enabled).

• Connectedness: Similar to capabilities of (virtual) networks between machines

in a (virtual) cluster, the connectedness of an iSCU will have a strong impact

on the performance of iSCU . Similar to pricing models in existing collaboration

services,h the pricing factor for connectedness can be built based on which SBS

and collaboration features are used for iSCU.

Furthermore, other conventional factors used in SBS such as usage duration and

location are considered.

2.3.4. Incentive factors

Incentive factors for ICU are determined by the ICU and/or the HBS cloud provider.

This can be done when the ICU is registered and provisioned under the cloud. When

enforcing the incentive models of ICU, obviously all incentives must be attributed

to the ICU. For SCU it is dependent on how the SCU is structured and the incentive

strategies for the SCU are implemented. Thus, when building an SCU, its incentive

strategies can also be programmed, e.g. using incentive programming frameworks,21

to allow the rewards for the whole SCU to be distributed to members of the SCU

in the right way. Overall, the enforcement of incentive models will be carried out

by the provider of HBS clouds.

hSuch as in Google Apps for Business (http://www.google.com/enterprise/apps/business/pricing.html).

1341003-11

2nd Reading



2.4. Cloud APIs for provisioning hybrid services

Services in a cloud of hybrid services can be requested and provisioned on-demand.

As APIs for provisioning SBS are well developed, we will focus on APIs for provi-

sioning HBS. Table 1 describes some abstract APIs that we develop for HBS in our

Vienna Elastic Computing Model.i These abstract APIs are designed in a similar

manner to common APIs for SBS.

Figure 2 shows main Java-based classes for APIs. HPU, HBS, ICU and SCU

are described by HPU, HBS, ICU and SCU classes, respectively. Requests and mes-

sages for HBS are described by (HBSRequest and HBSMessage), while skills and

skill levels are described Skill and SkillLevel. The cloud skills, described

in CloudSkill, are built from Skill and SkillLevel. HBS and SBS are sub-

classes of Unit which represents generic service units. Unit is associated with

Cost, describing cost models, and Benefit, describing incentive models and other

Table 1. Main (abstract) APIs for provisioning HBS.

APIs Description

APIs for service information and management

listSkills ( );listSkillLevels( ) List all pre-defined skills and skill levels of cloudslistICU( );listSCU( ) List all iICU and iSCU instances that can be used. Different

filters, e.g. based on pricing/incentive, location, and skills,can be applied to the listing.

negotiateHBS( ) Allow a consumer to send and negotiate service contract with aniICU or an iSCU . In many cases, the cloud can just give theservice contract and the consumer has to accept it (e.g.similar to SBS clouds) if the consumer wants to use the HBS.

startHBS( ) Allow a consumer to start an iICU or an iSCU . Via this API,the consumer sends message to the HBS cloud which, amongother activities, passes a notification to the HBS that theHBS is being used from the consumer perspective. Dependingon the provisioning contract, the usage can be time-based(subscription model) or task-based (pay-per-use model).

suspendHBS ( ) Allow a consumer to suspend the operation of an iICU oriSCU . Note that in suspending mode, the HBS is notreleased for other consumers yet.

resumeHBS ( ) Allow a consumer to resume the work of an iICU or iSCU .stopHBS( ) Allow a consumer to stop the operation of an iICU or iSCU .

By stopping the HBS is no longer available for the consumer.reduceHBS( ) Reduce the capabilities of iICU or iSCU , for example, reduce

the power unit and some specific communication APIs.expandhbs( ) Expand the capabilities of iICU or iSCU , for example, reduce

the power unit and some specific communication APIs.

APIs for service execution and communication

runRequestOnHBS( ) Execute a request on an iICU or iSCU . By execution, the HBSwill receive requests from the consumers and perform them.

receiveResultFromHBS( ) Receive the result from an iICU or iSCU .sendMessageToHBS( ) send (support) messages to HBS.receiveMessageFromHBS( ) receive messages from HBS.

idsg.tuwien.ac.at/research/viecom.

1341003-12

2nd Reading



Fig. 2. Example of some Java-based APIs for clouds of HBS.

1341003-13

2nd Reading



types of benefits. The VieCOMHBSImpl class describes the collection of APIs that

can be used to discover and invoke HBS, as described in Table 1. Currently,

we simulate our cloud of HBS. The HBS can be accessed via APIs described

in VieCOMHBSImpl. For SBS, we use existing APIs provided by cloud providers

and common client APIs libraries, such as JClouds (www.jclouds.org) and boto

(http://docs.pythonboto.org/en/latest/index.html).

These APIs provide different ways to acquire and interact with HBS. How the

HBS’s performance management is supported despite the fact these APIs do not tell

if the HBS really continues to work even though being suspended via APIs. From

the consumer perspective, the HBS will receive corresponding requests (based on

APIs) and s/he will understand what the messages mean. In principle the HBS

should follow the messages requested by the consumer but whether the HBS really

follows the request or not is a different aspect, as humans may not necessary strictly

follow requests, even they must be. What happens inside an HBS work cannot be

controlled by the cloud. However, two possibilities could be supported. First, the

cloud of HBS can control the quality of HBS and decide how to utilize the HBS

based on quality of results (e.g. time, cost and quality of data) delivered by the

HBS. Similarly, the consumer can also control the quality of the HBS the consumer

pays for. These control mechanisms are complex enough for being out of this paper

scope and we have developed some solutions in Ref. 22. Still, due to the nature

of human works, not all human activities within the HBS can be measured and

controlled.

2.5. Conceptual architecture for hybrid unit as a service

Based on the conceptual models of clouds of hybrid services, we describe a con-

ceptual architecture for establishing a cloud of hybrid services. Figure 3 outlines

our conceptual architecture for provisioning and programming hybrid service units.

At the lowest level, software, people and things can be provisioned by interfacing

and integrating them to the Service-based Middleware. Using this middleware, we

enable different types of integration for software, people and things due to their dif-

ferent interaction models. The Service-based Middleware basically provisions HBS

and SBS to the consumer via programmable, extensible APIs, e.g. based on the list

of APIs that we present in Sec. 2.4. The Service-based Middleware utilizes our con-

cepts by abstracting software, things and people using SBS and HBS unit model.

This allows consumers to access software, people and things via a uniform way in

which SBS and HBS will be mapped to underlying software, things, and people. To

ensure the proper operations of this cloud, we need to implement Runtime Mon-

itoring and Enforcement (e.g. for monitoring and enforcing costs, incentives and

quality), Communication (e.g. for supporting the communication among HBS and

SBS), Service Life-cycle Management (e.g. for supporting HBS selection and for-

mation), and Capability/Profile Management (e.g. for managing service capabilities

and HPU).

1341003-14

2nd Reading



Fig. 3. Conceptual architecture for provisioning hybrid SBS/HBS services.

The Service-based Middleware will be the core of a hybrid service provisioning

platform. Atop this, one can program HBS and SBS by using Provisioning/Negotia-

tion/Communication Cloud APIs. In the next sections, we describe some utilization

possibilities and how to program hybrid services.

3. Framework for Utilizing Hybrid Services

By utilizing hybrid services in clouds, we could potentially solve several complex

problems that need both SBS and HBS. In our work, we consider complex problems

that can be described under dependency graphs. Let DG be dependency graph of

tasks to be solved. It can be provided or extracted automatically. In order to solve

a task t ∈ DG, we need to determine whether t will be solved by SBS, HBS or

their combination. For example, let t be a virtual machine failure and the virtual

machine is provisioned by Amazon EC2. Two possibilities can be performed: (i)

request a new virtual machine from Amazon EC and configure the new virtual

machine suitable for the work or (ii) request an HBS to fix the virtual machine.

In case (i) SBS can be invoked, while for case (ii) we need to invoke an HBS which

might need to be provisioned with extra SBS for supporting the failure analysis.

1341003-15

2nd Reading



Our approach for utilizing hybrid services includes the following points:

• Link tasks with their required HPUs via skills and skill levels, before programming

how to utilize HBS and SBS.

• Form or select suitable iSCU or iICU for solving tasks. Different strategies will

be developed for forming or selecting suitable iSCU or iICU , such as utilizing

different ways to traverse the dependency graph and to optimize the formation

objective.

• Program different strategies of utilizing iSCU and iICU , such as considering the

elasticity of HBS due to changes of tasks and HBS. This is achieved by using

programming primitives and constructs atop APIs for hybrid services.

Figure 4 describes the conceptual architecture of our framework for solving com-

plex problems. Given a task dependency graph, we can detect changes in required

human computing power by using Task Change Management. Detected required

power changes will be sent to Change Adaptation, which in turns triggers different

operations on HBS usage, such as creating new HBS or adapting an existing HBS.

These operations are carried out by the HBS Formation service which implements

and integrates different algorithms for handling requests of HBS, each suitable for

specific situations. Change Adaptation also decides whether a change should be

applied to SBS by sending change request to the SBS Adaptation service which will

perform the change and modify the task graph accordingly. When an HBS deals

with a task graph, the HBS can change the task graph and its required HPUs (this

will trigger HBS operations again). During the solving process, HBS can change

and this can be detected by HBS Change Management. The HBS change will be

sent to Change Adaptation.

HBS Formation

description

HBS Change Management

Task Change Management

solve tasks

Change Adaptation

change detection

changerequest HBS

create/modify

iICU|iSCUchange detection

change

algo

algo

algo

human power unithuman power

unit

SBS Adaptation

cloud of hybrid services

description

task dependency

Fig. 4. Conceptual architecture.

1341003-16

2nd Reading



At the time of writing, we have developed an SCU provisioning platform for

forming, managing and controlling quality of SCUs for independent tasks.22 This

platform utilizes HBS from simulated ICU clouds based our concepts and APIs to

form quality-aware SCUs and we also developed elasticity rules for adapting ICU

and SBS.23 The SCU expansion and reduction for dependent and evolving tasks

are currently being prototyped. In the next section, we explain some concepts of

programming hybrid services that are the key elements of the architecture depicted

in Fig. 4.

4. Programming Hybrid Services

In this section, we discuss some programming primitives for hybrid services that can

be applied to the complex framework that we mentioned before. Such primitives can

be used in different components, such as HBSFormation and ChangeAdaptation,

in our framework described in Fig. 4. In illustrating programming examples, we

consider a virtualized cloud of hybrid services that are built on top of our cloud

of HBS and real-world clouds of SBS. Consequently, we will combine our APIs,

described in Sec. 2.4, with existing client cloud API libraries. Our goal in this section

is not to present specific algorithms, e.g. for HBSFormation, adaptation strategies,

e.g. for ChangeAdaptation, or specific applications to solve specific tasks. Instead,

we present how different algorithms, strategies or applications could be developed

and integrated into our framework.

4.1. Modeling HPU-aware task dependency graphs

4.1.1. Task dependency graphs

Our main idea in modeling HPU-aware task dependencies is to link tasks that are

required for management skills and compliance constraints:

• human resource skills: Represent skill sets that are required for dealing with

problems/management activities;

• constraints: Represent constraints, such as resource locations, governance compli-

ance, time, cost, etc. that are associated with management activities and humans

dealing with these activities.

Given a dependency graph of tasks, these types of information can be provided

manually or automatically (e.g. using knowledge extraction). Generally, we model

dependencies among tasks and required skills and compliance constraints as a

directed graph G(N, E) where N is a set of nodes and E is a set of edges. A

node n ∈ N represents a task or required skills/compliance constraints, whereas an

edge e(ni, nj) ∈ E means that nj is dependent on ni (ni can cause some effect on

nj or ni can manage nj). Edges may be associated with weighted factors to indicate

the importance of edges. The required skills, compliance constraints and weighted

1341003-17

2nd Reading



lotusdomino

was

is Deployed On

Business Applications Services

supported By Emailand Collaboration Services

supported By

aix

is Deployed On

db2

depends On supported By

Web Middle ware

supported By

emcbackup

depends On

Platform Support Unix

supported By

nasbox

depends On

network

depends On

Database Management

supported By

Storage DASD Backup Restore

supported Bydepends On supported Bysupported By

Network Service

supported By

Fig. 5. An example of HPU-aware dependency graph. A component box describes a software andits problems (ITProblem node). An eclipse describes management skills (Management node).

factors will be used to determine the required HPU for a task, to select iICU and

members for iSCU , and to build the connectedness for SCUs.

4.1.2. Examples and implementation

Figure 5 presents an example of a dependency graph of an IT system linked to

management skills. In this system, we have a LotusDomino system (described by

lotusdomino) deployed in a Web Application Server (described by was). The Web

Application Server is deployed on an AIX server (described by aix) and depends on

a DB2 server (described by db2). The DB2 server depends on a NAS box (described

by nasbox) and a network (described by network). The AIX server is dependent

on an EMC backup system (described by emcbackup) which depends on network.

Each software node in the IT system has different requirements for HBS in order

to solve IT problems arisen.

In our implementation of dependency graph, we use JGraphT.j We define two

main types of Node — ITProblem and Management. All relationships are depen-

dency. It is also possible to use TOSCA24 to link people skills and map TOSCA-

based description to JGraphT.

4.2. Combining HBS and SBS

Combining HBS and SBS is a common need in solving complex problems (e.g. in

evaluating quality of data in simulation workflows). In our framework, this feature

can be used for preparing inputs managed by SBS for an HBS work or managing

outputs from HBS work. Furthermore, it can be used to provision SBS as utilities

jhttp://jgrapht.org/.

1341003-18

2nd Reading



for HBS work (e.g. requiring HBS to utilize specific SBS in order to produce the

result where SBS is provisioned by the consumer).

Example: Listing 1 shows an example of programming a combination of HBS and

SBS for a task using our cloud APIs and JClouds. In this example, we want to

invoke Amazon S3 to store a log file of a Web application sever and invoke an HBS

to find problems. Using this way, we can also combine HBS with HBS and of course

SBS with SBS from different clouds.

// us ing JClouds APIs to s t o r e l o g f i l e o f web a pp l i c a t i o n

server

BlobStoreContext context = new

BlobStoreContextFactory ( ) . c r eateContext ("aws-s3" ,"REMOVED" ,

"REMOVED" ) ;

BlobStore b lobStore = context . ge tBlobStore ( ) ;

// . . . . and add f i l e in t o Amazon S3

Blob blob = blobStore . b lobBui lder ("hbstest" ) . bu i ld ( ) ;

blob . setPayload (new F i l e ("was.log" ) ) ;

b lobStore . putBlob ("hbstest" , blob ) ;

S t r ing u r i = blob . getMetadata ( ) . g e tPub l i cUr i ( ) . t oSt r ing ( ) ;

VieCOMHBS vieCOMHBS = new VieCOMHBSImpl ( ) ;

//assume t ha t WM6 i s the HBS t ha t can analyze the Web

Middleware problem

vieCOMHBS. startHBS("WM6" ) ;

HBSRequest r eque s t = new HBSRequest ( ) ;

r eque s t . s e tDe s c r i p t i on ("Find possible problems from " +

ur i ) ;

vieCOMHBS. runRequestOnHBS ("WM6" , r eque s t ) ;

Listing 1. Example of HBS combined with SBS.

4.3. Forming and configuring iSCUs

A cloud provider can form an iSCU and provide it to the consumer as well as a

consumer can select iICU and SBS to form an iSCU . An iSCU not only includes

HBS (iICU or other sub iSCU) but also consists of possible SBS for ensuring the

connectedness within iSCU and for supporting the work and interaction within the

iSCU . There are different ways to form SCUs. In the following, we will describe

some approaches for forming SCUs to solve a dependency graph of tasks.

4.3.1. Selecting resources for iSCU

Figure 6 describes a general concept of how iSCU forming algorithms work. To

form an iSCU, we need to consider both Business-as-Usual (BAU) and corrective

1341003-19

2nd Reading



Fig. 6. General model for forming iSCU.

action (CA) cases. Given a task t ∈ DG, our approach in dealing with t is that

we do not just simply take required management resources suitable for t but we

need to consider possible impacts of other tasks when solving t and the chain

of dependencies. To this end, we utilize DG to determine a set of suitable human

resources to deal with t and t’s possible impact. Such human resources establish HBS

capabilities in an iSCU . Overall, the following steps are carried out to determine

required SCU:

• Step 1: Determine DGBAU ⊆ DG where DGBAU includes all tj ∃ a walk (tj , t),

tj is the task that must be dealt together with t in typical BAU cases.

• Step 2: Determine DGCA ⊆ DG that includes tasks that should be taken into

account under CA cases. DGCA = {tr} ∃ a walk(tr, tj) with tj ∈ DGBAU .

• Step 3: Merge DGSCU = DGBAU ∪ DGCA by (re)assigning weighted factors to

links between (tk, tl) ∈ DGSCU based on whether (i) tk and tl belong to DGBAU

or DGCA, (ii) reaction chain from t to tk or to tl and (iii) the original weighted

factor of links consisting of tk or tl.

• Step 4: Traverse DGSCU , ∀ti ∈ DGSCU , consider all (ti, ri) where ri

is management resource node linking to ti in order to determine human

resources.

Based on the above-mentioned description, different SCU formation strategies can

be developed. Note that our principles mentioned above aim at forming iSCU

enough for solving main tasks and let iSCU evolve during its runtime. There could

be several possible ways to obtain DGBAU and DGCA, dependent on specific config-

urations and graphs for specific problems. Therefore, potentially the cloud of HBS

1341003-20

2nd Reading



Table 2. Examples of SCU formation strategies.

Algorithms Description

SkillWithNPath Select iICU for iSCU based on only skills with a pre-definednetwork path length starting from the task to be solved.

SkillMinCostWithNPath Select iICU for iSCU based on only skills with minimum cost,considering a pre-defined network path

length starting from the task to be solved.

SkillMinCostMaxLevelWithNPath Select iICU for iSCU based on skills with minimum cost andmaximum skill levels, considering a pre-defined network pathlength starting from the task to be solved.

SkillWithNPathUnDirected Similar to SkillW ithNPath but considering undirecteddependency.

MinCostWithNPathUnDirected Similar to MinCostWithNPath but considering undirecteddependency.

MinCostWithAvail NPathUnDirected Select Select iICU for iSCU based on skills with minimum cost,considering availability and a pre-defined network path lengthstarting from the task to be solved. Undirected dependenciesare considered.

can provide several algorithms for selecting HBS to form SCUs. As we aim at pre-

senting a generic framework, we do not describe here specific algorithms, however,

Table 2 describes some selection strategies that we implement in our framework.

Listing 2 describes an example of forming an SCU.

DefaultDirectedGraph<Node , Re la t ionsh ip > dg ; // graph o f

problems

// . . .

double hpu = HPU. hpu (dg ) ; // determine

SCUFormation app = new SCUFormation( dg ) ;

ManagementRequest r eque s t = new ManagementRequest ( ) ;

// de f i n e r e qu e s t s p e c i f y i n g on ly main problems to be s o l v ed

// . . . .

// c a l l a l gor i t hms to f i n d s u i t a b l e HBS. Path l en g t h =2 and

a v a i l a b i l i t y from 4am to 19pm in GMT zone

ResourcePool scu = app .

MinCostWithAvailabil ityNPathUnDirectedFormation( request ,

2 , 4 , 19) ;

i f ( scu == null ) { return ; }ArrayList<HumanResource> scuMembers = scu . getResources ( ) ;

SCU iSCU = new SCU( ) ;

iSCU . setScuMembers ( scuMembers ) ;

// s e t t i n g up SBS fo r scuMember . . .

Listing 2. Example of forming iSCU by minimizing cost and considering no direction.

1341003-21

2nd Reading



4.3.2. Setting up iSCU connectedness

After selecting members of iSCU , we can also program SBS and HBS for the iSCU

to have a complete working environment. iSCU can have different connectedness

configurations, such as:

• Ring-based iSCU : The topology of iSCU is based on a ring. In this case for each

(hbsi, hbsj) ∈ iSCU then we program hbsi →request

hbsj based on message-passing

or shared memory models. For example a common Dropbox directory can be

created for hbsi and hbsj to exchange requests/responses.

• Star-based iSCU : A common SBS can be programmed as a shared memory for

iSCU . Let sbs be SBS for iSCU then ∀ hbsi ∈ iSCU give hbsi access to sbs.

For example, a common Dropbox directory can be created and shared for all

hbsi ∈ iSCU .

SCU iSCU ;

// . . . f i n d members f o r SCU

DropboxAPI<WebAuthSession> scuDropbox ; // us ing dropbox ap i s

// . . .

AppKeyPair appKeys = new AppKeyPair (APP KEY, APP SECRET) ;

WebAuthSession s e s s i o n =

new WebAuthSession( appKeys , WebAuthSession . AccessType .

DROPBOX) ;

// . . .

s e s s i o n . setAccessTokenPair ( accessToken ) ;

scuDropbox = new DropboxAPI<WebAuthSession>( s e s s i o n ) ;

// shar ing the dropbox d i r e c t o r y to a l l scu members

// f i r s t c r ea t e a share

DropboxAPI . DropboxLink l i n k = scuDropbox . share ("/hbscloud" )

;

// then send the l i n k to a l l members

VieCOMHBS vieCOMHBS = new VieCOMHBSImpl ( ) ;

for (HBS hbs : iSCU . getScuMembers ( ) ) {vieCOMHBS. startHBS( i cu ) ;

HBSMessage msg = new HBSMessage ( ) ;

msg . setMsg ("pls. use shared Dropbox for communication " +

l i n k . u r l ) ;

vieCOMHBS. sendMessageToHBS( hbs , msg) ;

// . . .

}

Listing 3. Example of star-based iSCU using Dropbox as a communication hub.

1341003-22

2nd Reading



• Master-slave iSCU : An hbs ∈ iSCU can play the role of a shared memory and

scheduler for all other hbsi ∈ iSCU .

Listing 3 presents an example of establishing the connectedness for an iSCU

using Dropbox. Note that finding suitable configurations by using HBS informa-

tion and compliance constraints is a complex problem that is out of the scope of

this paper.

4.4. Change model for task graph’s human power unit

When a member in an iSCU receives a task, she might revise the task into a set

of sub-tasks. Then she might specify human compute units required for sub tasks

and revise the task graph by adding these sub-tasks. As the task graph will change,

its required HPU is changed. By capturing the change of the task graph, we can

decide to scale in/out the iSCU . Listing 4 describes some primitives for scaling

in/out iSCU based on the change of HPU.

SCU iSCU ;

// . . .

iSCU . setScuMembers ( scuMembers ) ;

// s e t t i n g up SBS fo r scuMember

// . . .

double hpu = HPU. hpu (dg ) ; // determine current hpu

//SCU so l v e s /adds t a s k s in DG

// . . . .

// graph change − e l a s t i c i t y based on human power un i t

double dHPU = HPU. de l t a (dg , hpu) ;

DefaultDirectedGraph<Node , Re la t ionsh ip > changegraph ;

// ob ta in changes

Set<CloudSki l l > changeCS = HPU. de te rmineC loudSk i l l (

changegraph) ;

i f (dHPU > SCALEOUT LIMIT) {iSCU . s c a l e ou t ( changeCS) ; //expand iSCU

}else i f (dHPU < SCALEIN LIMIT) {iSCU . s c a l e i n ( changeCS) ; // reduce iSCU

// . . .

}Listing 4. Example of elasticity for SCU based on task graph change.

5. Related Work

Although both humans and softwares can perform similar work and several com-

plex problems, both of them are esential in the same system, currently there is a

1341003-23

2nd Reading



lack of programming models and languages for hybrid services of SBS and HBS.

Most clouds of SBS offer different possibilities to acquire SBS on-demand, however,

similar efforts for HBS are missing today.

Cloud models and APIs for HBS: Tai et al.25 outlined several research ques-

tions in cloud service engineering to support “everything is a service” in which

services can be provided/integrated from different providers and charged based on

different costs and values. However, contemporary systems focus only on SBS. Sev-

eral frameworks for engineering cloud applications based on different IaaS, PaaS

and SaaS, such as Aneka.26 BOOM27 have been introduced. Generally, they utilize

software-based cloud resources via different sets of APIs, such as JClouds, Boto,k

and OpenStack,l to develop applications under different programming models, such

as MapReduce and dataflows. These frameworks do not consider hybrid services

consisting of SBS and HBS, while our work supports conceptualizing and providing

programming techniques for both SBS and HBS. To our best knowledge, there is

no other work that proposes HBS cloud models.

Programming HBS and SBS in a unified way: Most clouds of SBS offering differ-

ent possibilities to acquire SBS on-demand. However, researchers have not devoted

similar efforts for HBS. A common way to utilize human capabilities is to exploit

human computation programming frameworks, e.g. Crowdforge28 and TurKit29 and

Jabberwocky framework,30 for utilizing crowds for solving complex problems.3,31

However, these works do not consider how to integrate and virtualize software in

a similar manner to that for humans. As we have analyzed, current support can

be divided in three approaches:1 (i) using plugins to interface to human, such as

BPEL4Peopleb or tasks integrated into SQL processing systems,9 (ii) using sep-

arate crowdsourcing platforms, such as MTurk,m and (iii) using workflows, such

as Turkomatic.6 A drawback is that all of them consider humans individually and

human capabilities have not been provisioned in a similar manner like software

capabilities. As a result, an application must split tasks into sub-tasks that are

suitable for individual humans, which do not collaborate to each other, before the

application can invoke humans to solve these sub-tasks. Furthermore, the applica-

tion must join the results from several sub-tasks and it is difficult to integrate work

performed by software with work performed by humans. This is not trivial for the

application when dealing with complex problems that requires human capabilities.

In terms of communication models and coordination models, existing models also

support messages push/pull/mediator, but they are platforms/middleware built-in

rather than reusable programming primitives of programming models. Our work

in this paper does not focus on managing and coordinating tasks but by propos-

ing high-level APIs for HBS in a similar manner to that for SBS, our work could

khttp://boto.s3.amazonaws.com/index.html.lhttp://www.openstack.org/.mAmazon mechanical turk, 2011. Last access: 27 Nov 2011.

1341003-24

2nd Reading



foster the utilization of several HBS and SBS from different clouds based on cloud

business models for different task management and coordination strategies.

Software tools for HBS: Some recent efforts have been devoted for software engi-

neering tools of human-services, such as Ref. 32, and general-purpose programming

languages for human computation, such as CrowdLang.33 While they call for a

better software engineering and programming languages support for human-centric

systems, they do not address issues related to human services provisioning, e.g.

using cloud and service models. Although we do not develop new general-purpose

programming languages, we believe that if these works need to utilize human capa-

bilities and software services in a large-scale, on-demand, pay-per-use fashion, then

our models and techniques can be integrated into these software tools and languages.

Overall, compared with related work, we develop models for clouds of HBS. Our

techniques for virtualizing HBS and programming HBS in a similar way to SBS are

different from related work. Such techniques can be used by high-level programming

primitives and languages for social computers.

6. Conclusions and Future Work

In this paper, we have proposed novel methods for modeling clouds of HBS and

describe how we can combine them with clouds of SBS to create hybrid services.

We believe that clouds of hybrid services are crucial for complex applications which

need to proactively invoke SBS and HBS in similar ways. We have described main

concepts for establishing clouds of hybrid services, covering several aspects, like

conceptual models and provisioning architectures for communication, pricing and

incentive models, and programming APIs. Based on that, we present general frame-

works and programming APIs to describe where and how hybrid services can be

programmed.

In this paper, we focus on designing models, frameworks and APIs, and illus-

trating programming examples. We have presented a broad view on conceptual-

izing and programming hybrid services but have not addressed detailed activities

in provisioning and managing the operation and interaction within HBS clouds as

well as ICU/SCU. They will be subjects of several future research activities. Fur-

ther real-world experiments should be conducted in the future to demonstrate the

benefits of programming HBS and SBS in the same system. With respect to the

software development for our concepts, we are currently working on programming

elements/constructs/patterns for hybrid services that consider different relation-

ships and cost/quality as first class entities in our programming models. Another

direction is to work on hybrid service life-cycle management. This is also strongly

related to how to monitor and enforce pricing and incentive strategies within a cloud

infrastructure of hybrid services. Furthermore, we are also working on the integra-

tion with programming languages for social collaboration processes5 using hybrid

services. Other related aspects, such as pricing models and contract negotiation

protocols, will be also investigated.

1341003-25

2nd Reading



Acknowledgments

This paper is an extended version of the paper published in Ref. 11 The work

mentioned in this paper is partially supported by the EU FP7 SmartSociety.n

References

1. S. Dustdar and H. L. Truong, Virtualizing software and humans for elastic processesin multiple clouds — a service management perspective, IJNGC 3(2) 2012.

2. D. Schall, H. L. Truong and S. Dustdar, Unifying human and software services inweb-scale collaborations, IEEE Internet Comput. 12(3) (2008) 62–68.

3. A. Doan, R. Ramakrishnan and A. Y. Halevy, Crowdsourcing systems on the world-wide web, Commun. ACM, 54(4) (2011) 86–96.

4. D. Oppenheim, L. R. Varshney and Y.-M. Chee, Work as a service, in ICSOC, eds. G.Kappel, Z. Maamar and H. R. Motahari Nezhad, Lecture Notes in Computer Science,Vol. 7084 (Springer, 2011), pp. 669–678.

5. V. Liptchinsky, R. Khazankin, H.-L. Truong and S. Dustdar, Statelets: Coordina-tion of social collaboration processes, in 14th Int. Conf. Coordination Models andLanguages (Coordination 2012), Stockholm, Sweden, June 2012.

6. A. P. Kulkarni, M. Can and B. Hartmann, Turkomatic: Automatic recursive taskand workflow design for mechanical turk, in Proc. 2011 Annual Conference ExtendedAbstracts on Human factors in Computing Systems, CHI EA ’11 (ACM, New York,NY, USA, 2011), pp. 2053–2058.

7. D. W. Barowy, E. D. Berger and A. McGregor, Automan: A platform for integrat-ing human-based and digital computation, Technical Report UMass CS TR 2011-44,University of Massachusetts, Amherst, 2011. http://www.cs.umass.edu/emery/pubs/AutoMan-UMass-CS-TR2011-44.pdf.

8. H. S. Baird and K. Popat, Human interactive proofs and document image analysis, inProc. 5th Int. Workshop on Document Analysis Systems V, DAS ’02 (Springer-Verlag,London, UK, 2002), pp. 507–518.

9. A. Marcus, E. Wu, D. Karger, S. Madden and R. Miller, Human-powered sorts andjoins, Proc. VLDB Endow. 5 (2011) 13–24.

10. S. Tai, P. Leitner and S. Dustdar, Design by units: Abstractions for human andcompute resources for elastic systems, IEEE Internet Comput. 16(4) (2012) 84–88.

11. H. L. Truong, S. Dustdar and K. Bhattacharya, Programming hybrid services in thecloud, in ICSOC, eds. Chengfei Liu, Heiko Ludwig, Farouk Toumani and Qi Yu,Lecture Notes in Computer Science, Vol. 7636 (Springer, 2012), pp. 96–110.

12. P. Mell and T. Grance, The NIST definition of cloud computing, NIST Special Pub-lication 800-145 (September 2011).

13. H. L. Truong, S. Dustdar, D. Baggio, S. Corlosquet, C. Dorn, G. Giuliani, R. Gom-botz, Y. Hong, P. Kendal, C. Melchiorre, S. Moretzky, S. Peray, A. Polleres, S. Reiff-Marganiec, D. Schall, S. Stringa, M. Tilly and H. Q. Yu, Incontext: A pervasive andcollaborative working environment for emerging team forms, in SAINT (IEEE Com-puter Society, 2008), pp. 118–125.

14. O. Nov, D. Anderson and O. Arazy, Volunteer computing: A model of the fac-tors determining contribution to community-based scientific research, in Proc.19th Int. Conf. World wide web, WWW’10 (ACM, New York, NY, USA, 2010)pp. 741–750.

nhttp://www.smart-society-project.eu/.

1341003-26

2nd Reading



15. A. J. Quinn and B. B. Bederson, Human computation: A survey and taxonomy of agrowing field, in CHI, eds. D. S. Tan, S. Amershi, B. Begole, W. A. Kellogg and M.Tungare (ACM, 2011), pp. 1403–1412.

16. W. Mason and D. J. Watts, Financial incentives and the “performance of crowds”,in Proc. ACM SIGKDD Workshop on Human Computation, HCOMP’09 (ACM, NewYork, NY, USA, 2009), pp. 77–85.

17. O. Tokarchuk, R. Cuel and M. Zamarian, Analyzing crowd labor and designing incen-tives for humans in the loop, IEEE Internet Comput. 16(5) (2012) 45–51.

18. O. Scekic, H.-L. Truong and S. Dustdar, Incentives and rewarding in social computing,Commun. ACM 56(6) (2013) 72–82.

19. J. J. Horton and L. B. Chilton, The labor economics of paid crowdsourcing, in Proc.11th ACM conf. Electronic commerce, EC’10 (ACM, New York, NY, USA, 2010),pp. 209–218.

20. S. Dustdar and K. Bhattacharya, The social compute unit, IEEE Internet Comput.15(3) (2011) 64–69.

21. O. Scekic, H.-L. Truong and S. Dustdar, Programming incentives in information sys-tems, in 25th Int. Conf. Advanced Information Systems Engineering (CAISE 2013),Valencia, Spain, 17–21 June 2013.

22. S. Dustdar, M. Z. C. Candra and H.-L. Truong, Provisioning quality-aware socialcompute units in the cloud, in Service-Oriented Computing — Proc. 9th Int. Conf.ICSOC 2013 (Springer, Berlin, Germany, 2–5 December 2013).

23. M. Z. C. Candra, H. L. Truong and S. Dustdar, Modeling elasticity trade-offs in adap-tive mixed systems, in WETICE, eds. S. Reddy and M. Jmaiel (IEEE, Hammamet,Tunisia, 17–20 June 2013), pp. 21–26.

24. T. Binz, G. Breiter, F. Leymann and T. Spatzier, Portable cloud services using tosca,IEEE Internet Comput. 16(3) (2012) 80–85.

25. S. Tai, J. Nimis, A. Lenk and M. Klems, Cloud service engineering, in Proc. 32ndACM/IEEE Int. Conf. Software Engineering — Volume 2, ICSE’10 (ACM, New York,NY, USA, 2010), pp. 475–476.

26. R. N. Calheiros, C. Vecchiola, D. Karunamoorthy and R. Buyya, The aneka platformand qos-driven resource provisioning for elastic applications on hybrid clouds, FutureGeneration Comp. Syst. 28(6) (2012) 861–870.

27. P. Alvaro, W. R. Marczak, N. Conway, J. M. Hellerstein, D. Maier and R. Sears,Dedalus: Datalog in time and space, in Datalog, eds. O. de Moor, G. Gottlob, T.Furche, and A. J. Sellers, Lecture Notes in Computer Science, Vol. 6702 (Springer,Oxford, UK, 16–19 March 2010), pp. 262–281.

28. A. Kittur, B. Smus, S. Khamkar and R. E. Kraut, Crowdforge: Crowdsourcing com-plex work, in Proc. 24th Annual ACM Symp. User Interface Software and Technology,UIST’11 (ACM, New York, NY, USA, 2011), pp. 43–52.

29. G. Little, L. B. Chilton, M. Goldman and R. C. Miller, Turkit: Tools for iterativetasks on mechanical turk, in Proc. ACM SIGKDD Workshop on Human Computation,HCOMP’09 (ACM, New York, NY, USA, 2009), pp. 29–30.

30. S. Ahmad, A. Battle, Z. Malkani and S. Kamvar, The jabberwocky programmingenvironment for structured social computing, in Proc. 24th Annual ACM Symp. UserInterface Software and Technology, UIST ’11 (ACM, New York, NY, USA, 2011),pp. 53–64.

31. A. Brew, D. Greene and P. Cunningham, Using crowdsourcing and active learning totrack sentiment in online media, in Proc. 2010 Conf. ECAI 2010: 19th European Con-ference on Artificial Intelligence, (IOS Press, Amsterdam, The Netherlands, 2010),pp. 145–150.

1341003-27

2nd Reading



32. C. Dorn and R. N. Taylor, Co-adapting human collaborations and software architec-tures, in ICSE, eds. M. Glinz, G. C. Murphy and M. Pezze (IEEE, 2012), pp. 1277–1280.

33. P. Minder and A. Bernstein, Crowdlang: A programming language for the systematicexploration of human computation systems, in SocInfo, eds. K. Aberer, A. Flache, W.Jager, L. Liu, J. Tang and C. Gueret, Lecture Notes in Computer Science, Vol. 7710(Springer, Lausanne, Switzerland, 5–7 December 2012), pp. 124–137.

1341003-28

On the Elasticity of Social Compute Units

Mirela Riveni, Hong-Linh Truong, and Schahram Dustdar

Distributed Systems Group, Vienna University of Technology{m.riveni,truong,dustdar}@infosys.tuwien.ac.at

Abstract. Advances in human computation bring the feasibility of utiliz-ing human capabilities as services. On the other hand, we have witnessedemerging collective adaptive systemswhich are formed from heterogeneoustypes of compute units to solve complex problems. The recently introducedSocial Compute Units (SCUs) present one type of these systems, whichhave human-based services as their core fundamental compute units.While, there is related work on forming SCUs and optimizing theirperformance with adaptation techniques, most of it is focused on staticstructures of SCUs. To provide better runtime performance and flexibilitymanagement for SCUs, we present an elasticity model for SCUs and mech-anisms for their elastic management which allow for certain fluctuations insize, structure, performance and quality. We model states of elastic SCUs,present APIs for managing SCUs as well as metrics for controlling theirelasticity with which it is possible to tailor their performance parametersat runtime within the customer-set constraints. We illustrate our contri-bution with an example algorithm.

Keywords: Social Compute Units, Elasticity, Adaptation, CollectiveAdaptive Systems.

1 Introduction

In recent years, new forms of collective adaptive systems(CASs) that considerheterogeneous types of compute units/resources(e.g., software services, humanbased services and smart-devices) have emerged [20]. These systems allow com-pute units to be flexibly added and/or removed from them, and different collec-tives can overlap with each other by utilizing each other’s resources. Computeunits within collectives are collaborative, manageable and may be given decisionmaking responsibilities. With the advance of human computation [17] there isa possibility of forming CASs that include human-based services [21] as com-pute units. Social Compute Units(SCUs), introduced in [6], can be considered asone type of these collective adaptive systems. They are virtual compositions ofindividual human compute units, performing human computation tasks with acloud-like behavior. SCUs are possible today because of the human resource poolsthat are provided by human computation platforms (e.g., crowdsourcing plat-forms, social networking platforms and expert networks), which have broughtthe possibility to investigate ways of utilizing human computation under theservice oriented computing paradigm. However, due to the unpredictability of

M. Jarke et al. (Eds.): CAiSE 2014, LNCS 8484, pp. 364–378, 2014.c© Springer International Publishing Switzerland 2014

On the Elasticity of Social Compute Units 365

human behavior, human-based services bring considerable challenges in theirmanagement. This is especially the case with collective adaptive systems suchas SCUs, where the ways to manage resources are obviously different and morecomplex than the management of crowd workers that work individually, and thatof collaborations with fixed number of resources. In this context, traditional plat-forms that support virtual fixed-sized collaborations might not be as efficient asthose that support SCUs with elastic capabilities that offer opportunities forvariable resource numbers with variable scalable capabilities. There are severalreasons for this. First, unexpected tasks might be generated at run-time whichmay require new type of elements with new type of capabilities. In fixed-resourcecollaborations, usually existing members need to learn these tasks and thus thework might be delayed and/or executed with lower quality. Next, there mightbe a human-compute unit that is temporarily misbehaving or its performanceis degraded. Its exclusion would bring degradation of the collaboration and theperformance of the collective, if another appropriate one is not employed in itsplace. Furthermore, due to badly planned delegations, it is often the case thatsome resources are overloaded while others are underutilized. The latter comesas a consequence of the problem of the reliance on human resource availability asone of the fundamental ones in social computing. In this context, the willingnessof a human resource to execute a particular task at a specific time point is oftenoverlooked. However, this is crucial for platforms supporting work that includeshuman computation because even if we assume that human resources can use”unlimited” software-based resources, e.g., using the cloud, human behavior isdynamic and highly unpredictable.

The aforementioned problems show that there is a need for management mech-anisms to support elasticity by scaling in size and computing capabilities ofSCUs in an elastic way. Authors in [8],[21] identify the underlying challenge inprovisioning SCU elasticity to be the lack of techniques that enable proactiveprovisioning of human capabilities in a uniform way in large scale. Nevertheless,assuming the possibility of utilizing human-based services in a cloud-like way,systems should support runtime elastic coordination of collectives. To addressthe aforementioned issues, in this paper, we investigate and provide runtimemechanisms with the elasticity notion in mind, so that platforms would be ableto provide elastic capabilities of human-based compute units/SCUs, that can bemanaged flexibly in terms of the number of resources, as well as their parameterssuch as cost, quality and performance time. Hence, our key contributions are:

– conceptualizing and modeling the SCU execution phase and states,– defining SCU-elasticity properties and APIs,– designing an SCU provisioning platform model with elastic capabilities.

The rest of this paper is organized as follows. In Section 2 we present a motivationexample and discuss challenges in elasticity provisioning. In Section 3 we describethe SCU concept, model the execution mode of an SCU and present our platformfor managing elastic SCUs. Section 4 illustrates the feasibility of our approach.We present related work in Section 5 and conclude the paper in Section 6.

366 M. Riveni, H.-L. Truong, and S. Dustdar

2 Motivation, Background and Research Statement

Scenario. Let us consider a concrete scenario of a software development projecte.g., for a health-care specific system, and assume that a software start-up com-pany is engaged for its execution and completion. To deliver the end-artifact,these type of projects require diverse set of skills. Hence, in addition to the com-pany employees, some specific parts of the project might need to be outsourced,e.g., to experts with experience in health-care but also to IT professionals withskills that the start-up is lacking. Hence, to solve the problem of skill deficiency,an SCU including human-based resources/services both from the software devel-oping company but also ”outside” experts is formed. The SCU utilizes softwareservices for collaboration and task execution. On the other hand, the human-based services and the software services that they utilize are supported by anSCU provisioning and management platform that coordinates their performance.

The challenges that arise in this scenario come from the importance of perfor-mance and quality of results in paid expert units. A software solution needs tobe delivered on time and in accordance with customer requirements and budgetlimitations. Fixed composite units with a known number of resources, includ-ing outsourced ones, often have problems with overloaded resources and mayresult in project delays with good quality or on time delivery of solutions witha lower quality than the desired ones. Problems such as those mentioned in theintroduction also appear. However, with the availability of online resource-poolsfrom human clouds [10], human-based services can be acquired and releasedfrom SCUs on demand, so as to best meet the customer performance and qual-ity requirements. Hence, we assume that the ”outside” experts for our softwaredevelopment SCU can be recruited from human clouds on demand. Under theseassumptions and if the SCU supporting platform incorporates mechanisms thatallow elasticity, an initial SCU will be able to adapt at runtime with respect tocertain parameters, such as the number of its compute units, unit types, structureand performance. This can be particularly important in agile software develop-ment, where both the customer requirements and the development process evolvein an iterative way, and teams have high collaboration with the customer and aremore responsive to change. Our hypothesis is that in consequence of these elas-tic capabilities, SCUs will provide higher efficiency at runtime. Thus, platformsthat include mechanisms and techniques for runtime support of coordination ofSCUs with elastic capabilities are crucial.

Background and Challenges. As aforementioned, our approach is based onthe concept of Social Compute Units [6], which fundamentally represent virtualcollective systems with human-based resources as compute units that are broughttogether to work on a common goal with a deadline. These compute units, canbelong to an enterprise, they can be invoked from a crowdsourcing platform, anexpert network or any platform that hosts pools of available resources for human(including social) computation. In relation to the work of the coauthors in [21], inthis paper, we use the term Individual Compute Units (ICUs) for SCU members,which represent human-based services that can be programmed in a manner that


they can execute tasks on-demand. Thus, an SCU is composed on request froma customer who defines requirements and sets constraints(e.g.,budget,deadline).It has its compute (performance) power, it can be programmed (managed) andis intended to work utilizing a collaboration platform hosted on the cloud. Thebehavior of an SCU is cloud-like, in the sense that its duration and performancedepends on its goal, customer constraints as well as events generated during itsexecution.

Considerable related research focus has been put on formation algorithms[1],[13] and performance optimization within fixed teams. However, SCUs havea different nature than teams, as the SCU structures and capabilities can beprogrammed and SCU members can be elastically managed at runtime. Thus,even if some work for teams can be utilized, there is a research gap concerningSCU elasticity during the execution phase, in terms of resource numbers butalso in terms of non-functional parameters(NFPs) such as cost, reliability, per-formance time etc. There has been a classification of human cloud platforms,where one category of platforms is said to be focused on project governance andcomplex coordination between resources [10], as opposed to crowdsourcing oneswhere the responsibility of project governance is not entirely on the platform.Examples of these type of platforms are TopCoder1 and workio2. Even thoughthese type of platforms can manage the lifecycle of collaborations, we argue thatthey lack the adaptation techniques and flexibility of resource management interms of elasticity at runtime. For example, the pricing in these cases is not setby the customer like in crowdsourcing, rather the human-based services set theirown prices. Thus, there is a possibility that with these models a collective ofhuman resources can be automatically ”programmed” so that if the number andtype of resources changes the cost does not exceed the customer’s total budget.This is one example of NFP elasticity in terms of cost. Consequently, identifyingpossible elastic operations that can be triggered at critical time points presentimportant challenges for optimizing an SCUs performance. In the context ofthe aforementioned scenario and what lacks in current platforms, some of theresearch questions that we confront are:– Given an initial formed SCU and a set of monitored team performance met-

rics, what are the set of actions that can enable SCU elastic capabilities, insituations when performance is degraded and violates a threshold value fora customer set constraint?

– When is optimization(e.g, load balancing) within an SCU not enough anda reorganization needed? Which tasks need to be reassigned, when and towhom(to a resource within/out of the SCU?

To sum up, this paper investigates the following fundamental challenge:Whatare the mechanisms that a human computation system needs to deploy so as toprovision SCUs with elastic capabilities, both in terms of resource scaling and interms of variable properties?

1 http://www.topcoder.com/2 https://www.workio.com/


3 Social Compute Units and Elasticity

3.1 Elastic Social Compute Units

Elastic SCUs have elastic capabilities that can be triggered at runtime to tailortheir performance to best fit client requirements at runtime. With human basedresources being unpredictable and dynamic, their skills, price, interest and avail-ability can change with time and within a specific context. However as statedin [6] the concept of SCU does not have a notion of elasticity in itself, thus anSCU provisioning platform which creates, deploys and supports the execution ofSCUs needs to include mechanisms for scaling it up or down as needed, and asaforementioned, with this scale an SCUs performance parameters vary as well.These mechanisms should ensure that at each time point these parameters arewithin desired levels and comply with customer constraints. For our purposes,we conceptually define the elasticity of SCUs as follows:

Definition 1. The Elasticity of Social Compute Units is the ability ofSCUs to adapt at runtime in an automatic or semi-automatic manner, by scalingin size and/or reorganizing and rescheduling, such that the variations in theoverall performance indicators such as capability, availability, effort, productivityand cost, at each point in time are optimal within the boundaries of the customer-set constraints.

To support elasticity for SCUs, we identify as a prerequisite to have an execu-tion model for an SCU, as previous work identifies SCU phases but do not gointo details into its execution phase. An SCU lifecycle consists of the followingstages: request, create, assimilate, virtualize, deploy and dissolve [6]. The elastic-ity mechanisms are needed after the virtualization stage, in the execution phase,which we model next.

3.2 SCU Execution Model

We denote a cloud of ICUs (e.g.,from online platforms and/or enterprise inter-nal pool) as the universal set R = {r1, r2, r3...rn}, and the set of ICUs thatare members of a particular SCU as S = {s1, s2, s3...sn}, where S ⊂ R. Letthe set of tasks to be executed from a specific SCU be T = {t1, t2, t3...tn}. Foreach task ti ∈ T , we denote the set of matching, appropriate and possible ICUsthat can perform the task ti as P = {p1, p2, p3...pn}, where P ⊂ R. Depend-ing on constraints the following can be valid in different situations: P ⊂ Sc,P ⊂ S or P = S. To provide elasticity, ICUs from S can be released and newICUs from P can be added to S, therefore, |S| might change at runtime. Wemodel an ICU belonging to the cloud of ICUs R, with the following set of globalproperties, ICUgl

prop = {Idicu, skillset, reputation, price, stateglobal}. Moreover,an ICU from the perspective of the specific SCU of which it is a member, ismodeled with its local properties, as ICU lscu

prop = {Idscu, ICUglprop, statelocal,

productivity, trust}, where reputation, state productivity, and trust are aggre-gate metrics that we discuss further in this section.


States. An SCU in execution mode, at a specific time point τ , can be in one ofthe following action-states, SCUstate(τ) = {running, suspending, resuming,expanding, reducing, substituting, stopped}. These states are listed in Table 1.The mentioned states are basic/atomic ones and a combination of them makes acomplex SCU execution state. For example, an SCU might be running but due toan adaptation action, at the same time multiple ICUs (a cluster of ICUs) withinan SCU might be suspended, while a new ICU is being added in expandingstate. In this case because running, suspending and expanding are all executionstates of an SCU, then running ∧ suspending∧ expanding is also an SCU state.However, some states are mutually exclusive if they refer to the whole SCU andcannot be aggregated, i.e., an SCU cannot be in running ∧ stopping state. Ifone of the atomic states refers to (a change in) individual or a cluster of ICUs,an SCU can be in running ∧ extending state or for example an SCU can be in arunning ∧ reducing state. Thus, the aggregate states are valid in the context ofthe scope that a state-changing action takes place. Table 1 also shows the scopefor which the state-changing actions are valid, in terms of the whole SCU, acluster of ICUs, or ICUs only. The importance of the state of an SCU as a wholeis tightly coupled with ICU states and is crucial when applying elastic strategiesin two ways: 1) the state of the SCU can be a trigger for elastic operations onthe SCU, and 2) it can be a desired result after applying these operations.

Table 1. Fundamental state alternatives of the SCU Execution phase

Trigger action State ScopeTriggering Role

Platform Customer ICU

Run Running SCU√ √

Suspend Suspending SCU/ICUcluster/ICU√ √ √

Activate Resuming SCU/ICUcluster/ICU√ √ √

Add Expanding ICUcluster/ICU√ √ √

Exclude Reducing ICUcluster/ICU√ √ √

Stop/Exclude/Add Substituting ICUcluster/ICU√ √ √

Stop Stopping SCU√ √

SCU Elasticity Management. Table 1 shows ways of adaptation triggering:platform based, customer based and ICU based. To clarify, a platform that sup-ports an SCU should have the mechanisms to support all of its execution stateselastically. Thus all state-changing actions can be triggered in an automatedway as shown in Table 1. Referring to our motivational scenario, in rare casesthe customer could suspend the whole SCU of software development until hehas consulted and decided for crucial changes. There are other triggering state-changing actions that the customer can also make(shown with light gray checksigns). Table 1 also shows which state-changing actions can be most affected bycommunication and ICU feedback, which we illustrate in Section 4. We show anexample for a software developing SCU in execution mode in Fig. 1. At a specifictime point ICUs with developer skills are in running state while designers are sus-pended. Next, due to an event when expert information is needed(e.g.,health-care


Fig. 1. An illustrative example of an SCU in execution: expanding and reducing states

information in our scenario), the SCU is expanded by including ICU with spe-cific expertise and consultancy skills while a designer-ICU is resumed. At anothertime point each ICU is running, while before dissolving, the SCU is reduced asICUs with designer and consultancy skills have finished their tasks. Adaptationactions on an SCU can change its execution model not only in terms of the statebut also in terms of its execution structure. These changes are interdependentwith task structure changes and ICU state changes.

Basic ICU and SCU Metrics. The decision to apply an elastic adaptationaction depends on events that are triggered by two level monitoring of global andlocal metrics, namely to detect: 1) a violation of preset threshold values for over-all SCU performance, and 2) which ICUs have affected the SCU’s performancedegradation. The focus of this paper is not to investigate extensive metrics, asmany are context dependent. Thus, in this section we list and define some basicones that we identify to be useful for SCUs at runtime.

Project Effort and Productivity have been listed as performance measuresfor software projects [12]. Modified versions of these metrics can be reused forSCUs on software and other goals. Thus, we define the SCU Effort as the sumof the average time spent by each ICU on each assigned task. The SCU taskcompletion ratio, gives the fraction of completed tasks within those assigned.However this does not always mean that the results of all completed tasks are also

Table 2. Notation and description of basic ICU metrics and parameters

Metrics Description

nreq Number of willingness requests sent from the scheduler to an ICU

nack Number of willingness acknowledgments sent to the scheduler by an ICU

nreasgn Number of tasks reassigned to an ICU

nsucreasgn Number of successfully executed reassigned tasks by an ICU

napproved(si) Total number of successfully executed/approved tasks for an ICU

τ (si, tx) Processing time for task x executed by an ICU

c(si, tx) Cost for task x when executed by an ICU

c(snwi , tx) Cost for task x when reassigned to a new ICU


approved. Thus, we also consider the number of valid or approved tasks, whichwe use for calculating the productivity of an SCU. We define SCU Productivityas the ratio of approved tasks to SCU Effort, giving an average number of tasks-per-time-unit value. The SCU Reputation is a weighted sum of the reputationscore of each ICU regarding its expertise for the skill for which is included in theSCU. We model the SCU Reputation in this way because some ICUs in a specificSCU are more crucial than others by executing more critical tasks. We definethe, reputation(si) as a function of (Success Rate, Approved Tasks, Timeliness,Reliability, SocialTrust). The SCU Cost is an aggregate sum of the cost of eachICU for each task according to its type and skill-type requirements. The metricsare given in Table 3, where si ∈ S and tx ∈ T . See Table 2 for notation onindividual metrics, some of which we use in calculating those in Table 3. Thedescribed metrics are dynamic and a platform supporting elastic SCUs shouldbe able to monitor and utilize them in runtime adaptation strategies.

From all that was discussed, we can now characterize the elastic profile of anSCU within time τ , as SCUexec(τ) = {SCUsize(τ), SCUstructure(τ), SCUstate(τ),SCUeffort(τ), SCUproductivity(τ), SCUcost(τ), SCUreputation(τ)}.

Table 3. Example metrics of SCU performance

SCU Metrics Definition

SCU Total Completed Tasks CT (scui) =

|S|∑

i=1

ncompleted(si)

SCU Approved Tasks AT (scui) =

|S|∑

i=1

napproved(si)

SCU Success Rate ST (scui) = AT (scui)/CT (scui)

SCU Effort Effort(scui) = 1CT (scui)

|S|∑

s=1

m∑

x=1

τ (si, tx)

SCU Productivity Productivity(scui) = AT (scui)/Effort(scui)

SCU Reputation Reputation(scui) =

|S|∑

i=1

wexpertise ∗ reputation(si)

SCU Cost Cost(scui) =

|S|∑

i=1

m∑

x=1

c(si, tx)

Elasticity APIs. To be able to provide SCU elasticity capabilities, which in-clude ICUs having the aforementioned (and other domain-dependent) properties,we need to have common APIs for their description and management. Currentlywe develop APIs which we categorize in ICU-description APIs for manipulatingICU profiles, ICU-scheduling APIs for ICU management and elastic operations,


Table 4. Example API, abstract methods for ICU manipulation

Scheduling methods Description

abstract AddICU() adds an ICU to the SCU

abstract void SuspendICU(SCU scu) brings an ICU to idle state, still includedin the SCU

abstract void ExcludeICU(SCU scu) excludes an ICU form the SCU

abstract void ResumeICU(SCU scu) restart an ICU and its associated tasks

abstract void ReserveICU(Task t) reserves an alternative ICU for an alreadyassigned task

abstract void SubstituteICU() substitutes an ICU with a reserved one

public List <ICU> getAllICUinSCU(SCUscu)

returns ICUs within the SCU

public List<ICU>getSuspendedICUs(SCUscu)

returns suspended ICUs within an SCU

public List<ICU>getIdleICUs(SCU scu) returns idle ICUs in an SCU

public List<ICU>getReservedICUs(Taskt)

maintains an ordered list of top appropri-ate ICUs for a certain task (ICUs might bein/out of the specific SCU)

and communication operations. Table 4 describes some specific methods that wedevelop to be utilized in strategies providing SCU elastic capabilities.

3.3 Elastic SCU Provisioning Platform

Figure 2 shows a model of our concept of an elastic SCU provisioning platform,that utilizing our SCU execution model, metrics and API is able to supportelastic SCU management. Thus, the platform supports the following behavior:a customer/SCU consumer submits a project/request with multiple tasks toit. When submitting tasks and request for SCU formation, the client specifiesfunctional and non-functional ICU requirements such as: skill, reputation andcost. In addition he specifies overall SCU constraints, such as total budget anddeadline. The platform integrates an SCU formation component with ICU se-lection/ranking algorithms. The resource selection and initial task assignment isnot in our focus. The SCU creation/formation component’s output is an initialSCU created by selecting ICUs from human cloud providers. This SCU is ”fed”to a controller -a component that hosts monitoring and adaptation algorithmsutilizing APIs for elasticity control, which provide SCU runtime management.The challenge of this component, is to monitor and adapt the SCU in accordanceto customer set constraints, such that the SCU gives the maximum performanceand quality within the preset boundaries for time related, cost and quality re-lated indicators. Different scheduling and ICU management algorithms can beplugged into the platform, which would support the SCU during its lifecycle.


Fig. 2. Conceptual platform model supporting elastic SCUs

4 Illustrating Example

In this section we show the benefit of having explicit state management, metricsand elasticity for supporting elastic SCU. We present the way our frameworkcan simplify the complexity of the development of elasticity strategies for SCUs.Typically, an elasticity strategy for an SCU is a domain-specific problem. In thefollowing, we illustrate how an ICU Feedback-based elastic SCU managementstrategy can be implemented.

As ICUs within an SCU are inherently dynamic and unpredictable, we cannotalways fully rely on the system-based availability information concerning an ICUand fully automated task assignment and scheduling might not always be themost suitable approach, especially when there is a possibility of unexpectedgeneration of tasks at runtime. Hence, we propose an SCU adaptation strategythat uses ICU acknowledgments for their willingness to work on specific tasks.More specifically, these acknowledgments are sent in response to system requestsfor availability guarantees for the execution of tasks that need reassignment.This strategy supports elasticity in the sense that it departs from the idea thata customer knows in advance which and how many ICUs will contribute andthe final cost for his ”project”. However, the customer budget is kept within itslimits as the cost may vary within these limits, just as the size and structure ofthe assembled SCU may vary with time until the final result is returned.

Our example of elastic SCU mechanism is a semi-automatic task schedulingstrategy where part of the coordination for task re-assignment is delegated toICUs. With this approach a task is being re-assigned to a more available ICU,


on an ICUs own approval and when certain conditions apply (e.g, when a thresh-old is reached). Thus, the task reassignment decisions are partly based on feedbackfrom ICUs and in this way the elastic SCU management is influenced from “hu-man in the loop” decentralized coordination. With this example, we show how newSCU metrics can be derived and how APIs for elastic capabilities can be used.

Deriving New SCU Metrics. By utilizing APIs for obtaining SCU metricsat runtime, one can calculate the willingness of an ICU and the willingnessconfidence score as: (See Table I for notations):

Willingness =nack

nreq, Successreasgn =

nsucreasgn

nreasgn, WCnf =

nack

nreq× nsucreasgn

nreasgn.

We derive the willingness confidence value from the basic indicators, ICU will-ingness, and the rate of success in executing the reassigned tasks. The willingnessconfidence score WCnf, is computed from the number of acknowledgments thatan ICU has sent to the scheduler in response to its Requests for Willingness, andthe number of successfully completed tasks that are assigned to it as responsesto these acknowledgments. Thus, it is an indicator about the reliability of thealternative ICUs guarantee about its willingness to work.

Programming an Elasticity Strategy Using Elasticity APIs. Consider-ing worker willingness, provides a way to measure and control the unpredictabil-ity/reliability of ICUs by asking them for task-execution guarantees because itprovides a way to compare their ”statements” with their actual behavior. Thisis what the value of Willingness Confidentiality indicates. In this strat-egy we assume that each incoming task is assigned to the ICU at the top of aranked list which is returned by a ranking algorithm, and references to the firstx most appropriate ICUs from the ranked list are stored as reserves/alternativesfor each task. The algorithm can be summarized with the following steps:1. When a preset threshold, related to a task which is already assigned to

the most appropriate ICU matching the requirements is reached, e.g.,thetasks waiting-time in an ICUs task-queue, the scheduler sends a request forexecution willingness to the next top x number of ICUs that it has referencesto (reserves from the initial ranked list), which at the same time are idle,or their task queues are smaller than that of the ICU to which the taskwas initially assigned. With this request for willingness, it notifies them thatthere is a task that they can work on. This request is a resource availability-check; it is a request for a resource’s willingness to work on a specific taskas a form of a worker-side commitment or guarantee that the task will beexecuted by it.

2. Each ICU that receives this request and is ready and wishes to work on thetask then sends the scheduler a willingness acknowledgment(Ack)/feedbackto this request.

3. The scheduling component reassigns the task on threshold to the alternativeresource that has sent a willingness acknowledgment and that is idle or hasthe smallest task queue. Priority is given to less loaded ICUs that are alreadymembers of the SCU.


Algorithm 1. Task-reassignment with ICU-side assurance

Require: scuTasks for SCURequire: customer constraints on NFP1: for all tasks in T do

rank matching ICUs and return the first 10 appropriate2: P ← getReservedICUList(Taskt) � store reserve ICUs3: assign task t to top ranked ICUs r4: if r is not an element in SCU then do5: SCU ← addICU() � add ICU r to SCU x and update its profile

6: if task.taskQueueT ime == task.timeThreshold then do7: if r == idle then do8: SCU ← removeICU() � reduction: remove ICU r from SCU

9: for all ICU in P do10: getICUState(ICUICUid)11: if ICU STATE==idle AND icuReserve.tQueue() <r.tQueueSize()/2

then do12: willingnessReqMessage()

13: for all icuReserve.sentAck == true in ascending order oficuResource.taskQueue do

14: if resource belongs in SCU then do15: substituteICU() � re-assign task to SCU member and update its

profile16: break17: substituteICU() � re-assign task to external ICU and update its

profile

18: SCU ← addICU() � expansion: include resource y in SCU

When multiple reserve ICUs send acknowledgments that they are ready to exe-cute the task, the reassignment decision is made based on the information fromthe Acks combined with monitoring information about their task queues andlogged information about the WCnf score. This type of scheduling combines thefreedom of choosing tasks that workers have in crowdsourcing environments,with policy based assignment of tasks. It is these ICU-side guarantees that arecombined with task queue analysis, that can avoid problems such as delegationsinks. We outline the steps of this strategy in Alg 1. Alternatively, the requestfor willingness can be sent immediately after the task’s initial assignment so thatwhen a threshold is reached the scheduler only checks the task queues of ICUs.

Executing an Elasticity Strategy. We implemented the algorithm usingmethods described in the API section. We created tasks with different skill re-quirements and modeled an ICU with a single skill for simplicity, and assignedeach of them different costs. When a decision is made about which tasks are go-ing to be reassigned to which ICU, the new cost calculation includes the pricesof each of the new ICUs, as follows:

Costadapt(scui) = Costprevious(scui) −m∑

i=1

j∑

x=1

c(si, tx) +

m∑

i=1

j∑

x=1

c(snwi , tx),


where Costadapt(scui) ≤ Allowed Budget. Due to space limitations and to thefact that it is not our goal to show how good this strategy is, we provide asupplement material3.

Generally, the results show that SCU productivity raises with the number ofICUs and the same effort, while it declines if the effort is high for a low numberof tasks and a small number of ICUs.

5 Related Work

Resource Management and Adaptation. Work on a retainer model forcrowdsourcing environments and examples of its application are presented in[4],[3]. The model is designed for recruiting guaranteed workers by paying thema small additional amount, and in this way keeping them in reserve and in readystate for handling real-time tasks. The similarity of our ICU-feedback basedstrategy is in that our scheduler keeps references to the top x number of re-sources that are previously ranked as most suitable for a specific task. Hence,these resources are the reserve resources in our approach. However, the differ-ence in our approach is that no prior payment is made for reservation of theseresources, rather the scheduler sends them a notification asking for feedback fortheir willingness to execute a task that is already assigned to another resourcebut for which a threshold is reached. Our model is not concerned with initial taskassignment and it is not intended for crowdsourcing tasks, although ICUs may beinvoked from a crowdsourcing platform. Authors of [15] present a programminglanguage and framework called CrowdLang for systems that incorporate humancomputation, and what is of interest to us is that they provide cross-platformintegration of resources, in this way making a human cloud possible. There is aconsiderable amount of work conducted on adaptation and more interestingly onself-adaptation strategies. For example, authors in [16] have presented an archi-tecture that includes a self-adaptation framework for service-oriented collabora-tion systems. The part that this work relates to, is their approach on identifyingworker misbehavior patterns (e.g., as a result of uncontrolled task delegations)and providing a solution of reassigning tasks to other alternative resources bytaking into account their task-queue size. Our strategy differs from theirs in thattasks are not delegated if ICUs are not willing to accept tasks. Rather, the taskreassignment is managed with consent from alternative ICUs. [9] describes adelegation model and related algorithms that concern trust updates. The au-thors mention adoption as a process where the delegation is initiated by the”delegatee”. Our algorithm stands in between delegation and adoption.

Collaborative Communities and Teams. The concept of the SCU that weutilize in our work is presented by one of the coauthors in [6]. However, while thisis the fundamental work introducing the SCU, it describes its life-cycle and doesnot go into details into the SCU execution phase as this was not its aim. This istackled in [19], where researchers have looked into a specific case of incident man-agement to investigate how SCUs and their evolution(adaptation) perform better

3 dsg.tuwien.ac.at/research/viecom/prototypes/viecas


over traditional process management. Resource discovery in crowdsourcing andteam formation strategies and algorithms have been the subject of investigationin many works, such as [1], [2], [14], [13],[5]. The algorithms in these works can beutilized for SCU formation and some also for ICU selection when an SCU needsto be extended. Task executing collaboration models and runtime collaborationsare also investigated in works such as [18]. However, the mentioned works focuson fixed teams without elasticity assumptions.

Elasticity. The notion of elasticity is treated in several domains and contextsand has especially gained importance with the advance of cloud computing. In[8] authors discuss the reasons, challenges and their approach toward virtualizinghumans and software under the same service-based model that will enable elasticcomputing in terms of scaling both software and human resources. The conceptof elasticity in Cloud computing, is being extended to concepts like application[22] and process [7] elasticity, e.g., in [7], the authors identify resource, costand quality elasticity as being crucial in modeling processes in service orientedcomputing. Mechanisms and a middleware to support scaling services in and outfrom applications utilizing SaaS are presented in [11].

6 Conclusion

Our research focus in this work was to provide mechanisms for effective provi-sioning of SCUs with elastic capabilities and their efficient runtime management.We have modeled an SCU at runtime and provided exemplary algorithm thatutilizes operations for provisioning of elastic capabilities. We have shown thatplatforms supporting human computation in collective collaborations are morereliable by working based on the elasticity concept of scalability in terms of bothresources and their parameters. Our future work includes further development ofan SCU execution framework, which will include the presented model, metrics,API and algorithms so as to be able to deploy our approach in real environments.

Acknowledgments. This work is supported by the Vienna PhD School of In-formatics (http://www.informatik.tuwien.ac.at/teaching/phdschool) and by theEU FP7 FET SmartSociety project(http://www.smart-society-project.eu/) un-der the Grant agreement n.600854.

References

1. Anagnostopoulos, A., Becchetti, L., Castillo, C., Gionis, A., Leonardi, S.: Powerin unity: forming teams in large-scale community systems. In: CIKM, pp. 599–608(2010)

2. Anagnostopoulos, A., Becchetti, L., Castillo, C., Gionis, A., Leonardi, S.: Onlineteam formation in social networks. In: Proceedings of the 21st International Con-ference on World Wide Web, WWW 2012, pp. 839–848. ACM, New York (2012)

3. Bernstein, M.S., Brandt, J., Miller, R.C., Karger, D.R.: Crowds in two seconds:enabling realtime crowd-powered interfaces. In: Proceedings of the 24th AnnualACM Symposium on User Interface Software and Technology, UIST 2011, pp. 33–42. ACM, New York (2011)


4. Bernstein, M.S., Karger, D.R., Miller, R.C., Brandt, J.: Analytic methods for op-timizing realtime crowdsourcing. CoRR abs/1204.2995 (2012)

5. Dorn, C., Dustdar, S.: Composing near-optimal expert teams: A trade-off betweenskills and connectivity. In: Meersman, R., Dillon, T.S., Herrero, P. (eds.) OTM2010. LNCS, vol. 6426, pp. 472–489. Springer, Heidelberg (2010)

6. Dustdar, S., Bhattacharya, K.: The social compute unit. IEEE Internet Comput-ing 15, 64–69 (2011)

7. Dustdar, S., Guo, Y., Satzger, B., Truong, H.L.: Principles of elastic processes.IEEE Internet Computing 15(5), 66–71 (2011)

8. Dustdar, S., Truong, H.L.: Virtualizing software and humans for elastic processesin multiple clouds- a service management perspective. IJNGC 3(2) (2012)

9. Hexmoor, H., Chandran, R.: Delegations and Trust. International Journal of Com-putational Intelligence, Theory and Practice 3(2), 95–108 (2008)

10. Kaganer, E., Carmel, E., Hirschheim, R., Olsen, T.: Managing the human cloud.MITSloan Management Review 54(2), 23–32 (2013)

11. Kapuruge, M., Han, J., Colman, A., Kumara, I.: ROAD4SaaS: Scalable businessservice-based saaS applications. In: Salinesi, C., Norrie, M.C., Pastor, O. (eds.)CAiSE 2013. LNCS, vol. 7908, pp. 338–352. Springer, Heidelberg (2013)

12. Kasunic, M.: A Data Specification for Software Project Performance Measures: Re-sults of a Collaboration on Performance Measurement. Technical report. CarnegieMellon University, Software Engineering Institute (2008)

13. Lappas, T., Liu, K., Terzi, E.: Finding a team of experts in social networks. In:Proceedings of the 15th ACM SIGKDD International Conference on KnowledgeDiscovery and Data Mining, KDD 2009, pp. 467–476. ACM, New York (2009)

14. Lopez, M., Vukovic, M., Laredo, J.: Peoplecloud service for enterprise crowdsourc-ing. In: 2010 IEEE International Conference on Services Computing, pp. 538–545(2010)

15. Minder, P., Bernstein, A.: Crowdlang: programming human computation systems.Technical report (JAN (2012)

16. Psaier, H., Juszczyk, L., Skopik, F., Schall, D., Dustdar, S.: Runtime behaviormonitoring and self-adaptation in service-oriented systems. In: Proceedings of the2010 Fourth IEEE International Conference on Self-Adaptive and Self-OrganizingSystems, SASO 2010, pp. 164–173. IEEEComputerSociety, Washington, DC (2010)

17. Quinn, A.J., Bederson, B.B.: A taxonomy of distributed human computation18. Sagar, A.B.: Modeling collaborative task execution in social networks. In: Potdar,

V., Mukhopadhyay, D. (eds.) CUBE, pp. 664–669. ACM (2012)19. Sengupta, B., Jain, A., Bhattacharya, K., Truong, H.-L., Dustdar, S.: Who do

you call? Problem resolution through social compute units. In: Liu, C., Ludwig,H., Toumani, F., Yu, Q. (eds.) Service Oriented Computing. LNCS, vol. 7636, pp.48–62. Springer, Heidelberg (2012)

20. SmartSociety: Hybrid and diversity-aware collective adaptive systems: When peo-ple meet machines to build a smarter society,http://www.smart-society-project.eu/

FP7 FET,EU Funded Project (accessed: December 20, 2013)21. Truong, H.-L., Dustdar, S., Bhattacharya, K.: Programming hybrid services in

the cloud. In: Liu, C., Ludwig, H., Toumani, F., Yu, Q. (eds.) Service OrientedComputing. LNCS, vol. 7636, pp. 96–110. Springer, Heidelberg (2012),http://dblp.uni-trier.de/db/conf/icsoc/icsoc2012.html#TruongDB12

22. Zhang, X., Kunjithapatham, A., Jeong, S., Gibbs, S.: Towards an elastic applicationmodel for augmenting the computing capabilities of mobile devices with cloudcomputing. Mob. Netw. Appl. 16(3), 270–284 (2011)

SmartSociety

Hybrid and Diversity-Aware Collective Adaptive SystemsWhen People Meet Machines to Build a Smarter Society

Grant Agreement No. 600584

Deliverable 7.1 Working Package 7

Technical Report – SmartCom Design

Dissemination Level(Confidentiality):1

PU

Delivery Date in Annex I: 31/12/2014Actual Delivery Date 31/12/2014Status2 FTotal Number of pages: 57Keywords: virtualization, communication,

middleware, SmartCom

1PU: Public; RE: Restricted to Group; PP: Restricted to Programme; CO: Consortium Confi-dential as specified in the Grant Agreeement

2F: Final; D: Draft; RD: Revised Draft


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: SmartSociety: Hybrid and Diversity-Aware CollectiveAdaptive Systems: When People Meet Machines toBuild a Smarter Society

Project Acronym: SmartSociety

Grant Agreement Number: 600854

Number and title of work-package:

7 Programming Models and Frameworks

Document title: Technical Report – SmartCom Design

Work-package leader: Hong-Linh Truong, TUW

Deliverable owner: Ognjen Scekic

Quality Assessor: Daniele Miorandi, UH



List of Contributors

Partner Acronym ContributorTUW Philipp Zeppezauer, Ognjen Scekic, Hong-Linh Truong



Executive Summary

This document presents the SmartCom architecture, components, and application pro-

gramming interfaces. Section 1 takes a look at the general architecture of the system and

how the functionalities are mapped and handled within the system and its various com-

ponents. Afterwards, Section 2 examines how SmartCom handles messages between the

platform, the applications, the middleware, collectives, and the peers, and how messages

look like. Section 2.4 presents the APIs of the components that have been described in

Section 1. Finally, Section 2.5 outlines some more complex algorithms that are used by

the system.



Table of Contents

1 Architecture 7

1.1 Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1.1 Output Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1.2 Input Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Communication Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2.1 Adapter Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2.2 Authentication Manager . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2.3 Messaging and Routing Manager . . . . . . . . . . . . . . . . . . . . 17

1.2.4 Handling of Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.3 Message Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.4 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.4.1 Message Query Service . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.4.2 Message Info Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Messages 23

2.1 Message Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2 Routing of Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3 Predefined Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.1 Control Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.2 Message Info Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.3 Authentication Messages . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Application Programming Interfaces (APIs) . . . . . . . . . . . . . . . . . . 28

2.4.1 Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.2 Public Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.3 Callback Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.5 Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.5.1 Creation of Output Adapters . . . . . . . . . . . . . . . . . . . . . . 46

2.5.2 Handling of Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3 Experimental Performance Evaluation 56



Communication Middleware

Peers

Tools

Input AdapterInput

AdapterOutput Adapter

Input AdapterInput

AdapterInput

Adapter

Services

Message Info

Service


Communication Engine

Messaging and Routing

Manager

AdapterManager

AuthenticationManager

Mes

sage

Bro

ker

Platform Components

<<REST>>

Figure 1: Overview of the communication middleware. Platform Components are part ofthe HDA-CAS platform and peers/tools are external to the system.

1 Architecture

Figure 1 presents a conceptual overview of SmartCom’s internal architecture. In a typ-

ical use-case, the SmartSociety platform components on the left hand side initialize the

communication by sending messages to peers and collectives on the right hand side via

SmartCom. We denote the messages flowing from the SmartSociety platform in the di-

rection of peers as Output Messages. Peers can reply to received messages by sending

messages via SmartCom. Additionally they can use external, third-party tools (e.g., up-

loading a file to a file server) which are monitored by SmartCom (i.e., the system checks

regularly if there are updates/changes). Messages originating from the peers being passed

on to SmartCom for delivery are referred to as Input Messages.

SmartCom consists of four groups of components:

• Adapters are used to handle and virtualize the actual communication with peers

and tools over communication channels (e.g., sending an email or making a REST

call) from the rest of SmartCom and the platform. The technology that is used by

adapters to send and receive messages depends on the actual implementation and

is abstracted from the rest of the system by providing a common interface for all

adapters. This is important to provide virtualization of peers. Furthermore, this



allows the adaptation of technological advancements in communication.

• Communication Engine consists of components that provide the core function-

ality of the system. They are responsible for the handling of messages intended to

be sent to or received from peers and tools. They resolve current collective mem-

bers and initialize communication. Additional functionalities, like message authen-

tication, management and execution of adapters and routing of messages are also

provided by the components of the Communication Engine.

• Services provide additional information on communication aspects to the peers and

platform components. Furthermore, they can be used, e.g., to derive metrics (such

as average response time) and profiles for peers.

• Message Broker is used to decouple the execution of various middleware compo-

nents to achieve scalability (i.e., multiple components listen for messages on a single

queue). Furthermore, the queues of the broker are used for the routing of messages

which is determined by the Messaging and Routing Manager of the Communication

Engine.

The following sections describe the internal structure and further details of the compo-

nents mentioned above. A detailed diagram of all the components is presented in Figure 2.

1.1 Adapters

This section discusses the technical aspect of adapters within SmartCom. In general there

are two different types of adapters: Output Adapters and Input Adapters. They differ

in their behavior as the Output Adapter is only allowed to send output messages to peers

and the Input Adapter is only allowed to receive input messages from peers. The reason

behind this distinction is that the two types are handled differently. Whereas Output

Adapters are shared among all applications running on the platform, Input Adapters

are usually created by applications and are dedicated to receive input messages for the

application that created the adapter. Their behavior is application specific compared to

the behavior of Output Adapter which is considered as peer specific.

This difference in behavior is also expressed in the way they are created. Output

Adapters are only registered in the system as adapter types (e.g., an email adapter that

sends emails to peers) and their lifecycle (i.e., registration, creation, execution, and re-

moval) is handled by the Adapter Manager (discussed in Section 1.2.1). On the other hand,



SmartCom - Communication Middleware


Adapter Manager

Addresses Address Resolver

Adapter Execution

Engine

Adapter Handler

cache for contact data of peers

AdaptersMessage Broker

Input Adapter Execution

Input Pull Adapter

Adapter Implementation

Input Pull/Push

AdapterAPI

Authentication Manager

SessionsAuthentication

Provider

AuthenticationRequestHandler

AUTH Queue

MIS Queue

Control Queue

Input Queue

Co

mm

un

icat

ion

AP

I

Co

llect

ive

In

fo A

PI

Pla

tfo

rm C

om

po

nen

t(s)

No

tifi

cati

on

C

allb

ack

AP

I

RoutingRules

Messages

Input Handler

MessageLoggingService

RoutingRule

Engine

Message Handler

Request Queues

Output Queues

Log Queue

Pe

er In

fo

AP

I

Output Adapter Execution

Output Adapter


OutputAdapter

API

Pe

erA

uth

en

tica

tio

n

Cal

lbac

k A

PI

executes

cached

Peers

Tools


MessageInformation

Request Handler

Me

ssag

e In

fo

Serv

ice

AP

I

<<REST>>


Query Handler

Me

ssag

e Q

uer

y Se

rvic

e A

PI

Figure 2: Detailed view of the communication middleware.

Input Adapters are created by applications running on the platform and are passed to

SmartCom because they might require special configuration. Consider an Input Adapter

that monitors a folder of a FTP server, such an adapter would require a path to be spec-

ified as well as some additional information like username and password. This data has

to be provided by applications because this information is application specific. Therefore,

Input Adapters are not shared among different applications.

1.1.1 Output Adapters

Output Adapters are responsible for sending messages from SmartCom to peers. There

are two categories of Output Adapters: Stateful Output Adapters and Stateless Output



Middleware


Stateless Output Adapter

Output Queue

Control Queue


OutputAdapter

API


Stateful Output Adapter

Output QueueAdapter

Implementation

OutputAdapter

API

Peer

Peer

Peer

Figure 3: Concept of the Output Adapter

Adapters. Stateful Output Adapters instances are created per peer, whereas single State-

less Output Adapters instances are used to send messages to different peers. Both cat-

egories have to be provided with peer specific contact data, such as an email address or

an URL. The necessary data to contact a peer with an Output Adapter is provided by

the Adapter Manager at each invocation. Additionally, Stateful Output Adapters are pro-

vided with this data also at the beginning of their lifecycle, because they might require

to maintain additional conversational data based on this peer information. Due to the

different lifecycles (further details below) they are provided with that data during the

creation of the adapter. Figure 3 presents the internal structure of both categories of

Output Adapters. The boxes labeled ’Adapter Implementation’ indicate the actual imple-

mentation of the corresponding adapter (e.g., code that issues a REST call). It can also

be observed that both adapters have their own Output Queue but they share one Control

Queue. Output Queues are adapter specific queues which are used for outgoing messages

that still have to be handled. The Control Queue is used to notify SmartCom that the



sending was successful or of an error. Instances of both categories have to implement the

Output Adapter API (see Section 2.4.2).

The lifecycle of an Output Adapter depends on whether it is stateful or stateless.

Both Stateful Output Adapters and Stateless Output Adapters, have to be registered in

the system by calling the Adapter Manager (see Section 1.2.1).

• In case of a Stateless Output Adapter, the adapter is instantiated and executed im-

mediately because they are shared among peers. This approach has the advantage

that there is no need to instantiate the adapter of a specific type at any point in

the future, which eliminates the need for synchronization and locking to ensure that

there is only a single instance of this adapter. Note that further scaled out instances

and the primary instance of the same adapter are considered as a single instance

from the conceptual point of view.

The disadvantage of this approach is that resources, such as computation time and

memory, are assigned to the adapter even if the adapter is not used to communicate

with peers. Nevertheless, due to the usually limited resource consumption of State-

less Output Adapters, this disadvantage is acceptable.

• In case of a Stateful Output Adapter the adapter is only instantiated on-demand

because there is an instance per peer that uses this adapter for communication. If

there are many peers using an adapter type (e.g., an email adapter) there are also

many adapter instances which causes a higher resource consumption compared to

Stateless Output Adapters. Hence, creating them on-demand and – if they have not

been used for some time – removing them reduces this resource consumption.

Adapters of both categories are usually just removed if the appropriate method of the

Adapter Manager is called. However, instances of Stateful Output Adapters could be

discarded earlier to save resources in case they have not been used for some time. Removing

an Output Adapter means that the corresponding communication channel cannot be used

by SmartCom to interact with peers. For example, removing an Output Adapter that

sends emails results in not being able to contact any peer using emails unless another

Output Adapter handling emails is registered.



1.1.2 Input Adapters

Input Adapters are responsible for either waiting for input or for actively checking for

input from peers or tools. Input Adapters can be implemented using a push or pull

mechanisms. Adapters using push are called Input Push Adapters. They are notified by

the external tool/communication channel of new developments (e.g., a new mail in the

mailing list) via a push notification. On the other hand, Input Pull Adapters are handled

and executed by the Adapter Execution Engine. The pull is triggered in a certain interval

or based on a programmed request (e.g., a peer has only one hour to send a file to a

FTP server. After the time runs out, the pull adapter checks if there is a file available).

This request is expressed by putting a corresponding message in the Request Queue of

a pull adapter. This message instructs the adapter to execute a pull. Figure 4 presents

the internal structure of both Input Adapter categories. Instances of both categories push

the received message to the Input Queue. Input Push Adapters have to implement the

Input Push Adapter API (see Section 2.4.2), instances of Input Pull Adapters have to

implement the Input Pull Adapter API (see also Section 2.4.2).

The lifecycle of Input Adapters is managed entirely by SmartSociety platform applica-

tions/components. Input Adapters are created and removed by applications because their

configuration is application specific.

The lifecycle of Input Push Adapters is special, because after adding them to the

Adapter Manager they have to register a technology-specific handler that is responsible

for the reception of push notifications. This handler has to be destroyed again when the

adapter is removed. For example, an adapter using a server socket has to register it at

the beginning and destroy it at the end of its lifecycle.

1.2 Communication Engine

The Communication Engine is the core of the execution system of SmartCom and is

responsible for the communication between the platform, the applications, and the peers

using messages and adapters. The Communication Engine consists of the Adapter Man-

ager, Authentication Manager, and the Messaging and Routing Manager. The interactions

of the subcomponents can be examined in Figure 2.

Messages that should be sent to peers are passed to the Messaging and Routing Man-

ager which decides based on internal routing rules how to forward messages (i.e., which

component/adapter handles the message). Messages are sent to and received from the



Middleware


Input Push Adapter

Input Queue


Input PushAdapter

API

Peer/Tool


Input Pull Adapter

Request QueueAdapter

Implementation

Input PullAdapter

API

Peer/Tool

Figure 4: Concept of Input Push Adapters and Input Pull Adapters.

peers using corresponding Input and Output adapters(described in Section 1.1), which are

created, managed and executed by the Adapter Manager. The Authentication Manager

is responsible to verify the authenticity of a peer and to provide a security token to peers

that allows SmartCom to verify the sender of a message. These components are described

in the following sections.

1.2.1 Adapter Manager

The Adapter Manager is responsible for the lifecycle management (i.e., registration, cre-

ation, initialization, execution, and removal) of adapters. It consists of the following sub-

components: Adapter Execution Engine, Adapter Handler, Address Resolver and multiple

Adapter Executions. Figure 5 shows the internal structure of the Adapter Manager and

how the subcomponents interact with each other.

The Adapter Handler manages the lifecycle of Output Adapters. Both categories of



Adapter Manager

Addresses

Address Resolver

Adapter ExecutionAdapter

ExecutionAdapter

ExecutionAdapter

Execution

Adapter Execution

Engine

executes

Adapter Handler

Co

mm

un

icat

ion

A

PI


Manager

System Component (e.g., Task Execution

Engine)

cache for contact data of peers

Figure 5: Subcomponents of the Adapter Manager and interaction with other internal andexternal components.

Output Adapters are registered with the Adapter Handler. Stateless Output Adapters are

instantiated immediately, while Stateful Output Adapters just remain registered. In case

a message has to be sent to a peer using a stateful adapter, the Adapter Handler creates

an instance of the adapter for the recipient of the message and passes its reference to the

Messaging and Routing Manager. The reference of the adapter represents the address of

the adapter-specific Output Queue of the Message Broker the adapter pulls messages from.

The Adapter Handler prevents the instantiation of multiple stateful adapter for a single

peer. The selection of the required adapters for a communication with a peer is based on

the Peer Channel Addresses3. The Peer Channel Address is the internal representation

of a communication channel used by a peer. Input Adapters are not registered at the

Adapter Handler. Platform components and applications have to create instances of Input

Adapters themselves and pass these instances to SmartCom using the Communication

API (see Section 2.4). Input Adapters either receive messages from peers or tools directly

via push notification or they check an external tool (e.g., a folder on a FTP server or a

mailing list) regularly if there is a new message represented by a new resource (e.g., a new

file) available.

To support scaling out to handle big workloads, each Output Adapter initially listens

3They consist of a unique name (e.g., Email) and a list of parameters (e.g., an email address)



for new messages on a single, adapter specific Output Queue of the Message Broker (see

Section 1.3). Scaled out instances of an adapter pull messages from the same queue which

allows multiple instances to handle messages of the queue concurrently. Conceptually, the

initial instance of the adapter and the scaled out instances are considered a single adapter

instance, because there is no difference in semantics, just an increase in performance.

Therefore, we will not differentiate between these instances in this description. Note that

Stateful Output Adapters and Stateless Output Adapters differ in their behavior regarding

scalability. Since each Stateful Output Adapters instance is associated with a peer there

is hardly any need for scaling out these instances because a higher workload only occurs in

rare cases. Since they are shared, Stateless Output Adapters have to be scaled out much

more often, especially if there are lots of peers using the communication channel handled

by the adapter.

Instances of both types of adapters are executed by the Adapter Execution En-

gine. Therefore, every adapter is assigned to an Adapter Execution which handles

its execution. The Adapter Execution retrieves messages from queues, determines the

address information of communication channels of peers, calls the appropriate methods

from the Adapter APIs (see Section 2.4) and publishes messages to queues. The behavior

of the Adapter Execution depends on whether it handles an Input Adapter or an Output

Adapter. Executions of Output Adapters retrieve messages from the Output Queue and

initiate the communication. Executions for Input Pull Adapters wait for pull requests in

the Request Queue and initiate a pull request upon reception of a message. Input Push

Adapters handle the adapter’s execution on their own, they are not assigned to Adapter

Executions. The details of algorithms for adapter lifecycle management can be examined

in Section 2.5.1.

Peer Channel Addresses for instantiated adapters are stored in the Addresses Data

Storage. These addresses are needed by adapters to be able to contact a peer. The

Address Resolver is responsible to resolve address requests by Adapter Executions.

When an adapter is sending a message to a peer, the Adapter Execution provides the

address of that peer by querying the Address Resolver. The data storage acts as a cache

for Peer Channel Addresses to speed up the execution of adapters because the Peer Channel

Addresses are usually managed by platform components and calling them regularly might

be a limiting factor to performance and throughput.



AUTH Queue

Control Queue

Authentication Manager

Sessions

System Component (e.g., Peer Manager)

Pe

erA

uth

en

tica

tio

n

Cal

lbac

k A

PI

AuthenticationProvider


Manager

AuthenticationRequestHandler

Figure 6: Concept of the Authentication Manager

1.2.2 Authentication Manager

The Authentication Manager is used to authenticate peers and verify the authenticity

of their messages in the system. Authentication request messages (see Section 2.3) are

dropped in the AUTH Queue by the Messaging and Routing Manager and are collected

by the Authentication Request Handler. This handler interacts with the Peer Au-

thentication Callback API (see Section 2.4.3) to get information on the peer and to

authenticate the peer (using the credentials provided in the message). After the success-

ful authentication, the manager creates a security token that can be used by peers and

SmartCom to provide security features (e.g., message authentication or message encryp-

tion). This token is only valid a certain period of time. The time period between the

creation of the token and the invalidating thereof is called session. The result of the

authentication is passed to the Control Queue in form of a response message. The Au-

thentication Provider can be used by the Messaging and Routing Manager to verify

the authenticity of a message – if required. Figure 6 presents the internal structure of the

Authentication Manager.

The Authentication Manager uses a Session Data Storage to handle the sessions

of peers. Sessions consist of a session token that can be used by peers to authenticate

messages, and a timestamp. If a message arrives with a token of an invalid session, the

peer has to be informed to renew its token. Such messages should be discarded or at least

retained until the peer authenticates itself again.



AUTH Queue

MIS Queue

Control Queue

Input Queue


Co

mm

un

icat

ion

A

PI

Co

llect

ive

In

fo A

PI

System Component (e.g., Task Execution

Engine)

No

tifi

cati

on

C

allb

ack

AP

I

RoutingRules

Messages

Input Handler

MessageLoggingService

Routing Rule

Engine

AdapterManager

Message Handler

Request Queues

Output Queues

Log Queue

Pe

er In

fo

AP

I

AuthenticationManager

cached

Figure 7: Concept of the Messaging and Routing Manager

1.2.3 Messaging and Routing Manager

The Messaging and Routing Manager is responsible for handling of internal and external

messages of the system. Figure 7 presents the internal structure and the communication

with external components of the Messaging and Routing Manager. Messages are sent to

peers, collectives, or components by this component.

Upon reception of a message the Message Handler handles the messages according

to the type of the receiver of the message. If the receiver of the message is a peer,

the Message Handler determines the corresponding adapter(s) that should be used for the

communication. If there are no adapters available, new ones have to be created. Therefore,

the Message Handler queries the Peer Info API (see Section 2.4.3) to retrieve the peer

profile information which contains the communication channels used by the peer. Since

this information does not change often, it can be cached to improve the performance of

further requests. Subsequently, the Adapter Manager is instructed to create new adapters

according to the peer’s preferred communication channels and delivery policies. After the

successful creation of adapters, the message is put in the corresponding Output Queues



of the adapters.

If the receiver of the message is a collective, the current members of the collective have

to be determined in order to initiate the communication. Therefore, the Message Handler

queries the Collective Info API (see Section 2.4.3). After receiving the members of

the collective, a new message is created and sent to every member using the procedure

described in the previous paragraph.

If the receiver of a message is an internal or external component, the Message Handler

directly forwards it to the corresponding component either by putting it into a special

queue or by notifying the Notification Callback API (see Section 2.4.3) of the corre-

sponding component. The Messaging and Routing Manager uses routing (described later

in this section) to be able to determine the corresponding component. If no receiver is

set for a message, the Message Handler notifies a platform component using the Notifi-

cation Callback API, because there is no possibility to determine a receiver due to the

stateless nature of SmartCom.

Platform components can register themselves with the Messaging and Routing Man-

ager to receive notifications upon messages through the Notification Callback API. All

registered callbacks implementing this API are invoked whenever a message arrives that

cannot be handled by SmartCom.

Besides the primary recipient of a message, further recipients of messages can be deter-

mined based on Routing Rules, which are handled by the Routing Rule Engine. Rules

can be added by platform components and applications to implement special communica-

tion patterns, or to simplify the communication and reduce overhead. For example, in an

application a message of a specific subtype is always transferred to a software service; the

message can be forwarded directly to the software instead of sending it the application

first.

The Input Handler pulls incoming input messages (e.g., a response from a peer) from

the Input Queue and incoming control messages (e.g., a communication error message)

from the Control Queue. Both messages are forwarded to the Message Handler that

determines their destination. It is possible to scale out the Input Handler to improve the

performance of the handling of input and control information.

The Message Logging Service is responsible for persisting of all sent and received

messages to a database. This information can be used to debug SmartCom, or to analyze

the data for determining incentives or constructing provenance graphs. Stored messages



can be retrieved by using the Message Query Service (see Section 1.4.1).

Routing There are two types of routing available in the proposed SmartCom. The

first type of routing is purely internal and represents the determination of corresponding

adapter(s) that have to be used for the communication with a peer. No routing rules are

involved in this process. This activity involves that the Adapter Manager be instructed

to instantiate new adapters if there are none available for a specific peer. This type of

routing also has to keep track of changes in the peer information of a peer because this

might result in the recreation/removal of previously instantiated adapters. Additionally,

the delivery policy (described later on) of a peer has to be tested for changes because this

might also trigger instantiations/removals of adapters using the Adapter Manager.

The second type of routing determines further recipients of a message based on the

following properties of messages: type and subtype, receiver, and sender. This routing

information can be added by providing Routing Rules which are stored in the Routing

Rule Engine. The resulting routing defines additional recipients of the message which can

either be peers, collectives, or internal and external components. Note that routing rules

with an empty recipient are not allowed due to obvious reasons. Routes are determined

by matching the properties of the message to properties of the routing rules, whereas

setting properties of the routing rules null matches every corresponding property of the

message. The route is determined by the properties in ascending order. First, the type

is determined, afterwards the subtype, then the receiver and finally the sender of the

message. Because null matches anything, it is not allowed to provide a routing rule with

the type, subtype, receiver, and sender being all null. This restriction prohibits that all

messages of the system are forwarded to a single peer.

The second type of routing adds flexibility to the system in terms of communication. It

allows applications to implement special communication patterns – e.g., a monitoring peer

that logs all the messages sent to a specific collective without being part of the collective.

1.2.4 Handling of Policies

SmartCom handles two types of policies. The first type are peer-specific privacy policies

which have to be considered when sending a message to a peer. Privacy policies might

restrict the sending of messages based on their properties or at a certain time (e.g., during

the night) which means that the sending has to be aborted. Privacy policies of peers



are managed outside of SmartCom and are retrieved by calling the Peer Info API (see

Section 2.4.3).

The second type of policies are the delivery policies. There are multiple levels where

they have to be considered and enforced. They are described in the following:

1. The first level of delivery policy enforcement is on the message level. At this level

it is possible to specify how messages are delivered, initially there is just an option

to determine whether a successful sending of a message is acknowledged or not. In

general the delivery policies on this level and any other level are not restricted to

this behavior. They can be easily extended in further versions of SmartCom.

2. The second level of delivery policies is concerned with the peer delivery policies.

Besides specifying the preferred communication channels in peer’s profile (in an

external component), these policies can also specify how a peer is to be contacted

using these addresses. The options TO ALL (all addresses are used), TO ANY

(any address is used) and PREFERRED (preference is expressed by the order of

addresses) are currently provided. The enforcement of these policies is handled by

the Messaging and Routing Manager. When a message is sent to a peer, the manager

registers a handler that listens for acknowledgement messages from the corresponding

adapters which indicate a successful sending. Unsuccessful sending is indicated by

a communication error message of the adapter. The TO ALL policy requires that

all adapters are able to successfully send the message, whereas TO ANY requires

at least one adapter to be successful. The delivery policy PREFERRED fails if

the message could not be sent to the preferred adapter of the peer. In case of

an unsuccessful delivery based on the chosen delivery policy, a failure message is

forwarded to the sender of the initial message.

3. The third level of delivery policies is concerned with the sending of messages to

collectives. This information about delivery policies is provided by the Collective

Info API (see Section 2.4.3) and defines how messages should be sent to members of

the collective. Options include TO ALL MEMBERS and TO ANY. Upon sending a

message to a collective, there is also a handler registered to enforce the policy. The

behavior on this level is similar to the one on the peer level but successful sending is

indicated by a successful policy enforcement on the peer level. TO ALL MEMBERS

means that the sending of messages has to be successful for each peer based on the

peers’ delivery policies, if one of these policies fails, the enforcement on the collective



level fails too. On the other hand the TO ANY policy only requires the sending to

one peer to be successful.

Note that the failure of a policy enforcement is always reported to the sender of the

initial message, the success case is just reported if required by the policy on the message

level of the initial message.

1.3 Message Broker

The purpose of the Message Broker is to decouple the executions of the various compo-

nents of SmartCom. Furthermore, it is used to implement the first type of routing (see

Section 1.2.3) to send messages to the correct adapters that have to forward it to the

peers. Some of the queues of the Message Broker have already been mentioned in previous

chapters, in the following we briefly describe all available queues that are used within the

system:

• Control Queue: contains messages that have been sent by internal components

and are needed to control the internal flow of messages, to forward results of in-

ternal service invocations (e.g., answer of an authentication request), to indicate

(communication) errors, or to enforce delivery policies.

• Input Queue: a single queue that is filled with input messages of peers by all Input

Adapters. These messages are handled by the Messaging and Routing Manager

according to the specified receivers and additional routing rules.

• Output Queues: contain the output messages that should be handled by adapters

to send a message to a peer over a communication channel. There is exactly one

output queue for each Output Adapter.

• Request Queues: used to force Input Pull Adapters to perform a pull. There is

one queue for each of these adapters so that they can be notified separately to pull

for new input.

• AUTH Queue: a special queue for messages that are intended for the Authenti-

cation Manager. Messages in this queue are authentication request messages (see

Section 2.3) which consist of the username and password so that peers can be au-

thenticated.




MessagesQuery Handler

Me

ssag

e Q

uer

y Se

rvic

e A

PI

Figure 8: Concept of the Message Query Service

• MIS Queue: a special queue for messages that are intended for the Message Info

Service. These messages are usually request messages (see Section 2.3) for informa-

tion about a certain message indicated by a certain type and subtype.

• Log Queue: intended for all messages that are handled within SmartCom and

that have to be logged. Messages in this queue are consumed by the Message Log-

ging Service of the Messaging and Routing Manager which saves the messages to a

database.

1.4 Services

1.4.1 Message Query Service

The Message Query Service provides an interface to query sent and received messages. Fig-

ure 8 presents the internal structure of the Message Query Service. The Query Handler

is responsible for the handling of queries and the execution of queries in the database. This

service can be used to query all internal and external messages that have been handled by

SmartCom.

1.4.2 Message Info Service

The Message Info Service provides information about messages based on their type and

subtype. It is used by peers to get information on how to interpret a message and how to

respond. Furthermore, it provides a human-readable description of the message’s struc-

ture and contents, as well as its semantic meaning and relation with other messages. This

service could also be improved to return an explanation how to interpret the message in

a machine-readable way. The prototype provides a simple textual description that the

worker can fetch to interpret the message semantics, especially with respect to related




MessageInformation

Request Handler

Me

ssag

e In

fo

Serv

ice

AP

I

Control Queue

MIS Queue

<<REST>>

System Component (e.g.,

Task Execution Engine)

Figure 9: Concept of the Message Info Service

messages. The service maintains a database to store the message information which is up-

dated through platform components. Figure 9 shows the internal structure of the Message

Info Service and how it is connected to the queues.

The service can be used by a peer either by sending a message info request (see Sec-

tion 2.3) to an adapter or by invoking a REST service that provides the corresponding

data. Since this data is application specific, it has to be provided by the application using

the Communication API (see Section 2.4.2).

2 Messages

SmartCom exchanges messages with platform components, the adapters as well as with

some internal components (i.e., the Authentication Manager and the Message Info Service).

The following section takes a look at how these messages look like, how the routing of

messages is handled and some predefined message types are discussed. Note that further

message types and subtypes can be defined by programmers of applications for a HDA-

CAS. The semantics of such message types and subtypes depend on the application that

created them.



2.1 Message Structure

The following section presents the structure of messages that are used within SmartCom.

The structure is quite similar to the FIPA ACL Message Structure [1], but some properties

have been removed and others added to fit the requirements of SmartCom.

Each message consists of several mandatory and optional fields. The most important

fields of a message are the Id of the message, the sender, the type and subtype. These and

further fields are discussed and described in Table 1. Listing 1 outlines a simple message

containing instructions for a task in the JSON format.

1 {

2 "id": "2837" ,

3 "type": "TASK",

4 "subtype ": "REQUEST",

5 "sender ": "peer291",

6 "receiver ": "peer2734",

7 "conversation -id": "18475" ,

8 "content ": "Check the status of system 32"

9 }

Listing 1: Example message with instructions for a task

After receiving a message, Output Adapters are responsible to transform them to the

appropriate technology-related and peer-understandable representation and send the mes-

sage using a communication channel. On the other hand, Input Adapters are responsible

for the transformation of received messages of a technology-related message format (e.g.,

email) to an internal message. Messages that are related to a specific execution of an

application are required to have a execution-dependent conversation-Id, otherwise it is

not possible to associate a message with the corresponding execution. Note that Smart-

Com does not use the conversation-Id internally, this functionality has to be provided by

platform component.

2.2 Routing of Messages

The routing of messages is handled by the Messaging and Routing Manager according

to rules based on the message’s type, subtype, receiver and sender. The order (type,

subtype, receiver, sender) also defines the priority, which means that the type has the

highest priority and the sender the lowest. Further information on routing can be found

in Section 1.2.3.



Field Description

Type This field defines the high-level purpose of the message (e.g., control mes-sage, input message, metrics message, etc.). This field is especially impor-tant for the routing of messages within the system.

Subtype This field is defined by the component that is in charge of the message(i.e., it is component specific). The subtype combined with the type of themessage defines the purpose of the message. The subtype can also be usedby programmers of applications to define custom message types for theirapplication.

Message-Id A global unique identifier is assigned to every message within the systemby the Messaging and Routing Manager.

Sender-Id The sender-Id specifies the sender of the message (can be a component,peer, etc.). Sender-Ids are unique within the systems. Sender-Ids are eitherpredefined in case of an internal component or are assigned by platformcomponent.

Receiver-Id(o)

The receiver-Id specifies the receiver of the message (can be a component,peer, collective). Can also be empty if the receiver is not clear.

Conversation-Identifier(o)

Denotes the system identifier for the conversation. This identifier can beused by platform components to map the message to the actual executioninstance of an application. For example: application A is executed twiceat the same time: A1 and A2. The conversation-Id is used to associate themessages with the right executions A1 or A2. If there is no conversation(e.g., for internal messages), the conversation-Id can also be empty.

Content (o) Defines the content of the message including instructions and data thatare needed to execute the message. This can be empty in case of simplemessages (e.g., acknowledge messages).

TTL (o) Time to live. Defines a time interval in which a message is valid. Forexample: a peer has one hour to post pictures in a folder of a FTP server,after this time SmartCom stops looking for pictures in the folder andcreates an error message if there are no pictures.

Language(o)

Denotes the language of the message. This can be a natural language,like English or German, as well as a computer format like binary. Theinitial intention of this field are logging and debugging purposes. In futureversions a translation service could be introduced that makes use of thisfield.

Security-Token (o)

The security token can be used to guarantee the authenticity of messagesor to encrypt the content of the message.

Delivery-Policy (o)

Specifies the delivery policy of the message. This field can be used to specifyif the sender wants an acknowledgement in case of a successful sending ofthe message.

RefersTo (o) This field can be used to specify that this message refers to another mes-sage.

Table 1: Structure of messages. Optional fields are marked with (o).



2.3 Predefined Messages

These messages are needed for special purposes, like authentication, or to indicate specific

behavior (i.e., an acknowledged message) or exceptional cases and errors. The following

sections describe these predefined messages and define their intended usage in the system.

The subtypes of the messages are defined in the corresponding rows within brackets and

in capital letters.

2.3.1 Control Messages

Control messages are exchanged within SmartCom and are exposed to the application.

Control messages are always indicated by the message type CONTROL. Their intention

is to indicate specific control behavior (e.g., acknowledgement of a message) or exceptions

during the communication. They are described in detail below. Table 2 presents the

various subtypes.

Message Description

Acknowledge(ACK )

This message is sent by the output adapter if the message has beensuccessfully sent to the peer. Note that this does not imply peer’sacceptance of the contents of the message, but is used to implementfunctionalities such as read receipts. This message is not sent if theprogrammer requires a fire-and-forget sending behavior (i.e., shedoesnt care if it actually has been delivered).

Error (ERROR) An error message that indicates a generic error. This message ishandled based on the routing rules.

CommunicationError(COMERROR)

This error message indicates an error during the communication.This is reported to the sender of the initial message.

Timeout(TIMEOUT )

This message indicates that a time out has appeared in the systemand that the message couldn’t be delivered in time or there was noresponse within a certain time.

Table 2: Predefined subtypes of Control Messages.

2.3.2 Message Info Messages

These messages are handled by the Message Info Service (see Section 1.4.2) and are in-

tended for requests of message information by peers over dedicated input adapters and

for the reply of such a request. All such messages are required to have the message type

MESSAGEINFO. Table 3 presents the two subtypes of message info messages.



Message Description

Message InfoRequest (RE-QUEST )

Request by a peer to the Message Info Service for information onhow to interpret and handle a given message based on its type, andsubtype.

Message Info Re-sponse (REPLY )

Response of the Message Info Service to a peer that contains infor-mation on how to interpret and handle a given message.

Table 3: Message Info Request and Reply Messages.

2.3.3 Authentication Messages

Authentication messages are used to perform authentication of a peer in the system and

provide him with a security token that is valid for a specific time period (internally called

session). Such messages are handled by the Authentication Manager (see Section 1.2.2)

which interacts with platform component to verify the identify of a peer. Further informa-

tion can be found in section 1.2.2. Authentication messages always have the type AUTH.

AuthenticationRequest messages are sent by peers to the system whereas the three other

messages (AuthenticationResponse, AuthenticationFailed, AuthenticationError) are sent

back from SmartCom to the peer. Table 4 describes the used subtypes.

Message Description

AuthenticationRequest (RE-QUEST )

Authentication request message of a peer that contains its creden-tials. The Authentication Manager queries platform component toverify the peer’s credentials. After the successful verification, a se-curity token is created and sent to the peer.

AuthenticationResponse (RE-PLY )

Response message for an authenticate request message from Smart-Com to the peer. It contains a security token that can be used infurther requests to verify the identity of a peer.

AuthenticationFailed (FAILED)

Special response for an authenticate request message from Smart-Com to the peer that indicates that the authentication failed. Thepurpose of this message is to distinguish between the cases of afailed authentication and a authentication error on the basis of themessage’s subtype.

AuthenticationError (ERROR)

Special response message for an authenticate message from Smart-Com to the peer that indicates that there was an error during theauthentication of the peer. Such an error might be that, for exam-ple, no external platform component is available that can verify thecredentials.

Table 4: Authentication Messages.



2.4 Application Programming Interfaces (APIs)

The following section takes a look at the API of SmartCom. First, we examine the

public entities that are needed to interact with the system. Afterwards, we take a look at

the callback entities that are needed by SmartCom to get required information for the

communication. Finally, the interfaces and their methods are described in detail to get an

understanding on how to interact with the system.

2.4.1 Data Structures

Table 5 presents the data structures that are exchanged between SmartCom and the

platform components. They are mainly used by the public entities described in Section

2.4.2, and the callback entities described in Section 2.4.3.

2.4.2 Public Entities

Table 6 describes the interfaces that are exposed by SmartCom to clients. These entities

are required to interact with the system and receive response. The interfaces and their

methods are described in the following sections in detail.

Communication API This section discusses the main API for the interaction with

peers, collectives, and SmartCom for the purpose of communication. It provides methods

to start the interaction with collectives and peers, and also defines methods to extend and

manipulate the behavior of SmartCom. Figure 10 presents the Communication API in

UML notation.

public Identifier send(Message message) throws CommunicationException

Send a message to a collective or a single peer. The method assigns an Id to

the message and handles the sending asynchronously, i.e., it returns immediately and

does not wait for the sending to succeed or fail. Errors and exceptions thereafter

are sent to the Notification Callback API (see Section 2.4.3). Optionally, received

acknowledgments are communicated back through the Notification Callback API.

The receiver of the message is defined by the message, it can be a peer, a collective,

or a component. If the receiver is not set, the message will be sent back to the



Entity Description

Identifier Defines an identifier object that distinguishes between differenttypes (peer, collective, component, message) and Id combina-tions.

Message Message that is exchanged between applications, SmartComand peers. There are also internal messages that are justhandled between SmartCom components, or applications andSmartCom components. See Section 2 for details.

RoutingRule Defines a rule of how messages should be handled withinSmartCom. This feature can be used to improve the han-dling of messages and increase the performance. A commonuse case is that a response message from peer A of a specifictype is always be sent to peer B. See Section 2.2 for details.

PeerChannelAddress Defines an address for a communication channel of a peer thatcan be handled by a specific adapter. It contains a list of pa-rameters that can be used by an adapter to contact the peer(e.g., an email address). The number of parameters, their syn-tax and semantic meaning depend on the adapter. See Section1.1 for details.

QueryCriteria An entity that can be used to specify the criteria of a query. Itis created using the Message Query Service. After specifyingthe criteria, a call can be made to query the database.

PeerInfo Provides communication related information about a specificpeer such as the used communication channels (PeerChan-nelAddresses), delivery policies defined by the peer as well asprivacy policies that restrict the communication behavior. Apeer is identified by an Identifier object.

CollectiveInfo Provides the members of a specific collective as well as the col-lective’s delivery policy. A collective is identified by an Identi-fier object.

Table 5: Domain model and data structures of the SmartCom.



Entity Description

Communication Main entity that is used for the communication with Smart-Com. New messages are sent using this interface and it alsoallows to register new adapters and routing rules.

OutputAdapter Adapter that is responsible to send messages to peers. Thereare two types of OutputAdapters: stateless and statefuladapters.

InputPushAdapter Adapters that receive messages from peers via push communi-cation.

InputPullAdapter Adapters that receive messages from peers via pull communi-cation, i.e. they query the corresponding endpoint in regularintervals.

MessageInfoService Provides information on a specific message, i.e. how to interpretthe message and the relationship to other messages.

MessageQueryService Service that allows to query persisted messages.

Table 6: Public entities of SmartCom that are used to interact with the system.

<<Interface>>

Communication

+ send(Message): Identifier+ addRouting(RoutingRule): Identifier+ removeRouting(RoutingRule): Identifier+ addPushAdapter(InputPushAdapter): Identifier+ addPullAdapter(InputPullAdapter, long): Identifier+ addPullAdapter(InputPullAdapter, long, boolean): Identifier+ removeInputAdapter(Identifier):InputAdapter+ registerOutputAdapter(Class<? extends OutputAdapter): Identifier+ removeOutputAdapter(Identifier):void+ registerNotificationCallback(NotificationCallback): Identifier+ unregisterNotificationCallback(Identifier): boolean

Figure 10: Communication API



Notification Callback API immediately.

Parameters

message - Specifies the message that should be handled by SmartCom.

The receiver of the message is defined by the message.

Returns

Returns the internal Id of SmartCom to track the message within the

system.

Throws

CommunicationException - A generic exception that is thrown if something

went wrong in the initial handling of the message.

public Identifier addRouting(RoutingRule rule) throws InvalidRuleException

Add a route to the routing rules (e.g., route input from peer A always to peer

B). Returns the Id of the routing rule (can be used to delete it). SmartCom checks

if the rule is valid and throw an exception otherwise.

Parameters

rule - Specifies the routing rule that should be added to the routing rules

of SmartCom.

Returns

Returns SmartCom internal Id of the rule

Throws

InvalidRuleException - If the routing rule is not valid (e.g., all fields are

null).



public RoutingRule removeRouting(Identifier routeId)

Remove a previously defined routing rule identified by an Id. As soon as the

method returns the routing rule is not applied any more. If there is no such rule with

the given Id, null is returned.

Parameters

routeId - The Id of the routing rule that should be removed.

Returns

The removed routing rule or null if there is no such rule in the system.

public Identifier addPushAdapter(InputPushAdapter adapter)

Adds an input push adapter that waits for push notifications. Returns the Id

of the adapter.

Parameters

adapter - Specifies the input push adapter.

Returns

Returns SmartCom internal Id of the adapter.

public Identifier addPullAdapter(InputPullAdapter adapter, long interval)

Adds an input pull adapter that pulls for updates in a certain time interval.

Returns the Id of the adapter. The pull requests are issued in the specified interval

until the adapter is explicitly removed from the system.

Parameters



adapter - Specifies the input push adapter.

interval - Interval in milliseconds that specifies when to issue pull requests.

Can not be zero or negative.

Returns


public Identifier addPullAdapter(InputPullAdapter adapter, long interval, boolean

deleteIfSuccessful)

Adds an input pull adapter that pulls for updates in a certain time interval.

Returns the Id of the adapter. The pull requests are issued in the specified interval. If

deleteIfSuccessful is set to true, the adapter is removed in case of a successful execu-

tion (i.e., a message has been received), it continues in case of a unsuccessful execution.

Parameters

adapter - Specifies the input pull adapter.

interval - Interval in milliseconds that specifies when to issue pull requests.

Can not be zero or negative.

deleteIfSuccessful - delete this adapter after a successful execution

Returns


public InputAdapter removeInputAdapter(Identifier adapterId)

Removes a input adapter from the execution. As soon as this method returns,

the adapter with the given Id is not executed any more. It returns the requested

input adapter or null if there is no adapter with such an Id in the system.



Parameters

adapterId - The Id of the adapter that should be removed.

Returns

Returns the input adapter that has been removed or nothing if there is no

such adapter.

public Identifier registerOutputAdapter(Class<? extends OutputAdapter>

adapter) throws CommunicationException

Registers a new type of output adapter that can be used by SmartCom to get in

contact with a peer. The output adapters are instantiated by SmartCom on demand.

Note that these adapters are required to have an @Adapter annotation which describes

the name and the type of the adapter (stateful or stateless). Otherwise an exception

is thrown. In case of a stateless adapter, it is possible that the adapter is instanti-

ated immediately. If any error occurs during the instantiation, an exception is thrown.

Parameters

adapter - The output adapter that can be used to contact peers.

Returns

Returns SmartCom internal Id of the registered adapter.

Throws

CommunicationException - If the adapter could not be handled, the specific

reason is embedded in the exception.

public void removeOutputAdapter(Identifier adapterId)

Removes a type of output adapters. Adapters that are currently in use are re-



moved as soon as possible (i.e., current executions of communication will not be

aborted and waiting messages in the adapter queue are still transmitted).

Parameters

adapter - Specifies the adapter that should be removed.

public Identifier registerNotificationCallback(NotificationCallback callback)

Register a notification callback that is called if there are new input messages available.

Parameters

callback - Callback for notification.

Returns

Returns SmartCom internal Id of the registered notification callback (can

be used to remove it).

public boolean unregisterNotificationCallback(Identifier callback)

Unregister a previously registered notification callback.

Parameters

callback - Callback for notification.

Returns

Returns true if the callback could be removed, false otherwise.

Output Adapter API The Output Adapter API is used to implement an adapter

that can send (push) messages to a peer. Therefore, the push method has to be imple-



mented. Output Adapters receive a message from SmartCom, transform this message

to the adapter specific format (e.g., email) and push it to the peer over an external com-

munication channel (e.g., send the message to a web platform or a mobile application).

As described in Section 1.1 there are Stateless Output Adapters and Stateful Output

Adapters. Stateless adapters are required to have a default constructor (no parameters)

whereas stateful adapters can have a default constructor or a constructor with a single

parameter of type PeerChannelAddress. Stateful Output Adapters are created on demand

by SmartCom. Figure 11 presents the Output Adapter API in UML notation.

<<Interface>>

OutputAdapter

+ push(Message, PeerChannelAddress): void

Figure 11: Output Adapter API

public void push(Message message, PeerChannelAddress address) throws AdapterEx-

ception

Push a message to the peer. This method defines the handling of the actual

communication between the platform and the peer.

Parameters

message - Message that should be sent to the peer

address - The address of the peer and adapter specific contact parameters.

Throws

AdapterException - If an exception occurred during the sending of a message

Input Push Adapter API The Input Push Adapter API is used to implement an

adapter for a communication channel that uses push to get notified of new messages.

The concrete implementation has to extend the InputPushAdapter class, which provides

methods that support the implementation of the adapter. The external tool/peer pushes

the message to the adapter, which transforms the message into the internal format and calls



the publishMessage of the InputPushAdapter class. This method delegates the message

to the corresponding queue and subsequently to the correct component of the system that

handles input messages. The adapter has to start a handler for the push notification (e.g.,

a handler that uses long polling) in its init method and remove this handler in the cleanUp

method (e.g., a server socket).

<<Abstract>>

InputPushAdapter

+ publishMessage(Message): void# schedule(PushTask): void# cleanUp(): void# init(): void

Figure 12: Input Push Adapter API

public void init()

Method that can be used to initialize the adapter and other handlers like a

push notification handler (if needed). For example, to create a server socket that

listens for connections on a specific port.

public void cleanUp()

Clean up resources that have been used by the adapter. Scheduled tasks using

the schedule(PushTask) method have already been marked for cancellation, when this

method is called.

protected void publishMessage(Message message)

Publish a message that has been received. This method has to be called when

implementing a push service to notify SmartCom that there was a new message.



Parameters

message - Message that has been received.

protected void schedule(PushTask task)

Schedule a push task that is executed in the context of the adapter. This

method should be used to reduce the resource consumption of push adapters by using

an executor service. Using this method also guarantees the clean removal of adapters

from the execution.

Parameters

task - Task that should be scheduled

Input Pull Adapter API The Input Pull Adapter is dedicated to pull messages from

external tools or peers. For example, it can query a FTP server if there is a new file avail-

able. Instances of input adapters are always related to a single application and therefore

in the context of the application, because their semantics depend on the application. Each

Input Pull Adapter is executed by a single Adapter Execution of the Adapter Manager

(see Section 1.2.1), which is responsible to call the pull method in certain intervals. Input

Pull Adapters are created by applications and therefore provided with the initialization

parameters by the application itself, implying a stateful adapter.

Having a stateful pull adapter has some advantages:

• The state of the communication (e.g., the corresponding execution Id of input mes-

sages) is always saved in the adapter and there is no need to save it in the Adapter

Manager.

• race conditions due to the parallel execution of a single adapter are not possible be-

cause each adapter is only executed by a single thread. Therefore, no synchronization

has to be applied to the adapter.



• The pull method does not require any parameters. Specific settings for adapters

(e.g., an URL) can be set during the instantiation of the adapter and there is no

need for a dirty parameter passing to a stateless adapter (e.g., a map or list of

objects/strings).

This approach also has some disadvantages:

• Input Pull Adapters have to be created by a platform component or on higher levels

(e.g., at the programming level).

• There might be a problem if too many adapters are running at the same time due

to the amount of resources (i.e., memory) or required execution time. Due to the

design of the Adapter Manager the Adapter Execution Engine could run on multiple

machines which would eliminate or at least reduce this problem.

• Adapters have to be cleaned up properly by the creator of the adapter

<<Interface>>

InputPullAdapter

+ pull(): Message

Figure 13: Input Pull Adapter API

public Message pull() throws AdapterException

Pull data from a predefined location. If there is no data available, null is re-

turned.

Returns

Returns a new message or null if there is no new information.

Throws

AdapterException - If an exception occurred during the pull operation.



Message Info Service API The Message Info Service provides information about the

semantics of messages, how to interpret them in a human-readable way and which messages

are related to a message. Therefore, it provides methods to query message information

and to add additional information to messages.

<<Interface>>

MessageInfoService

+ getInfoForMessage(Message): MessageInformation+ addMessageInfo(Message, MessageInformation): void

Figure 14: Message Info Service API

public MessageInformation getInfoForMessage(Message message) throws Un-

knownMessageException

Returns information about a given message to the caller. This contains how

the message has to be interpreted, how it is related to other messages and which

messages are expected in response to this message.

Parameters

message - Instance of a message. Must contain at least either the mes-

sage Id or the message type, other parameters are optional, are used as a

template.

Returns

Returns the information about a given message

Throws

UnknownMessageException - If no message of that type found or the Id of

the message is not valid.



public void addMessageInfo(Message message, MessageInformation info)

Add information on a given message. If there already exists information for a

message, it is replaced by this one.

Parameters

message - Specifies the message.

info - Information for messages of the type of parameter message.

Message Query Service API This service can be used to query the logged messages

that have been handled by the system. All internal and external messages are logged by

the Messaging and Routing Manager. To query the service, a QueryCriteria object has to

be used that specifies the query and executes the query.

<<Interface>>

MessageQueryService

+ createQuery(): QueryCriteria

Figure 15: Message Query Service API

public QueryCriteria createQuery()

Creates a query object that can be used to specify the criteria for the query.

Returns

Returns a query criteria object that can be used to specify parameters and

execute the query.



2.4.3 Callback Entities

Callback entities are used by the system to interact with platform components which are

not part of SmartCom but that SmartCom communicates with and depends on for

specific features. The corresponding components have to implement the callbacks in order

to be able to communicate with them. Table 7 presents an overview of the available

callback entities. These entities are described in detail in the following sections.

Entity Description

PeerAuthenticationCallback The Peer Authentication Callback is used by the system toverify the identity of a peer (used for authentication) andto provide security functionalities.

PeerInfoCallback The Peer Info Callback is used to resolve peer informationabout a peer. This information does not change very oftenbut is queried quite frequently, therefore retrieved datashould be cached as long as the callback does not providethe required performance throughput.

CollectiveInfoCallback The Collective Info Callback is used by SmartCom to re-solve the peers that are in a collective. This informationcannot be stored in SmartCom because it changes fre-quently, two consecutive calls might not result in the sameresponse.

NotificationCallback This Notification Callback is used by SmartCom to no-tify a platform component about messages that are notintended to be handled by SmartCom. This includes mes-sages like task results or task-related information like com-munication errors.

Table 7: Callback entities of SmartCom.

Peer Authentication Callback API This callback is used to authenticate a peer

within SmartCom because such information is not stored within the system but is pro-

vided by some platform component that implements this interface. After a successful

authentication a session should be created to avoid calling this callback too often due to

the unforeseeable performance impact.

public boolean authenticate(Identifier peerId, String password) throws PeerAuthen-

ticationException;



<<Interface>>

PeerAuthenticationCallback

+ authenticate(Identifier, String: boolean

Figure 16: Peer Authentication Callback API

Authenticates a peer, i.e. checks if the provided credentials match the peer’s

credentials in the system.

Parameters

peerId - Id of the peer.

password - Password of the peer

Returns

Returns true if the credentials are valid, false otherwise

Throws

PeerAuthenticationException - If an error occurs during the authentication.

Peer Info Callback API This callback is used to resolve information about a peer,

the so called PeerInfo. This information does not change very often but is queried quite

frequently, therefore, retrieved data should be cached as long as the callback does not

provide the required performance throughput.

<<Interface>>

PeerInfoCallback

+ getPeerInfo(Identifier): PeerInfo

Figure 17: Peer Info Callback API



public PeerInfo getPeerInfo(Identifier id) throws NoSuchPeerException

Resolves the information about a given peer (e.g., provides the address and

the adapter that should be used).

Parameters

id - Id of the requested peer

Returns

Returns information about a peer, such as the communication channel

addresses and the preferred delivery policy.

Throws

NoSuchPeerException - If there exists no such peer.

Collective Info Callback API This API is used to provide information regarding

the composition and the state of the collectives to SmartCom, in order for SmartCom

to allow to platform components the functionality of addressing their messages on the

collective level.

<<Interface>>

CollectiveInfoCallback

+ getCollectiveInfo(Identifier): CollectiveInfo

Figure 18: Collective Info Callback API

public CollectiveInfo getCollectiveInfo(Identifier collective) throws NoSuchCollec-

tiveException

Resolves and returns the members of a given collective Id.



Parameters

collective - The Id of the collective.

Returns

Returns a list of peer Ids that are part of the collective and other collective

related information.

Throws

NoSuchCollectiveException - If there exists no such collective.

Notification Callback API The Notification Callback is used to inform the different

platform components of the messages that arrived for them (e.g., to inform the components

about task results or other task-related information like an error) or that the receiver of

a message could not be determined.

Since SmartCom does not save any conversational state, it is not possible to determine

the right recipient if multiple platform components are implementing the Notification Call-

back API. Therefore, these components are required to be capable of handling (filtering)

unexpected messages.

<<Interface>>

NotificationCallback

+ notify(Message): void

Figure 19: Notification Callback API

public void notify(Message message)

Notifies the corresponding callback about task results or task-relation informa-

tion like an error.



Parameters

message - The received message.

2.5 Algorithms

The following section presents some important algorithms of SmartCom in pseudocode

which are needed for the creation and handling of adapters, as well as the handling and

routing of messages in SmartCom.

2.5.1 Creation of Output Adapters

Algorithm 2.1 describes how Output Adapters are created/instantiated in the Adapter

Manager (see Section 1.2.1) based on a peer’s delivery policy and the provided addresses

of communication channels.

The algorithm prefers Stateless Output Adapters over Stateful Output Adapters be-

cause they have a smaller impact on the performance of the system. All or at least multiple

peers share one Stateless Output Adapter, therefore, they have a lower resource usage.

Contrary to Stateful Output Adapters, Stateless Output Adapters are instantiated imme-

diately after their registration in the system, therefore, they are not instantiated using

this algorithm. On the other hand, Stateful Output Adapters are instantiated per peer

and on demand, because they have a higher resource usage in the system compared to

Stateless Output Adapters.

Depending on the chosen delivery policy the algorithm either instantiates a single

adapter (in case of the delivery policy PREFERRED) or multiple adapters (in case of

delivery policies TO ALL CHANNELS and AT LEAST ONE). Note that the ordering of

addresses defines the preference of communication channels (and therefore adapters) of

a peer. Also note that TO ALL CHANNELS means all available channels, therefore, it

is not an error if there is no adapter registered in the system that can handle a specific

address. The intentional meaning is that the sending to all available communication

channels has to succeed. The same applies for adapters that could not be instantiated due

to an error. Finally the algorithm returns the internal Ids of adapters, which are required

by the Messaging and Routing Manager and the Message Broker to send messages to

peers. If no adapters have been found, the returned list is empty.



1 Function createAdapterInstances isinput : Peer information (peerInfo)output: Identifiers of the created adapters

2 addresses = peerInfo.addresses;3 policy = peerInfo.deliveryPolicy;

4 for all address in addresses do

5 if there is a stateless adapter instance available for this address then6 add the address of the stateless instance to the result list;7 if policy == PREFERRED then8 return result list;9 else

10 continue with next address;11 end

12 else if there is a stateful adapter implementation for this address then

13 if there is already an instance of that adapter for this peer then14 add the address to the result list;15 if policy == PREFERRED then16 return result list;17 else18 continue with next address;19 end

20 end

21 instantiate new stateful adapter with a unique ID;22 add new instance to the instances of stateful adapters;23 add new instance to the result list;

24 if policy == PREFERRED then25 return result list;26 else27 continue with next address;28 end

29 else30 log that there was an unknown adapter;

31 end

32 endAlgorithm 2.1: Creation of adapters instances for a peer based on peer’s deliverypolicy.



2.5.2 Handling of Messages

Messages are handled by the Messaging and Routing Manager (see Section 1.2.3). Every

incoming message, regardless of whether it is from an internal component, an application

or a peer is handled by the handleMessage function. Algorithm 2.2 depicts the function.

Line 7 of the algorithm indicates the application of a routing rule which has been described

in Section 2.2.

First, the message is assigned with a unique message Id which is used to track the

message within SmartCom. Additional to the receiver of the message (can also be empty),

further receivers - if there are any - are determined by the Routing Rule Engine based

on routing rules (see Section 1.2.3). Note that the delivery policy handler is only created

if the receiver of the message has been set and it is only created for the first receiver.

This prevents the case of receiving an acknowledge and a communication error message

for messages that have been sent to multiple receivers. Further details on the enforcement

of delivery policies can be found in the following section. Finally the presented algorithm

forwards the message to the corresponding receivers.

Algorithm 2.3 describes how the messages are forwarded to a collective and Algorithm

2.4 describes how the messages are forwarded to single peers. The function calls register-

CollectiveMessageDeliveryAttempt and registerPeerMessageDeliveryAttempt indicate the

registration of a policy handler that observes whether a delivery policy has been enforced

for an outgoing message or if there was an error during communication (see the corre-

sponding paragraph in Section 1.2.4).

First, the algorithm retrieves the collective info from the CollectiveInfoCallback di-

rectly. This object contains information about the delivery policy of the collective as well

as the peers that are currently part of the collective. If required (indicated by the vari-

able createHandlers) a collective message delivery attempt is registered. Thereafter the

message is delivered to every peer which is currently part of the collective. Note that this

membership is subject to constant change.

Similar to sending messages to a collective, the peer info are retrieved first. It consists

of the delivery policy, privacy policies and contact addresses for adapters (which are not

used in this algorithm). First, the algorithm checks if a message is allowed to be sent to



1 Function handleMessage isinput : Message (msg)

2 if message Id is empty then3 create unique message ID;4 end

5 createPolicyHandlers = false;

6 if message receiver is not null then7 add the message receiver to the receiver list;8 createPolicyHandlers = true;

9 end

/* check if there are further receivers */

10 get further receivers from the routing engine (based on routing rules);11 add them to the receiver list;

12 if receiver list is empty then13 send error message to NotificationCallback;14 return;

15 end

16 for each receiver in receiver list do17 if receiver is component then18 forward message to component;19 continue;

20 else if receiver is collective then21 deliverToCollective(msg, receiver, createPolicyHandlers); // Alg. 2.3

22 else23 try24 deliverToPeer(msg, receiver, createPolicyHandlers); // Alg. 2.4

25 catch26 send error message to the sender of the message;

27 createPolicyHandlers = false;

28 end

29 endAlgorithm 2.2: Handling of messages in the Messaging and Routing Manager.



1 Function deliverToCollective isinput : Receiver (collective)

Message (msg)Boolean value whether to create delivery policy handler

(createHandlers)

2 retrieve collective info (collInfo) from CollectiveInfoCallback;

3 if createHandlers then// to trace the enforcement of delivery policies

4 registerCollectiveMessageDeliveryAttempt(msg, collInfo.deliveryPolicy);

5 end

6 for each peer in collInfo.peers do7 try8 deliverToPeer(msg, receiver, createHandlers); // see Alg. 2.4

9 catch10 enforceCollectiveDeliveryPolicy(new error message);

11 if collInfo.deliveryPolicy is TO ALL MEMBERS then/* delivery failed because the massage could not be sent

to everyone */

12 break;

13 end

14 end

15 endAlgorithm 2.3: Sending messages to a collective.



1 Function deliverToPeer isinput : Receiver (peer)

Message (msg)Boolean value whether to create delivery policy handler

(createHandlers)

2 retrieve peer info (peerInfo) from PeerInfoCallback;

3 for each policy in peerInfo.privacyPolicies do// check if policy allows sending messages

4 if !policy.condition(msg) then5 throw an exception;6 end

7 end

8 if createHandlers then// to trace the enforcement of delivery policies

9 registerPeerMessageDeliveryAttempt(msg, peerInfo.deliveryPolicy);

10 end

11 determine list of adapters (adapterList) from routing engine;

12 if adapterList is empty then13 throw exception;14 end

15 for each adapter in adapterList do16 send output message to adapter using the message broker;17 end

18 endAlgorithm 2.4: Sending messages to peers.



a peer at the moment based on its privacy policies. If required (indicated by the variable

createHandlers) a peer message delivery attempt is registered. The list consists of Ids of

adapters which can send the message to this peer. Finally, using the Message Broker the

message is sent to the peer over each adapter (indicated by its Id) that has been returned

previously by the routing engine.

Enforcing delivery policies As described in Section 1.2.4 there are multiple delivery

policies on three different levels (collective, peer and message level) which have to be

enforced. Handlers for these policies are registered during the sending of messages to peers

and collectives (see Algorithm 2.3 and 2.4) but the enforcement of policies is handled upon

reception of acknowledge and communication error messages which are sent by adapters.

Table 8 describes how the data structure to enforce collective delivery policies might

look like. The MessageID and the SenderID represent the composed key that identifies an

entry. There is a policy handler for every entry that keeps track of the policy enforcement

for a specific message and sender, and decides whether a policy has been enforced, if

there are still results missing or if it failed. The acronym CollPolEDS is used instead of

”collective delivery policy enforcement data structure” in the following.

MessageID SenderID Policy Policy Handler

msg1 sender1 TO ALL MEMBERS policyHandlerInstance1

msg2 sender2 TO ALL MEMBERS policyHandlerInstance2

msg3 sender1 TO ANY policyHandlerInstance3

Table 8: Data structure to enforce collective delivery policies (CollPolEDS). Underlinedentries indicate the composed key for each entry.

Table 9 describes the proposed data structure to enforce peer delivery policies. It

looks almost the same as the CollPolEDS except that the ID of the receiver is added to

the composed key. Multiple entries of this data structure might correspond to a single

entry in the CollPolEDS. In case of a message being sent only to a peer, there is no

corresponding entry in the CollPolEDS.

MessageID SenderID ReceiverID Policy Policy Handler

msg1 sender1 receiver2 TO ALL CHANNELS policyHandlerInstance1

msg2 sender2 receiver3 AT LEAST ONE policyHandlerInstance2

msg3 sender1 receiver1 PREFERRED policyHandlerInstance3

Table 9: Data structure to enforce peer delivery policies. Underlined entries indicate thecomposed key for each entry.



If a message is sent to a collective, a corresponding entry is created in the CollPolEDS.

For every peer in the collective an additional entry is created in the peer delivery policy

enforcement data structure. Ingoing acknowledge and communication error messages from

adapters are handled on the peer level first and only if that level indicates a successful or

erroneous enforcement of the delivery policy, the collective level is enforced. This behavior

can be observed in Algorithm 2.5 which handles the enforcement on the peer level. If there

is a corresponding entry in the CollPolEDS, the enforcement is redirected to the collective

level because the peer delivery policy has been successfully enforced (in case of Line 9) or

there was an error during enforcement (in case of Line 19).

Algorithm 2.6 describes the delivery policy enforcement on the collective level.



1 Function enforcePeerDeliveryPolicy isinput : Acknowledge or communication error Message (msg)

2 try3 if checkPeerDeliveryPolicy(msg) then // might throw an exception

4 entry = discardPeerPolicyEntry(msg);5 if entry == null then // Policy has already been enforced

6 return;7 end8 if collectiveDeliveryPolicyHasEntry(msg) then9 enforceCollectiveDeliveryPolicy(msg); // see Alg. 2.6

10 else if entry.messagePolicy == ACKNOWLEDGE then11 send acknowledgement to entry.sender;

12 end

13 catch/* msg can only be a communication error message */

14 entry = discardPeerPolicyEntry(msg);15 if entry == null then // Policy has already been enforced

16 return;17 end18 if collectiveDeliveryPolicyHasEntry(msg) then19 enforceCollectiveDeliveryPolicy(msg); // see Alg. 2.6

20 else21 send communication error message to entry.sender;

22 end

23 Function checkPeerDeliveryPolicy isinput : Acknowledge or communication error Message (msg)

24 policy = getPeerDeliveryPolicy(msg.id, msg.sender, msg.receiver);25 if policy == null then26 return false; // entry has already been evicted

27 end28 if msg.subtyp == ACKNOWLEDGE then29 return policy.check();30 else31 throw exception; // indicates that this is an error message

32 endAlgorithm 2.5: Enforcing a delivery policy on the peer level.



1 Function enforceCollectiveDeliveryPolicy isinput : Acknowledge or communication error Message (msg)

2 try3 if checkCollectiveDeliveryPolicy(msg) then // might throw an exception

4 entry = deleteCollectivePolicyEntry(msg);

5 if entry.policy == ACKNOWLEDGE then6 send acknowledgement to the entry.sender;7 end

8 end

9 catch10 entry = deleteCollectivePolicyEntries();

11 send error message to the entry.sender;

12 end

13 Function deleteCollectivePolicyEntry isinput : Message (msg)output: collective delivery policy entry

14 lock(collectiveDiscardCondition); // prohibits race conditions

// delete entries because policy has been enforced

15 entry = discardCollectivePolicyEntry(msg);16 for every corresponding entry in the peer delivery policy data structure do17 discardPeerPolicyEntry(entry);18 end

19 unlock(collectiveDiscardCondition);20 return entry;

21 end

22 Function checkCollectiveDeliveryPolicy isinput : Message (msg)output: true if delivery policy has been enforced, false otherwise

23 policy = getCollectiveDeliveryPolicy(msg.content, msg.sender);24 if policy == null then25 return false; /* policy has already been enforced */

26 end27 if msg.subtyp == ACKNOWLEDGE then28 return policy.checkAcknowledge(); /* returns true if this message

enforced the policy */

29 else30 return policy.checkError(); /* can throw an exception or just return

false */

31 endAlgorithm 2.6: Enforcing a delivery policy on the collective level.



3 Experimental Performance Evaluation

The following performance evaluation was made on a machine with the following specifi-

cations: Windows 7 64-bit, Intel Core2 Duo with 2x 2.53 GHz, 4.00 GB DDR2-RAM. The

simulation configuration is as follows:

• One implementation of a Stateless Output Adapter (one instance shared by all

peers).

• 10 Input Push Adapter to receive input from peers.

• Output and Input Adapters communicate directly using a in-memory queue to sim-

ulate a peer with a response time of zero.

• Worker threads (workers) simulate the number of applications/users that send mes-

sages to the system.

• One million messages are sent for each evaluation test run to get a meaningful average

number of messages sent/received.

• Only sent and received messages are considered as ’handled’, no internal messages.

Figure 20 depicts the setup for the performance evaluation as described above.

WorkersCommunication

MiddlewarePeers

Worker

Stateless Output Adapter

Input Adapter

WorkerWorker

simulated

10 instances

1 instance (scales)

1 mio messages

Figure 20: Setup for the performance evaluations.

The performance has been evaluated for every combination of 1, 5, 10, 20, 50 and 100

worker threads (Worker) simulating SmartSociety platform applications sending 1 · 106

messages concurrently, uniformly distributed to 1, 10, 100, and 1000 peers waiting for

messages and replying to them. Each test run has been executed 10 times to obtain

average throughput results. Figure 21 presents the results of the test runs. The test runs

can be reproduced using the stated setup data to configure the Java application located at



GitHub4. As one can see, the average throughput remains between 5000 and 3000 messages

per second. The performance decrease with higher amounts of peers is result of increased

memory requirements rather than computational complexity. The limiting factor here is

the used ActiveMQ message broker which only allows a maximum of approximately 20000

messages per second. The system has an upper bound of 5000 messages per second since

each message is handled multiple times by the message broker and the SmartCom. This

limitation applies to a single SmartCom instance, but multiple SmartCom instances

can be deployed to balance the load if needed, sharing the database and PeerManager

access. The chosen numbers of worker threads and peers cover the maximum number

of concurrent SmartSociety platform applications and collective members, respectively,

expected to use a single SmartCom instance. Performance is not expected to become a

primary concern of SmartCom due to the increased latency of human peers and variance

of response times compared to machine peers.

1 10 100 1000

0

1000

2000

3000

4000

5000

6000

Peers

Mes

sage

s/se

con

d

1 Worker

5 Worker

10 Worker

20 Worker

50 Worker

100 Worker

Figure 21: Measured message throughput. Workers simulate SmartSociety platform ap-plications sending out messages to the peers.

References

[1] A. Fipa, “Fipa acl message structure specification,” Foundation for Intelligent Physical

Agents, http://www. fipa. org/specs/fipa00061/SC00061G. html (30.6. 2004), 2002.

4https://github.com/tuwiendsg/SmartCom/blob/master/smartcom-demo/src/main/java/at/ac/

tuwien/dsg/smartcom/demo/PerformanceDemo.java


d7.1 - virtualization techniques and prototypes

Documents