Engineering Future Internet applications: The Prime approach

The Journal of Systems and Software 106 (2015) 9–27

Contents lists available at ScienceDirect

The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss

Engineering Future Internet applications: The Prime approach Mauro Caporuscio a,∗, Carlo Ghezzi b a b

Department of Computer Science – Linnaeus University, Växjö SE-351 95, Sweden Dipartimento di Elettronica, Informazione e Bioingegneria – Politecnico di Milano, P.zza L. Da Vinci 32, Milano 20133, Italy

a r t i c l e

i n f o

Article history: Received 23 June 2014 Revised 30 March 2015 Accepted 31 March 2015 Available online 14 April 2015 Keywords: Resource-oriented architecture Middleware Future Internet

a b s t r a c t The Future Internet is envisioned as a worldwide environment connecting a large open-ended collection of heterogeneous and autonomous resources, namely Things, Services and Contents, which interact with each other anywhere and anytime. Applications will possibly emerge dynamically as opportunistic aggregation of resources available at a given time, and will be able to self-adapt according to the environment dynamics. In this context, engineers should be provided with proper modeling and programming abstractions to develop applications able to benefit from Future Internet, by being at the same time fluid, as well as dependable. Indeed, such abstractions should (i) facilitate the development of autonomous and independent interacting resources (loose coupling), (ii) deal with the run-time variability of the application in terms of involved resources (flexibility), (iii) provide mechanisms for run-time resources discovery and access (dynamism), and (iv) enable the running application to accommodate unforeseen resources (serendipity). To this end, Prime (P-Rest at design/run tIME) defines the P-REST architectural style, and a set of P-REST oriented modeling and programming abstractions to provide engineers with both design-time and run-time support for specifying, implementing and operating P-RESTful applications. © 2015 Elsevier Inc. All rights reserved.

1. Introduction Since the first packet-switching network was deployed, the evolution of the Internet has been constant and produced a phenomenon that radically changed communications. While initially simply used to exchange data between hosts, today the Internet is essential for the development and provision of software resources (e.g., data, applications, services) distributed all over the world. Furthermore, wireless network technology (e.g., 4G, Wi-Fi Direct, and Bluetooth LE) allows autonomous mobile devices (e.g., sensors, smartphones, and real world objects) to both consume and provide software resources over the Internet. On the other hand, from the application-level perspective, the Internet evolution is characterized by a fast transition from “sharing” (Web1.0) and “contributing” (Web2.0) toward “contextualizing” (Web3.0), which encompasses machine-facilitated understanding and correlation of software resources. Several EU1 and USA2 research initiatives are currently focusing on the definition and development of the Future Internet (FI). According to the vision of the EU research initiative (Papadimitriou, 2009), FI

is built upon three key pillars – Internet of Things, Internet of Services, Internet of Contents – underpinned by a dynamic network infrastructure. FI is envisioned as a worldwide pervasive execution environment dynamically formed by interconnected real-world objects, which are all around us, everywhere and anytime, and can be discovered, correlated and consumed as needed. Indeed, FI can be considered as a worldwide network-based system,3 where a large open-ended collection of heterogeneous and pervasive resources dynamically interact with each other, to provide users with rich functionalities, e.g., content sharing, service provisioning, and real thing consumption. FI applications will dynamically emerge as opportunistic aggregation (Preda et al., 2012) of resources of interest available at any given time. To achieve this vision, key objectives are: (i) Abstraction to facilitate the design, implementation, and integration of software resources, irrespectively of their specific nature (i.e., thing, service, and content) and location, and (ii) Contextualization to support opportunistic discovery and correlation of resources of interest. Concerning abstraction, software engineering best practices suggest the exploitation of middleware solutions, which mask the distribution and heterogeneity of both the execution and the networking environments, and support the development of network-based

∗

Corresponding author. Tel.: +46 470708558. E-mail addresses: [email protected] (M. Caporuscio), [email protected] (C. Ghezzi). 1 http://www.future-internet.eu. 2 http://www.nets-find.net. http://dx.doi.org/10.1016/j.jss.2015.03.102 0164-1212/© 2015 Elsevier Inc. All rights reserved.

3 Network-based systems rely on explicit distribution of independent and autonomous components, which interact by means of (asynchronous) message passing (Tanenbaum & Van Renesse, 1985).

10

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

systems through the provision of proper mechanisms for designing and implementing software resources, as well as for deploying, publishing, discovering and binding them at run time (Issarny et al., 2007). Existing middleware solutions provide different types of abstraction – e.g., procedure, object, component, service – to deal with these issues. However, all the stability assumptions made on network-based systems are no longer valid in the continuously changing contexts that characterize FI, where mobility affects the dynamic availability of resources (Roman et al., 2000). As a result, FI applications can be viewed as a dynamic software architecture where both the entities and their interconnections can change at run time. In the FI setting, applications are required to be “fluid”. By this we mean that they must be able to accommodate continuous architectural changes, possibly without affecting their behavior (Kortuem, 2006). Therefore, key requirement is to provide developers with a set of proper abstractions enabling architectural fluidity: (i) loose coupling: entities are deployed and executed independently of other entities, (ii) flexibility: entities can be added and removed into the running application, (iii) dynamism: entities of interests are discovered and bound into the running application, and (iv) serendipity: unforeseen entities are accommodated into the running application. The literature defines context as “any information that can be used to characterize the situation of entities, such as individuals, places, or objects, that are deemed relevant to the interaction between a user and an application, including the user and the application themselves” (Dey et al., 2001). The term “contextualization” indicates that FI applications should be built by dynamically aggregating resources related to a particular situation, and be able to adapt to the evolving situation in which they operate, such as the physical environment and the computational entities populating it or the device on which the application runs. The challenges related to Contextualization concern the ability of discovering, understanding, selecting, and correlating resources of interests. Contextualizing resources of interest in an open-ended world asks for mechanisms to semantically describe both functional and extra-functional properties of the resources, and to reason about them and their actual context. To this end, semantic description of software artifacts demonstrated to be effective and has been being largely adopted in the context of Semantic Web (BernersLee et al., 2001), which employs ontologies as main building blocks to enable the semantic web vision. Contribution of the work – In this work we study FI from a software engineering perspective. Specifically, we develop a principled, middleware-supported architectural approach that is intended to support fluid applications. Our main contribution is twofold. First, we present a fully revised and extended version of the P-REST architectural style (Caporuscio et al., 2011), and define a set of modeling abstractions to provide engineers with design-time support for specifying P-RESTful applications.4 Second, we define a set of programming abstractions to provide engineers with run-time support for implementing and operating P-RESTful applications. Indeed, the Prime (P-Rest at design/run-tIME) approach provides both modeling and programming abstractions for (i) uniformly representing things, services and contents as resource, and (ii) developing FI applications as opportunistic aggregations of contextualized resources. To assess the applicability of our approach, we evaluate Prime’s modeling and programming abstractions in supporting the development of a set of FI applications, namely Smart City Pulse, Smart Slide Show, and Smart eHealth. We also empirically evaluate the effectiveness of Prime’s middleware in supporting resource management, discovery, provision, and interaction. The paper is structured as follows: Section 2 introduces a motivating scenario further used as running example throughout the paper, and Section 3 discusses related work. Sections 5 and 6 discuss design

4

That is, applications that conform to the P-REST style.

Fig. 1. Smart City Pulse application – scenario.

rationale for resource abstraction and contextualization, respectively, whereas Section 7 details their implementation. The assessment of Prime is carried out in Section 8, which evaluates both efficacy and efficiency of the approach. Finally, Section 9 concludes the paper and sketches our perspectives for future work. 2. Motivating scenario This section introduces Smart City Pulse, a Future Internet application that serves as running example throughout the paper to illustrate the proposed approach. Smart City Pulse is a crowdsourcing application that aims at finding, retrieving, and monitoring data produced by a networked sensing infrastructure made of sensors embedded in end-user mobile devices (e.g., GPS, temperature), public utilities (e.g., smart metering, surveillance, traffic and pollution monitoring), and many other kinds of sensing systems. Referring to Fig. 1, Smart City Pulse is composed of: (i) an open-ended set of heterogeneous Sensors deployed within the city, and (ii) a Monitoring Service that analyzes the data gathered from the sensors. Functional requirements for Smart City Pulse are specified as follows: R0: Sensors are deployed on mobile devices, and may enter/leave the network dynamically. R1: Sensors are autonomous and the Monitoring Service has no apriori knowledge of them. R2: The number of Sensors engaged in the application changes over the time. R3: The types of Sensors engaged in the application change over the time. R4: A Monitoring Service dynamically discovers and accesses new sensors. For instance: (R4.0) all Sensors in the network, irrespectively of their specific type; (R4.1) all Sensors of a given type (e.g., temperature); (R4.2) all Sensors within a given area (e.g., downtown); and (R4.3) all Sensors related to a given situation (e.g., weather report). 3. Related work Related work spans several research areas, from pervasive computing to software architecture and semantic web. This section focuses on related work in the two areas where Prime mainly contributes, namely engineering resource abstraction and engineering resource contextualization. 3.1. Engineering resource abstraction Software engineering best practices suggest to support the development of network-based applications through the exploitation of middleware, which provides engineers with abstractions for designing and implementing networked software resources (Issarny et al., 2007).

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

11

Fluid Architecture

Properties

is characterized by

Flexibility

is concerned with

Activities

facilitates

facilitates

Loose Coupling

is concerned with

Deploy/execute independent entities

Add/remove entities

facilitates

Dynamism

is concerned with

Discover and bind entities

Serendipity

is concerned with

Accommodate unforeseen entities

Fig. 2. Fluid architecture conceptualization.

Table 1 Distributed design models.

RPC OO CB SOA REST

Abstraction

Coupling

Flexibility

Dynamism

Serendipity

Procedure Object Component Service Resource

Tight Tight Loose Loose Loose

✗ √ √ √ √

✗ ✗ ✗ √ √

✗ ✗ ✗ ✗ √

The choice of the middleware is quite critical, because it affects the resulting software architecture. It has been argued, in fact, that each specific middleware imposes structural/behavioral constraints, and has structural/behavioral properties that might be well-suited for some situations and ill-suited for others (Di Nitto & Rosenblum, 1999). By choosing a middleware that induces a wrong structure/behavior one might prevent the application from achieving certain properties of interests. As discussed earlier, FI applications are characterized by a highly dynamic structure where both the resources and their interconnections may change at run time. To accommodate the required architectural fluidity, FI applications adopt “a software architecture that can accommodate continuous structural change without aversely affecting the system behaviour” (Kortuem, 2006). The notion of a fluid architecture, already introduced in Section 1 as characterized by loose coupling, flexibility, dynamism, and serendipity, is detailed in Fig. 2, which also highlights the set of run-time activities each property is concerned with. Many different architectural styles have been proposed to develop, and reason about, distributed systems. Table 1 classifies them with reference to the set of fluid architecture properties. The oldest architectural style for distributed systems is Remote Procedure Call (RPC), which is based on functional distributed procedures synchronously accessed through the network. This supports a client–server interaction, where: (i) client and server are tightly coupled, (ii) adding/removing procedures strongly affects the behavior of the overall network-based system, (iii) binding between procedures is statically defined and cannot vary (new procedures cannot be discovered at run time), and (iv) heterogeneous and unforeseen procedures cannot be accommodated within the running application since their signatures must be know in advance. Referring to a FI application like Smart City Pulse, RPC fails to provide the application with the required architectural fluidity, and thus it prevents the fulfillment of functional requirements. Object Oriented (OO) architectural model supports the development of distributed systems through objects, which encapsulate state information and expose the methods needed to manipulate such in-

ternal state. Although OO raises the level of abstraction, it suffers from the same problems of RPC: (i) interacting objects are tightly-coupled and bound at compile time, (ii) object instances can be added/removed as the system is running, (iii) once a reference to a remote object is set, normally it does not change at run time, and there is no predefined way of making objects discoverable, and (iv) heterogeneous and unforeseen objects cannot be accommodated within the running application since their signatures must be known in advance. Still referring to Smart City Pulse, OO does not satisfy some of the fluid architectural properties: requirements R0, R1, R3 and R4 cannot be fulfilled. Component Based (CB) architectural style further enhances OO model by providing for entity independence. Specifically, CB supports the development of distributed systems through components, which are independent executable entities exposing their functionalities through interfaces: (i) components are independent and looselycoupled entities, (ii) components can be added/removed as the system is running, (iii) references to remote components do not change at run time, and there is no standardized way of making components discoverable (i.e., supporting this feature requires for additional ad-hoc effort), and (iv) heterogeneous and unforeseen components cannot be accommodated within the running application since their interfaces must be known in advance. Concerning Smart City Pulse, CB does not satisfy some of the fluid architectural properties: requirements R0, R3, and R4 cannot be fulfilled. Service Oriented Architecture (SOA) abstracts networked entities as autonomous software services that can be accessed irrespectively of their underlying technologies: (i) services are independent and loosely-coupled entities, (ii) they can be easily added/removed, irrespective of their base technology, (iii) binding between them can in principle be dynamically established at run time (although in existing SOA application this is not common practice), and may be discovered through the Service Registry, which stores the binding information required to access the services, and (iv) heterogeneous and unforeseen services cannot be easily accommodated within the running application since service access is regulated by their own interfaces, which must be known in advance. Concerning Smart City Pulse, SOA fails to support requirements R0, R3, R4.2, and R4.3. REpresentational State Transfer (REST) abstracts networked entities as autonomous and univocally addressable resources implementing a uniform interface and interacting with each other by means of a stateless communication protocol. In summary: (i) resources are independent and loosely-coupled entities, (ii) resources can be easily added, removed and accessed, irrespective of their underlying technology, (iii) although REST does not provide any specific discovery mechanism (such as the Service Registry defined by SOA), dynamic resource discovery and access are supported through Connectedness

12

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

(see Section 5), and (iv) heterogeneous and unforeseen entities can be easily accommodated within the running application since resource access is regulated by a uniform interface. Concerning Smart City Pulse, although REST provides all fluid architecture characteristics, it fails to support two key requirements: R0 and R4. Requirement R0, which concerns resource mobility, is key to the pervasive computing settings that characterize FI. In addition, Connectedness is not sufficient to fulfil R4 since it does not support “searching” functionality. Several middleware solutions have been developed to support the previously discussed architectures for the development of pervasive network-based applications. Obje (Edwards et al., 2009) is an object-oriented framework where networked devices are abstracted as objects implementing specific “meta-interfaces”. Such “meta-interfaces” are further used by applications to exchange the behaviors needed to achieve compatibility at run time. The methods of such interfaces make use and return objects that themselves implement well-known interfaces. Hence, the loading of objects is made transparent to user applications, which simply see them as new implementations of already-known interfaces. Many different frameworks have been developed for componentbased programming such as JavaBeans (Sun Microsystems, 2006) and COM Platt (1999). Although these systems are widely accepted as standard component-based frameworks, they are not well suited for pervasive environments, since they do not allow components to be dynamically added/removed at run time: bindings between components are predefined and fixed. Conversely, OSGi (Open Services Gateway initiative) (OSGi Alliance, 2007) implements a dynamic component model (Cervantes & Favre, 2002) where bundles (i.e., components) can be installed/removed, started/stopped, and updated at run time. Services can be published in a service registry, making them available to other bundles. Another example of component-based framework for pervasive computing is described in Hoareau and Mahéo (2008). It provides developers with an architecture description language to specify constrains on components, which can be considered at deployment time to find a distribution scheme satisfying all constraints. SOAs abstract applications as autonomous services, which may be dynamically combined to accomplish complex tasks (Bellur & Narendra, 2005). The widespread adoption of WS technologies combined with mobile networking has led to investigating architectures for mobile Web services (Hirsch et al., 2006; Issarny et al., 2005), where mobile devices act as Web service clients. Today’ device technology also enables mobile devices to act as Web service providers. ReMMoC (Grace et al., 2005) and ubiSOAP (Caporuscio et al., 2012) provide middleware functionalities supporting service provision over pervasive networks. The idea of exploiting RESTful principles is not new, and some projects have been investigating the exploitation of Web standards into pervasive computing. For example, Mancinelli (2010) applies them to Ambient Computing. Similarly, the Cooltown project (Kindberg & Barton, 2001) extends Web principles to devices and services situated in the physical world. However, both approaches leverage Web standards to achieve interoperation, and hence they suffer from limitations, such as lack of mobility management, pointto-point communication, and client–server interaction style. To this end, the XWeb (Olsen et al., 2000) project presents a web-oriented architecture relying on a new transport protocol, called XTP, which provides mechanisms for finding, browsing, and modifying information. In Bonetta and Pautasso (2011) RESTfulness has been exploited to achieve scalability, by means of replication of resources, in the context of Web Services. In particular, the REactor (RESTful Actor) framework provides a RESTful Web service interface and a composable architecture which is capable of delivering scalability and high performance independently from the underlying deployment infrastructure. Moreover, due to its scalability and flexibility, the REST architectural style has been employed also for monitoring and controlling data- and

computationally-intensive tasks, such as in the context of Grid (Lelli & Pautasso, 2009). The exploitation of RESTful principles has been advocated also by the Web of Things community (Guinard et al., 2010). Things may become part of the Web in two ways, either through direct Web connectivity (e.g., Guinard et al., 2009) on the devices or through a proxy (e.g., Kansal et al., 2007). The Physical Web project (Google, 2014) recently announced by Google aims at enabling people to move around and interact with any smart device – a vending machine, a toy, a bus stop, a rental car – without the need to first download an application. Cornerstone of Physical Web, which is very close in spirit to the work presented herein, is the discovery service, through which objects of interest broadcast their URLs, and nearby devices can receive them. Once interested parties receive the URL, they can access the objects of interests. In conclusion, our discussion has shown that REST provides the best solution for the stated fluidity requirements for FI applications. To the best of our knowledge, the work presented here is the first attempt to provide application developers with abstractions to support the design and implementation of RESTful FI applications. 3.2. Engineering resource contextualization Contextualization refers to the ability of discovering, understanding and selecting resources of interest deployed within the environment. This requires mechanisms to semantically describe resources and reason about them. The Semantic Web (Berners-Lee et al., 2001) community has advocated the need for semantic-aware descriptions of software artifacts as first-class entities when dealing with a huge amount of information, created by multiple organizations, communities, and individuals. Several research efforts focused on the discovery and selection of Web services on the basis of semantic interface description. An important role is played by ontologies, which have been employed to make service descriptions semantic-aware. For instance, WSDL-S (W3C, 2005) provides extensibility features to use ontologies to annotate Web service input and output data types. OWL-S (W3C, 2004a) is a high-level service oriented ontology. WSMO (ESSI WSMO Working Group, 2007) provides support for mediators, which can resolve mismatches between ontologies or services. These approaches have been exploited in SOA to extend Universal Description Discovery and Integration (UDDI) registry with semantic annotations, and to provide semantic matching relying on service signatures. Signature matching allows for matching a requested service against the set of advertised services stored in the registry (Paolucci et al., 2002; Sycara et al., 2003; Zaremski & Wing, 1995). Both requested and advertised services are described as a set of required inputs and provided outputs enriched by means of semantic concepts defined by ontologies. Signature matching checks if provided and required ontology concepts satisfy one of the following subsumption relationships: (i) the concepts are equivalent (exact), (ii) the provided concept subsumes the required one (plugin), (iii) the required concept subsumes the provided one (subsume), and (iv) there does not exist any subsumption relation between the two concepts (fail). This approach is exploited by EASY (Mokhtar et al., 2008), which focuses on pervasive services. EASY provides an ontology-based specification language (EASY-L) that specifically target extra-functional properties by extending the above languages with support for QoS and context properties. The matching algorithm implemented by EASY (EASY-M) exploits the algorithm for service signature matching (Paolucci et al., 2002) to rate services according to user preferences on extra-functional properties. The SAPERE framework (Zambonelli et al., 2011) also relies on signature matching, which achieves service discovering in pervasive networking environments through the combination of semantic reasoning and context-awareness. SAPERE extends the signature

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

Fig. 3. REST architectural style.

matching algorithm to account for contextual factors (Stevenson et al., 2013). 4. Design principles As discussed in Section 3.1, REST seems to provide the best solution for the stated fluidity requirements. In fact, the set of design principles underpinning REST makes it an appealing architectural style for implementing FI applications. The REST style (Fielding, 2000) is founded on the client–server paradigm, to clearly separate user interface (i.e., the client side) concerns from the data storage concerns (i.e., server side). It is meant to improve both portability and scalability of clients. Two main architectural entities are involved in REST (see Fig. 3): the User Agent, which initiates a request and becomes the ultimate recipient of the response, and the Origin Server, which holds the data of interest and responds to user agent requests. REST defines also two optional entities, namely Proxy and Gateway, which provide interface encapsulation, clientside and server-side respectively. The data of interest, held by origin servers, are referred to as Resources and denote any information that can be named. That is, any resource is bound to a unique Uniform Resource Identifier (URI) identifying the particular resource involved in an interaction between entities. Referring to Fig. 3, when User Agent issues a request for the resource identified as Rb to Origin Server2 , it obtains as a result a Representation of the resource (i.e., ρ b ). Specifically, a Representation is not the resource itself, but captures the current state (at a given instant of time) of the resource in a format matching a standard data type. An application built according to the REST style is said to be “RESTful” if it does respect the design principles (Fielding, 2000; Richardson & Ruby, 2007): namely Addressability, Statelessness, Connectedness, Uniformity. Addressability: a RESTful application is required to expose its data of interest as resources, which are uniquely identified through URIs. Statelessness: a RESTful application must serve any user agent’s request in complete isolation without relying on information from previous requests. Hence, every user agent’s request should include all information necessary to fulfill that request. Connectedness: clients can interact with a RESTful application through hypermedia provided dynamically by the application itself. Indeed, user agents access the application through a given URI, and then all further actions to be performed are discovered at run time by consuming the representations returned from the application. The origin server guides user agents from one application state to another by embedding links and forms in its representations. At the same time, user agents transition through application states by selecting from the links embedded in such representations. Uniformity: every resource must understand the same fixed set of core operations specified by a shared uniform interface. While resources provide the “subjects” and “objects” of the interaction, the uniform interface specifies the set of “verbs” defining the interaction to perform among resources. To support scalability, RESTful applications are loosely coupled, and do not incorporate any Quality-ofService (QoS) guarantees (e.g., data consistency, transactionality, and

13

referential integrity). Rather, the RESTful application needs to know how to cope with unintended outcomes or outright failures. To this extent, REST relies on a well defined set of status codes, which can be used by origin servers to indicate what has happened. RESTful applications try to guide a user agent toward a successful conclusion of an interaction, but without introducing tight coupling. RESTful applications can be classified according to four RESTfulness levels:5 Level Zero applications expose a single resource, and use a single method (typically HTTP POST). For example, Web Services typically have a single endpoint (URI), and use POST to transfer SOAP messages (W3C, 2007). Level One applications employ many URIs but a single method. While Level Zero applications tunnel all interactions through a single (large, complex) resource, Level One applications expose several resources whose operations are consumed by embedding operation names and input parameters into the resource URI (typically accessed via HTTP GET). For example, Google Map6 is accessed by issuing a GET to a URI respecting the following pattern: maps.google.com/maps/api/staticmap?[args], where [args] must be replaced by a well-formed string (e.g., center=Milan&size=600x300). Level Two applications expose several URI-addressable resources supporting several methods. Included in this level are Create Read Update Delete (CRUD) applications, where the state of resources can be manipulated over the network. For example, within the Amazon’s S3 storage system,7 an object can be created, read, updated and deleted through the PUT, GET, POST, and DELETE HTTP verbs, respectively. Level Three applications fully support the Connectedness principle. That is, the application returns representations that embed URIs, which in turn lead consumers through a series of resources, causing application state transitions as a result. The above set of design principles makes the REST architectural style appealing for implementing FI applications. However, REST relies on a stability assumption for the underlying networking environment and exploits synchronous interaction protocols, while pervasive environments must cope with an ever-changing networking infrastructure, because of devices mobility (Roman et al., 2000), and must support asynchronous coordination mechanisms (Huang & GarciaMolina, 2001). As result, the REST style must be extended.

5. Engineering resource abstraction The goal of resource abstraction is to support a seamless interaction among different kinds of pervasive resources (i.e., thing, service, and content), independent of their concrete nature and location. To this end, Prime leverages the aforementioned set of REST principles to provide a uniform abstraction achieving the effective aggregation of pervasive things, services, and contents.

5.1. P-REST architectural style The P-REST (Pervasive REST) style extends REST to specifically address FI-supported pervasive environments (Caporuscio et al., 2011). In these settings, the role of “prosumer” – an architectural entity fulfilling both roles of producer and consumer – is central (Papadimitriou, 2009), since any “thing” within the environment can potentially provide and consume data of interest. Hence, we need

5 L. Richardson, Justice Will Take Us Millions of Intricate Moves at QCon San Francisco 2008; see http://www.crummy.com/writing/speaking/2008-QCon/. 6 http://developers.google.com/maps/. 7 http://aws.amazon.com/documentation/s3/.

14

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

5.2. Modeling P-REST applications

Fig. 4. P-REST architectural style.

to depart from usual REST view of the world, in terms of user agents that consume resources from origin servers (see Fig. 3), to P-REST view, which refers to a unifying entity that fulfills both roles. At the architectural level, P-REST (see Fig. 4) is founded on the peer-to-peer paradigm, and defines a resource as a first-class entity playing the role of prosumer. A resource models anything made available over the network, such as a document (content) or a business process (service) or a real-world object (thing), which can interact with other resources. P-REST departs from synchronous communication and defines two different connectors, namely asynchronous point-to-point and asynchronous point-to-multipoint. A point-to-point connector supports direct interaction between two resources, whereas a point-tomultipoint connector allows a given resource to interact with many different resources at the same time. Although the HTTP protocol is largely adopted today, this departure is justified by the fluidity requirement of FI applications, which suggests asynchronous message passing as a more natural communication model (B’far, 2004). To support coordination among resources, P-REST further extends REST with a set of new facilities: (i) a distributed Domain Name System (DNS) service maintaining the mappings between resource URIs and their actual location in case of mobility, (ii) a Lookup service enabling discovery of new resources at run time, and (iii) a coordination model based on the Observer pattern (Khare & Taylor, 2004) allowing a resource to express its interest in a given resource and be notified whenever changes occur in it. Since resources may join/leave the system dynamically and change their location dynamically, DNS is in charge of tracing them and managing routing tables, whereas Lookup enables the discovery of new resources by yielding their URIs. Fig. 4 summarizes the new features introduced by P-REST. Resources interact with each other by exchanging their representations (denoted by ρ i ). Resource1 and Resource2 observe Resource3 (messages ). When a change occurs in Resource3 , it notifies (message ) its observers. Upon receipt of a notification, Resource1 issues a request for the Resource3 and obtains as a result the representation ρ 3 (message ). Notice that, while observe/notify interactions take place through the asynchronous point-to-multipoint connector (represented as a cube), legacy REST operations exploit asynchronous point-to-point connector (represented as a cylinder). All the resources exploit the lookup operation to discover the resources of interest, and the DNS service to translate URIs into physical addresses. The P-REST style satisfies the properties characterizing fluid architectures: (i) resources are interconnected in a loosely-coupled, peerto-peer manner entities, (ii) resources can be flexibly added/removed and accessed, (iii) resources can be dynamically discovered either by means of the Connectedness principle or by means of the Lookup service, and (iv) new resources can be accommodated within the running application, because of their conformance to the uniform interface.

The model of a PREST-Application follows the meta-model illustrated in Fig. 5. It is composed of a set of Architectural Elements, namely Resource and Link. Resource specializes into AbstractResource and ConcreteResource. AbstractResource represents a class of resources whose details are unknown at design time (e.g., the specific kind of a “temperature sensor”). By exploiting this mechanism, developers can specify at design time the need for a class of resources, whereas the specific resource to access will be retrieved at run time, depending on the actual set of resources available within the environment. On the other hand, ConcreteResource represents the main architectural entity modeled in the application. A ConcreteResource can be accessed, irrespective of its specific nature, by means of Requests, which in turn map to the set of methods defined by the uniform interface. To achieve backward compatibility with legacy REST applications, P-REST adheres to the uniform interface defined by HTTP (Network Working Group, 1999): namely, OPTIONS, GET, HEAD, POST, PUT, and DELETE. Further, the P-REST meta-model (see Fig. 5) allows developers to specify multiple responses for the same request’s type (e.g., multiple GET) for each resource. Then, the specific method to invoke will be selected at run time, depending on the actual evaluation of the condition attribute. This mechanism allows for conditional method overriding, and is used to achieve Content Negotiation – i.e., the ability to serve different representations for a given resource (Network Working Group, 1999). When processing a Request, a resource responds with a Response, which embeds a StatusCode and a representation of the resource’s state. The Status Code is used by resources to indicate the result of the attempt to process the request. According to HTTP specifications, StatusCode is a set of pre-established and well-defined three-digit integer values, where the first digit defines the class of response, and the last two digits define specific statuses within a class. There are five classes: (1xx) Informational informs that the request was received, (2xx) Success informs that the action was successfully understood, and accepted, (3xx) Redirection informs that further action must be taken in order to complete the request, (4xx) Client Error reveals that the request contains bad syntax or cannot be fulfilled, and (5xx) Server Error reveals that the server failed to fulfill an apparently valid request. The resource’s state representation to be embedded within the Response can be represented by means of different Content types, namely SimpleMedia, InternetMedia,8 LinkCollection, and HyperMedia. For example, a resource modeling a text book can be rendered either as application/pdf for human consumption, or as text/xml for machine consumption. HyperMedia represents a complex and structured aggregation of Contents: it is a collection of intertwined contents such as graphics, audio, video, plain text and links, which create a non-linear contents (Nelson, 1965). Enhancing the link definition provided by Web Linking (Nottingham, 2010), in P-REST a Link represents a conditional relation of type RelationType from a context resource to a target resource – i.e., the defined link is active if and only if condition holds. The relation type identifies the “semantics” of the specified link, and it is used to indicate “why” the context refers to the target resource – i.e., use and include. Furthermore, since resources are architectural elements, a link also denotes the architectural constraint existing between the context and target resources. The constraint type identifies “how” the context resource relates to the target resource – i.e., mandatory, optional, and alternative. Finally, a link might be associated with an optional set of key, value attributes, which allows

8

http://www.w3.org/2001/tag/2002/0129-mime.

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

15

Fig. 5. P-REST metamodel.

developers to specify application-dependent properties (e.g., title, media, and web semantic concepts). As we said, every resource is identified by its URI. P-REST enhances the concept of URI by introducing Abstract URI (aURI) and Concrete URI (cURI) entities: aURI defines a class of resources (e.g., “temperature sensor”), whereas cURI uniquely identifies a specific resource instance within the environment (e.g., the sensor “ts23”). Further, URIs adhere to the URI Template standard (Gregorio et al., 2012) that, leveraging variable expansion, provides a mechanism for abstracting a space of resource identifiers by means of URI parameterization. Hence, at design time, URIs are expressed in terms of variables, which will be then instantiated at run time to generate well-formed cURI. This allows for automatically generating run-time cURIs, which

reflect the design-time semantic relations holding between resources. Specifically, the semantic relation include, holding between two resources R1 and R2 (i.e., R1 includeR2 ), induces a hierarchy-based structural relation on R1 and R2 (i.e., R1 is parent of R2 ), which in turn induces a syntactic relation on the respective cURIs. On the other hand, since the use semantic relation does not imply any structural relation on resources, it does not induce any syntactic relation on cURIs. Example 1. Referring to Smart City Pulse application (see Section 2), Fig. 6 shows an excerpt of the P-RESTful architectural design of Monitoring Service. The /monitor resource include four different resources, namely /find/all, /find/area, /observed, and /list/{item}, which can be accessed by following the links labeled as findall, findarea,

16

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

GET[html]

/find/all ll” inda

f [ ]: “

/monitor m

dm

a

[ ]: “findarea

”

[ ]:

“ob

GET[html]

da

/find/area b

GET[html] POST[html]

rve

d”

iz .s

observe

em [it

se

db

/observed

GET[html]

MapService

e > t” lis :“ 0]

[#Sensor]

c

dc

/list/{item} l

dl

GET[html]

Fig. 7. Knowledge base reference architecture. Optional:

Mandatory:

Use:

Include:

Alternative:

Fig. 6. Smart City Pulse application – model.

observed, and list respectively. All such resources use the #Sensor abstract resource, which specifies a generic sensor from which the data of interest are retrieved. Specifically, resource /find/all displays all the sensors belonging the to the networked sensing infrastructure; /find/area displays all the sensors belonging to the networked sensing infrastructure and deployed within a given geographic area; /observed retrieves and display data gathered from a specific set of observed sensors; /list/{item} lists all the monitored sensors and provides direct access to them.9 The actual cURIs of the resources identified by {item} are derived in two steps: (1) following the include relation from /monitor to /list/{item} to obtain the /monitor/list/{item} URI Template, and (2) substituting the item variable with actual values. This results in a set of n distinct resources identified by /monitor/list/1, /monitor/list/2, . . . , /monitor/list/n cURIs, respectively. Finally, to display the discovered sensors on a geographic map, /find/all, /find/area, and /observed use an optional legacy MapService accessed through HTTP connector. 6. Engineering resource contextualization Resource contextualization concerns the ability of discovering, understanding and selecting the resources of interest. A query-advertise protocol is provided to allow for discovering available resources and matching them against the consumer’s interests. Following the SOA paradigm, the protocol is composed of three phases: (i) the resources of interest advertise their availability and the specification of their capabilities to the discovery service, (ii) interested resources query the discovery service looking for resources matching their interest, and (iii) whenever the discovery service successfully matches the query against a resource advertisement a reference is returned to the requester. Since P-REST adheres to REST principles including uniformity, a purely syntactic matching (Beugnard et al., 1999) would be inadequate. Semantic match-making is instead needed for contextualizing P-REST resources (Bandara et al., 2008; Giunchiglia et al., 2007; Paolucci et al., 2002). We enrich resource advertisements with semantic annotations, enabling resources to be categorized, published and retrieved from a shared knowledge base. A knowledge base (see Fig. 7) is a software system that represents an ontologically described information base to be processed and accessed in an application. It is composed of a storage component, an access component to support queries, and an inference engine to reason about the data. 9

Because list is a conditional link, there can be no monitored sensors.

Fig. 8. An excerpt of the Smart City Pulse ontology.

A knowledge K is specified by means of the Resource Description Framework (RDF) (W3C, 2004b), which is part of World Wide Web Consortium (W3C) specifications family and has been accepted as standard for modeling data interchange in the context of Semantic Web (Berners-Lee et al., 2001). RDF describes statements about entities in the form of subject, predicate, object triples, where subject and object denote entities, and predicate denotes a relationship between subject and object. The subject of a statement indicates the entity being described while the predicate describes a relationship (e.g., definitions, associations, aggregations, and restrictions) between the subject and the object. RDF statements define a graph where subjects and objects represent the nodes and predicates represent the edges. RDF statements can describe both concepts (e.g., a person has a birth date) and instances (e.g., Bob was born on Jan 14, 1980). Statements that refer to concepts define an ontology, statements that refer to individuals define instance data. Because in practice both the ontology and instance data are based on RDF, there is no explicit distinction between the ontology and the data the ontology describes. Example 2. Referring to Smart City Pulse, a sensor is defined by the set of concepts in Fig. 8, which are excerpted from the Smart City Pulse ontology. Specifically, Sensor is an RDF class with some properties: (i) Sensor has an ID, (ii) Sensor has a value, (iii) Sensor can relate to other sensors, and (iv) Sensor has a Location, which in turn is defined as RDF class with two properties, namely latitude and longitude. According to this definition, Fig. 9 shows the set of statements describing the instance data of Sensor_TF3. Specifically, Sensor_TF3 is a Temperature sensor that (i) is identified as Temp_floor3, (ii) has a value equal to 23, (iii) relates to sensor Sensor_HF3, and (iv) is located at (45.47787, 9.23457).

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

17

@prefix rdf: <22-rdf-syntax-ns#>. @prefix scp: . <#Sensor_TF3> a scp:Temperature; scp:hasID "Temp_floor3"; scp:hasValue "23"; scp:relatesTo <#Sensor_HF3> . scp:hasLocation scp:Location; scp:Location scp:latitude "45.47787"; scp:longitude "9.23457". Fig. 9. Query-advertisement – sensor description

SELECT ?id ?val ?lat ?long WHERE{ ?p a scp:Temperature ?p scp:hasId ?id . ?p scp:hasValue ?val . ?p scp:hasLocation ?location . ?location scp:latitude ?lat . ?location scp:longitude ?long . FILTER (?lat>43 && ?lat<47 && ?lon>7 && ?lon<11) } Fig. 10. Query-advertisement – SPARQL query.

As introduced before, the knowledge base includes a reasoning component that can infer new information based on the contents of the storage. There are two primary inference methods (Russell & Norvig, 2003): forward chaining and backward chaining. In forward chaining inference, all entailments (implied facts) are asserted directly to the repository whenever new facts are added. On the other hand, in backward chaining, reasoning is performed by attempting to derive the conditions of goal set of facts by applying the logic of the system backwards until the conditions are satisfied by explicit facts in the knowledge. Concerning the query-advertise protocol, when a resource wants to advertise itself, it submits its description to the discovery service, which in turn updates the knowledge as a set of RDF statements. Specifically, the advertise operation first writes into the knowledge a triple (s.subject, s.predicate, s.object) for each statement s in the RDF resource description, and then asserts new entailments by means of forward chaining. Searching for resources requires querying the knowledge base to discover what relationships hold between the semantic description specified by the query and the individuals stored into the knowledge. The semantic access component (see Fig. 7) queries the graph model by means of standard semantic query languages, such as SPARQL.10 SPARQL is an RDF query language, able to retrieve and manipulate data stored in RDF format. Example 3. Referring to the Smart City Pulse ontology defined in Fig. 8, a Temperature Sensor advertises itself by submitting the description in Fig. 9. The SPARQL query in Fig. 10 will produce the following output, specifying id, value and location of temperature sensors located within the given area: “Temp_floor3” | “23” | “45.47787” | “9.23457”

Fig. 11. Prime middleware software architecture.

enforce RESTfulness at the application level, which is totally entrusted to the designer. Referring to Fig. 11, the Prime middleware has a twolayer architecture consisting of a communication layer upon which the API layer provides programming abstractions to P-REST applications. Communication layer – To deal with the inherent instability of pervasive environments, Prime arranges devices in an overlay network built on top of low-level wireless communication technologies (e.g., Bluetooth, Wi-Fi, Wi-Fi Direct, and UMTS). Such an overlay is then exploited to provide two basic communication facilities, namely point-to-point and point-to-multipoint. Point-to-point communication grants a given node direct asynchronous communication with a remote node, whereas point-to-multipoint communication allows asynchronous communication with many different nodes at the same time. Furthermore, for the sake of backward compatibility, Prime also provides an HTTP connector, enabling resources to interact with legacy HTTP-based web applications deployed outside the Prime overlay network. Finally, the Prime communication layer implements a DNS facility for managing resource mobility (Roman et al., 2000). API Programming layer – Prime provides the programming abstractions and operations to implement P-RESTful applications. PrimeApplication provides access to basic functionalities and acts as container for exposed Resources – i.e., it handles both resources life-cycle and provision. The set of operations allowed on resources defines the message-based Prime interaction protocol and includes: (i) Access, which gathers the set of operations to access resources according to the P-REST uniform interface, (ii) Observe/Notify, which allows resources to declare interest in a given resource and to be notified whenever changes occur, and (iii) Lookup, which support resource discovery. The following sections clarify these aspects and provide implementation details about the communication layer and the API programming layer, respectively.

7.1. The Prime communication layer Prime arranges devices in an overlay network, a virtual network of nodes and logical links built on top of existing physical networks

7. PRIME run-time support The Prime middleware provides run-time support for the development of P-RESTful applications. The Prime middleware realizes P-REST at the infrastructure level by providing abstractions for the implementation of Level Three P-RESTful applications. Prime cannot

10

http://www.w3.org/TR/rdf-sparql-query/.

Fig. 12. Prime node.

18

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

Fig. 13. Prime communication over Pastry overlay network (a) Point-to-point communication. (b) Point-to-multipoint communication.

(Doval & O’Mahony, 2003) and meant to augment the native network with new services. The Prime overlay network manages the logical links between nodes (i.e., resources) and enables message exchange. In pervasive environments, a key requirement for the overlay is the ability to self-organize itself into a flexible topology, as well as to maintain it. Hence, the Prime overlay network aims at (i) keeping the overlay network connected when the topology of the underlying native network changes (e.g., as a consequence of mobility), and (ii) regulating the message flow between nodes according to the specific coordination model used, namely point-to-point and point-tomultipoint. Prime exploits Pastry (Rowstron & Druschel, 2001), a decentralized, self-organizing framework to implement the peer-to-peer overlay network. Due to its pure peer-to-peer nature, the Pastry overlay is scalable, efficient, and tolerant of physical topological changes due to node mobility. Pastry self-organizes itself to keep all nodes connected. Referring to Fig. 13, a Prime node acts as resource container and is implemented as Pastry node. Pastry nodes are arranged in a logical ring and uniquely identified by a nodeId assigned in a circular 128-bit identifier space. On the other hand, at the application level, Prime resources are identified through cURI adhering to the URI Template standard (see Section 5.2). In order to reconcile the different address spaces, Prime implements a distributed DNS service that resolves URIs and maps Prime resources to Pastry nodes. The Prime DNS is implemented as a decentralized service, where all Prime nodes are active participants. Prime nodes maintain a local table mapping cURI to nodeId (see Fig. 12) and interact with each other to share table entries. To keep the table size reasonable, each node maintains only the set of known resources, i.e., the set of resources it is currently interacting with. The local table initially contains the set of locally deployed resources, and is further populated as local resources interact with remote resources of interests, which are discovered by means of the Lookup service (see Section 7.2.3). Example 4. Fig. 12 shows two interacting Prime nodes identified by the Pastry nodeIds 65a1fc and d467c4, respectively. Node 65a1fc acts as a container for two Prime resources, namely A1 and A2 , whereas node d467c4 manages resource B. Fig. 12 also shows the table held by node 65a1fc. It initially contains only entries for the local resources A1 and A2 . Whenever A1 needs to interact with resources of interest, it refers to the lookup service and populates its table accordingly (e.g., resource B is located at node d467c4). Prime point-to-point communication is implemented by exploiting the Pastry native communication protocol. Referring to Fig. 13a, given a Prime sender resource A1 , and a receiver resource B, the Prime DNS

maps B to the Pastry nodeId d467c4, and relies on Pastry communication to deliver the message m. Pastry efficiently routes m through the ring (Rowstron & Druschel, 2001), from node 65a1fc to node d467c4, in log2b N steps.11 Once received by node d467c4, m is processed by Prime container and forwarded to B. For the sake of backward compatibility, Prime communication layer also provides an HTTP connector (see Fig. 12), enabling resources to interact with legacy HTTP-based web applications deployed outside the Prime overlay network. Still referring to Fig. 13a the Prime resource M can interact with the legacy application L (which is deployed outside the Pastry ring) by means of the HTTP protocol. To provide point-to-multipoint communication, Prime uses Scribe (Castro et al., 2002), a multicast framework built on the Pastry ring as underlying route management overlay. Scribe nodes create/join/leave groups, and multicast messages to all members of the group. A Scribe group has a unique 128-bit groupId computed as the hash of the textual group name. The Pastry node having the numerically closest nodeId to this groupId will act as rendez-vous point (the root of the multicast tree) for the group – e.g., node d13da3 in Fig. 13b. When a new node n wants to join a given group, it sends a join message to the group’s rendez-vous point (identified by groupId). The join message then is routed toward the rendez-vous point through the Pastry overlay. Each node ni traversed by the message, checks whether it is in the group’s tree or not. If the answer is “yes” n is added as a child in the routing table of ni . If it is not, ni creates a new group in the local routing table, adds n to the children table for the group, and sends to groupId a join message for itself. This procedure is iterated recursively up to the rendez-vous, by creating the multicast tree. To guarantee scalability, Pastry assures multicast trees to be balanced. To multicast a message m to a given group, m is firstly routed to the rendez-vous point identified by groupId, and then disseminated from the rendez-vous point along the multicast tree. Example 5. Referring to Fig. 13b, let resources B, C, and D belong to a given group myGroup. When a Prime resource A1 multicasts a message m to such a group, m is sent through the Pastry ring to node d13da3 (i.e., the randez-vous point for myGroup), which in turn forwards m to all children in its routing table, namely d467c4, d4213f and 70b2a8. As discussed above, P-REST relies on the network-based systems paradigm, where resources interact by means of message passing. Hence, operations upon Prime resources are expressed in terms of messages exchanged among Prime applications. Indeed, the Prime 11 Where N is the number of nodes, and b is a configuration parameter usually set to 4.

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

19

Fig. 14. Prime interaction management.

interaction protocol is defined as an extensible hierarchy of messages encoding the set of operations to be performed on resources. Referring to Fig. 14, PrimeApplication sends and receives PrimeMessages through ICommGateway and MessageDispatcher, respectively. A Prime message can be either a PrimeGroupMessage or a PrimeUnicastMessage. A Prime group message is used for point-to-multipoint communication and can be of different types, as specified by PrimeProtocol. A Prime group message of type Observe is used by a resource to declare its interest in remote resources. The group attribute contains either a cURI or a aURI, depending on the object of interest, i.e., observing a specific resource or observing a group of resources. Such a message is handled by ICommGateway as a Scribe subscription, where the payload is the groupId. A resource notifies occurred changes by generating a group message of type Notify. A Notify message has a sourceURI field identifying the origin resource cURI and a group field identifying the groupId of the group of interest. The payload can be used to notify any kind of information about the changes happened in the observed resource. The Notify message is sent by ICommGateway as a Scribe notification, which is matched against active subscriptions and delivered to recipients. Group message of type Lookup/Query is used to discover resources of interests. In this case, group is set to a special groupId defined by Prime to broadcast lookup/query messages through the overlay network. Specifically, the Lookup/Query message is sent by ICommGateway as a Scribe notification to be delivered to all Pastry nodes on the ring. PrimeUnicastMessage is used for point-to-point communication and can be of the following types. The Request type represents generic requests exchanged among resources, and defines a destURI field containing the cURI of the destination resource. A Request can be one of the P-REST operations (i.e., GET, POST, PUT, DELETE, HEAD and OPTIONS) to be performed on the destination resource. The payload attribute contains a code identifying the specific operation to be performed plus a resource representation whether needed (e.g., POST operation). The Response type is used to reply to Request messages by embedding the StatusCode and the representation of the resource’s state. Finally, Lookup_Reply and Query_Reply are used to reply to Lookup

and Query requests, respectively. This set of messages is handled by ICommGateway as Pastry messages. Incoming messages are managed by Prime applications through a MessageDispatcher thread, which is in charge of receiving PrimeMessage from the underlying overlay network and processing it. Specifically, Prime instantiates a IMessageHandler for each message type specified by PrimeProtocol, and registers it at the MessageDispatcher with the type of handled message. IReceiver receives both unicast and group messages from the overlay network and forwards them to the message dispatcher, which in turn matches the message type against the set of registered types, and invokes the message handler in charge for it. The Prime interaction management implementation uses three interfaces, namely ICommGateway, IReceiver, and IMessageHandler. This design choice provides two benefits. First, Prime interaction protocol can be easily extended by adding new message types to PrimeProtocol and handlers to MessageDispatcher.12 Second, decoupling the Prime interaction management from Pastry through the ICommGateway and IReceiver interfaces allows Prime to be further employed on different kinds of overlay networks. 7.2. The Prime API programming layer The Prime API programming layer supports development of PRESTful applications through the PrimeApplication and PrimeResource abstractions. They are presented hereafter along with excerpts from the Smart City Pulse PrimeApplication. 7.2.1. PrimeApplication The PrimeApplication entity is the Prime entry-point abstraction, and provides developers with the basic facilities needed to build PRESTful applications. User Applications (see Fig. 11) exploit services provided by the Prime middleware by extending PrimeApplication, and using inherited methods. PrimeApplication is in charge of 12 For instance, see Prime Extensions: https://github.com/maurocaporuscio/primemiddleware-extensions.

20

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

managing the application state and exposing it through resources, which in turn are accessed by interested applications/resources. PrimeApplication provides facilities for managing resources’ lifecycle and communication messages. Specifically, PrimeApplication stores local exposed resources into a Resource Registry and, whenever a message addressed to a specific resource is received from the underlying communication layer, it forwards the message payload to the Resource. Outgoing messages issued by local resources are delivered toward their destination by means of the Prime communication layer (see Section 7.1).

@prefix : . :Resource a owl:Class . :aURI a owl:ObjectProperty ; rdfs:domain :Resource ; rdfs:range owl:Class . :cURI a owl:DatatypeProperty ; rdfs:domain :Resource ; rdfs:range xsd:string . :expose a owl:ObjectProperty ; rdfs:domain :Resource ; rdfs:range :Interface . :Interface a owl:Class . :hasCapability a owl:ObjectProperty ; rdfs:domain :Interface ; rdfs:range :Capability . a :Capability . a :Capability . a :Capability . a :Capability . a :Capability . :hasContext a owl:ObjectProperty ; rdfs:domain :Resource ; rdfs:range :Context . :Context a owl:Class . Fig. 15. Resource Description Ontology excerpt.

Listing 1. TSensor class

Example 6. Listing 1 is an excerpt from the Smart City Pulse application implementing a temperature sensor. TSensor periodically checks the temperature sensed by the Thermometer and enriches it with geolocation information provided by the GPS. Line 7 initializes the PrimeApplication by specifying the application name and the HTTP port through which legacy applications can consume TSensor. Lines 8–9 instantiate the Prime communication layer; Line 10 instantiates the Prime resource and registers it within the Resource Registry (see Section 7.2.3). Finally, Line 11 starts the PrimeApplication, and Line 12 checks the temperature every 5 min.

Example 7. Listing 2 defines a PrimeResource TInfo exposing the internal state of the TSensor PrimeApplication. TInfo defines two different methods, namely toXML() and toHTML(), which implement the GET operation by returning a XML Representation and a HTML Representation, respectively. Method toXML() serializes the info object into a XML document, whereas toHTML() embeds the information extracted from the info object into a string marked up with HTML.

7.2.2. PrimeResource PrimeApplication exposes the information of interest (e.g., the sensed temperature in Example 6) by instantiating resources. A PrimeResource is defined as an abstract class, which is further extended by any resource to be deployed within Prime. According to P-REST, a resource is defined by extending PrimeResource: it declares the set of provided operations and the expected type of representation for each operation. This is achieved by annotating the method declaration with metadata describing the P-REST operation and the type of representation returned by the operation: @Op(“type”), where Op ∈ {Get, Post, Put, ...} and type ∈ MIME Media Types.13

7.2.3. Resource description As discussed in Section 6, to achieve contextualization resources are required to be semantically described and published on a shared knowledge base. To do so, Prime implements a query-advertise protocol that exploits a Resource Description Ontology, which in turn specifies the set of concepts needed to advertise/retrieve resources of interest to/from the knowledge base. Fig. 15 presents an excerpt of the Resource Description Ontology defining Resource as an ontology concept having aURI and cURI properties, which define the semantic concept implemented by the given resource, and its concrete identifier, respectively. The ontology provides concepts for describing both functional and context specification of the given resource. The functional specification describes “what” capabilities are actually provided through the uniform Interface. For each implemented Capability, the ontology specifies the semantic concept it refers to (e.g., getInfo), the data expected as output, and the input parameters (POST and PUT require an input parameter, while others do not). The context specification describes the contextual information related to the resource. To do so, Context is defined as a generic concept to be further specified. Example 8. Referring to the Resource Description Ontology reported in Fig. 15, the PrimeResource TInfo defined in Example 7 is described in Fig. 16.

Listing 2. TInfo class

13

http://www.ietf.org/rfc/rfc2046.txt.

Following the query-advertise protocol described in Section 6, once a Resource is described, it should advertise itself to a discovery service. Prime implements a fully distributed semantic-aware discovery service to advertise/retrieve resources of interest.

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

@prefix : . @prefix ex: . a :Resource ; :aURI [ a ex:Temperature ] ; :cURI ; :offers [ a :Interface ; :method [ a :GET ; :output "text/html" ; :note "getInfo" ] ] ; :hasContext [ a :Location ; :latitude "45.510708" ; :longitude "9.185987" ] ; :Location a :Context . :latitude a owl:DatatypeProperty ; rdfs:domain :Location ; rdfs:range xsd:string . :longitude a owl:DatatypeProperty ; rdfs:domain :Location ; rdfs:range xsd:string .

21

This example shows how to exploit the lookup functionality to discover all available sensors. In fact, since the Devices ontology defines all types of sensors – e.g., thermometer, hygrometer, photodiode, motion detection, etc. – as subconcepts of #Sensor, the lookup will return a list containing all the sensors, irrespective of their specific nature. The lookup(AURI auri) method matches the requested aURI against the set resources stored within the local resource repository by checking whether provided and required aURIs, specified by means of ontology concepts, satisfy one of the following subsumption relationships (Paolucci et al., 2002; Sycara et al., 2003): (i) the concepts are equivalent (exact matching), (ii) the provided concept subsumes the required one (plugin matching), (iii) the required concept subsumes the provided one (subsume matching), and (iv) there does not exist any subsumption relation between the two concepts (fail). If the result is not fail, then cURI of the matching resource(s) is returned to the requesting node.

Fig. 16. TInfo resource description.

Listing 3. load method

Example 9. Listing 3 defines the load method of TSensor (see Listing 1, Line 10) that, given a Class extending PrimeResource, registers it within the Prime resource registry and stores its description within the local knowledge base. Interested parties query the semantic-aware discovery service to look for resources of interest, using two different methods, namely lookup and query:

Listing 5. MonitoringService – looking for all sensors within a given area

Example 11. Listing 5 shows an alternative implementation of the MonitoringService application, which looks for all the sensors located within a given area defined by lat ࢠ [44, 46] and lon ࢠ [8, 10].

The lookup method queries the Prime discovery service looking for the set of available resources (returned as a Collection of LookupResult) implementing the given aURI. The query method instead queries the Prime discovery service, looking for the set of available resources (returned as a Collection of QueryResult) matching the given SPARQL Query. In both methods, t is the maximum amount of time (expressed in milliseconds) the interested party will wait for responses from the Prime discovery service. The auri/qstr is injected through the Prime overlay and delivered to all nodes. Each node receives the message and tries to match its contents against the local knowledge base. In case of success, the node issues a reply message containing a RDF description, which is returned to the requester. The lookup will then return a set of messages embedding the descriptions of matched resources.

Listing 4. MonitoringService – looking for all sensors

Example 10. Listing 4 is an excerpt from the MonitoringService of Smart City Pulse performing a lookup of all resources belonging to the #Sensor aURI advertised within the discovery service.

This example shows how to exploit the query functionality to discover all the sensors matching the SPARQL query. The query is broadcasted to all nodes within the environment, and processed by the knowledge base access component belonging to each node. If the query is successfully matched against the local knowledge base, the result is returned to the issuing node. 7.2.4. Resource access operations Following the P-REST architectural style presented in Section 5, resources can be accessed through REST operations defined by the following IPrimeConnection interface:

22

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

The IPrimeConnection interface maps the abstract P-REST uniform interface defined in Section 5 onto the Prime communication layer (see Section 7.1). IPrimeConnection is implemented by three different classes: (i) PrimeP2PConnection (implements the point-to-point connector), (ii) PrimeP2MConnection (implements the point-to-multipoint connector), and (iii) PrimeHTTPConnection (implements standard HTTP connector and allows Prime resources to interact with legacy REST resources). PrimeP2PConnection and PrimeP2MConnection leverage the Prime overlay network, whereas PrimeHTTPConnection leverages standard TCP/IP protocol suite. Example 12. Listing 6 further extends the MonitoringService application by retrieving information (returned as XML representation) from all the sensors discovered within the Prime discovery service, and stores them in infoList. Note that the get method call (Line 8) makes use of the Content Negotiation mechanism by declaring the type of expected representation (see also Example 7). The infoList is further displayed as a map showing where each sensor is located.

Applications can notify occurrences of changes by invoking the notify method and specifying the cURI and aURI of the local affected resource, as well as a message to be delivered to the observers. The message is defined as a Serializable object, to support object transmission.

Listing 8. TSensor – notifying the observers

Example 14. Listing 8 shows the definition of the checkSensorValue method implemented by TSensor (see Example 6). The method checks every millis milliseconds the temperature currently sensed by the thermometer. If the new temperature differs from the previous, the internal state is updated and a notification is sent to all the observers. 8. PRIME in action

Listing 6. MonitoringService – retrieving sensor’s representation

7.2.5. Observe/notify According to the observe/notify pattern defined by P-REST, an application can express its interest in a given resource and be notified whenever changes occur in it. Prime provides two different methods:

The Observe method is used by applications to declare their interest in the resource identified by uri. The uri attribute refers to either a cURI or aURI, allowing observation of a single resource or a set of resources, respectively. Notifiable is the object in charge of handling and processing incoming notifications. Example 13. Listing 7 refines the MonitoringService application by declaring an inner class Handler that extends the abstract class Notifiable by implementing the handleNotification method. The method simply stores the received message m into a list. MonitoringService also defines the observeSensors() method, which instantiate a new AURI object and make use of it for observing resources of interest - e.g., all the temperature sensors deployed within the environment.

The Prime assessment presented in this section is both qualitative (Section 8.1) and quantitative (Section 8.2). The qualitative assessment aims at evaluating the proposed approach from a software engineering standpoint: how do Prime modeling and programming abstractions support the development of fluid applications. This qualitative analysis is performed by developing a set of applications in the area of Smart Cities and evaluating them with respect to the fluid architecture properties stated earlier – loose coupling, flexibility, dynamism, and serendipity. Quantitative analysis aims at assessing performance of the Prime middleware prototype. Since FI applications may execute on different types of devices (such as sensors, smartphones, and desktops) and may involve several resources, quantitative analysis aims at measuring the Prime middleware performance in providing resource management, discovery, provision, and interaction. 8.1. Abstractions efficacy The set of Prime abstractions discussed in previous sections satisfy the properties that define architectural fluidity: (i) Prime resources are autonomous and loosely coupled entities, interacting with each other via message passing, (ii) Prime applications can instantiate new resources at run time, (iii) Prime resources can be dynamically discovered at run time through both hypermedia and lookup mechanisms, and (iv) unforeseen Prime resources can be accommodated into the running application, thanks to the uniformity principle. To achieve a more concrete qualitative assessment of Prime’s abstractions, we developed three resource-oriented applications in the area of Smart Cities, namely Smart City Pulse, Smart Slide Show, and Smart eHealth.14 The main findings from this implementation effort are presented hereafter. 8.1.1. Smart City Pulse Smart City Pulse is a crowdsourcing application that aims at finding, retrieving, and monitoring data produced by a networked sensing infrastructure made of sensors embedded in different types of devices

Listing 7. MonitoringService – observing sensors

14 For the sake of space constraints, implementation details are omitted. Please, refer to https://github.com/maurocaporuscio/prime-middleware-examples.

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

Fig. 17. Smart Slide Show application – scenario.

(see Fig. 1). As shown in Fig. 6, Smart City Pulse is composed of an openended set of Sensors that are discovered and accessed at run time by Monitoring Service, which in turn exposes data of interest through a set of resources. Fulfillment of requirements {R0, . . . , R4} (see Section 2) is facilitated by the architectural fluidity properties. Because of loose coupling the Monitoring Service has no knowledge of Sensors, which are autonomous and mobile (R0, R1). Because of flexibility the number of sensors involved into the Smart City Pulse application can change at run time (R2). Because of dynamism the Monitoring Service discovers and accesses Sensors at run time (R4). Finally, because of serendipity unforeseen Sensors are dynamically engaged into the Smart City Pulse application (R3). 8.1.2. Smart Slide Show The Smart Slide Show application aims at providing conference speakers and attendees with easy accessibility to networked facility (e.g., projectors, smart-screen, and microphone) deployed within a conference room (see Fig. 17). In a typical scenario, (i) Speaker is going to give a talk at the conference room, and carries her laptop storing the presentation slides set, (ii) the conference room provides speakers with a smart-screen available on the local wireless network, and (iii) attendees are equipped with their own devices (e.g., laptop, smartphone, PDA), which can be used for displaying the slide currently projected on the screen. Functional requirements for Smart Slide Show are specified as follows: R0: Speaker has no knowledge of neither the attendees nor the smart-screen. R1: Attendees may join/leave the presentation dynamically.

23

R2: The type of smart-screen and attendees changes over the time. R3: Speaker dynamically discovers and accesses the smart-screen. Attendees dynamically discover and access Speaker. The Smart Slide Show model in Fig. 18 conforms to the P-REST metamodel and specifies two interacting Prime applications, namely SpeakerApp and AttendeeApp. SpeakerApp specifies the following resources: /currentslide, representing the currently projected slide; /speaker, modeling the remote controller used by the speaker to browse the slide show represented as an ordered list of slides. Furthermore, /speaker uses #Presenter, an abstract resource specifying a generic slide presenter. AttendeeApp specifies a resource /attendee that observes the currently projected slide, and shows it on the device’s /display. Fulfillment of requirements {R0, . . . , R3} is facilitated by the set of architectural fluidity properties. Because of loose coupling Speaker has no knowledge of Smart-screen and attendees (R0). Because of flexibility the number of attendees involved into the Smart Slide Show application changes at run time (R1). Because of dynamism Speaker can discover and access Smart-screen at run time; Attendees observe /currentslide and get notified when changes occur (R0, R3). And because of serendipity unforeseen resources implementing the #Presenter abstract resource are dynamically engaged by Speaker (R0, R2, R3). 8.1.3. Smart eHealth The Smart eHealth application aims at (i) monitoring elder people’s health parameters (e.g., weight, blood pressure, and heart rate), as well as their daily activity (e.g., sleeping, eating, and walking), and (ii) raising health alarms whenever either the health parameters or the activity deviate from usual (e.g., the patient is sleeping to much and/or the blood pressure is too low). Smart eHealth is built as an aggregation of a set of resources (see Fig. 19). In a typical scenario, wearable and ambient “Things” sense health parameters and daily activities, respectively, and provide them to Patient. This, in turn, analyzes sensed data and, in case of anomaly detection, sends an alarm to Health Service. Health Service receives the alarm and alerts either First Aid or Technical Assistance; (iv) Technical Assistance, upon receiving a Technical alarm, sends a Technician to the patient’s home. First Aid contacts the Ambulance Service, and makes a reservation at the Hospital. Hospital reserves Analysis Laboratory and Operating Rooms to manage the alarm. Finally, the Ambulance Service selects an Ambulance according to the requirements of the ongoing emergency. Besides the functional requirements, which are similar to those elicited for Smart City Pulse and Smart Slide Show, Smart eHealth also has a set of QoS requirements: whenever a choice has to be made

GET[html] POST[html]

/speaker m

[next]: “update”

dm

[#Presenter]

/display d

[#next]: “update” /currentslide b

db

GET[html] POST[html]

GET[html]

dd []: “watch”

/attendee a

GET[html]

da

observe Speaker App Fig. 18. Smart Slide Show application – model.

Attendee App

24

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

Fig. 21. Memory footprint for Resource deployment.

8.2. Implementation efficiency Fig. 19. Smart eHealth application – scenario.

Fig. 20. Smart eHealth application – model.

(of a specific health service from a patient, of a specific first-aid from a health service, of a specific ambulance service and hospital from a first-aid), the selection must guarantee the “best response time”. Fig. 20 presents a fragment of the eHealth application model, showing the architectural design of Patient: /patient is the Prime resource that represents the patient in Fig. 19, and includes a /list resource, which can be accessed by following the link labeled as analyze. /list is defined as a set of resources {res_id}. /patient makes use of three abstract resources, namely #WearableThing, #AmbientThing and #HealthService. To support a dynamic service composition, which can aggregate services at run time to satisfy the QoS requirement, Prime’s interaction management has been extended (see Section 7.1) to provide upper-level applications with a QoS-aware service assembly functionality, which is in charge of building and maintaining an assembly of resources that fulfills certain QoS requirements. The GoPrime extension leverages architectural fluidity to implement QoS-aware a service assembly feature. Because of loose coupling, service assembly has no a-priori knowledge of available resources (e.g., Health Service, Ambulance). Because of flexibility, the number of available resources can change at run time (e.g., available ambulances). Because of dynamism, service assembly can discover resources at run time and select the ones that best fits QoS requirements. Because of serendipity, unforeseen services can be dynamically engaged into the application. All these features contribute to fulfill the aforementioned set of QoS requirements.

The Prime middleware has been implemented using Java (J2SE) and released under open source license.15 Since FI applications may widely vary in size, involving few resources as well as several hundreds of resources (Schuhmann et al., 2013), Prime’s quantitative evaluation has been carried out by considering both a large number of resources and high-rate workload. To assess the efficiency of the Prime middleware implementation we evaluate (i) the amount of memory required to manage resources, which includes dynamic resources deployment and provision (Section 8.2.1), (ii) the time required to discover resources of interest (Section 8.2.2), (iii) the time required to access a resource once discovered (Section 8.2.3), and (iv) the number of messages flowing in the overlay network during resource interaction (Section 8.2.4). The physical system supporting the experiments is based on VMWare ESXi 4.0, running on an Intel Nehalem dual socket quad-core system with 32 GB of RAM. Tests have been performed by deploying Prime on a set of different and independent Virtual Machines (VM) running Linux, namely Desktop, Smartphone, and Board VM. Exploiting VMWare ESXi 4.0 management utility, VMs have been configured to simulate current state-of-the-art devices: Desktop VM is configured with 4 CPU and 8 GB of memory, Smartphone VM is configured with 4 CPU and 2 GB RAM to simulate handheld devices,16 and Board VM is configured with 1 CPU and 256 MB RAM to simulate microcontroller boards.17 VMs are isolated and communicate each other via network interfaces. 8.2.1. Resource management Figs. 21 and 22 show the memory footprint needed by Prime to manage a set of resources. Specifically, Fig. 21 profiles the memory footprint in relation to the number of deployed resources, whereas Fig. 22 profiles the memory footprint in relation to the number of active threads used to provide resource access. Both diagrams depict two different situations: Bootstrap refers to the memory footprint measured at start time, whereas Running refers to the footprint measured at run time, after the bootstrap phase is ended. Fig. 21 shows that the Bootstrap phase is critical, especially when considering Board VM. Bootstrap concerns both loading and initializing resources, which are high memory consuming tasks and may cause a “memory overflow”. The more resources we deploy the more heap memory we need to load and initialize them. However, Fig. 21 shows that the memory footprint is below the board memory limit even when considering a large number of resources (e.g., up to 5000). At

15 The Prime middleware is available at https://github.com/maurocaporuscio/primemiddleware. 16 As instance, Samsung S5 has a Quad-core 2.5 GHz Krait 400 CPU, and 2 GB of memory. 17 As instance, Intel Galileo Board has a Intel Quark X1000 400 MHz CPU, and 256 MB of memory.

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

Fig. 22. Memory footprint for Resource provision.

Fig. 24. Resource access on Desktop VM.

Fig. 23. Response time for Resource discovery.

Fig. 25. Resource access on Smartphone VM.

25

run time, memory footprint is stable and does not depend on the number of deployed resources. In fact, Prime does not keep resources into the heap memory, but they are dynamically allocated as soon as required – e.g., when processing an access request. While the memory footprint required for managing the thread pool does not vary between the two phases, the number of active threads directly impacts on the amount of memory needed to manage them (see Fig. 22): the greater the number of threads the greater the memory footprint. 8.2.2. Resource discovery Contextualization is key objective of Prime. To evaluate the semantic resource discovery mechanism provided by Prime, Fig. 23 reports the processing time needed by Prime to match requests against the local knowledge and provide a response. The lookup line represents the time to process a discovery request using the lookup feature (see Example 10), whereas the query line represents the time to process a discovery request expressed as a complex SPARQL query (see Example 11). Time increases according to the complexity of the local knowledge and, in particular, according to the complexity and size of the internal data structure used to manage the knowledge base. As expected, the complexity of both lookup and query is proportional to the number of resources managed by the PrimeApplication and depends on the specific semantic reasoner employed by Prime – i.e., OpenRDF Sesame.18 However, Fig. 23 shows that the processing time is low when considering a reasonable number of resources (e.g., less than 1000). 8.2.3. Resource provision To assess the efficiency of the Prime middleware in providing resource access, we evaluate the processing time needed to access a simple Echo resource under various configurations. Results presented are the average of 10 runs with 100 interactions each. 18

http://www.openrdf.org/.

Fig. 26. Resource access on Board VM.

Figs. 24–26 assess the performance of Prime resource access in the following configurations: (Fig. 24) provider is running on Desktop VM, (Fig. 25) provider is running on Smartphone VM, and (Fig. 26) provider is running on Board VM. The results show the average response time depending on both the requests rate and the number of threads serving them. Response time strongly depends on the request rate (i.e., requests/s) in all cases. In fact, when incoming requests exceed the available processing threads, some are queued and wait. The effect on provider behavior is twofold: (1) memory footprint increases at a fast rate by raising a “memory overflow” exception, especially on Board VM where memory limit is low (i.e., 256 MB), and (2) the response time is related to the number of requests waiting in the queue, as each request takes a finite time to be processed. Indeed, incrementing the number of threads in the thread pool solves both issues, as requests are processed concurrently and queue size does not overflow the memory space. However, as the size of the thread pool increases, the amount of memory needed by the PrimeApplication also grows (see Fig. 22). Prime is highly configurable, and lets developers set the thread pool to find out the best trade off solution among memory consumption and response time.

26

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

Fig. 27. Messages exchange for resource discovery.

8.2.4. Resource interaction Resource interaction scalability is a key aspect to be considered while assessing the Prime prototype. In fact, since resource interaction is expressed in terms of message exchanging via the overlay network (see Section 7.1), evaluating message management performance at the overlay level is crucial. Fig. 27 reports the number of messages exchanged by a set of 1000 Prime nodes involved in a resource discovery operation. Resource discovery is the most critical operation, since it involves all nodes in the Prime overlay network. To assess the efficiency of Pastry in providing message management, we evaluate the average number of messages flowing through the ring under various configurations. Results presented are the average of 10 runs, since the number of messages exchanged by any pair of nodes A and B is equal to the number of routing steps from A to B. Indeed, it depends on the specific position of A and B within the ring, which is assigned randomly. Fig. 27 shows the average number of messages exchanged between Prime nodes during the two discovery phases: (i) Lookup refers to the number of messages flowing through the Pastry ring whenever a given node A initiates the resource discovery process, and (ii) Reply refers to the number of messages flowing through the ring to whenever resources of interest are discovered. The number of Lookup messages is proportional to the total number of nodes deployed on the ring (i.e., 1000 in our experiment). As discussed in Section 7.1, a Lookup message is broadcasted to all nodes, and Pastry requires in average log24 1000 = 3 steps to route it to each node. The number of Reply messages increases according to the number of matching nodes, i.e., nodes hosting the resource of interest. Specifically, Fig. 27 shows the number of Reply at varying of the number of matching nodes: 1 out of 1000, 5 out of 1000, . . . , 1000 out of 1000. As discussed in Section 7.1, Replay is a unicast message sent by all matching nodes back to the requesting node. Also in this case Pastry requires in average log24 1000 = 3 steps to route each of them through the ring. As it can be observed, the total number of messages flowing through the Pastry ring grows rapidly as the number of interacting Prime nodes grows, especially when issuing lookup messages. This is due to the strategy adopted by Prime to implement the lookup operation, i.e., broadcasting lookup messages to all nodes thorough the Scribe multicast framework, which in turn relies on Pastry communication. The experimental results show that this implementation strategy is not optimal and hinders scalability. However, as discussed in Section 7.1, Prime’s interaction management is fully decoupled from the underlying overlay implementation, which can be easily replaced with different types of overlay networks providing better routing strategies that can mitigate or even eliminate the problem.

As discussed above, abstractions efficacy has been assessed by developing a set of Smart City applications that point out the importance of satisfying architectural fluidity properties. Since the three applications have been specifically developed for evaluation purposes, they provide only a limited set of simplified features. Indeed, descriptive statistics of such prototypes, e.g., lines of code and cyclomatic complexity, would result simplistic and not significative. To overcome this issue, we plan to conduct a controlled experiment with a number of software engineering students, which will design and develop real fully-featured applications on top of Prime. Hence, such applications will be used to derive meaningful descriptive statistics. Implementation efficiency has been assessed by running a number of experiments aiming at the evaluation of key functionalities: resource management, resource discovery, resource provision, and resource interaction. Such experiments have been performed by deploying Prime on a set of independent and isolated VMs that communicate each other via network interfaces. On the one hand, this allows us to evaluate such key functionalities in isolation, by preventing VMs from interfering with each other. On the other hand, it prevents us to evaluate the key functionalities in real FI settings. In fact, making the experimentation environment closed and fully controlled removes de facto all the uncertainties inherent to FI. To overcome this issue, we plan to conduct a set of experiments on the field, by deploying Prime on real handheld devices and microcontroller boards. 9. Conclusions and future work In this paper we have addressed the problem of designing and developing network-based applications for future internet. To support application development, we developed the Prime (P-Rest at design/run tIME) approach, which provides modeling and programming abstractions for: (i) Resource Abstraction to uniformly represent heterogeneous software artifacts irrespectively of their specific nature (i.e., thing, service, and content), and (ii) Resource Contextualization to discover and correlate resources of interest. Prime supports the design and implementation of resource-oriented FI applications by leveraging P-REST architectural style and semantic awareness. We have assessed Prime both qualitatively and quantitatively and the obtained results were encouraging. In particular, we have been able to show that Prime can be successfully executed also on lowresource devices, such as smartphones and microcontroller boards. Ongoing and future work proceeds toward different lines of research. First, we are currently defining a high-level composition language allowing developers to specify their own resource compositions in an agile and asynchronous way. Further evolution of Prime is toward the satisfaction of extra-functional requirements. In particular, we want extend the Resource Description Language, and the lookup service, to consider extra-functional concerns (e.g., quality of service, security) while specifying and searching for resources of interest, as well as when composing them. We are also improving Prime prototype by investigating alternative overlay networks (Baresi et al., 2013). Concurrently, we are implementing Prime for Android19 to develop real world mobile applications. Acknowledgments Prime has been developed as part of a larger initiative on assisting the development of dependable self-managing situated applications, which was undertaken under funding from European Commission, Programme IDEAS-ERC, Project 227977-SMScom (http://www.ercsmscom.org).

8.3. Threats to validity There are some potential threats to the validity of the qualitative and quantitative assessment.

19

http://www.android.com/.

M. Caporuscio, C. Ghezzi / The Journal of Systems and Software 106 (2015) 9–27

References Bandara, A., Payne, T., De Roure, D., Gibbins, N., Lewis, T., 2008. A pragmatic approach for the semantic description and matching of pervasive resources. In: Proceedings of the 3rd International Conference on Advances in Grid and Pervasive Computing, pp. 434–446. Baresi, L., Guinea, S., Saeedi, P., 2013. Self-managing overlays for infrastructure-less networks. In: Proceedings of the 2013 IEEE 7th International Conference on SelfAdaptive and Self-Organizing Systems. Bellur, U., Narendra, N., 2005. Towards service orientation in pervasive computing systems. In: International Conference on Information Technology: Coding and Computing. Berners-Lee, T., Hendler, J., Lassila, O., 2001. The semantic web. Sci. Am. 284 (5), 34–43. Beugnard, A., Jézéquel, J.-M., Plouzeau, N., Watkins, D., 1999. Making components contract aware. IEEE Comput. 32 (7), 38–45. B’far, R., 2004. Mobile Computing Principles: Designing and Developing Mobile Applications with UML and XML. Cambridge University Press, New York, NY, USA. Bonetta, D., Pautasso, C., 2011. An architectural style for liquid web services. In: Proceedings of the Ninth Working IEEE/IFIP Conference on Software Architecture. Washington, DC, USA. Caporuscio, M., Funaro, M., Ghezzi, C., 2011. RESTful service architectures for pervasive networking environments. In: Wilde, E., Pautasso, C. (Eds.), REST: From Research to Practice. Springer, New York, pp. 401–422. Caporuscio, M., Raverdy, P.-G., Issarny, V. , 2012. ubiSOAP: a service-oriented middleware for ubiquitous networking. IEEE Trans. Serv. Comput. 5 (1), 86–98. Castro, M., Druschel, P., Kermarrec, A.-M., Rowstron, A., 2002. Scribe: a large-scale and decentralized application-level multicast infrastructure. IEEE J. Sel. Areas Commun. 20 (8), 1489–1499. Cervantes, H., Favre, J.-M. , 2002. Comparing JavaBeans and OSGi towards an integration of two complementary component models. In: Proceedings of EUROMICRO Conference. Dey, A.K., Abowd, G.D., Salber, D., 2001. A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Hum.-Comput. Interact. 16 (2), 97–166. Di Nitto, E., Rosenblum, D., 1999. Exploiting ADLs to specify architectural styles induced by middleware infrastructures. In: Proceedings of the 21st International Conference on Software Engineering. ACM, pp. 13–22. Doval, D., O’Mahony, D., 2003. Overlay networks: a scalable alternative for P2P. IEEE Internet Comput. 7 (4), 79–82. Edwards, K., Newman, M., Sedivy, J., Smith, T., 2009. Experiences with recombinant computing: exploring ad hoc interoperability in evolving digital networks. ACM Trans. Comput.-Hum. Interact. 16, 3:1–3:44. ESSI WSMO Working Group, 2007. Web Services Modeling Ontology. http://www.wsmo.org. Fielding, R.T., 2000. REST: Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine. (Ph.D. thesis) Giunchiglia, F., Yatskevich, M., Shvaiko, P., 2007. Semantic matching: algorithms and implementation. In: Journal on Data Semantics IX. Springer-Verlag, pp. 1–38. Google, 2014. Physical Web. http://google.github.io/physical-web/. Grace, P., Blair, G.S., Samuel, S., 2005. A reflective framework for discovery and interaction in heterogeneous mobile environments. SIGMOBILE Mobile Comput. Commun. Rev. 9, 2–14. Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., Orchard, D., 2012. Uri template – Request for Comments: 6570. http://tools.ietf.org/html/rfc6570. Guinard, D., Trifa, V., Pham, T., Liechti, O., 2009. Towards physical mashups in the web of things. In: Proceedings of the 6th International Conference on Networked Sensing Systems, pp. 196–199. Guinard, D., Trifa, V., Wilde, E., 2010. A resource oriented architecture for the web of things. In: Internet of Things (IOT), 2010, pp. 1–8. Hirsch, F., Kemp, J., Ilkka, J., 2006. Mobile Web Services: Architecture and Implementation. John Wiley & Sons. Hoareau, D., Mahéo, Y., 2008. Middleware support for the deployment of ubiquitous software components. Pers. Ubiquitous Comput. 12, 167–178. Huang, Y., Garcia-Molina, H., 2001. Publish/subscribe in a mobile environment. In: Proceedings of the 2nd ACM International Workshop on Data Engineering for Wireless and Mobile Access, pp. 27–34. Issarny, V., Caporuscio, M., Georgantas, N., 2007. A perspective on the future of middleware-based software engineering. In: Future of Software Engineering. IEEECS Press. Issarny, V., Sacchetti, D., Tartanoglu, F., Sailhan, F., Chibout, R., Levy, N., Talamona, A., 2005. Developing ambient intelligence systems: a solution based on web services. Autom. Software Eng. 12 (1), 101–137. Kansal, A., Nath, S., Liu, J., Zhao, F., 2007. Senseweb: an infrastructure for shared sensing. IEEE Multimedia 14 (4), 8–13. Khare, R., Taylor, R.N., 2004. Extending the representational state transfer (REST) architectural style for decentralized systems. In: ICSE. Edinburg, UK. Kindberg, T., Barton, J., 2001. A web-based nomadic computing system. Comput. Networks 35 (4), 443–456. Kortuem, G., 2006. Modelling and evaluating fluid software architectures for intelligent environments. In: 2nd IET International Conference on Intelligent Environments, pp. 201–210. Lelli, F., Pautasso, C., 2009. Controlling and monitoring devices with REST. In: Proceedings of the 4th International Workshop on Distributed Cooperative Laboratories: “Instrumenting” the Grid (INGRID 2009). Italy.

27

Mancinelli, F., 2010. Leveraging the web platform for ambient computing: an experience. IJACI 2 (4), 33–43. Mokhtar, S.B., Preuveneers, D., Georgantas, N., Issarny, V., Berbers, Y., 2008. EASY: efficient semantic service discovery in pervasive computing environments with QoS and context support. J. Syst. Software 81, 785–808. Nelson, T., 1965. Complex information processing: a file structure for the complex, the changing and the indeterminate. In: Proceedings of the 20th National Conference, pp. 84–100. Network Working Group, 1999. Hypertext transfer protocol (HTTP/1.1) – Request for Comments: 2616. http://tools.ietf.org/html/rfc2616. Nottingham, M., 2010. Web linking – Request for Comments: 5988. http://tools.ietf.org/ html/rfc5988. Olsen Jr., D.R., Jefferies, S., Nielsen, T., Moyes, W., Fredrickson, P., 2000. Cross-modal interaction using XWeb. In: 13th Annual ACM Symposium on User Interface Software and Technology, pp. 191–200. OSGi Alliance, 2007. OSGi service platform, core specification, release 4. Paolucci, M., Kawamura, T., Payne, T., Sycara, K., 2002. Semantic matching of web services capabilities. In: First International Semantic Web Conference. Papadimitriou, D., 2009. Future internet – the cross-ETP vision document. http://www.future-internet.eu, Version 1.0. Platt, D., 1999. Understanding COM+. Microsoft Press. Preda, M.D., Gabbrielli, M., Guidi, C., Mauro, J., Montesi, F., 2012. Interface-based service composition with aggregation. In: Proceedings of the First European conference on Service-Oriented and Cloud Computing, pp. 48–63. Richardson, L., Ruby, S., 2007. RESTful Web Services. O’Reilly. Roman, G.-C., Picco, G.P., Murphy, A.L., 2000. Software engineering for mobility: a roadmap. In: FOSE ’00. ACM, New York, NY, USA, pp. 241–258. Rowstron, A., Druschel, P., 2001. Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. In: Guerraoui, R. (Ed.), Proceedings of Middleware 2001. In: Lecture Notes in Computer Science, 2218. Springer, Berlin, Heidelberg, pp. 329–350. Russell, S.J., Norvig, P., 2003. Artificial Intelligence: A Modern Approach, second ed. Pearson Education. Schuhmann, S., Herrmann, K., Rothermel, K., Boshmaf, Y., 2013. Adaptive composition of distributed pervasive applications in heterogeneous environments. ACM Trans. Auton. Adapt. Syst. 8 (2), 10:1–10:21. Stevenson, G., Ye, J., Dobson, S., Pianini, D., Montagna, S., Viroli, M., 2013. Combining self-organisation, context-awareness and semantic reasoning: the case of resource discovery in opportunistic networks. In: Proceedings of the 28th Annual ACM Symposium on Applied Computing, pp. 1369–1376. Sun Microsystems, 2006. Enterprise JavaBeans, Version 3.0. Sycara, K., Paolucci, M., Ankolekar, A., Srinivasan, N., 2003. Automated discovery, interaction and composition of semantic web services. J. Web Semant. 1 (1), 27–46. Tanenbaum, A.S., Van Renesse, R., 1985. Distributed operating systems. ACM Comput. Surv. 17, 419–470. W3C, 2004a. OWL-S: Semantic Markup for Web Services. http://www.w3.org/ Submission/OWL-S/. W3C, 2004b. Resource Description Framework (RDF). http://www.w3.org/RDF/. W3C, 2005. Web Service Semantics (WSDL-S). http://www.w3.org/Submission/ WSDL-S/. W3C, 2007. Simple Object Access Protocol. http://www.w3.org/TR/soap/. Zambonelli, F., Castelli, G., Ferrari, L., Mamei, M., Rosi, A., Marzo, G.D., Risoldi, M., Tchao, A.-E., Dobson, S., Stevenson, G., Ye, J., Nardini, E., Omicini, A., Montagna, S., Viroli, M., Ferscha, A., Maschek, S., Wally, B., 2011. Self-aware pervasive service ecosystems. Procedia Comput. Sci. 7 (0), 197–199. Zaremski, A.M., Wing, J.M., 1995. Signature matching: a tool for using software libraries. ACM Trans. Software Eng. Methodol. 4, 146–170.

Mauro Caporuscio is an Associate Professor at the Department of Computer Science, Linnaeus University (Växjö, Sweden). He received his Ph.D. in Computer Science from the University of L’Aquila, Italy (2006). He was an Assistant Professor at the Politecnico di Milano (2010–2014), and Postdoctoral Researcher at INRIA Paris-Rocquencourt (2006–2009). He has published several papers on the most important international journals and conferences, and has served in the program committee of international conferences. His research interests mainly focus on the application of Software Engineering methodologies and techniques to the field of distributed systems, with particular emphasis to middleware supporting Pervasive Computing. Further information is available at http://www.maurocaporuscio.net.

Carlo Ghezzi is an ACM Fellow, an IEEE Fellow, a member of the European Academy and of the Italian Academy of Sciences. He received the ACM SIGSOFT Distinguished Service Award. He is the current President of Informatics Europe. He is a regular member of the program committee of flagship conferences in the software engineering field, such as the ICSE and ESEC/FSE, for which he also served as Program and General Chair. He has been the Editor in Chief of the ACM Trans. on Software Engineering and Methodology and is currently an Associate Editor of the Communications of the ACM, IEEE Trans. on Software Engineering, Science of Computer Programming, Computing, and Service Oriented Computing and Applications. His research has been mostly focusing on different aspects of software engineering and, most recently, on dependable self-adapting systems. He co-authored over 200 papers and 8 books. He coordinated several national and international research projects. He has been the PI of the ERC Advanced Grant SMScom.