Supervisors : Dominique Guinard, Vlad Trifa Prof. Dr. Friedemann Mattern Institute for Pervasive Computing Department of Computer Science ETH Zurich
April 2010
Abstract
After the age of the mainframe (“many humans per computer”) and the period of the PC (“one computer per human”), we are currently experiencing the dawn of the era of ubiquitous computing (“many computers per human”), a time that is expected to lead to the integration of microprocessing and networking capabilities into all kinds of everyday objects. The idea at the very core of a Web of Things is to integrate such smart devices as first-class citizens into the World Wide Web (WWW) and thus allow users to access physical objects via URLs, to browse them and to compose the data they provide and their functionalities into physical mashups.
This thesis explores approaches to incorporating new devices into the Web of Things as well as to combining their services through the use of a distributed management infrastructure. Within the context of extending the Web of Things, we propose a novel architecture for the web-enabling of smart devices and discuss results from a comparison of that alternative with an existing design. Furthermore, we present a meta-program that enables developers to rapidly integrate devices into the Web of Things by automating the implementation of the web server component responsible for exposing these things on the Web. Regarding the facilitated creation of physical mashups that incorporate the data and/or func- tionality of multiple resources on the Web of Things, we introduce the notion of Smart Hubs and present InfraWOT, a concrete implementation of this concept. As a modular, distributed man- agement infrastructure for the Web of Things that focuses on infrastructure-assisted searching and includes a versatile semantic discovery mechanism, InfraWOT fosters the rapid compo- sition of services provided by devices connected to the Web. Additionally, the nodes of this infrastructure feature a maintenance module that provides structure-level self-stabilization and a messaging component that establishes the link between attached devices and different Web 2.0 applications. To illustrate the benefits of such an infrastructure with respect to the combination of functionalities of different devices, we present multiple prototype applications. Zusammenfassung
Wir erleben gegenw¨artigden Anbruch des Zeitalters des ubiquitous computing, einer Entwick- lung, die den Ausklang der Epoche des PCs als Einzelplatzrechner einl¨autetund, im Vergleich mit dem Zeitalter des Grossrechners, gleichzeitig ein grundlegend gegens¨atzliches und vollkom- men neues Paradigma verk¨orpert: An die Stelle der Vielzahl an notwendigen Operatoren um einen einzelnen Computer zu bedienen tritt nun eine Schar an vernetzten smart things, die als allgegenw¨artige,unsichtbare Hintergrundassistenten f¨ur einzelne Menschen agieren. Die Vision eines Web of Things zielt darauf ab, solche Objekte als gleichwertige Mitglieder in das World Wide Web (WWW) zu integrieren, um die von ihnen angebotenen Daten und Funktionen mit- tels seiner Mechanismen (URLs, HTTP, etc.) in physischen Mashups zu verkn¨upfenund es Benutzern zu erm¨oglichen, die physische Welt mit den Mitteln des Web zu begreifen.
In dieser Arbeit untersuchen wir Ans¨atzef¨urdie Integration von vernetzten Ger¨atenund deren Funktionalit¨atin das Web of Things und stellen eine verteilte Managementinfrastruktur vor, die es Benutzern erleichtert, diese zu physischen Mashups zu kombinieren. Um das Web of Things zu erweitern, schlagen wir eine neuartige Architektur f¨urdie Anbindung von vernetzten Dingen an das Web vor und untersuchen deren Vor- und Nachteile im Vergleich mit einer beste- henden Alternative. In diesem Zusammenhang stellen wir ausserdem ein Meta-Programm vor, welches die Implementierung der f¨urdie Web-Darstellung der Ger¨ateeigenschaften zust¨andigen Webserver-Komponente automatisiert und es damit Entwicklern erm¨oglicht, neue Dinge sehr schnell mit dem Web of Things zu verbinden. Um die einfache und schnelle Entwicklung von Mashups zu erm¨oglichen, f¨uhrenwir das Konzept des Smart Hub ein und pr¨asentieren InfraWOT als eine konkrete Implementierung einer In- frastruktur solcher Knoten. Es handelt sich hierbei um eine modulare, verteilte Manage- mentinfrastruktur f¨urdas Web of Things, deren Schwerpunkte auf einem infrastrukturun- terst¨utztenSuchapparat und einem vielseitigen Mechanismus zur semantischen Identifizierung und Eingliederung von schlauen Gegenst¨andenliegen. Damit wird die vereinfachte Kombi- nation der von smart things angebotenen Dienste erm¨oglicht. Die einzelnen Knoten dieser Infrastruktur beinhalten einen Mechanismus zur Selbststabilisierung auf Strukturebene und ein Vermittlungsmodul um die Kooperation zwischen dem Web of Things und verschiedenen Anwendungen des Web 2.0 herzustellen. Anhand einiger implementierter Beispiele – vor allem aus dem Bereich der Mensch-Maschine Interaktion – werden die Vorteile dieser Infrastruktur illustriert. Table of contents
4 Enabling Devices for the Web of Things 15 4.1 Sun Small Programmable Object Technology (SPOT) ...... 16 4.2 Integrating Smart Devices into the Web of Things ...... 16 4.3 A Synchronization-Based Web of Things Driver Architecture ...... 18 4.3.1 The Sun SPOT OnSPOT Software ...... 18 4.3.2 The Sun SPOT Host Software ...... 19 4.4 Evaluation ...... 23 4.4.1 Power Requirements ...... 24 4.4.2 Response Time ...... 24 4.4.3 Age of Retrieved Data ...... 25 4.4.4 Concurrency ...... 25 4.4.5 Protocol Consistency ...... 26 4.5 Summary ...... 26
5 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT 29 5.1 Conceptional Properties of Web-Enabled Resources ...... 30 5.1.1 XML Structure Configuration ...... 30 5.1.2 Push-Based Interaction ...... 32 5.1.3 Semantic Markup of Resources ...... 32 5.2 AutoWOT System Design ...... 33 5.2.1 Interpreter ...... 33 5.2.2 Builder ...... 34 5.3 System Design of AutoWOT-Generated Web Servers ...... 34 5.3.1 Components of a Plain Java AutoWOT Web Server ...... 35 5.3.2 Components of an OSGi-based AutoWOT Web Server ...... 35 5.3.3 Resource Representations and Web Interaction ...... 37 5.4 Examples of Web-enabled Devices ...... 39 5.4.1 Sun SPOT Driver ...... 39 5.4.2 Lego Mindstorms NXT Driver ...... 39 5.4.3 Phidgets RFID Driver ...... 40 5.4.4 Augmented Gaming for the Web of Things: Settlers of Catan ...... 40 5.4.5 Enabling virtual resources for the Web of Things ...... 41 5.5 Summary ...... 41
6 A Distributed Modular Infrastructure for the Web of Things: InfraWOT 43 6.1 Structuring the Web of Things ...... 44 6.2 Technical Design Choices ...... 45 6.3 System Design ...... 45 6.3.1 Modules Overview ...... 46 6.3.2 Discovery Service ...... 47 6.3.3 Querying Service ...... 49 6.3.4 Infrastructure Service ...... 56 6.3.5 Messaging Service ...... 59 6.3.6 Registry Service ...... 62 6.3.7 Aggregation Service ...... 66 6.3.8 Web Interface Service ...... 67 6.4 Summary ...... 69
7 Applications and Prototypes 71 7.1 Miniature Mashups ...... 71 7.1.1 WOTStocks ...... 72 7.1.2 LED Control Mashup ...... 73 7.1.3 Shadow Mashup ...... 73 7.2 WOTic Music Player ...... 73 7.2.1 Technical Details ...... 74 7.2.2 Summary ...... 75 7.3 WOTpong ...... 75 7.4 Summary ...... 76
8 Conclusion and Future Work 77 8.1 Future Work ...... 77 8.2 Conclusion ...... 78 8.3 Acknowledgements ...... 79
Appendices 79
A Hints and How To-s 81 A.1 OSGi Setup ...... 81 A.1.1 Running OSGi Frameworks with DS-support within Eclipse ...... 82 A.2 Sun SPOT Driver Manual ...... 82 A.3 AutoWOT Manual ...... 82 A.4 InfraWOT Manual ...... 85 B InfraWOT REST API 87 B.1 Messaging Service REST API ...... 87 B.2 Discovery Service REST API ...... 90 B.3 Others ...... 91
C Class Diagrams 93 C.1 Class Diagram - Sun SPOT onSPOT Software ...... 93 C.2 Class Diagrams - Sun SPOT Host Software ...... 94 C.2.1 Sun SPOT Host Driver Core Bundle ...... 94 C.2.2 Sun SPOT Host Web Server Bundle ...... 95 C.3 Class Diagram - AutoWOT Deployment Toolkit ...... 96 C.4 Class Diagrams - InfraWOT ...... 97 C.4.1 InfraWOT Discovery Service Bundle ...... 97 C.4.2 InfraWOT Messaging Service Bundle ...... 98
Bibliography 98
Chapter 1 Introduction
The Web of Things (WoT) paradigm [22] is a vision of a World Wide Web that reaches into the physical world by providing a seamless integration of smart devices and considering them as being first-class citizens of the Web. The aim of this approach is that interacting with devices as well as creating new applications by composing their services with existing ones becomes almost as easy as browsing the Web [21] because commonly known Web tools, interaction tech- niques and languages can be directly applied to the real world [22]. Although inspired by the Internet of Things [13], this concept is different in that it aims at us- ing widely deployed and highly accepted protocols and standards known from the “traditional” Web like the Hypertext Transfer Protocol (HTTP) or Uniform Resource Identifiers (URIs). The Web of Things distinguishes itself from WS-* Web Services in that it does not use HTTP only as a transport protocol to convey specification-conform data but rather directly exposes the functionalities of smart things by adopting a Representational State Transfer (REST)-driven [11], Resource-Oriented Architecture (ROA) [38]. As any information exchange within the Web of Things takes place using one of the four basic HTTP verbs (GET, POST, PUT and DELETE), the entire interaction with smart things can happen via browsers and browser side-kicks thereby virtually eliminating compatibility issues due to vendor-specific protocols and greatly lowering the barrier of entry [37]. Additionally, the Web of Things inherits all the mechanisms that made the Web scalable and successful like caching, load-balancing, indexing and searching [22] and the stateless nature of the HTTP protocol. For making a RESTful service discoverable, it is not necessary to register it to a specific repository [37] – rather, such services can be indexed by “traditional” web search engines and may even provide standardized semantic markup to convey their functionalities and interaction possibilities. Finally, enabling devices to communi- cate via HTTP requires only a fraction of the resources that would be needed for having them support “big” web services based on the Simple Object Access Protocol (SOAP) or similar architectures [21].1
1For a thorough comparison of REST and WS-*, refer to [37] 2 Introduction
However, using HTTP as the basic primitive for building the Web of Things also introduces problems, most prominently the pull-based interaction model of the web that is not suitable for modeling the communication with smart devices with respect to monitoring [22] – we would like devices that are equipped with sensors and monitor their environment to provide their data using an event-based, publish/subscribe mechanism. Another limitation of RESTful services is that the inherent simplicity of REST paradoxically complicates the creation of complex services [21]. To counteract this effect, an infrastructure for the Web of Things is required that provides services on top of resources connected to the WoT, including a mechanism that facilitates the rapid combination of multiple resources for creating advanced mashups. Within the context of web-enabling smart devices, the current way of how we integrate resources that are not HTTP- enabled by themselves seems to have several drawbacks [21] and alternative architectures should be proposed and evaluated. Finally, to support efforts of populating the Web of Things with more devices, it would be very interesting to have a standardized approach to integrating smart things into the WoT.
1.1 Goals
With respect to the limitations mentioned above, several components of the Web of Things should be proposed and implemented in this thesis, most prominently an auxiliary management infrastructure and software tools providing rapid integration of real-world devices into the WoT while building upon and relating to previous projects. In particular, the goals of this thesis are:
Web-Enabling Devices Evaluate, implement and compare approaches to the RESTful in- tegration of devices into the Web of Things. The evaluation should also include REST- enabling several real-world devices.
Infrastructure for the Web of Things Develop, implement and evaluate a modular, dis- tributed infrastructure for the Web of Things that provides additional functionality on top of the integration of devices into the WoT, in particular the ability to efficiently search for services provided by web-enabled devices.
Web 2.0 Integration Propose a method to integrate smart things with different Web 2.0 applications and platforms (e.g. Twitter) via the Web of Things infrastructure to foster interactivity and information sharing and, in particular, enabling physical mashups that involve real-world devices.
1.2 Contributions
In this thesis, we propose an architecture for web-enabling smart things and use it to attach multiple devices (Sun SPOTs, RFID readers, augmented playing fields) to the Web of Things. To foster the rapid integration of further devices, a generic resource model was developed and integrated into a meta-program that semi-automatically builds web server components which expose these smart things as prime citizens of the Web. Furthermore, we designed and implemented a distributed, modular management infrastructure for the Web of Things where the main focus was to enable clients to search for smart devices and their respective functionalities/services thereby facilitating the creation of composite ap- plications. Additionally, the nodes of this infrastructure feature a maintenance module that 1.3. Outline 3 provides structure-level self-stabilization and a messaging component that establishes the con- nection between attached devices and “Information Consumers” like, for instance, Web 2.0 applications such as Twitter or Google Talk.
1.3 Outline
This thesis is structured into the following parts: After an introduction to different com- ponents of the Web of Things and a discussion of related work in Chapter2, we will present some of the major technologies used throughout this work in Chapter3. Chapter4 focuses on driver architectures for the Web of Things and presents a synchronization-based driver design for smart devices. The discussion on ways to web-enable devices is taken one step further in Chapter5, where AutoWOT, a toolkit for the rapid web-enabling of devices, is described. In Chapter6, a management infrastructure for the Web of Things is introduced and its modules, in particular those responsible for querying, infrastructure maintenance and messaging, are de- scribed thoroughly. Chapter7 presents several application prototypes that largely benefit from the proposed driver architecture and infrastructure and in Chapter8, an overall conclusion is given and further steps are motivated. 4 Introduction Chapter 2 Components of the Web of Things
Several terms are used to identify the different components of the Web of Things that will often be referred to in the rest of this thesis. In this section, these and the associated concepts will be introduced and clarified, thereby also describing some more aspects of the WoT. Where appropriate, we will refer to related work that has been done within the context of the Web of Things.
Web of Things Drivers A Web of Things Driver is a piece of software that bridges the gap between the physical world and the World Wide Web by exposing smart things as web resources. Such a driver typically consists of a device driver module that makes a physical device accessible from a computer and a web server component whose task it is to expose a subset of a device’s functionality via the Web and thereby establish the link between HTTP clients and the physical device. However, specific implementations of Web of Things Drivers may differ in how exactly the device is accessed by the software: A driver may either act as a reverse-proxy that relays HTTP requests to devices that themselves contain a web server component [20] or it may decouple the processes of client-driver and driver-device communication. Chapter4 provides detailed information on Web of Things Drivers as well as a description of a concrete implementation of a driver developed in the course of this thesis. In Chapter5, we propose a way of automatically creating the web server component of Web of Things Drivers and thereby enable rapid deployment of smart devices into the WoT.
Smart Things / Smart Devices We refer to all kinds of physical objects that are networked and can therefore be web-enabled using a Web of Things Driver as smart things or smart devices. Examples of such devices are web-enabled sensors, actuators, embedded computers or even complete augmented gaming environments.
Smart Hubs A Smart Hub is a component of the Web of Things that provides advanced services on top of devices that are connected to the Web, in particular services that enable physical mashups i.e. that offer the possibility of having devices interact with each other to 6 Components of the Web of Things provide functionality that goes beyond what each device could present by itself. Every Smart Hub requires modules that discover smart devices and store information on them, a process that is referred to as attaching a resource (i.e. the smart device) to the hub. Additionally, it may provide querying and publishing services on top of the discovered devices and, as one will typically go for a distributed implementation rather than having a central portal that every smart device is attached to, a way of maintaining the structural relationships between hubs within an infrastructure. More detailed information on this concept and its components can be found in Chapter6, where a Smart Hub-based infrastructure for the Web of Things is proposed.
Smart Gateways A Smart Gateway is a software component that enables web-based interac- tion with different kinds of embedded devices. Furthermore, such gateways can be connected to form hierarchical trees [44] and thus represent a concept very similar to the combination of a Smart Hub and Web of Things Drivers for several smart devices within a single software package. Smart Gateways were designed such that users can easily integrate drivers for any em- bedded device or sensor network to expose the device’s functionality as URI-identified resources that are directly accessible on the Web and thus can be manipulated using HTTP [44].
Physical Mashups Web 2.0 Mashups are applications that use information or functionalities provided by external sources to generate more sophisticated services on top of these. One of the pre-eminent examples for such an application is the HousingMaps mashup1 which combines Google Maps2 with Craigslist3 apartment rental/purchase data to create an interactive housing search tool [36]. Physical Mashups are an extension of that paradigm in that they combine real-time data and services provided by smart things to create advanced virtual or physical services [21]. A. Aguilar [1] explores an approach to enable end users to create physical mashup applications by the use of a mobile device – an example of a physical mashup that users are able to generate within that project is an energy-saving application that would start a user’s home heating as soon as he approaches his home by combining information from the user’s mobile phone (i.e. the GPS sensor data) with the functionality of a RESTful plug.
2.1 Related Work
Here we provide an overview of some related work, starting with systems that have been proposed for the web-integrated processing of sensor data and the HTTP-integration of hetero- geneous devices in general.
SenseWeb SenseWeb [28] is a platform that allows people to collect, share and query sensor data. It aims on providing a means to enable the easy registration of sensors and the facilitated development of sensing applications that use these. To interact with the Coordinator module (a centralized server that holds the main database), a SOAP-based API is provided.
Pachube Pachube [24] offers similar services as SenseWeb, i.e. sharing and searching for sensor data, while focusing on sensor environments that provide a contextual reference for sensor data. However, it is based on a centralized repository and devices need to be individually registered before they can publish data which poses problems regarding scalability [44].
1http://www.housingmaps.com 2http://maps.google.com 3http://www.craigslist.org 2.1. Related Work 7
Flexeo Flexeo [45] is an architecture for implementing monitoring solutions based on wireless sensor networks and connecting these to the Internet. By adopting a multi-layer decision- making approach, Flexeo tries to enable hetergeneous application scenarios while minimizing the required amount of redesign and recoding. On its top Supervision layer, it provides a web interface for end users to access and manage the sensor data.
Our approach differs from these architectures with respect to its purely REST-based, dis- tributed architecture where HTTP is used not only for transport but as an application layer protocol to web-enable and mashup devices. The approach taken by TinyREST [31] is similar to ours with respect to the integration of sensors and actuators into the web but introduces the SUBSCRIBE operation as a new HTTP method and thereby violates the REST uniform interface principle in its fundamentals. With respect to the RESTful interaction paradigm, the pico-REST (pREST) [10] system is very similar system to ours. pREST distinguishes between Complex Resources that are represented by static XML documents and may contain context and semantical information using the Resource Description Framework (RDF), Primitive Resources that act as data sinks or sources and Services where HTTP POST requests are interpreted as invocations of the service. Next, we present some interesting projects that build upon the REST principles to create and support physical mashups.
EnergieVisible The EnergieVisible [23] software can be used to easily monitor the power consumption of devices connected to Bluetooth-enabled smart plugs (Ploggs4). The software retrieves all Ploggs in the environment and exposes their functionality (i.e. power consumption data and an on/off switch) via a dynamic, Google Web Toolkit (GWT)-driven web page.
RESTful EPCIS This project [34] focused on exposing the heavy-weight web services of the Electronic Product Code Information Service (EPCIS) standard as a light-weight RESTbased interface that allows to access the service by also using web languages like JavaScript. A mashup was created that contains widgets to visualize the tracked business events and to expose relationships and aggregations of EPCIS data thereby allowing multiple scenarios with respect to supply chain management (goods tracking) or logistics (inventory level history tracking).
Friends and Things The Friends and Things (FaT) project [19] proposes a way of sharing web-enabled devices that relies on existing social networks. As such Web 2.0 applications (such as Facebook and Twitter) increasingly reflect our social relationships, one can simply select friends or groups of friends to share with instead of creating abstract resource access lists or username/password-pairs. This adds to the vision of the Web of Things as a composable ecosystem that fosters the re-using and combining of devices to create physical mashups.
4http://www.plogginternational.com/ 8 Components of the Web of Things Chapter 3 Technological Background
In this chapter, we will introduce some of the major technologies and architectural concepts that were applied during this thesis and motivate the reasons for favoring them. After an introduction to the REST architectural style, the ROA and Restlet that almost every web server component of our software is dependent on in Section 3.1, we will present the JavaScript Object Notation (JSON) as the main data interchange format used throughout this thesis (Section 3.2). We will then introduce Microformats as a way of providing semantic markup for (X)HTML pages in Section 3.3 and describe the OSGi framework as an environment to develop modular applications in Section 3.4.
3.1 Representational State Transfer (REST)
The REST architectural style introduced in Roy Fielding’s doctoral thesis [11] and the Resource-Oriented Architecture (ROA) [38] as a concrete implementation of this style revolve around the central concept of resources and the principles of addressability, the uniform inter- face, statelessness and hypermedia as the engine of application state [12]:
Resources A resource is any component of an application that is important enough to be addressed and has (at least) one URI [38]. Resources can be web sites, weblog entries or lists of open bugs [38] but also physical objects like light sensors, motors or RFID-tagged items. We distinguish between the abstract concept of resources and the representation of a resource which is the data that is actually delivered to an HTTP client and contains any useful information about the current state of a resource. As there can be multiple representations of a single resource (e.g. in different data formats or several languages), the server also has to have a way of selecting the most appropriate representation to return. To support this kind of interaction, HTTP features a mechanism called content negotiation that allows the client to specify the expected response type (or even a preference list of multiple types) within the request, for instance using the Accept or Accept-Language headers [16]. 10 Technological Background
Addressability The principle of addressability states that scoping information (i.e. informa- tion on the resource to interact with) is kept within the URI rather than being transmitted in the body of HTTP requests. Furthermore, when relying on URIs to identify resources, links to resources can be established using a well-known identification scheme [22].
Uniform Interface This principle defines that the server has to be able to determine what to do when a request is received at a specific URI by just looking at the request’s HTTP method. The four basic operations encoded in this header are GET, POST, PUT and DELETE. To give an example, a server at example.com that receives a request the first line of which reads
1 DELETE /users/testuser immediately knows what the client expects it to do: Delete the resource testuser that is a sub- resource of a users-resource attached to example.com. Such a request and the corresponding server action are thus an example of a RESTful service that conforms to the principles of addressability and the uniform interface.
Hypermedia As The Engine Of Application State (HATEOAS) This principle states that resources should provide links to other resources that should be followed by clients to explore the resource structure. The ability of clients to able to discover offered services by simply following links eliminates the need for specific discovery formats [33].
Statelessness The principle of statelessness is automatically followed by HTTP as it provides no interaction possibilities other than request/response. While a common method for introduc- ing state to a user’s session is keeping a server-side state (for instance using session ID that is included in a request), the protocol is still stateless in that the interaction is fully self-contained and does not depend on the context for interpretation [38].
According to [37], REST is the architecture of choice for “tactical, ad hoc integration over the Web (`ala Mashup)” and previous work on integrating sensor networks on the Internet [31, 32] has shown that the lightweight aspect of REST makes it an “ideal candidate for resource- constrained embedded devices to offer services to the world” [20].
3.1.1 Restlet Restlet [35] is a lightweight, open-source REST framework for the Java platform that provides the architectural basis for the web servers within most software developed during this thesis. In our implementations, we use the Noelios Restlet Framework (NRF)1 that is developed in the context of the Restlet project itself. Restlet was preferred over other frameworks because of its full dedication to the REST architectural principles where core REST concepts like resources have equivalent Java artifacts. This, together with provided, specialized components like Ap- plications or Routers greatly simplifies the combination of different resources into REST-based web services.
For more information on the REST architectural style, the ROA and Restlet, we refer to the book “RESTful Web Services” by L. Richardson and S. Ruby [38].
The JavaScript Object Notation is a very lightweight information interchange format that has been used by software produced in the course of this thesis as the preferred way of transmitting data. JSON-encoded data is human-readable while at the same time being easily parseable by machines (cf. 3.1). As JSON was first designed as a format to serialize JavaScript objects, its structure is legal JavaScript syntax based upon associative arrays (dictionaries) and any JSON string can be directly evaluated in JavaScript while lightweight libraries exist that enable using it in lots of other languages2. JSON is specified within HTTP content negotiation, its Internet media type (originally MIME type) is application/json.
1 { 2 "tags":["Web of Things", "Resource", "Temperature"], 3 "dtreviewed":"2010-04-07", 4 "description":"This device measures the current temperature.", 5 "reviewer":"testuser", 6 "rating":4.3, 7 "type":"service" 8 }
Listing 3.1: An example of a JSON object that represents a review of a temperature sensor.
3.3 Microformats
Microformats [4] present a very natural and expressive means of adding semantic informa- tion to (X)HTML markup by re-using existing syntax of this language, most prominently the
- and -tags together with their class-attributes. Microformat-based metadata is woven transparently into the fabric of (X)HTML pages and has no direct impact on how a site is presented by browsers. As the augmentation of a web page using Microformats provides semantics without having side-effects on how the same site is perceived by humans (Figure 3.3), this technology is especially useful within the Web of Things context, where we strive to offer man-machine as well as machine-machine interfaces. “Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards.” [4]
� ���Wikimedia�Foundation�Inc.
Wikimedia Foundation Inc. ��� �����200�2nd�Ave.�South�#358
�����
200 2nd Ave. South #358 �������St.�Petersburg,� �������FL�33701-4313 St. Petersburg, FL 33701-4313 �����
Apart from the hCard3 Microformat presented in the above example4 that represents an extract from a Microformats-enabled web site and its corresponding XHTML markup, the major Microformats that are used within the context of this thesis are hProduct5, hReview6, GEO7 and hRESTS [29], where the goal of the latter is to provide a machine-readable representation of REST-based web services [1].
3.4 OSGi
Formerly known as the Open Services Gateway initiative, the OSGi framework [42] provides a dynamic component model on top of the Java platform. The modularization of applica- tions into bundles that provide services and the management of these services via the OSGi Service Registry provides ideal conditions for the development of loosely coupled applications. By means of the OSGi Life-Cycle management, the starting, stopping and updating of single components of a software package is possible without requiring a restart of the whole applica- tion. While the OSGi specifications were originally only intended to provide the framework for service gateways, they have now been adopted in the context of a wide range of applications including application servers, building automation and grid computing8.
OSGi Bundles The bundle is the basic functional software unit within the OSGi framework. An OSGi Bundle consists of Java classes together with a manifest (cf. Listing 3.2) that specifies information on the bundle itself and describes the packages that are provided to other bundles or required at runtime.
Listing 3.2: An example of an OSGi bundle manifest.
OSGi Declarative Services (DS) The wiring of services across different bundles is facilitated by the Declarative Services specification that is a part of OSGi versions 4.0 and above9. OSGi DS are based on the definition of OSGi components (Listing 3.3) that declare required and provided services and have to be referenced within the manifest (cf. line 8 of Listing 3.2). For more detailed information on OSGi Declarative Services and an introductory tutorial to using them, refer to [2].
Listing 3.3: An example of an OSGi Declarative Services component definition.
The OSGi component model has been extensively used and is present in almost every software that was developed during this thesis: While the implemented Web of Things Drivers employ this model primarily to achieve a decoupling of their device driver component from the web server module, the distributed Web of Things infrastructure that is proposed in this thesis makes use of the OSGi framework to split the functionality into units that are individually upgradeable and exchangeable. 14 Technological Background Chapter 4 Enabling Devices for the Web of Things
”On the Internet, nobody knows you’re a dog.”
Peter Steiner, cartoon in The New Yorker, July 5, 1993
A realization of the Web of Things vision requires to extend the existing Web so that real- world objects and embedded devices can blend seamlessly into it [20]. To integrate such objects into the Web within the Web of Things context, we need to make them addressable through a RESTful API, thereby using HTTP not only for transport but also as application layer protocol. Once a device is exposed via such an interface while respecting the Resource-Oriented Architecture, it can be browsed and interacted with using the HTTP verbs GET, POST, PUT and DELETE. The modeling of smart things using this approach is often straightforward as, in many cases, their functionalities can intuitively be mapped to RESTful resources (e.g. a temperature sensor exposing the current temperature).
This chapter will describe several ways of integrating networked real-world objects into the Web of Things while focusing specifically on the integration of Sun Small Programmable Object Technology (SPOT) sensor nodes. After a short overview of the properties and functionalities of these sensor platforms in Section 4.1, we will present two architectures to enable smart de- vices for the Web of Things in Section 4.2. In Section 4.3, a specific driver architecture that was implemented during this thesis will be described in detail and in Section 4.4, the results of evaluations of this architecture as well as a direct comparison of the alternative solutions will be discussed. 16 Enabling Devices for the Web of Things
4.1 Sun Small Programmable Object Technology (SPOT)
Sun SPOT sensor platforms, commonly called Sun SPOTs, are Java-programmable wireless embedded devices developed by Sun Microsystems that feature a radio for communication using the IEEE 802.15.4 standard1. We distinguish between two types of Sun SPOTs:
Free-Range Sun SPOTs feature a rechargeable battery and an additional unit, the eDe- moSensor Board, that offers sensors for measuring ambient light and temperature, a 3D-accelerometer, two switches and several actuators (tri-colored LEDs). The function- ality of these SPOTs can further be extended using the provided analog and digital I/O pins. Base Station Sun SPOTs do neither include a battery nor any sensors or actuators and are used solely for communication between free-range SPOTs and a host device (e.g. a PC). The base stations themselves are connected to their hosts via Universal Serial Bus (USB) (cf. Figure 4.1).
Free-Range Sun SPOT
eDemoSensor Board
Rechargeable Battery Host Machine Free-Range Sun SPOT
Base Station eDemoSensor Board
Rechargeable Battery
Free-Range Sun SPOT Host Machine eDemoSensor Board Base Station Rechargeable Battery
Figure 4.1: Setup involving two host machines with attached base stations and several free-range Sun SPOTs.
4.2 Integrating Smart Devices into the Web of Things
In [21], a RESTful architecture for Sun SPOTs has been proposed that consists of a Restlet- based embedded HTTP server directly on the devices and a gateway middleware that relays HTTP requests to the Sun SPOTs via the IEEE 802.15.4 link. The software includes a dynamic discovery system that allows Sun SPOTs to travel between gateways by means of a Discov- ery Component in every gateway that regularly broadcasts invitation messages on a dedicated port. Sun SPOTs listen on that port and can choose to register to the broadcasting gateway by sending their MAC address, name and a short description.
1http://www.sunspotworld.com 4.2. Integrating Smart Devices into the Web of Things 17
Sun SPOT
RequestDispatcher
Light Sensor Sun SPOT Driver Temperature Sensor
LED Actuator EntryPointApplication
From Client, HTTP To Client, HTTP
Sun SPOT
RequestDispatcher HTTP via IEEE 802.15.4 Light Sensor HTTP via IEEE 802.15.4 Temperature Sensor
LED Actuator
Figure 4.2: Client request handling of the embedded HTTP server-based architecture.
When the gateway receives an HTTP request from a client, the EntryPointApplication uses that request’s URL to select the corresponding Sun SPOT and forwards the request to that device (cf. Figure 4.2). The RequestDispatcher, a component of the Sun SPOT-embedded software, routes incoming requests to the correct resource (e.g. to the light sensor resource) and invokes a handler method corresponding to the HTTP request method (i.e. doGET(), doPOST(), doPUT() or doDELETE()) which processes the request using the native Sun SPOT API. The resource’s answer (e.g. the currently measured light level) is sent to a formatter component, wrapped into an HTTP packet and transmitted to the gateway that relays it to the requesting HTTP client. If a Sun SPOT is currently busy with handling a request, the gateway buffers other incoming requests and attempts to resubmit them as soon as the Sun SPOT is available again. This project furthermore features a dynamic AJAX application that allows users to explore the device hierarchy and to test different resource requests, thereby acting as a Web interface to the physical world. However, the authors of [21] state that the reported work has a number of issues that should be investigated further. These include improving the scalability of the architecture with respect to concurrent requests on the same Sun SPOT, enhanced support for asynchronous communication and standards/models for the values returned by the devices. To overcome some of these challenges and especially those related to scalability, we propose an alternative architecture of a Sun SPOT Driver that can also serve as a general prototype for integrating smart devices into the Web of Things. Another goal when designing this alternative solution was to broaden the range of applications of Web of Things Drivers – as an extreme example, when one considers remote, wireless, battery-powered sensors that are queried regularly, it is not the best choice to have these nodes listen to incoming requests at all times as such an architecture drastically reduces their battery lifetime and thus increases the maintenance effort. Our version of the Sun SPOT Driver includes a software proxy that handles HTTP requests and thus abandons the idea of having an HTTP server directly on the device. To exchange sensor and actuator data between the device and the proxy, a synchronization-based architec- ture is used, i.e. a virtual representation of the physical device is kept at the proxy at all times and updated in regular intervals. Whenever the device is requested from the Web, the proxy returns the currently stored representation of the device rather than querying the smart 18 Enabling Devices for the Web of Things thing itself which leads to a decoupling of the driver-device communication via device-specific protocols (e.g., in this case, JSON-encoded data over IEEE 802.15.4) on the one hand and the HTTP-based client-driver communication on the other (cf. Figure 4.3). As the synchronization interval may be adapted to suit specific applications, this driver architecture provides increased flexibility, especially with respect to the ability of trading off the actuality of the retrieved data against the battery lifetime of free-roaming sensor nodes.
Sun SPOT Sun SPOT Driver Synchronizer JSON via IEEE 802.15. JSON via IEEE 802.15. SpotRepresentations 4 From Client, HTTP 4 To Client, HTTP
SpotSynchronization
4 Sun SPOT 4 JSON via IEEE 802.15.
Synchronizer JSON via IEEE 802.15.
Figure 4.3: Client request handling of the synchronization-based architecture.
4.3 A Synchronization-Based Web of Things Driver Archi- tecture
In this section, a concrete implementation of a synchronization-based driver that enables Sun SPOTs for the Web of Things will be presented. After an overview of the developed software, different aspects like Sun SPOT Discovery and optimizations with respect to performance and power consumption. For a more user-oriented account, refer to the Sun SPOT Driver Manual in Appendix A.2. Consult the Javadoc of the project for information on implementation specifics that are not covered in this report. The Sun SPOT Driver consists of two software projects that correspond to the two modules of the driver architecture, namely the software for the host running the web server and managing multiple Sun SPOTs that are connected via a base station and the software for the Sun SPOTs themselves (commonly referred to as the OnSPOT -software). The entire communication taking place between base stations and Sun SPOTs is datagram-based where message payload is encoded in the JSON format.
4.3.1 The Sun SPOT OnSPOT Software The OnSPOT software is a very small package consisting of three Java classes (plus libraries for handling JSON data) that it is easy to get an overview of – the main components of this program are responsible for communication with the base station and representation of Sun SPOT data, respectively. The software implements a synchronization protocol including a discovery module that searches for available base stations on a predefined port in regular 4.3. A Synchronization-Based Web of Things Driver Architecture 19 intervals, a handshake component to negotiate synchronization ports with a discovered host and the main synchronization loop that sends updated sensor data to the host and receives actuator data from it. For class diagrams of this software, refer to Appendix C.1.
4.3.2 The Sun SPOT Host Software The host-component of the Sun SPOT Driver is a considerably more complex piece of soft- ware that is based on the OSGi framework (cf. Section 3.4). It is split into two OSGi bundles, the Driver Core Bundle and the Web Server Bundle that interact via OSGi Declarative Services (DS) (cf. Figure 4.4). While the core is responsible for the communication with connected Sun SPOTs and especially – following the synchronization-based approach – for keeping a local im- age of the current data of each SPOT, the web server bundle handles outbound communication with HTTP-clients. In the following, these two bundles and their features will be described in detail.
Web Server Bundle Driver Core Bundle RestletAccessInterfa
HTTP-based Client Interaction ce Sun SPOT Discovery
RESTful Interface Sun SPOT Synchronization
Expose Sun SPOT Functionality Local Representation of SPOTs ce RestletAccessInterfa
OSGi Framework + Declarative Services
Figure 4.4: The OSGi-based architecture of the Sun SPOT Host Software.
Driver Core Bundle The main function of the Driver Core Bundle-software is the establishment of connections to available Sun SPOTs and the exchange of data via these links. The representations of all attached SPOTs are exposed via the RestletAccessInterface that is declared as an OSGi DS interface and provides access to the names of the currently connected SPOTs, the sensor data of every Sun SPOT, functions that handle actuation of the SPOTs and different methods for controlling the driver itself, for instance imposing bans to prevent certain Sun SPOTs from connecting to the host.
Handshake and Synchronization For discovering new Sun SPOTs, the program listens for connection attempts on a pre-defined port (referred to as the SPOT Host Port). If a new SPOT is encountered, the parameters of a new connection to this specific device – the number of the datagram port to be used for synchronization and the synchronization interval – are 20 Enabling Devices for the Web of Things negotiated and a SpotSynchronizerThread is launched that creates and updates the locally held representation of the SPOT according to the synchronization interval (cf. Figure 4.5).
Figure 4.5: Handshake and synchronization between a Sun SPOT and the Driver Core Bundle.
In a single synchronization round that is triggered by the Sun SPOT, two JSON-strings of encoded data are exchanged between the host and the SPOT. First, the device sends the sensor data, i.e. data on the current temperature (measured close to the circuit board and therefore usually higher than the surrounding temperature), the current light value as measured by the SPOT’s photodetector (an integer value between 0 and 720), the current tilt of the device and acceleration forces acting on it (both as floating point values) as well as information on seven LEDs of the device (LED state and the red, green and blue color values as integers between 0 and 255). In response, the host sends actuation data (the prospective color values and state of the LEDs) and the time until the next synchronization round. The Sun SPOT then applies the changes to its LEDs as prescribed by the actuation data and uses the synchronization interval to determine whether it is possible to switch to Deep Sleep-mode until the next check-in with the host. During the development of the driver, special care was taken to optimize the involved components as far as possible with respect to synchronization efficiency. While it is not possible to guarantee that every single synchronization attempt succeeds, we were able to arrive at a high stability and speed of the communication between the base station and the Sun SPOTs (cf. Figure 4.6). Examples of the enhancements that were introduced are lazy synchronization, i.e. transmitting only the data that changed since the last synchronization round, and the adoption of rigorous threading for taking work off the hands of the main synchronization loop and thereby enabling faster re-synchronization if required. A feature called Device-Driver Delay Compensation (DDDC) was introduced to compensate for the delay introduced by the driver-device communication by means of decreasing the user-desired synchronization interval by a fixed 200ms or alternatively setting it to 0ms if the user-desired interval is lower than 200ms. Without using DDDC, a synchronization interval of e.g. 2000ms leads to an actual synchronization round only approximately every 2200ms as the synchronization timer starts to count only after a round has completed. 4.3. A Synchronization-Based Web of Things Driver Architecture 21
Figure 4.6: Graph showing the improvement of the synchronization stability during development of the driver. The stability is depicted as the ratio of theoretically possible synchronization rounds to actual synchronization rounds for an increasing synchronization interval and 2 connected Sun SPOTs (DDDC = Device-Driver Delay Compensation).
In the context of driver stability, another important aspect is the handling of multiple Sun SPOTs per base station or even multiple base stations with several Sun SPOTs each in a single room (i.e. base stations whose coverage areas overlap):
Multiple Sun SPOTs that are all connected to the same host are assigned different syn- chronization datagram ports by the host software during the handshake that thereby establishes an exclusive channel to every Sun SPOT. If a Sun SPOT disappears (e.g. if it leaves the area covered by the base station but also if a single synchronization round fails), the port assigned to that SPOT is kept open for a specified time interval (usually expressed as a multiple of the synchronization interval) in order to permit the device to resume synchronization. If the SPOT does not return within that allocated time frame, it is removed from the list of currently connected SPOTs and its representation is deleted.
Multiple Base Stations operating within proximity of each other need to be assigned dif- ferent SPOT Host Ports if it does matter which host a certain Sun SPOT connects to (otherwise, a SPOT is going to connect to the first host it discovers). It may happen that two different Sun SPOTs get assigned the same synchronization port by two different hosts. Although this is unlikely (depending, of course, on the number of Sun SPOTs), it does not pose a problem as the ports get assigned to Sun SPOTs in a random fashion. That way, eventually, the system is going to be stable with a different synchronization port assigned to every SPOT.
Driver Management Apart from the methods needed to get sensor data from the attached Sun SPOTs and control their actuators, the driver core provides access to driver management features via OSGi DS. In particular, it provides access to an On/Off Switch, the ability to 22 Enabling Devices for the Web of Things set the default SPOT synchronization interval, a method to change the SPOT Host Port, and functions to block/unblock Sun SPOTs from connecting to the host.
Implementation From a developer’s perspective, the most interesting parts of this software are the classes SpotManagement, SpotHandler, SpotRepresentation, SpotCommunication- Backend and SpotSynchronizerThread which are described in the following. For a corre- sponding class diagram, refer to Appendix C.2.
SpotManagement This class is responsible for the high-level management of the attached sensor nodes and the driver itself. Its tasks include the creation and deletion of local Sun SPOT representations, the assignment of datagram ports to Sun SPOTs and the connectivity control of attached nodes that is achieved via an instance of ConnectivityTesterThread. This thread keeps track of the synchronization rounds with the attached Sun SPOTs and removes representations of SPOTs that repeatedly fail to establish contact. Another important task of this class is to expose information on the attached Sun SPOTs and the current driver state to the SpotHandler-class.
SpotHandler This construct acts as an interface between the web server component and the driver core by exposing information that it retrieves from the SpotManagement.
SpotRepresentation Instances of this class represent the current state of Sun SPOTs and are updated during each synchronization round with their associated sensor node. The representation of a SPOT includes the current values retrieved from its sensors and the current and provisioned state of its actuators (i.e. its LEDs). Furthermore, this class handles the serialization and deserialization of data for communication with the Sun SPOTs.
SpotCommunicationBackend The main task of this class is to listen for incoming Sun SPOT communication attempts. Upon receiving such a request, it calls the createNewSpot- method of the SpotManagement class that sets up the internal structures for handling this SPOT, most prominently an instance of the class SpotSynchronizerThread responsible for the new device. This method also returns the datagram port assigned to the sensor node which is then communicated to the Sun SPOT as part of the initial handshake.
SpotSynchronizerThread Instances of this class handle the synchronization with single Sun SPOTs and are created and started by the SpotManagement-class as soon as a new SPOT is encountered. After successful execution of the synchronization protocol, they further- more update the timeOfLastSync-parameter of their associated SPOT which is in turn used by the ConnectivityTesterThread within the SpotManagement class to ascertain whether a device is still connected.
Web Server Bundle The second bundle that contributes to the Sun SPOT Driver software is the Web Server Bundle whose task it is to expose the functionality provided by the driver’s core – accessing the sensors and actuators of attached Sun SPOTs and providing a management interface for the driver itself – to clients that are connected via the Web (i.e. that send HTTP requests). In other words, this bundle is responsible for integrating the current driver state, most promi- nently the state of each Sun SPOT, into a dynamic, resource-oriented web representation that reflects the resource structure of the driver and the connected Sun SPOTs. This structure is de- picted in Figure 4.7 together with a short description of every resource, where wildcard-tokens 4.4. Evaluation 23 that represent multiple structurally uniform resources (e.g. spotName) are shown within curly braces.
Unblock SPOT /unblock LED Switch Block SPOT /switch /block Sun SPOT Driver Color Red / /red Actuators /actuators List of LEDs LED Color Green /leds /{ledNumber} /green
Color Blue Light Value /blue /light List of Sun SPOTs /sunspots Sun SPOT Temperature Value /{spotName} /temperature
Sensors Switch 1 /sensors /1
Switches Switch 2 /switches /2
/x /y Acceleration Data /z /acceleration
/x /y Tilt Data /z /acceleration
Figure 4.7: Web representation of the Sun SPOT Driver and connected Sun SPOTs.
Implementation This bundle has been implemented using a semi-automatic rapid deployment toolkit for the Web of Things that will be presented in the following chapter. Please refer to the discussion of general web servers created using that instrument in Section 5.3 for details on this software component.
4.4 Evaluation
The two Web of Things Driver architectures presented in this chapter were evaluated with respect to several different metrics including concurrency/scalability, response time, the age of the retrieved data and their power requirements. In this section, the results of these evaluations 24 Enabling Devices for the Web of Things
No payload Full Payload Run-Time 5880000ms 3660000ms Sleep Time 5461013ms 3497255ms Shallow Sleep Time 549812ms 271377ms Deep Sleep Time 4911201ms 3225878ms Shallow Sleep / Total 92.87% 95.55% Deep Sleep / Total Sleep 89.93% 92.24%
Table 4.1: Performance of a synchronization-based driver with respect to the amount of time spent in Shallow Sleep and Deep Sleep mode. No Payload refers to no sensor or actuator data being transmitted while Full Payload corresponds to all sensor data being sent to the host (for this test, the lazy synchronization was deactivated).
and the associated tradeoffs will be presented and discussed. Throughout this section, we will designate the architecture that is based on a device-embedded HTTP server as “Embedded HTTP” or, “Emb. HTTP”. The alternative architecture will be called “Synchronization-based” or “Sync-based”.
4.4.1 Power Requirements
While an embedded device that includes a web server needs to be listening for incoming HTTP requests at all times, a device that knows when its next callback will take place (or even triggers that callback by itself) may shut down all non-necessary functions in the mean- time. Specifically for Sun SPOTs, the device may enter a Shallow Sleep or even Deep Sleep mode depending on the length of the interval between two synchronization attempts, where the Deep Sleep mode is typically triggered whenever the waiting time exceeds about 2900ms and includes powering down the radio. According to Sun Microsystems, a Sun SPOT draws a current of about 46 milliamperes from its battery when not actively calculating but having the radio activated and listening for incoming packets (Shallow Sleep mode). However, as soon as the SPOT enters the Deep Sleep mode, its power usage drops to about 33 microamperes i.e. to only about one thousandth of the initial requirements2. Tests of the idle/sleep-performance of Sun SPOTs using a synchronization interval of 10000ms with varying amounts of synchronization payload strongly support the assumption that a synchronization-based driver architecture leads to significantly reduced awake-time and thus to considerably higher battery lifetimes (see table 4.1).
4.4.2 Response Time
Due to the decoupling of the communication between the HTTP client and the host on the one side and the synchronization between the host and the device on the other, synchronization- based drivers allow for considerably lower data-access times and thus faster servicing of HTTP clients. Our evaluation has shown that, while a local GET request on a resource takes approx- imately 205ms on average when having the request pass through a proxy, the same request is answered after only around 4ms by a synchronization-based driver (cf. Figure 4.8).
Table 4.2: Time elapsed between the request arriving at the driver and the triggering of the corresponding action on the device (equal to the age of data retrieved by an HTTP client when not considering the time taken by the HTTP response to reach the client) in the average, best and worst case. delayair denotes the time needed for messages to be transmitted between the driver and the device (one-way).
4.4.3 Age of Retrieved Data Although the synchronization-based approach has advantages over proxy-based drivers with respect to the response time, one has to keep in mind that the data retrieved by that architecture is, on average, older than that retrieved via the proxy-based design. This is due to the fact that any data received from a synchronization-based driver does not reflect the current state of the smart device but rather its state at the beginning of the last synchronization round. Equally, actuation commands that are sent to a device take, on average, longer to reach the device itself and thus to have an observable effect although the HTTP requests that trigger these commands are answered virtually immediately. This leads to a very characteristic saw-tooth pattern in the variability of the data age over sequential requests (cf. Figure 4.9). In table 4.2, the deduced formulas for calculating the average-, best- and worst-case retrieved data age for the two driver architectures are shown.
4.4.4 Concurrency Implementing an HTTP server directly on (possibly mobile, battery-powered) devices leads to increased strain on their capabilities regarding processing power, memory usage and power 26 Enabling Devices for the Web of Things
400 Embedded HTTP, Age of Data Synchronization-based, Age of Data 350
300
250 Emb. HTTP Sync-based 200 Min 48ms 102ms
150 Max 4282ms 335ms Ageof Data[ms] Mean 102.37ms 179.68ms 100
50
0 3000 3050 3100 3150 3200 Request No.
Figure 4.9: Comparison of the two driver architectures with respect to the age of the retrieved data (245 requests shown out of 10000). consumption. The performance of Web of Things Drivers with respect to client concurrency is particularly interesting as devices on the Web of Things should be able to handle high numbers of clients and, thus, lots of concurrent requests. For synchronization-based drivers, concurrent requests pose no problem due to their decoupled architecture – they are thus expected to perform equally well as other web servers. However, when the HTTP server is embedded on the smart device itself, one has to design a system specifically for handling concurrent requests. According to the authors of [21] and specific to Sun SPOTs, there are three possible solutions to this problem, namely (1) a locking mechanism and a pool of buffered requests, (2) proposing temporary cache requests or (3) creating a mechanism that would negotiate multiple StreamConnections with the proxy. They state that the third proposition has little meaning since a Sun SPOT will still have limited processing power and therefore implemented a locking mechanism on the proxy. Figure 4.10 shows the performance of the two driver architectures in terms of the percentage of successfully answered HTTP requests for an increasing number of concurrent clients.
4.4.5 Protocol Consistency According to [26], it is likely that, in the near future, a lot of embedded devices will natively support TCP/IP connectivity as 6LoWPAN introduces an adaptation layer that enables efficient IPv6 communication over IEEE 802.15.4 LoWPAN links. This approach is desirable from an architectural standpoint as devices can be directly integrated into the Web and HTTP requests must no longer be translated to device-specific protocols [20].
4.5 Summary
In this chapter, two different paradigms for connecting devices to the Web of Things have been demonstrated and compared with respect to several different metrics. The evaluation of these architectures regarding the average data age, power consumption and concurrency shows that one can provide strong real-time guarantees on the data retrieved from a device by directly embedding an HTTP server but that this leads to disadvantages regarding scalability, 4.5. Summary 27
0 0 10 20 30 40 50 60 70 80 90 100 Number of Concurrent Clients
Figure 4.10: Comparison of the two driver architectures with respect to the success rate of con- current HTTP requests (100 requests per client).
response time and battery lifetime. An advantage of the synchronization-based architecture is its increased flexibility that allows to employ it within a wider range of applications, specifically in deployments where a higher data refresh period is tolerable and/or long battery lifetimes are desirable. However one has to keep in mind that this architecture introduces the need for a host software gateway that translates incoming HTTP requests to device-specific synchronization messages whereas the alternative is HTTP-compatible without compromise. 28 Enabling Devices for the Web of Things Chapter 5 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT
”The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.”
Edsger W. Dijkstra (1930 - 2002)
During the development of the Sun SPOT Driver, it became clear that a lot of properties of different resources that are to be integrated into the Web of Things can be abstracted from the specific resource itself and into a conceptional description that holds information on possible interactions with single resources (for instance on the types of data that a resource provides or on actions that are possible on a resource) and on the relationship of different resources with each other (e.g. a Light Sensor being a child resource of a Sensors-resource). Following this idea, we tried to abstract as much as possible from single resources and were able to concentrate all of the interaction-specific information in only a few resource descriptors (i.e. XML documents or Java templates). Initially only seen as a way of taking algorithmic web server implementation work off our hands, the idea of having a meta-program that would automatically connect resource drivers to the Web of Things has developed into one of the main contributions of this thesis: The Au- toWOT Deployment Toolkit. AutoWOT enables developers to rapidly integrate their devices into the Web of Things by semi-automatically creating the web server component for things that can already be accessed via a computer. It provides that functionality to users via an intu- itive and easy-to-use SWT-based Drag-and-Drop interface. This toolkit allowed us to rapidly populate the Web of Things with different resources – however, one has to bear in mind that it still is a prototype program with flaws and limitations, especially concerning its expressiveness regarding resource characteristics. 30 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT
In the following, we will detail different aspects of AutoWOT, starting with a description of the conceptional properties of a resource from a RESTful/Web-standpoint in Section 5.1. After that, we are going to describe the AutoWOT software itself in Section 5.2 and characterize the web server components that it creates in Section 5.3. An overview of the different devices that were web-enabled using this software along with descriptions of the respective enabling- processes will be given in Section 5.4.
5.1 Conceptional Properties of Web-Enabled Resources
The abstraction from resource-specific properties to a conceptional description of generic properties of resources with respect to the Web of Things is the most important step when creating an automatic Web-Enabler. We approached this issue adopting a pure RESTful stand- point, thereby producing a classification of the different features of resources regarding possible interactions and resource-to-resource relationships into five categories:
Getters refer to data that is provided by the resource. Every Getter of a resource is dependent on a callback method in the resource driver that supplies the data to be presented. Information on a Getter can be enriched by specifying a description of the Getter and/or an OnChange-method that enables push-based publish/subscribe paradigms. Getters are identified by their name, which, together with the optional description, is used to provide semantic markup when the resource is displayed by a client.
Posters refer to HTTP POST-based interaction with the resource. Posters require a callback method that is to be called whenever the resource receives an HTTP POST request (with the POST argument as parameter). Furthermore, Posters feature Argument Type and Presentation Type properties that are used in request handling and automatic inter- face creation, respectively. The Argument Type currently supports the values Integer, Double and String while the Presentation Type supports Text and Binary. Posters are identified by a name and can be described using the Poster description property.
Putters refer to interaction with the resource that is HTTP PUT-based. Putters are similar to Posters in that they are described by a name, description, callback method, argument type and presentation type.
Deleters refer to handling HTTP DELETE requests that are sent to the resource. They are described by a name, description and callback method.
Children are the means of describing relationships between resources, where every child of a resource is a resource itself. Children are described using the properties Name, URI, Methods and Description which give the name of the resource, its URI, the HTTP methods allowed for the resource and an informal description, respectively. Additionally, the optional property Collection Method may be used – this attributed is required to describe resources that have multiple uniform children whose presence and/or name may vary at runtime. As an example for such a constellation, consider a Web of Things Driver that exposes multiple Sun SPOTs as a list of SPOT-resources.
5.1.1 XML Structure Configuration All the structural and interaction-specific information on a composite resource (such as a Sun SPOT) is aggregated in a single XML-document, usually referred to as the Structure 5.1. Conceptional Properties of Web-Enabled Resources 31
Configuration of the resource. As an example, an excerpt of the configuration document for Sun SPOT resources is shown in Listing 5.1. In addition to the interaction and relationship information described above, the configuration file contains data on the class names to be used during automatic web server creation in the start- and end-tags of the different resources.
1 ... 2 3 4 Sun SPOT {spotName} 5 /{spotName} 6 GET 7 getSpotNames 8 9 10 11 Sensors 12 /sensors 13 GET 14 15 16 Temperature 17 /temperature 18 Temperature measured by { spotName} 19 GET 20 21 22 Current Temperature 23 Current Ambient Temperature 24 getTemperature 25 tempChanged 26 27 28 29 30 31 32 33 34 35 36 ...
Listing 5.1: The XML Structure Configuration of a single Sun SPOT that is the sub-resource of a Sunspots-resource. Only the Sensors/Temperature resource is shown and all non-relevant attributes are omitted.
The identifiers within curly braces, occurring for instance at line 4 of Listing 5.1, are wildcard-tokens that are replaced by the actual property at runtime. In this specific case, the resource SunSPOT spotName in fact describes a single SPOT within a collection of Sun 32 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT
SPOTs. The names of all available Sun SPOTs are loaded at runtime using the Collection Method property (in this case, the method getSpotNames, cf. line 7 of the above listing) and substitute the wildcard-tokens – to give an example, if a connected Sun SPOT has the name TestSpot, it will be accessible at the relative URL /TestSpot and its actual resource name property will be Sun SPOT TestSpot.
5.1.2 Push-Based Interaction A noteworthy characteristic of AutoWOT is the getterOnChangeMethod-property (cf. line 23 of Listing 5.1 for an example) that enables basic event-based interaction mechanisms. In the specific case of the temperature sensor, this property specifies that, whenever the value of the temperature property as measured by the Sun SPOT changes, the method tempChanged is called with the current (i.e. changed) temperature value as parameter. The tempChanged- method may then, for instance, update an ATOM feed or provide some other means (in fact, any other means) of push-based resource interaction.
5.1.3 Semantic Markup of Resources In order to enable advanced machine-to-machine interaction within the Web of Things con- text (i.e. when computers act as clients of resources), every resource on the WoT is required to provide some kind of semantic markup. This markup is used by clients to classify and system- atically make use of the information and interaction functionalities provided by the resource. AutoWOT provides such information on resources by also creating a Microformat-based de- scription of the resource that is deduced from the information provided in the Structure Con- figuration document. Specifically, it provides stubs for the hProduct, hReview, GEO, hListing and hRESTS Microformats and already includes actual information into two of these formats. Information on the name and description of the resource is included in the hProduct Microfor- mat while the hRESTS Microformat is constructed from the information on Getters, Posters, Putters and Deleters. Listing 5.2 shows the hRESTS Microformat descriptor that is created for the “Temperature”-resource in Listing 5.1.
1 2 3 Current Temperature 4 String 5 6 GET 7 {hostName}/sunspots/{spotName}/sensors /temperature 8 Current Ambient Temperature 9 10
Listing 5.2: The hRESTS Microformat descriptor generated for the Temperature-resource in Listing 5.1. The resource’s name is inserted into the service label property while the operation information is enriched using the Getter’s name and description as well as the specified HTTP methods property and the URI. All attributes that are not relevant to this discussion are omitted.
As, in the current version, the semantic markup of a resource will often have to be manually reconfigured and extended, we propose to include ways of defining properties of resources (e.g. 5.2. AutoWOT System Design 33 the product category or brand specified in hProduct) directly into the graphical user interface of AutoWOT. To further extend the usability of hRESTS-based annotations, we suggest the use of annotations based on SA-REST [40] or even MicroWSMO [30]. According to [29], “hRESTS is a good basis (and a common model) for extensions” such as SA-REST that provides support for describing various facets of Web APIs or MicroWSMO that adds means for semantic Web service automation. However, it is important to not re-implement HTTP features when extending the device markup – for instance, SA-REST provides markup for specifying the data-format that a specific web-service outputs, a feature that is already implemented via HTTP content negotiation.
5.2 AutoWOT System Design
In this section, the main features of the AutoWOT software will be presented where, for being able to better structure the description, the two main architectural components of AutoWOT will be described separately. For the corresponding class diagrams, refer to Appendix C.3. For a user-oriented step-by-step manual on how to use AutoWOT to enable a device for the Web of Things, please refer to Appendix A.3. The specifics on the web server implementations that are created by AutoWOT are given in Section 5.3.
5.2.1 Interpreter
The Interpreter module lets the user specify the structure and properties of the resource that reflects the entity to be included into the Web of Things where this object may be anything that can be accessed via a computer. An example of such an item is a Sun SPOT together with a program that is, for instance, able to retrieve sensor data from this SPOT. To characterize the desired resource, AutoWOT features a Drag-and-Drop-based GUI (Figure 5.1) – the user may select one of the options of extending the current resource that are displayed at the right-hand side of the screen (e.g. a Getter, a Child or a Description) and drag the corresponding icon into the buildup-area on the left-hand side. AutoWOT then opens a dialog box to prompt the user for necessary information on the selected option and, as soon as all required information has been entered, creates the matching resource and displays it in the buildup-area. The user may further modify already created resources and can also drop a Structure Con- figuration document into the program window to edit resources that were created during an earlier session. To do this, AutoWOT provides a way of traversing the resource structure by clicking onto child resources in the GUI.
Implementation The core of the Interpreter’s implementation stretches over two Java classes, namely the SWTFrontend and the FileHandler. The SWTFrontend is responsible for building and displaying the user interface and tracking the user’s progress when building the resource structure. Its two main variables are rootResource and currentResource that store the structure’s root resource and the resource currently displayed to the user, respectively. The FileHandler’s task is to try and parse XML Structure Configuration files that are dropped into the program window to recreate the resource structures they encode which then can be edited by the user. 34 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT
Figure 5.1: The AutoWOT user interface.
5.2.2 Builder
The Builder component is responsible for creating the implementing classes of the web server that will be connecting the specified resource to the Web of Things. Before this can happen, though, the user is prompted for the name and location of the Handler class that contains the different callback methods specified in the Structure Configuration. The user may choose whether to deploy the web server component as a plain Java program or as an OSGi bundle that interacts with its driver counterpart via OSGi Declarative Services – here, AutoWOT also creates component definitions, manifest additions and access interfaces for the driver- component. The OSGi-alternative is provided to foster pluggability and interoperability across different platforms and is the recommended way of enabling devices for the Web of Things.
Implementation The Builder module contains two separate Java classes, the PlainJava- Builder and the OSGiBuilder, that are responsible for creating web server components from the structural configuration defined via the Interpreter. The web servers constructed by these classes differ in their way of accessing the callback methods – while the PlainJavaBuilder constructs a web server that directly calls these methods on the Handler class defined by the user, the OSGiBuilder’s web server implementations rely on OSGi DS and thus have to provide additional interfaces, component definitions and manifests to enable the interaction with the driver component.
5.3 System Design of AutoWOT-Generated Web Servers 5.3. System Design of AutoWOT-Generated Web Servers 35
In this section, we will describe the web server software that is created by AutoWOT to make smart devices RESTful – the explanations here apply to the web server components of all devices that were enabled for the Web of Things using the AutoWOT Toolkit. In the current version of AutoWOT, the user has two options of how exactly the created web server is to be implemented, both of which will be presented in the following (Sections 5.3.1 and 5.3.2). After that, we will provide information on how exactly the WoT-enabled resources are exposed on the Web in Section 5.3.3.
5.3.1 Components of a Plain Java AutoWOT Web Server The most important component of a created web server is its Java implementation. For any resource structure that a user specifies, AutoWOT creates at least five Java classes:
RestletMain This provides the root implementation of the web server’s Restlet. Its tasks are to create a new web server, to create and attach a RootApplication and some web-resources (images and CSS-scripts) to it and to launch the server.
RootApplication This is the main Restlet application that takes care of guiding incoming HTTP requests to their destination resources. To route requests, it defines a Router and attaches all resources while specifying their respective path within the resource hierarchy. See the listing below for an example code snippet that attaches the resource implementing a single Sun SPOT to the Router (in the variable router).
The identifier within curly braces is a wildcard-token that is substituted by the name of the actually requested SPOT at runtime. The actual name parameter can be retrieved from a request using the command
1 getRequest().getAttributes().get("spotName");
BaseResource This class implements all common behavior of resources which includes getting information on the resource at runtime, substituting the wildcard-tokens with actual data and supplying generic HTML, XML and JSON representations of each resource. Furthermore, it prepares lists of uniform sub-resources by calling the method specified in the CollectionMethod-property via Java reflection. All classes that implement specific resources inherit from this class.
RESTSOperation, RESTSService These are two utility classes that facilitate the structuring of information on services provided by a specific resource within the hRESTS Microformat.
An additional Java class is generated for every resource that has been defined by the user. These resource-specific classes extend the BaseResource and implement the Getters, Posters, Putters and Deleters that the user has specified together with callbacks to retrieve the actual data at runtime. Furthermore, AutoWOT creates the images and CSS-scripts that are used when building the generic HTML representation of the resources.
5.3.2 Components of an OSGi-based AutoWOT Web Server As OSGi-based web server bundles created by AutoWOT are basically stand-alone programs, creating these is somewhat more involved. Additionally to the implementing Java classes that differ only slightly from those of plain Java web servers, AutoWOT creates the web server’s 36 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT
OSGi manifest and Declarative Services definitions for the web server and the device driver bundles (cf. Figure 5.2).
XML-based�Resource�Configuration
AutoWOT
Web Server Bundle Driver Core Bundle
/lib RestletAccessInterfa Java libraries (JSON and Restlet) ce HTTP-based Client Interaction Provide Handler Methods /META-INF OSGi Manifest RESTful Interface
Figure 5.2: Overview of the components of an OSGi-based web server created using AutoWOT.
Furthermore, to execute the defined callback methods which are situated in the device driver bundle, the resource classes of the web server need a DS access interface and implementation in the driver component. AutoWOT also creates these classes while using Java reflection to keep the interface small and compatible to any web server component. To give an example of this mechanism, an excerpt of the handlePost method of a Sun SPOT’s LED Switch resource that switches on and off a single LED is reproduced here:
1 public void handlePost() { 2 (...) 3 String posterVar = param.getValue(); 4 RestletMain.getRestletAccessInterface().executeMethod( 5 "handleLEDPost", new Object [] {getSource(), posterVar}); 6 (...) 7 } After retrieving the value that was POSTed to the resource and storing it in posterVar, the program fetches an instance of the RestletAccessInterface that is part of the device driver bundle and provided as a service by the OSGi framework as soon as this bundle is loaded. The method executeMethod then uses reflection to call the method handleLEDPost with the arguments getSource() and posterVar. The getSource() method is provided by the BaseResource and returns all wildcard-parameters of an HTTP request which is necessary for enabling the device driver to select the correct resource. If, for instance, the value on is sent to the resource example.com/sunspots/TestSpot/actuators/leds/4/switch as an HTTP POST request, the posterVar will have the value on while getResource() will return TestSpot:4 thereby identifying LED 4 of Sun SPOT TestSpot. For providing basic event-based interaction, AutoWOT runs several background threads (one thread per Getter) that poll each Getter’s callback method and trigger the method specified 5.3. System Design of AutoWOT-Generated Web Servers 37 in its onChange-property as soon as the callback’s output changes. In the current version of AutoWOT, this feature is only available for resources that are not transitive children of collection-type resources and only for OSGi-based AutoWOT web servers. AutoWOT stores the generated Java classes of the resources together with the RestletMain, RootApplication, RESTSOperation, RESTSService and a RestletConstants-class that holds common parameters used by the resources in a directory hierarchy (rooted at src/ ) that reflects the user’s desired package configuration. Additionally, the following directories are created:
The lib/ folder contains all Java libraries necessary for the web server to be runnable, i.e. the json.jar for parsing JSON strings and the Restlet libraries org.restlet.jar, org.noelios.restlet.jar and org.simpleframework.jar.
The META-INF/ directory holds the MANIFEST.MF file that contains information on some properties related to OSGi, for instance the bundle’s activator (RestletMain.java) or the bundle’s imported packages.
The OSGi-INF/ directory contains the file component.xml that defines the OSGi DS services referenced by the bundle (i.e. the device driver’s access interface).
The resources/ folder holds images, CSS-scripts and the Structure Configuration of the web server component.
5.3.3 Resource Representations and Web Interaction The single most important task of a WoT-enabling web server is the presentation of the en- abled devices as resources on the web in order to enable interaction of HTTP clients with them. The BaseResource-class of the created server components provides three different, generic, ways to expose resources:
HTML Representation Especially for simplifying the interaction of human clients with the resource, an HTML/CSS-based website is created for every resource. These pages (cf. Figure 5.3) give users the ability to (a) navigate within the resource structure by following links to parents/children, (b) grasp the information provided by the resource (i.e. by Getters of the resource) and (c) interact with the Posters of the resource by providing an annotated web-form. The provided HTML pages are enriched with semantic markup using a composition of different Microformats (cf. Section 5.1.3).
JSON Representation For enabling straightforward machine-resource interaction, AutoWOT exposes every resource as a JSON string that describes its interaction capabilities and the relationships to other resources by including information on the Children, Getters, Posters, Putters and Deleters of the resource (cf. Listing 5.3 for an example).
1 {"resource": 2 {"methods":["GET"], 3 "name":"Temperature", 4 "children":[], 5 "getters":[{ 6 "description":"Current Temperature", 7 "name":"Current Ambient Temperature", 8 "value":"31.0" 9 }], 38 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT
Figure 5.3: The HTML repesentation of the resource Temperature.
10 } 11 }
Listing 5.3: Excerpt from the JSON representation of the resource Temperature.
XML Representation The third description that AutoWOT creates to foster especially inter- action of machines with the created resources is an XML-based representation. As for the JSON string, this reproduction of the resource is easily parseable by clients accessing the resource (cf. Listing 5.4).
1 2 3 Temperature 4 5 GET 6 7 8 9 Current Ambient Temperature 10 Current Temperature 11 31.0 12 13 14
Listing 5.4: Excerpt from the XML representation of the resource Temperature.
The HTML, JSON and XML representations have exactly the same format for all resources that are WoT-enabled using AutoWOT as they are produced by the very same Java method for every resource. If, for a specific resource, a different representation is desired, it is nec- essary to override the respective getRepresentationHTML(), getRepresentationJSON() or getRepresentationXML() method in the resource’s implementation. 5.4. Examples of Web-enabled Devices 39
5.4 Examples of Web-enabled Devices
In this section, we are going to describe the processes of connecting different devices to the Web of Things. The enabling was done by the author, i.e. by a person familiar with both the AutoWOT Toolkit and the software that connects the different devices to the computer in the first place. For every enabled thing, we will give a short introduction to the device itself as well as information on the process of web-enabling it where the specified durations do not include the development of the driver component itself but rather the action of enabling a given driver for the Web of Things.
5.4.1 Sun SPOT Driver The Web of Things Driver for Sun SPOTs marks the starting point of the development of AutoWOT as this device was first enabled without using the toolkit. AutoWOT was made possible because of the consistent abstraction from resource-specific information within the initial version of the web server component included in the Sun SPOT Driver and the deferral of that information into few resource descriptors, most importantly into the XML Structure Configuration file. The web server component of the Sun SPOT Driver was later replaced by a bundle created using AutoWOT. The process of creating this bundle took approximately 30 minutes. For an overview of the created resource structure, refer to Figure 4.7 in the previous chapter. In total, the Sun SPOT Driver encompasses 29 different resources.
5.4.2 Lego Mindstorms NXT Driver The second device that was web-enabled using the AutoWOT Toolkit was a LEGO R Mind- storms NXT Driver that had already been developed by the author in the course of a laboratory project prior to this thesis (cf. Section 5.4.4). This driver is capable of connecting to multiple Lego Mindstorms NXT bricks and can read data from their sensors as well as actuate motors connected to them.
Lego NXT Driver Actuators / /actuators Motor /{motorNumber} Set Motor Degrees /setdegrees
List of NXT Bricks NXT Brick /nxts /{nxtName}
Sensors Sensor /sensors /{sensorNumber}
Figure 5.4: Web representation of the Lego Mindstorms NXT Driver.
The entire process of enabling the NXT Driver for the Web of Things took about 18 minutes. The structure of the 11 generated resources is similar to that present in the Sun SPOT Driver 40 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT
(cf. Figure 5.4): The NXT Driver features a Root-resource with attached Driver Manager and NXT List-children where the NXT List-resource is comprised of all Lego Mindstorms NXT bricks currently connected to the computer. Every single NXT-resource features up to four sensors and up to three actuators.
5.4.3 Phidgets RFID Driver AutoWOT was also used to link an RFID Reader from Phidgets, Inc.1 to the Web of Things. This resource features a very simple structure of just a single resource (i.e. a Root resource without any children) providing a single Getter that informs about the currently read RFID tag (cf. Figure below). The process of enabling the Phidgets RFID Reader for the Web of Things was accomplished within three minutes.
Phidgets RFID Driver - Currently Read Tag /
5.4.4 Augmented Gaming for the Web of Things: Settlers of Catan In a laboratory project prior to this thesis2, a digitally augmented version of the popular multi-player board game Settlers of Catan was developed. One of the main aspects of this work was a Human-Computer-Interface that enabled human players to interact with computer- controlled opponents via a playing field enhanced using RFID technology.
List of Players Quantity /players /{specialCardName} Player Special Cards /{playerColor} /cards
Player's Winpoints /winpoints SoC Game Driver / Resource Type /resource
Number Token /numbertoken
Playing Field Robber /playingfield /robber List of Hexagons Hexagon /hexagons /{hexagonID} Road Item /{roadID} Roads /roads
Villages Village Item /villages /{villageID}
Figure 5.5: Web representation of the Settlers of Catan Game Driver.
1http://www.phidgets.com/ 2Simon Mayer, Digital Augmentation of “Settlers of Catan” 5.5. Summary 41
In this context, AutoWOT was used to generate a live external interface of Settlers of Catan-games, thereby supporting WoT-based interaction between remote (physical or virtual) playing fields. Unfortunately, though, we did not have enough time during this thesis to further explore the possibilities of an augmented gaming environment within the context of the Web of Things. The resource structure representing a game of Settlers of Catan is very complex as all information concerning the current game state has to be exposed (cf. Figure 5.5): The root resource has two sub-resources, a Players and a Playing Field resource where the previous one contains information on all players participating in the game (i.e. has a single PlayerColor-sub- resource for every player. The resources representing the different players contain information on the number of so-called Winpoints of the players as well as on their currently held Game Resources and Special Cards. The Playing Field-resource contains information on the setup of the playing field, that is, on the nineteen Hexagons that constitute the field and on their associated information including their adjacent Roads and Villages. The whole process of web-enabling the Settlers of Catan software, which included the amount of time needed for (1) transforming the game software into an OSGi component, (2) writing the callback handlers and (3) setting up the resource structure in AutoWOT took about an hour in total. The resulting Game-resource structure consists of 18 different resources.
5.4.5 Enabling virtual resources for the Web of Things When using AutoWOT, a user is not constrained to WoT-enabling only physical resources – rather, AutoWOT can be applied to any information or actuation that can be retrieved or triggered via a computer program. As an example of this functionality, we have created a so-called Stocks Driver that retrieves information on stock-market quotations of different companies from Yahoo! Finance3 and exposes that information RESTfully in the same way as a Sensor-type resource. The process of enabling the Stocks Driver for the Web of Things using the AutoWOT Toolkit took about nine minutes. The resulting web server incorporates five resources in total (cf. Figure 5.6).
Lowest Ask /ask
Stocks Driver / List of Stocks Single Stock /stocks /{stockID} Highest Bid /bid
Figure 5.6: Web representation of the Stocks Driver.
5.5 Summary
In this chapter, the AutoWOT Deployment Toolkit was presented together with the abstrac- tions necessary to enable semi-automatic generation of web server components that bind drivers of different devices to the Web of Things. We described the AutoWOT meta-program as well as
3http://http://finance.yahoo.com/ 42 Towards Automatic Enabling of Resources for the Web of Things: AutoWOT the web servers it creates and presented multiple examples of drivers that were enabled for the Web of Things using this toolkit. AutoWOT has proven to considerably facilitate the process of WoT-enabling device drivers and allows to rapidly populate the Web of Things with lots of different kinds of devices. A particularly interesting property of AutoWOT is that it creates multiple web representations of resources and annotates these, e.g. using Microformats, with semantic markup on their functionalities and interaction capabilities. This gives rise to many scenarios where machines use and process these representations, for instance with respect to au- tomatic user interface creation or even for enabling fully automated RESTful machine-machine interaction. Chapter 6 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
”Prototype tabs, pads and boards are just the beginning of ubiquitous computing. The real power of the concept comes not from any one of these devices; it emerges from the interaction of all of them.”
Mark Weiser (1952 - 1999)
In accordance with the above quote by Mark Weiser who has often been described as the father of ”ubiquitous computing”1 [46], the real power of the Web of Things does not directly come from the devices attached to it but rather unfolds when intertwining the functionalities of different resources which leads to the notion of physical mashups. A crucial component to enable the fast and easy construction of such mashups is a Web of Things infrastructure that provides advanced services on top of WoT-enabled resources. The basic characteristics and functionalities of such an infrastructure have been outlined in Chapter2, specifically when introducing the notions of Smart Hubs and Smart Gateways: It is a component that essentially brings together different, web-enabled resources to provide advanced services on top of the layer of smart devices within the Web of Things. In other words, such an infrastructure for the Web of Things should act like an enabler for building applications on top of the resources that are already integrated into the WoT. While a search engine for the Web of Things can be seen as a first step towards providing such advanced functionality, a federation of Smart Hubs should offer more features than that, most importantly resource discovery and hierarchy maintenance services that impose a meaningful and reasonable structure onto collections of Things on the Web. In the last months, several related architectures have been presented: The first Smart Gate- way that was developed by S. Wieland [47] presents an initial step towards helping the rapid
1http://www2.parc.com/csl/members/weiser/ 44 A Distributed Modular Infrastructure for the Web of Things: InfraWOT development and deployment of web mashups and already includes basic searching and infras- tructure maintenance capabilities. However, the author states that, among others, the querying and device discovery functionalities are not suitable for a larger-scale deployment. Nevertheless, the gateway developed in [47] certainly did set the foundation for infrastructures for the Web of Things. Another architecture enabling advanced services within the Web of Things is the Aparat Smart Gateway proposed in [6] that explored especially a RESTful publish/subscribe architecture based on channels as the basic abstraction of message grouping and thereby en- abling subject-based message filtering. Furthermore proposing a protocol for physical device discovery, Aparat is a powerful information broker for Web of Things resources.
In this chapter, we present an infrastructure for the Web of Things that is based on Infra- WOT Smart Hubs. While building upon formerly developed implementations, the InfraWOT architecture developed during this thesis is different in that it was designed with the main focus on a hierarchically structured, distributed design and an infrastructure-assisted searching mechanism to enable efficient querying of resources. Another major design decision when con- structing InfraWOT was to apply the concept of the ROA and especially the REST uniform interface principle to as many components as possible or at least craft the software in a way that would allow for simple integration of that design pattern in the future. We decided to build the distributed structure of InfraWOT Smart Hubs based on hierarchical location infor- mation, an idea that will be described and motivated in the Section 6.1. After a summary of the main technical design choices involved in the development of InfraWOT in Section 6.2, we will present the InfraWOT architecture and each of its modules in detail in Section 6.3. In Section 6.4, we will summarize the main features and contributions of InfraWOT and its modules. For instructions on how to set up and configure a distributed hierarchy of InfraWOT hubs, refer to Appendix A.4 whereas a description of the RESTful API of InfraWOT is given in AppendixB.
6.1 Structuring the Web of Things
In our opinion, one of the most prominent tasks of an infrastructure for the Web of Things is to establish a meaningful structure on top of resources attached to the WoT. As the prime dimension according to which this structure is to be generated, we have chosen information on the hierarchical location of a single node which implies that a single hub is responsible for all devices in its proximity and all hubs in that are situated at a lower hierarchical level than itself. By making use of this hierarchical location data for structuring, a collection of Smart Hubs automatically gets arranged as a rooted tree, where the root represents the highest level of hierarchical location: In a world-wide InfraWOT deployment, the tree structure would be rooted at a hub with hierarchical location “Earth”. Within an organization, the root of such an infrastructure would probably be located at the headquarters of this organization and named thereafter while its immediate children would for instance designate the different branch offices. The approach of using hierarchy information for structuring has already been adopted by other Web of Things infrastructures [44] and has proven successful with respect to load bal- ancing and scalability as users mostly access devices located in their surroundings and due to the loose coupling between the infrastructure nodes. An important design concept that we adhered to during the development of InfraWOT was that every communication that takes place between hubs does happen locally (i.e. between neighboring nodes in the tree-structure). This specification guarantees infrastructure scalability as, by fulfilling it, each Smart Hub only requires knowledge about its immediate neighbors in order to function and can remain ignorant of the actual hierarchy depth. 6.2. Technical Design Choices 45
Selecting information on the hierarchical location as the main structural descriptor has imme- diate implications on several components of the Smart Hubs infrastructure, for instance on the service responsible for querying within the InfraWOT tree structure or on the module in charge of maintaining the correct infrastructure internally (i.e. deciding which hub to choose as parent and which to accept as children). In InfraWOT Smart Hubs, the process of assigning a logical hierarchical location identifier to hubs has to be performed manually during the configuration of each hub. However, since the infrastructure nodes are not mobile and the structure of their connections is rather static, little effort is required to maintain the tree structure [47]. We refer to a Smart Hub Scope as the collection of all nodes that are transitively reachable from each other when only traversing direct links between nodes. Two Scopes can be combined by defining a common root node and registering the hierarchically topmost hubs of both individual Scopes with that common parent.
6.2 Technical Design Choices
As basic paradigm for the development of InfraWOT, we have chosen the OSGi framework in order to support component-based development and future component-level upgrades and to foster “pluggability” with other software developed within this project. The InfraWOT software consists of six different components that interact via OSGi Declarative Services (DS) where every bundle is bound to implement a specific interface that gives access to a limited set of framework-wide functions this component provides. The integrated web server module has been generated using the AutoWOT toolkit (cf. Chapter 5) and thus is based upon Restlet (cf. Section 3.1.1). Reasons for employing AutoWOT for this task include the facilitated interoperability with other applications developed within this thesis. The data format used for internal information transfer is the JavaScript Object Notation (JSON) (cf. Section 3.2) interchange format that provides very lightweight and easy-to-use encoding and decoding of data. Another advantage of using JSON as data format that comes due to the human-readable structure of this format is the simplification of debugging running software infrastructures from message logs and/or live monitoring of the message streams exchanged between the Smart Hubs. One of the most basic design choices when starting the development of the InfraWOT Smart Hubs Infrastructure was that every hub shall be viewed as a RESTful resource itself – inter- nally with respect to the Java class implementing resources and externally when it comes to the Microformat-based web representation of the hub. This means that, at its web server core, In- fraWOT is equivalent in structure to every resource that was web-enabled using the AutoWOT Toolkit.
6.3 System Design
In this section, after a general overview of the main components of the InfraWOT software in Section 6.3.1, we will describe the individual modules of this project in the following sections (6.3.2- 6.3.8), where the emphasis will be placed on the components responsible for discovery, searching and infrastructure maintenance. 46 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
6.3.1 Modules Overview The InfraWOT software consists of several OSGi bundles that interact via OSGi DS. Each bundle is responsible for a specific task within the context of a management infrastructure for the Web of Things. Here, we present an overview of the different modules of InfraWOT (cf. Figure 6.1).
Aggregation Service
Discovery Service Messaging Service
Querying Service RegistryRegistry Service Service
Infrastructure Service Web Interface Service
OSGi Framework + Declarative Services
Figure 6.1: InfraWOT modules.
Discovery Service Bundle This component of InfraWOT handles the discovery of resources which includes the retrieval of information on new resources and the mapping of this data to internal representations. Through this process, newly discovered resources get attached to the tree hierarchy via an InfraWOT node and start to benefit from the services offered by the Smart Hubs infrastructure. This bundle is described in a detailed fashion in Section 6.3.2.
Querying Service Bundle This module is responsible for handling incoming queries i.e. re- trieving local resources that correspond to the query as well as forwarding the query to suitable sub- or super-nodes. See Section 6.3.3 for more information on the Querying Service Bundle.
Infrastructure Service Bundle This bundle’s duty is maintaining the correct tree structure with respect to the hierarchical locations of other hubs within its scope. As such, it takes care of child/parent registration and generates maintenance traffic between directly connected hubs i.e. between parents and their children. Refer to Section 6.3.4 for a thorough discussion of the Infrastructure Service Bundle.
Messaging Service Bundle The duty of this module is to present a transparent interface for enabling clients to set up messaging (i.e. publish/subscribe) relationships with resources 6.3. System Design 47
attached to the Web of Things. A more detailed specification of this bundle as well as a description of the underlying Unified Messaging System can be found in Section 6.3.5.
Registry Service Bundle This component manages data on attached resources and hubs and typically builds upon a database for persistent storage of this information. Detailed information on this bundle is available in Section 6.3.6.
Aggregation Service Bundle This external component of InfraWOT is responsible for the aggregation of data that is retrieved from multiple resources and also features POST- aggregation i.e. the relaying of a single HTTP POST request to multiple resources identified via the Querying Service. See Section 6.3.7 for a detailed description of this bundle.
Web Interface Bundle This bundle provides a Smart Hub’s interface to the outside world via HTTP. Its main component is an AutoWOT-generated web server that has been extended with a variety of custom-built functionality. The Web Interface Bundle and specifically the RESTful configuration mechanism of InfraWOT are described in 6.3.8.
6.3.2 Discovery Service
InfraWOT provides a discovery service for Web of Things resources (cf. Figure 6.2) that includes semantic identification strategies. When a new resource is being discovered by Infra- WOT, it is analyzed and mapped to an internal resource representation according to semantic markup that it may provide. To extract this data, InfraWOT tries to interpret any accessible representation of the resource using a number of different discovery strategies. Depending on the specific strategy, the string representing the resource is interpreted differently, e.g. as URL or as JSON-encoded resource description. Additionally, the InfraWOT infrastructure takes into account the location information that may be provided by a discovered resource and takes care of registering that resource with the best-suited Smart Hub.
Aggregation Service
Discovery Service Discovery Service Messaging Service
Semantic Identification Querying Service Registry Service
Strategy-based Discovery Infrastructure Service Web Interface Service
Runtime Strategy Injection
OSGi Framework + Declarative Services
Figure 6.2: Overview of the InfraWOT Discovery Service. 48 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
Technical Details In InfraWOT Smart Hubs, the discovery process is initiated by the resource that wants to become a part of the Web of Things infrastructure or any client that wants a specific resource to become a part of it. The process is triggered as soon as an InfraWOT node receives a POST request at the /resources endpoint. Such requests are unpacked by the Web Interface Bundle and the payload is relayed to the Discovery Service Bundle of the hub. The Discovery Service then tries to gather semantic information on the resource and map that information to a new instance of the internal Resource Java class. This is done by evaluating the request parameter(s) using different strategies (Figure 6.3) that have been implemented as a Strategy- pattern and can easily be extended, e.g. by implementing parsers for RDFa- or XML-based resource descriptors. In the current version of InfraWOT, two groups of strategies have been implemented:
Microformat-based Strategies InfraWOT features two strategies that interpret the data string as a URL and try to parse the resource representation found at that URL as a Microformat. The first of these strategies retrieves semantic information by sequentially parsing the single representation against several different Microformats (e.g. hProduct, hReview and hRESTS), a mechanism for semantic discovery that is proposed in [25]. The second Microformat-based strategy parses the representation according to the hEntity Microformat specified in [6],
JSON-based Strategies These discovery strategies are based on interpreting the resource representation as a JSON-Object or JSON-Array of JSON-Objects, respectively. This way of discovering resources is a lot faster than Microformat-based discovery as no detour to the URL of the resource in question is required and is therefore the preferred way in internal communication. If, for instance, a Smart Hub parses a resource found at a specific URL to an internal representation but determines from the provided location information that this resource should be registered with its parent hub, it sends a JSON-encoded representation of the resource instead of sending the URL.
Figure 6.3: Handling of an incoming HTTP POST request to the /resources endpoint using multiple discovery strategies. 6.3. System Design 49
A very interesting feature of the InfraWOT Discovery Service is that additional strategies may be injected to the system at runtime. This feature has been implemented as a proof of concept for JSON-based discovery strategies and enables clients to supply InfraWOT with new strategies by sending them to the /infrastructure/strategies endpoint of the Smart Hub. The discovery mechanism of InfraWOT is very permissive as the only information on a resource that is absolutely required by the Smart Hub is the URL of that resource. If a resource provides a unique identifier within its representation, that data is incorporated as the resource’s Unique Universal Identifier (UUID). Else, the Smart Hub that registers the object generates a new ID for unique identification of that resource. Every piece of additional information that a resource offers is used to extend the resource’s internal representation and thereby enables more services for that resource, most prominently advanced support for querying and location-aware registration (cf. Section 6.3.4).
Implementation The InfraWOT Discovery Service bundle consists of six Java classes, it depends on no other bundles and provides the interface ResourceDiscovery via OSGi DS. The class Resource- DiscoveryService implements this interface and is thus the main entry point of the bundle. It contains the method getResources(String resourceRepresentation) that is responsible for invoking the different strategies defined in the DiscoveryStrategy interface (cf. Listing 6.1).
1 DiscoveryStrategy strategy; 2 List retrievedResources = new ArrayList(); 3 List resources = null;
4
5 strategy = new JSONObjectDiscoveryStrategy(); 6 resources = strategy.getResources(resourceRepresentation); 7 if (resources != null) retrievedResources.addAll(resources);
8
9 strategy = new UnifiedMicroformatDiscoveryStrategy(); 10 resources = strategy.getResources(resourceRepresentation); 11 if (resources != null) retrievedResources.addAll(resources);
Listing 6.1: An excerpt of the getResources(String resourceRepresentation) method with the invocations of two discovery strategies.
The different discovery strategies are implemented by the four Java classes UnifiedMicro- formatDiscoveryStrategy, EntityMicroformatDiscoveryStrategy, JSONArrayDiscovery- Strategy and JSONObjectDiscoveryStrategy. For a diagram that covers the most important classes of this bundle, refer to Appendix C.4.1.
6.3.3 Querying Service An important feature of an infrastructure of Smart Hubs is enabling clients to query for resources within the scope of that structure. InfraWOT allows users to search for resources using a multitude of parameters that range from the name or description of a resource to the RESTful services it offers and even to the rating that was given to the resource by different clients. Additionally, InfraWOT defines several query types that abstract scoping information i.e. data on where to search for resources. The Querying Service Bundle (cf. Figure 6.4) is 50 A Distributed Modular Infrastructure for the Web of Things: InfraWOT mostly concerned with routing incoming queries through the infrastructure while the “actual” querying, i.e. the local retrieval of appropriate resources from the database, is performed by the Registry Service of InfraWOT. For that reason, this section will describe the characteristics of distributed searching in InfraWOT as a whole rather than going into details about database retrieval.
Aggregation Service
Querying Service Discovery Service Messaging Service
Routing of Queries Querying Service Registry Service
Query Parameters Infrastructure Service Web Interface Service
Query Types
OSGi Framework + Declarative Services
Figure 6.4: Overview of the InfraWOT Querying Service.
Technical Details A client may trigger a new query by sending an HTTP POST request to the /querying endpoint of a Smart Hub that contains a description of the query either as a JSON encoded string or using a collection of application/x-www-form-urlencoded parameters. Internally, queries are represented as JSON-serializable Java objects (defined in the Query class) that contain, as mandatory parameters, an ID, the URL of the Smart Hub that initiated the query and their type. Additionally, a query may contain an arbitrary amount of (optional) parameters that are stored in a Java HashMap and are also added to the JSON-representation when the query is serialized. This very open design has been selected to facilitate future development of InfraWOT – for instance, one could have queries carry piggy-back structural information. Query-related messages are exchanged between the Smart Hubs via HTTP POST requests to the /querying endpoints.
Querying Parameters In principle, Smart Hubs should enable querying for all parameters that occur in the internal representation of resources. However, in the current implementation of InfraWOT, we have focused on the parameters that are most valuable for clients of the infrastructure – a client may search for resources according to their name, their UUID, their rating, the REST services offered or by providing keywords:
Keyword Queries Keyword queries have, due to the popularity of web search engines, become the most intuitive kind of query for many users. Humans are, in general, not used to performing structured queries (i.e. classical database queries) but rather like to provide informal information on the object in demand (e.g. a collection of strings) and have the querying mechanism do the work of interpreting this data. InfraWOT provides simple 6.3. System Design 51
keyword-based querying by performing a matching algorithm on the provided keywords and multiple properties of every device in the database. These properties are the name of the device, its category, its brand, the description that is obtained whenever the device is reviewed by a user and tags that are held on the device.
Name Queries These queries reflect another typical way that users search for resources. For instance, as the resource names of all Sun SPOTs that are attached to the Web of Things contain the user-assigned name of the device, this is the method one would choose to search for a Sun SPOT by name. A query for that keyword is, however, expected to return the same result.
UUID Queries Especially when considering machine-machine interaction, querying for the unique identifier of a device is necessary if a program wants to use the Smart Hub infra- structure to interact with the same device over and over again. To humans, UUID queries are only of limited usefulness because of the typically numeric format of device IDs.
Rating Queries Clients may perform queries that take into account the rating that other users have attributed to specific resources. This is especially useful if multiple uniform resources have to be distinguished according to quality parameters that are not directly visible – in our case, several Sun SPOTs that, although they were homogeneous regarding their functionality, differed with respect to the degree of reliability they offered. A rating-based querying system, together with users that regularly provide updated reviews on resources, can be a powerful tool to find well-proven resources (e.g. for public demonstrations).
REST Service Queries Matching resources according to the REST services they offer is, in our opinion, one of the most important enablers for machine-machine-interaction in the context of querying. As all of the devices that we enabled for the Web of Things implement the hRESTS Microformat, their HTML representation already conveys in- formation on their capabilities – every resource that offers services specifies a number of REST Operations that it provides together with the associated label, HTTP method, input, output and address information. To give an InfraWOT-specific example, the Light Sensor-resource of a Sun SPOT would specify its REST capabilities using this markup:
1 2 3 4 The 5 Light Value 6 operation returning 7 the current light value 8 can be invoked using a 9 GET 10 at 11 ../{spotName}/sensors/light 12 13 14
While the Querying Service supports all five of these properties, the two that seem to be most useful for enabling InfraWOT-supported physical mashups are the input and output-specifiers as these properties are explicitly meant to be machine-readable and thus provide a very natural way for machines to search for resources. 52 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
In the current implementation of the Querying Service, the list of resources returned for a specific query is compiled by separately retrieving resource sets that correspond to each specified parameter and then taking the intersection of all these sets i.e. the collection of retrieved resources corresponds to the AND of the sets of resources that match the individual querying parameters.
Query Types While the query parameters allow users to search for resources by specifying desired properties of these, InfraWOT also provides a way of defining the scope of a query, i.e. where to search for corresponding resources by offering four different types of queries (cf. Figure 6.5) that may be used when searching the infrastructure. In the following, these query types will be introduced and motivated.
InfraWOT Smart Hub
Attached Resources
Scope of a BEQ for
Initially queried Smart Hub Scope of a CAQ for two
Scope of any EXQ
Figure 6.5: InfraWOT queries overview (three of four query types shown): EXQ (EXhaustive Query) - search the entire subtree of a Smart Hub. CAQk (CArdinality Query) - search for k resources within the subtree of a Smart Hub. BEQ (Best-Effort Query) - trigger an EXQ or CAQ at a different location than that of the queried hub.
Exhaustive Queries (EXQ) When a client triggers an exhaustive query at a Smart Hub, the hub will answer by specifying all resources within its subtree that correspond to the query parameters. Typically, queries of this type will perform slowly depending on the depth of the subtree and the total number of hubs within.
Example: “I’d like to listen to some music!” - find all streams within Zurich.
When a client submits an Exhaustive Query to the infrastructure, the entire subtree of the initially queried Smart Hub is searched for resources corresponding to the query using a wave algorithm that is reflected at the leaf nodes of the tree structure. These leaf nodes furthermore 6.3. System Design 53 transform the query to an Answer To Query (ATQ) and add all local resources that match the query before relaying that ATQ to their respective parent. Thus, every non-leaf node in the subtree receives will, at some point in time, have received an ATQ from each of its sub-nodes. As soon as all answers have been collected, they are merged, the resulting ATQ is extended with information on corresponding resources native to the non-leaf hub and relayed to the parent.
Cardinality Queries (CAQk) CAQs are triggered whenever a client wants to find exactly k resources that correspond to its request. Cardinality Queries typically perform faster than EXQs as there is the possibility to abort the transitive subtree search as soon as enough re- sources have been found.
Example: “I want to play WOTPong using buttons!” - find exactly 2 buttons.
Cardinality Queries are implemented very similar to exhaustive queries, but a CAQ is aborted as soon as it has encountered sufficient corresponding resources. This implementation is, due to the tree structure traversal, by no means efficient as the number of resources that are retrieved may be considerably higher as the initial cardinality of the query and, due to the depth-first search, the set of returned resources for a query does not follow intuition. To rem- edy these problems, the current implementation of InfraWOT filters responses to Cardinality Queries to return only k resources retrieved from the top-most hubs with respect to location hierarchy. As this mechanism still has severe performance problems, we suggest to implement a different, asynchronous mechanism to process CAQs during future work on this Smart Hubs infrastructure.
Best Effort Queries (BEQ) A special case of the cardinality query is the BEQ that corre- sponds to a CAQ1 i.e. to a query that only retrieves the first fitting resource that is encountered.
Example: “Should the heating be turned on?” - find a temperature sensor in my home.
Request For Query (RFQ) EXQs and CAQs only allow clients to search exclusively within the subtree of the Smart Hub they initially send that query to. To remedy this restriction, RFQs enable searches that involve hubs on higher levels of the infrastructure by wrapping “ordinary” requests (i.e. a EXQ or CAQ). The query is then sent to a hub anywhere within the scope of the initial Smart Hub and triggered there, meaning that its payload-query is unpacked and activated. The result of the search is sent back to the initial hub which relays it to the querying client.
Example: “I’m in the office right now. What is my flat’s current power consumption?” - find all smart plugs in my flat (Figure 6.6).
An RFQ is created whenever a client queries the InfraWOT structure and additionally specifies information on the hierarchical location to be searched. This process happens in a transparent way to the client i.e. it looks the same as if an “ordinary” query would have been sent to the Smart Hub at the specified location itself. A hub that receives an RFQ first analyzes the location parameter in order to determine how to process the request. From the data in the location field, the hub is capable of deciding whether its destination is the processing Smart Hub itself (in which case the query is unpacked and triggered locally) or whether the query has to be routed “downwards” or “upwards” (in terms of the tree hierarchy). If the InfraWOT 54 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
Figure 6.6: A client at the Smart Hub at location ../zurich/testoffice wants to issue an Exhaustive Request (EXQ) at location ../zurich/testflat. To enable this, InfraWOT uses RFQs internally.
node decides that it is a (transitive) super-node of the queried one, it loads its child hubs from the Registry Service to find the Smart Hub that is most appropriate for handling the query (i.e. whose location better represents the query location than the processing hub’s own location) – if no such Smart Hub is found, the query is triggered locally. Otherwise, i.e. if the hub determines that it is a sub-node of the queried one or if the destination node is in a different subtree altogether, the query is relayed to the Smart Hub’s parent.
Implementation The InfraWOT Querying Service bundle consists of two Java classes. To be able to handle queries, it needs access to an OSGi service that implements the ResourceRegistry interface. The QueryFrameworkService Java class of the Querying Service provides the interface QueryFramework via OSGi DS. The single public method provided by that interface is route- Query(Query receivedQuery) that returns instances of type Query and is responsible for the correct handling of incoming queries which includes the relaying of EXQs and CAQs to neighboring nodes, the merging and augmenting of received ATQs with information on locally corresponding resources and the triggering of RFQs the destination of which corresponds to the node’s location hierarchy. The second class contained in the Querying Service bundle is the CorrespondenceChecker which holds several methods to wrap the retrieval of resources corresponding to a request from the Registry Service (cf. Listing 6.2). 6.3. System Design 55
1 (...) 2 List corr = null; 3 for (String output : desiredOutput) { 4 corr = QueryFrameworkService.getResourceRegistry(). getEntitiesByRestOutput(output); 5 if (corr != null) correspondences.addAll(corr); 6 } 7 (...)
Listing 6.2: An excerpt from the implementation of the method getRestOperationOutput- Correspondences(List desiredOutput) illustrating the retrieval of resources that provide REST services offering a certain output from the Resource Registry Service. The reference to the registry is provided by the static method getResourceRegistry() of the QueryFrameworkService class.
Evaluation Most tests were performed on a real-life infrastructure scenario that was rooted at Europe and included representations of three research institutions together with some building and room specifiers each in two countries, reaching a maximum hierarchy depth of 6 (cf. Figure 6.7). In this scenario, a total of 61 resources were present and attached to the InfraWOT Smart Hub system. When performing 10000 exhaustive queries for resources providing Light as REST service output at the root of this structure, a mean response time of about 619ms was attained (see Figure 6.8). The query retrieved three resources (i.e. photosensors of three different Sun SPOTs) that were attached at the hubs at europe/ch/ethz/cnb (one Sun SPOT) and at europe/ch/ethz/cnb/d/101 (two Sun SPOTs).
europe/ InfraWOT Smart Hub
at/ ch/
tuvienna/ uzh/ ethz/
koh/ kol/ cab/ cnb/
d/
101/
Figure 6.7: The InfraWOT scenario Europe.
However, as these evaluations were performed locally, i.e. on a single machine running all Smart Hubs in parallel, the presented figures/numbers do not include network latency and we strongly suggest to do a thorough evaluation of the querying performance in a distributed setting in the future. 56 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
Figure 6.8: Histogram of querying response times for the scenario Europe. For this test, a custom, inverted-index-based database implementation was used (cf. Section 6.3.6).
6.3.4 Infrastructure Service
The Infrastructure Service bundle (cf. Figure 6.9) has multiple duties related to establish- ing the tree structure at startup/configuration time and its maintenance during operation. With respect to the structure maintenance, this service equips InfraWOT with the ability of structure-level self-stabilization meaning that the Smart Hub infrastructure can recover from node failures and eventually re-establish the initial tree configuration. Furthermore, the Infras- tructure Service is responsible for the process of attaching sub-resources (i.e. other Smart Hubs and ordinary resources) that are retrieved by the Discovery Service. It also acts as a garbage collector on the sub-resources of a Smart Hub by regularly checking up on them and triggering their deletion if they become unavailable.
Technical Details During setup of the Smart Hub infrastructure, i.e. after every hub within a scope has been configured, all of them initialize their Infrastructure Service bundles which start the registration process with their assigned parents by sending an HTTP POST request that includes the hub’s own URI. Every Smart Hub that receives such a request fetches the sender’s representation from the transmitted URI using the Discovery Service and adds the retrieved hub as one of its child nodes. Furthermore, the Infrastructure Service starts two threads that regularly contact the parent Smart Hub, all registered children hub and all attached resources. If the connection to an attached hub or resource is lost, the corresponding entity gets black-listed and will be removed if it is not possible to establish contact for a defined duration which can be specified by the user. Any resource that is encountered and analyzed by the Discovery Service is passed to the Infras- tructure Service which determines whether to attach it to the current Smart Hub depending on the hierarchical location information provided by the resource (cf. 6.3.2). The infrastructure takes care of routing that resource to the most appropriate Smart Hub, i.e. the hub whose 6.3. System Design 57
Aggregation Service
Infrastructure Service Discovery Service Messaging Service
Self-Stabilization Querying Service Registry Service
Sub-resource Management Infrastructure Service Web Interface Service
Location-aware Registration
OSGi Framework + Declarative Services
Figure 6.9: Overview of the InfraWOT Infrastructure Service. hierarchical location corresponds best to the resource’s (cf. Figure 6.10). If a resource does not provide location information within its web representation, the Discovery Service already extends the internal representation of the resource (i.e. the Resource object) with the hierar- chical location of the Smart Hub itself, i.e. in this case, the resource will be registered to the current Smart Hub in any case.
Self-Stabilization A special condition arises when a Smart Hub loses the connection to its parent: In this situation, as an intermediary Smart Hub (i.e. the parent hub) failed, a whole subtree – the one rooted at the failed node – will not be reachable from the rest of the infras- tructure anymore. InfraWOT counteracts such failures in two ways:
To guarantee accessibility of the subtree, the Infrastructure Service of its pivot Smart Hub (i.e. the one that detected a parent failure) triggers a registration to the root node of the structure or to any other known Smart Hub at a higher hierarchical level. As the registration process takes into account the hierarchical location of a hub, this will lead to the pivot being registered to its former grand-parent (i.e. the parent of the failed hub). However, as we (usually) expect a Smart Hub to be reachable again at some point, these pivots will not be adopted by the grand parent but rather listed as a “Rogue” child. In order to re-establish the correct structure (i.e. the structure before the failure oc- curred), every InfraWOT node regularly tries to register its “Rogue” children to hierar- chically better-suited Smart Hubs that are attached to the node. For an observer of this mechanism, it looks like nodes try to push “Rogue” children down the correct path in the tree structure until they eventually are re-attached to their former parent and thus are no Rogues anymore. Because of this continuing effort of the InfraWOT infrastructure, the initial tree structure will be recovered as soon as all failed Smart Hubs are restored. In the current implementation of the Infrastructure Service, the time needed for these repairs is 2 · thierarchy where thierarchy is a user-defined interval that specifies the time between successive hierarchy management checks.
These mechanisms make an InfraWOT Smart Hub infrastructure self-stabilizing [8] with respect to the convergence to a legitimate state, i.e. the establishment of a hierarchically correct 58 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
/.. InfraWOT Smart Hub
Smart Plug
../zurich
Register
../zurich/testflat Register ../zurich/testoffice
"Please register me! I am !
Register By the way - I'm located at /zurich/testflat/roomB"
../zurich/testflat/roomB
Figure 6.10: Infrastructure-assisted discovery.
tree structure. Specifically, the two aspects described above guarantee the convergence property because the system will eventually reach a correct state when following that protocol while the closure property is guaranteed as no changes to the initial infrastructure occur provided that no fault happens. The current implementation of the system does, however, not satisfy superstabilization [9] as it cannot recover from changes in the network topology (e.g. the permanent removal of a node). This is due to the fact that pivot hubs are never fully “adopted” by nodes other than their parent and thus remain in the “Rogue” state forever if that hub does not recover. A possible way to extend InfraWOT with respect to this issue is to have Smart Hubs assume the functionality of their children if these remain unavailable for a certain time period and are not expected to resume operation in the future.
Implementation
The InfraWOT Infrastructure Service bundle consists of three Java classes. For operation, it requires running OSGi services implementing both the ResourceRegistry and the Resource- Discovery interface. The bundle itself provides the InfrastructureFramework interface to other bundles via its Java class InfrastructureFrameworkService. The InfrastructureFrameworkService class offers three public methods – registerWith- Parent(), registerChild(Resource newResource) and getResourceFromString(String- resourceRepresentation) where the latter is a simple wrapper for the getResources-method from the Resource Discovery Service (cf. Listing 6.1). The method responsible for registration with the parent node is implemented in a fairly straightforward way: After configuration, each Smart Hub tries to contact its designated parent hub by POSTing its own URL to the parent’s address and continues to do this until a valid answer is received. The third important functional- ity of the InfrastructureFrameworkService is implemented in the registerChild(Resource newResource) method: When called with a valid instance of type Resource, this method an- alyzes the resource’s hierarchical location using a simple iterative matching algorithm that 6.3. System Design 59 determines what to do with the resource in question. We distinguish between four cases:
(a) The resource’s location matches the local Smart Hub’s location, e.g. a resource at location a/b/c/ registering at the Smart Hub at location a/b/c/,
(b) The resource’s location lies within the subtree of the local Smart Hub, e.g. a resource at location a/b/c/d/ registering at the hub at a/b/c/,
(c) The resource’s location corresponds to an ancestor hub of the local Smart Hub, e.g. a resource at location a/ registering at the infrastructure node at location a/b/c/ or
(d) The resource’s location corresponds to a hub that is neither contained in the subtree nor is it one of the ancestors of the local Smart Hub, e.g. a resource at location a/x/y/z/ registering at the Smart Hub at location a/b/c/.
While in case (a), the private registerWithMe(Resource resource) method is called to trigger the resource’s local registration, the resource is relayed to the best-suited child of the local hub in case (b), except if the hub has no children in which case the resource is registered locally, too. In cases (c) or (d), the resource is sent to the parent node to be taken care of.
6.3.5 Messaging Service The Messaging Service bundle (cf. Figure 6.11) provides publishing functionality for Infra- WOT Smart Hubs that facilitates the monitoring of resources, machine-machine interaction and connects InfraWOT to Web 2.0 services. Users can provide information on their communication endpoint(s) (e.g. E-mail or Google Talk) and register their interest in certain resources. Within this service, such subscribers are abstracted to Information Consumers which are objects that contain information on the different communication channels a client wants to be contacted at. The resources a specific consumer is interested in are specified utilizing the concept of Data Consumptions.
Aggregation Service
Messaging Service Discovery Service Messaging Service
Information Consumers Querying Service Registry Service
Data Consumptions Infrastructure Service Web Interface Service
Rigorous ROA
OSGi Framework + Declarative Services
Figure 6.11: Overview of the InfraWOT Messaging Service. 60 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
Technical Details Our intention when creating this particular implementation of a publishing service was to pro- vide a mechanism that allows users to transparently set up multiple different communication channels (e.g. E-mail, Twitter, Callback-URLs) with the Smart Hub infrastructure. Infor- mation Consumers describe communication endpoints that are defined by a set of parameters which are used by the system to determine the different channels a specific user is eligible to be subscribed to. For instance, if a user wants to have the Smart Hubs publish new data via his Twitter account, he must provide information on its Twitter ID and credentials. Consequently, any user who offers these pieces of information via an Information Consumer is eligible for the Twitter-channel. In order to register a new Information Consumer, a user submits a PUT (or POST) request to the /messaging/consumers/{consumerID} endpoint of an InfraWOT Smart Hub where the consumerID is a parameter chosen by the user. If the requested ID is not already in use, the hub responds with a 201 CREATED message containing the URI the user requested and creates a new Information Consumer with the desired ID (cf. Figure 6.12).
Web Interface Service Messaging Service
PUT�/messaging/consumers/testconsumer
OSGi DS Create�new�Consumer� 201�CREATED
Figure 6.12: RESTful creation of a new Information Consumer.
Communication Channels The current version of the Messaging Service offers five different communication channels that are implemented as sub-classes of an abstract Communication- Interaction-class where every channel specifies requirements on the information it needs to operate successfully (e.g. user names, credentials or phone numbers). Special care has to be taken to accommodate two-way channels, for instance E-mail-based communication that requires not only information on the recipient of messages but also on their sender. Our ap- proach is to let the Information Consumer also define the sender-side information as otherwise, each Smart Hub would need an individual user account to be able to send messages via these channels (e.g. an e-mail address and corresponding credentials).
E-mail E-mail channels require a recipient email address on the receiver-side as well as infor- mation on the sender e-mail address, credentials and mail server to be considered valid. Multiple receivers may be specified using the optional CC - and BCC -fields.
SMS SMS interactions depend on being aware of the receiver’s phone number, a sender phone number and sender name to work properly. Currently, this service is realized via a REST- ful SMS gateway provided by ETH Zurich.
Twitter This kind of channel enables InfraWOT Smart Hubs to communicate via Twitter microblogs. For setting up the ”tweeting“ capability, InfraWOT requires a Twitter ID and corresponding credentials. 6.3. System Design 61
Google Talk Google Talk is a free instant messaging application that uses the open Extensible Messaging and Presence Protocol (XMPP) for transmission. In order to set up a Google Talk interaction, a consumer must provide sender credentials as well as a recipient ID.
URL Callback This service is particularly useful for providing machine-to-machine interac- tion as it POSTs the desired information to a callback URL. The URL is the only manda- tory piece of information that an Information Consumer must provide to enable this interaction.
To configure his communication channels, a user may send PUT requests to the Smart Hub– the endpoint to do this is /messaging/consumers/{consumerID}/channels/{channelName}- /{channelProperty} where the consumerID is again the ID of the user’s Information Con- sumer, the channelName is the name of the channel to configure (e.g. /twitter) and the channelProperty is the specific property to change (e.g. the Twitter ID or password). For in- stance, to set up a Twitter channel, a user would send the following requests where we assume that he already has created an Information Consumer with ID testuser:
1 PUT /messaging/consumers/testuser/channels/twitter/id twitterid 2 PUT /messaging/consumers/testuser/channels/twitter/password 1234
Data Consumptions After enrolling at a Smart Hub and providing the contact information on their required channels, Information Consumers may define ”Data Consumptions“ to register their interest in the data provided by specific resources. To create a new Data Consumption, a user sends an HTTP PUT request to the Smart Hub’s endpoint at
1 /messaging/consumers/{consumerID}/consumptions/{consumptionID} The parameters of that consumption are set using subsequent HTTP PUT requests to the URI of the newly created Data Consumption. For instance, to be informed about the data provided by resources that offer a REST service with output ”Temperature“ every 10000ms, a user who has created a consumption with ID con would send the following requests:
1 PUT /messaging/consumers/testuser/consumptions/con/restoutput Temperature 2 PUT /messaging/consumers/testuser/consumptions/con/interval 10000 The Messaging Service then searches for appropriate resources using the Querying Service. The retrieved resource URLs are added internally to the consumptions of the Information Consumer and polled for new data regularly according to the time interval specified. The provided data is pushed to the consumer via each of its valid communication channels.
RESTful Message Brokerage Another feature of the Messaging Service bundle is that it allows to transmit simple text messages (subject + message) where the recipient may be a specific consumer or the collection of all Information Consumers registered with the Smart Hub. Every message sent using this interface is distributed to its recipient(s) via all channels that are valid for the individual users.
Implementation The Messaging Service bundle is an optional component of InfraWOT in the sense that no other service depends on it – it may be launched at the user’s discretion for Smart Hubs that are in- tended to provide advanced publishing/messaging services. The bundle itself requires a running 62 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
QueryFramework service and provides a service that implements the MessagingService inter- face via the Java class MessagingFrameworkService. The most important method of this class is publishMessage(String subject, String message, String consumerid) that handles the publishing of a message (usually including data from a specific resource as payload) to a specific consumer via all available channels. The MessagingFrameworkService further- more contains several methods that are responsible for providing a public interface for the RESTful registration, retrieval and deletion of Consumers and Consumptions while the ac- tual implementation of this management functionality is situated in the ConsumerRegistry and ConsumptionManager classes. The ConsumerRegistry that is implemented following the Singleton-pattern is responsible for keeping track of the current consumers that are imple- mented as instances of Consumer and for relaying published messages to these. Instances of the ConsumptionManager run in separate execution threads and handle individual Con- sumptions: In regular intervals (as specified by the interval-parameter), they query the Smart Hub infrastructure for resources that correspond to the Consumption parameters, retrieve the newest data from these and publish that data to their associated Consumer by get- ting the ConsumerRegistry instance and calling its publishToConsumer(Consumer consumer, String subject, String message) method. In order to facilitate the extension of this module, the different Communication Channels have been implemented as a Strategy-pattern and their requirements with respect to the in- formation they require on the Information Consumer’s communication endpoints have been abstracted into categories defined within the Requirements class. For instance, the Twitter channel is of requirement-type ”Wall Update“ as it requires a user name and corresponding password to work successfully. The Java libraries that were utilized within this bundle are twitter4j2 for the Twitter communication channel, the JavaMail3 API for enabling e-mail interactions and the Smack API4 to provide the XMPP service. For a class diagram of this bundle, refer to Appendix C.4.2.
6.3.6 Registry Service The Registry Service bundle (cf. Figure 6.13) incorporates the persistence unit of an Infra- WOT hub and is thus responsible for managing all data that is relevant for the operation of a Smart Hub and for persistent storage of that information. As a service to other bundles, it provides methods to store new resources and to access recorded ones by encapsulating the actual database retrieval/storage processes.
Technical Details The first implementation of the Registry Service was directly taken from the Aparat Smart Gateway presented in [6] that was based on db4o5. However, due to its low performance and unexpected behavior under OSGi that had already been observed in [6], we decided to explore different implementations of the persistence service. Due to the OSGi service model, extending the set of persistence providers is very simple as any new implementation only needs to implement the ResourceRegistry interface to offer persistence services via OSGi DS. As a first step towards replacing the db4o-based persistence unit, we created a common reference benchmark by implementing two “persistence” implementations that store the resources in a
2http://http://twitter4j.org/en/index.html 3http://http://java.sun.com/products/javamail/ 4http://http://www.igniterealtime.org/projects/smack/ 5http://www.db4o.com/ 6.3. System Design 63
Aggregation Service
Registry Service Discovery Service Messaging Service
Persistence Unit Querying Service Registry Service
Resource Storage Infrastructure Service Web Interface Service
Multiple Implementations
OSGi Framework + Declarative Services
Figure 6.13: Overview of the InfraWOT Registry Service.
Machine 1 Machine 2 db4o 283479ms 355964ms Text File 253523ms 346574ms Text File / Inverted Indices no data 478732ms RAM / JSON 371730ms 263983ms RAM / Reference 3780ms 4831ms
Table 6.1: Performance of different implementations of the InfraWOT persistence for 1500 inser- tions of resources and 1500 deletions.
volatile way in random-access memory (RAM). While one of these preserved the actual runtime instances of the resources, the other kept the resources as JSON-serialized strings. Then, initially only to get a general feeling for database performance, we implemented a simple persistence unit that stores resources as JSON-serialized strings in a text file. However, due to very promising preliminary evaluations of this “naive” database implementation (cf. Table 6.1), we decided to further explore the approach based on text files. This eventually led to the implementation of a persistence service that was based on multiple inverted indices6 for fast querying of resources. For our prototype implementation we created two such indices for the keywords associated to resources and their REST service outputs, respectively. With this persistence service, whenever a resource is stored, a total of three tables are updated (cf. Listing 6.3). When compared to the implementation based on a single text file, such a system defers the indexing of a resource to the time when this resource is registered at the Smart Hub which is reasonable as we expect the number of lookup operations to exceed the number of registration events by far. For this reason, we expect the querying performance of an inverted-index-based implementation to greatly outperform that of a system based on single text files (cf. Section 6.3.6). However, the inverted indices come at a price: Due to the increased storage redundancy, the file size of the database increases by at least 200% (for our three tables) and grows not only according to
6http://en.wikipedia.org/wiki/Inverted index 64 A Distributed Modular Infrastructure for the Web of Things: InfraWOT the total number of stored resources but also with the number of indices (i.e. the number of keywords and REST service outputs per resource).
1 // Actually store entity in core table 2 writeStringToFile(entity.toJSONObject().toString(), databaseCoreTable);
3
4 // Get keywords from entity and add inverted index entries 5 for (String keyword : entity.getKeywords()) writeReverseEntryToFile(keyword.toLowerCase(), entity. toJSONObject().toString(), keywordReverseTable);
6
7 // Get REST Output from entity and add inverted index entries 8 for (String restOutput : entity.getRESTOutput()) writeReverseEntryToFile(restOutput.toLowerCase(), entity. toJSONObject().toString(), restOutputReverseTable);
Listing 6.3: Persisting a new resource to the inverted-index-based database implementation: Additionally to storing the resource itself in the databaseCoreTable (line 2), entries in the keywordReverseTable (line 5) and the restOutputReverseTable (line 8) are created.
While the RAM-based persistence module was initially implemented only for being able to compare the different database implementations to a common standard, we decided to augment this implementation with a Persistor unit (i.e. a thread that writes all the information to the hard disc every few seconds) and recommend to use that version of the Registry Service whenever it is expected that InfraWOT will only have to deal with a limited number of resources.
Implementation The Registry Service bundle depends on no other bundles and provides the OSGi DS service interface ResourceRegistry via the Java class RAMbasedResourceRegistryService which im- plements the RAM + Persistor-based database implementation. This class provides multiple methods that wrap the database functionality into an easy-to-use registry interface and enable other bundles to get resources from the persistence by several different parameters:
1 public Resource getResourceByUuidString(String resourceUUID); 2 public List getResourcesByRating(Double ratingDouble); 3 public List getResourcesByDescription(String string); 4 public List getResourcesByRestMethod(String restMethod); 5 public List getResourcesByRestOutput(String restOutput); Additionally, this bundle contains implementations of all other persistence services presented in this section that may be swapped for the RAMbasedResourceRegistryService class by re- placing the class attribute in the OSGi DS component definition (OSGi-INF/components.xml).
Evaluation The local database performance of a Smart Hub is also one of the two main determinants of the querying performance in an InfraWOT infrastructure while the other main parameter for this is the depth of the subtree that is queried (especially for EXQs). Of course, the effect of the database performance on the total querying efficiency depends largely on the depth of the infrastructure hierarchy – we expect that, for increasing hierarchy depths, the influence of the 6.3. System Design 65 database speed on querying will get negligible. This effect is illustrated in Figure 6.14 where, for a subtree depth of 10, the (comparatively slow) custom-made, text file-based database even outperforms a RAM-based reference implementation with respect to the querying performance.
50 Custom DB Implementation, Inverted-Index Based 45 RAM-based Reference Implementation
40
s] 35
30
25
20
15 Avg. Response Time [m Time Response Avg.
10
5
0 1 2 3 4 5 6 7 8 9 10 Smart Hub Hierarchy Depth
Figure 6.14: Querying performance versus the Depth of the queried InfraWOT hierarchy.
We also tested the performance of the different database implementations in comparison to each other. Specifically, as Figure 6.15 illustrates, we were interested in the amount of time it takes a certain implementation to insert the i-th resource into the database. Our evaluation shows that, when the number of insertions stays below a certain limit (about 1500 resources), it is more beneficial to use any implementation other than the db4o while the latter exhibits only a minor drop in performance for high numbers of resources.
Figure 6.15: Comparison of the time needed for the insertion of the i-th resource using the different database implementations. 66 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
6.3.7 Aggregation Service The Aggregation Service (cf. Figure 6.16) is a component of InfraWOT that enables clients to retrieve aggregated data from the resources registered to a Smart Hub infrastructure and also provides a module called POSTregator that allows to aggregate HTTP POST requests. This functionality depends greatly on the Querying Service of InfraWOT that is used to identify the resources the data of which is to be aggregated / that are to be POSTed to. The Aggregation Service has been implemented as a standalone program external to the InfraWOT project as we perceive aggregation as a mashup application that builds on top of an infrastructure of Smart Hubs rather than constituting an organic part of every single InfraWOT node.
Aggregation Service
Aggregation Service Discovery Service Messaging Service
External Module Querying Service Registry Service
"Standard" Aggregation Infrastructure Service Web Interface Service
HTTP POST Aggregation
OSGi Framework + Declarative Services
Figure 6.16: Overview of the InfraWOT Aggregation Service.
Technical Details The software implementing the Aggregation Service comprises a component that provides the aggregation services along with a web server module generated by the AutoWOT toolkit (cf. Chapter5). The aggregations provided by this service are
Average – Returns the average of the retrieved data values. Count – Returns the size of the retrieved data values. Majority – Returns the value that occurs most often within the set of the retrieved data values. Maximum – Returns the maximum value of the retrieved data values. Minimum – Returns the minimum value of the retrieved data values. POSTregation – Distributes a POST request to all retrieved resources. Standard Deviation – Returns the standard deviation of the values within the set of the retrieved data values. Sum – Returns the sum of a given set of values. 6.3. System Design 67
Implementation This component contains 28 Java classes that are grouped into four packages. The classes within ch.ethz.inf.vs.wot.infrawot.external.aggregation.aggregators implement the different aggregation functions, where all of these implementations inherit from the abstract Aggregator class. The most important methods of these are the getResourceURLsFrom- Keywords(...) method that is responsible for retrieving the resources whose data is to be aggregated from the Smart Hub infrastructure and the method getValuesFromResource- URLs(...) that retrieves the data values themselves. These values are then, depending on the actual aggregation function to be applied to them, passed to the methods aggregateToDouble, aggregateToInteger or aggregateToString and the aggregated value is returned to the user together with additional information (e.g. the number of occurrences of the majority value).
The web server implementation is contained in the package ch.ethz.inf.vs.wot.infrawot.- external.aggregation.restlet.automatic prototypes and follows the usual implementa- tion model of AutoWOT-generated web server modules, i.e. it contains a BaseResource class, a RestletMain and RootApplications and classes implementing the different web resources (cf. Figure 6.17).
Query Parameter /{queryParameter]
if�functionName�==�"postregator" InfraWOT Aggregator / Aggregation Function Query Type else /{functionName} /{queryType}
Query Parameter /{queryParameter]
Figure 6.17: RESTful resource structure of the Aggregation Service web resource.
6.3.8 Web Interface Service The InfraWOT Web Interface Service bundle (cf. Figure 6.18) is responsible for providing the services of the Smart Hub to HTTP clients and enables RESTful interaction of these clients with the infrastructure and its attached resources. An especially important task of the Web Interface Service is to enable the RESTful configuration of InfraWOT Smart Hubs.
Technical Details The web interface of InfraWOT has been generated using the AutoWOT Deployment Toolkit for the Web of Things. In general, an InfraWOT Smart Hub provides exactly the same kinds of information via its ROA as any Web of Things Driver created by AutoWOT. However, the HTML representations of its resources have been overridden to improve the usability for human clients. In the following, we are going to describe the individual endpoints of the InfraWOT web interface and their functionalities: The Root (“/”) HTML representation provides general information on the current Smart Hub (e.g. its name, hierarchical location and associated review) and on its connected sub-nodes and 68 A Distributed Modular Infrastructure for the Web of Things: InfraWOT
Aggregator Service
Web Interface Service Discovery Service Messaging Service
Web Representation Querying Service Registry Service
RESTful Client Interaction Infrastructure Service Web Interface Service
RESTful Configuration
OSGi Framework + Declarative Services
Figure 6.18: Overview of the InfraWOT Web Interface Service.
attached resources. It furthermore offers a web form for resource registration. Beneath the root resource, the InfraWOT web interface features five resources:
The /hubs resource represents a list of all attached hubs. Child nodes may send HTTP PUT requests to this address to be registered by the Smart Hub. The HTML representation of this resource can be used to navigate the Smart Hub infrastructure. The individual Smart Hubs registered to the local hub are represented as child resources of the /hubs resource which can be used to delete individual child nodes. For instance, to delete the Smart Hub with UUID ID32, an HTTP DELETE request should be sent to the resource /hubs/ID32.
The /resources resource represents a list of all sub-resources attached to the current Smart Hub. Similar to the /hubs resource, Web of Things resources may send HTTP PUT requests to this resource to be registered by the Smart Hub. Likewise, these resources are represented as child resources of the /resources resource and can be interacted with via requests to their respective endpoint within the local Smart Hub. Apart from enabling clients to delete certain sub-resources (by sending an HTTP DELETE request), users can also use their associated URI within InfraWOT to evaluate Web of Things resources that are attached to the InfraWOT infrastructure. This is done via HTTP POST requests that carry JSON-encoded reviews as payload. A client may include multiple review parameters including a rating (typically between 1.0 and 5.0 where 5.0 is the best rating), an informal review description, a reviewer name, a review category (e.g. Product or Service) and multiple tags that describe the reviewed resource. When an evaluation of an attached resource is received, the Smart Hub retrieves the reviewed item and merges the new information and the resource’s current review while updating the Date Reviewed-field. The user is also given the possibility to remove a specific tag from a resource’s review by POSTing that tag together with a leading “-” to the Review Interface. If multiple persons (as indicated by the reviewer name-parameter) review the same resource, that property is set to Multiple Reviewers. However, as this method of reviewing individual resources depends on a proprietary JSON representation of reviews, it violates the REST principle of the uniform interface. We suggest a revision of the reviewing mechanism in a future version of InfraWOT. 6.4. Summary 69
The /querying endpoint can be used to submit queries to the InfraWOT Querying Service using HTTP POST requests with content in the application/x-www-form-urlencoded encod- ing or as JSON strings. Its HTML representation provides a web form that allows POSTing queries via a browser. When receiving a search request from a user, the wothubsynone uses the POSTed information to create a new instance of a Query object that is passed to the Querying Service which retrieves information on corresponding resources and returns that data to the web interface. Query answers are delivered in the HTML, JSON or XML format depending on the HTTP Accept-header where the HTML representation of these responses is again modified to better suit human users.
The /messaging resource and its sub-resources handle all interaction related to the Infra- WOT Messaging Service, i.e. the creation, updating and deletion of Information Consumers, Data Consumptions and the information on communication channels for individual consumers (cf. Section 6.3.5).
The /infrastructure is mainly used internally by the InfraWOT software to send and receive maintenance information. Its /configuration sub-resource, though, plays an impor- tant part in the fully web-based configuration system of InfraWOT that enables any client to configure a Smart Hub by sending HTTP POST requests to its configuration interface at /infrastructure/configuration. When a client POSTs a string of data to this endpoint, the Smart Hub relays that data to the Discovery Service to retrieve the resource encoded in the transmission and applies that information to its own representation. Although the currently preferred way to configure a Smart Hub is to POST the desired configuration as a JSON-encoded resource, a hub can be configured using any representation that is supported by the Discovery Service.
Implementation The Web Interface Service bundle requires several running services, including a Resource- Registry, QueryFramework, InfrastructureFramework and MessagingFramework. The bun- dle itself provides the OSGi DS service interface RestletWebInterface that is implemented by the Java class RestletMain. Most of the Java classes within the Web Interface Service bundle have been generated by the AutoWOT toolkit and we therefore refer to Section 5.3.2 for details on their implementation. However, several of these classes have been changed to accommodate special needs of Infra- WOT – for instance, the HTML interface was adapted to better suit human users and some methods responsible for handling POSTs and PUTs were extended as the limited expressiveness of AutoWOT does not allow for routines of such complexity.
6.4 Summary
In this chapter, we presented InfraWOT, a modular, distributed infrastructure for the Web of Things that is based on Smart Hubs and fosters the rapid creation of mashups, i.e. of composite services that incorporate that data and/or functionality of multiple resources on the WoT. The most important component it provides to facilitate the construction of these is its Querying Service that allows infrastructure-assisted searching for resources. Multiple Smart Hubs within the same scope are structured according to their hierarchical locations, a property that is guaranteed by InfraWOT’s Infrastructure Service and made use of during 70 A Distributed Modular Infrastructure for the Web of Things: InfraWOT device discovery, querying and to ensure infrastructure-level self-stabilization. For the storage of information on discovered and attached devices, we have implemented multiple persistence units within the Registry Service module and evaluated these while we encourage the integration of additional implementations. Every hub additionally features a web interface that widely supports the principles of REST and of the ROA. Finally, extending and upgrading InfraWOT in the future is greatly facilitated by its OSGi-based architecture and bundle interactions via OSGi Declarative Services. Chapter 7 Applications and Prototypes
”Nothing great was ever achieved without enthusiasm.”
Ralph Waldo Emerson (1803 - 1882)
We have implemented several demonstration prototypes to exemplify and illustrate the advan- tages associated with the different components of the Web of Things that have been presented in this thesis. While these applications range in complexity from very simple physical-physical mashups to extensive examples of Human-Computer Interaction (HCI), the emphasis shall by no means be placed on the prototypes themselves but rather on the facilitation when implement- ing these while profiting from an infrastructure of the Web of Things. Even though InfraWOT Smart Hubs has limitations with respect to the parameters a client may use to search for re- sources, it acts as an enabler for lots of applications as will be demonstrated in this chapter. After presenting several smaller mashups that demonstrate the potential of this work with re- spect to the fast prototyping of applications dedicated to single, confined tasks in Section 7.1, we will describe two elaborate prototypes that make extensive use of the InfraWOT Web of Things infrastructure and that especially highlight the potential of the Web of Things with re- spect to HCI in Sections 7.2 and 7.3. To better explain how these applications benefit from the distributed infrastructure and especially from the Querying Service of InfraWOT, information on the development process and its duration will be included for these prototypes as well.
7.1 Miniature Mashups
The mashups presented in this section are comparatively small applications that were de- veloped within some minutes and are presented to accentuate the feasibility and simpleness of implementing virtual-physical and physical-physical mashups on WoT-enabled smart devices. The three prototypes that are shown here all share the same basic architecture: The smart things or resources that are to be linked within one mashup are identified by keywords and 72 Applications and Prototypes fetched as JSON strings from the infrastructure using the InfraWOT Querying Service. Ini- tially, these used a search engine for the Web of Things which is a precursor-architecture of InfraWOT but were adapted to InfraWOT-based searching by modifying the query format. Apart from the keywords they use, the three mashup applications differ in the way of inter- preting incoming sensor data and of encoding data that is sent to actuate smart devices. Developing mashups like the ones described in the following is greatly simplified when one may rely on a Web of Things infrastructure and on its querying services as a background assistance. In order to implement a different (but architecturally similar) mashup, the only thing that needs to be done is to exchange the querying keywords and write methods to correctly handle the data that is retrieved from the smart things that are used.
7.1.1 WOTStocks The WOTStocks application is a virtual-physical mashup that combines data on current stock quotes with the colors of a Sun SPOT’s LEDs and was inspired by the Ambient Orb1 developed by Ambient Devices, Inc. For being able to operate, this mashup requires a running Sun SPOT Driver together with at least one connected Sun SPOT and access to the Web of Things Stocks Driver (cf. Section 5.4.5) which provides near-time bid and ask-quotes of multiple listed companies.
"LEDs" ? InfraWOT Smart Hub
Sun SPOT Driver
WOTStocks "Stock {stockID}" ? Stocks Driver
Figure 7.1: Interaction of the WOTStocks software with InfraWOT.
On startup of WOTStocks, the user is prompted to enter the ID (ISIN or Nasdaq Code) of the company whose stock quote is to be displayed using the Sun SPOT’s LEDs. WOTStocks
1http://www.ambientdevices.com/cat/orb/orborder.html 7.2. WOTic Music Player 73 then queries the InfraWOT infrastructure to retrieve the LEDs-resource of a Sun SPOT and a Stocks Driver resource using the query keywords “LEDs” and “Stock {stockID}” where the stockID is replaced by the actual ID entered by the user (cf. Figure 7.1). If the retrieval of both of these resources is successful, WOTStocks enters a loop that regularly queries the Stocks Resource for the most current quotes and then updates the LEDs of the Sun SPOT where the first and the third LED are used to present the change in the ask and the bid of the chosen stock, respectively. The color of these two LEDs is set to green, red or blue depending on whether the value of the stock has increased, decreased or not changed since the last tick.
7.1.2 LED Control Mashup
The LED Control Mashup is one of the physical-physical mashups developed during this thesis that allows to control a Sun SPOT’s LEDs using a LEGO NXT brick’s buttons. The keywords used to query for these resources, here, are “led list” and “button”. The data retrieved from the resource that was returned by InfraWOT for the “button”-query is mapped straightforward to the Sun SPOT’s LEDs by interpreting a 0 as the off and a 1 as the on-command. To switch on/off all LEDs that it can find, this mashup may use InfraWOT’s aggregation service.
7.1.3 Shadow Mashup
The Shadow Mashup is basically a miniature version of an automatic controller for sun blinds that actuates a motor as long as the incident light measured by a light sensor is above a certain threshold. This mashup uses the keywords “motor” and “light” to find its resources that, in our prototype, have been a Sun SPOT’s Light Sensor-resource and one of the Motor-resources of a LEGO NXT brick.
7.2 WOTic Music Player
The WOTic Music Player is one of the larger and more complex mashups that have been developed in order to demonstrate the power of the Web of Things with respect to Human- Computer Interaction. WOTic essentially is a music player that is controlled via physical interfaces of various nature: To select the audio CD to listen to, a user simply places the casing of that CD on an RFID reader that is connected to the Web of Things whereas, for browsing the songs on a CD, he uses a WOTic Controller. While our experience has shown that a Sun SPOT’s Tilt and Acceleration-resources provide the most intuitive means of control, WOTic supports a multitude of different input interfaces. As multiple persons at different machines may be using WOTic to listen to music at the same time, it is possible for a user to join the WOTic Streams of other people by using the InfraWOT structure to tune into the same RFID reader as they are using. WOTic features an SWT-based GUI that lets users browse streams and controllers within the InfraWOT scope that the application is connected to, where a user is given the possibility to specify the type of controller he wishes to use as well as the URI of the InfraWOT Smart Hub to use as an entry point to the infrastructure. The WOTic software makes extensive use of various features of InfraWOT and, having been implemented within only two hours, is one of the prime examples to illustrate the convenience of a searchable Web of Things infrastructure when constructing physical mashups. 74 Applications and Prototypes
7.2.1 Technical Details On startup, the software loads all available RFID readers from the infrastructure by querying an InfraWOT hub at a default URI that may be changed by the user via a text box and the Reload Streams-button. The query that is sent to the infrastructure contains the keyword “RFID” and is of type Exhaustive Query (EXQ) as WOTic tries to retrieve all applicable devices while the user is left to decide which of these is to be used (cf. Figure 7.2). The answers to that query are presented to the user as music streams together with their hierarchical locations within the structure. As soon as the user selects one of the retrieved feeds and clicks the Join Stream-button, the software starts to regularly poll the associated RFID reader for its currently read tag. If a tag is retrieved, WOTic uses an internal dictionary to find the name of the appropriate audio CD and starts to play the first song of that album while continuing to poll the RFID reader in the background. If the tag is replaced by a different one, the currently playing song is stopped and WOTic switches to the new audio CD. If the tag is removed, WOTic stops playing.
"RFID" ? InfraWOT Smart Hub
Sun SPOT Driver
WOTic "{cntrlDescriptor}" ? Phidgets RFID Driver
Figure 7.2: Interaction of the WOTic software with InfraWOT.
By providing a controller-descriptor string (e.g. “tilt” or “light”) to the software and clicking the Reload Controllers-button, the user is able to search for input interfaces that can be used to browse the songs on an audio CD. To retrieve these controllers, WOTic again queries the InfraWOT infrastructure, this time specifying the descriptor as the REST Operation Output to search for. The hub’s answer which is a description of all resources corresponding to the query together with their respective locations, is presented to the user who now may select one of these controllers or, if the answer was not satisfactory, query for resources with different functionalities. When a controller is selected, a handler is started that polls the associated resource and analyzes the data it receives. 7.3. WOTpong 75
Due to the diversity of the data that is provided by different smart devices (boolean, floating point or integer values or general strings), WOTic requires an algorithm that is capable of interpreting such heterogeneous data and mapping it onto the user actions Play Next Track and Play Previous Track. We have chosen to first try to cast any received data to floating- point numbers where also boolean values are casted to numbers for enabling switch-based interaction. The algorithm estimates the dynamic range of a specific controller by keeping track of the globally highest and lowest received value for that input resource and converting that range to integer scores between 0 and 100. All received values are adjusted according to this system where scores higher than 75 are interpreted as the command Play Next Track and values lower than 25 are resolved to the command Play Previous Track. To give an example, we consider a Sun SPOT’s acceleration sensor that yields values between −1.5 and 1.5. After having been calibrated, i.e. after the algorithm has encountered these extreme values and thus determined the actual dynamic range of the data source, an incoming value of, for instance, −1.1 will be mapped to the score 13 and therefore interpreted as the Play Previous Track- command. Consequently, a value of 0.8 (score 76) will result in WOTic switching to the next song on the current disc. While this method of interpreting received data is very simple, it allows for the correct and meaningful processing of a high number of input resources as most sensor data (especially when considering Sun SPOTs) can be mapped to floating-point values. In practice, the algorithm performs very well especially for Tilt and Acceleration sensor data and test subjects were able to rapidly adapt to this way of controlling a music player.
7.2.2 Summary The WOTic Music Player is a prime example of how the distributed infrastructure of the Web of Things enables programmers to rapidly and conveniently construct complex mashups on top of the resources attached to it. The challenging part when doing this is the interpretation of incoming values and converting that data to application commands. As a first step, we have presented a self-calibrating algorithm capable of handling numeric values as well as any other data that can be transformed into floating-point values in a meaningful way. A different solution that we propose is the concept of Web of Things Wrappers which are intermediate data mashups that produce prototype-specific according to rules that can be injected at runtime. In such a setup, WOTic would not query a Sun SPOT’s sensor directly and interpret its data but rather use the InfraWOT structure to find a Wrapper-Resource that directly provides WOTic-specific commands. As such intermediate data mashups are, in fact, aggregation services, they could also be integrated into aggregation services along with the usual aggregation functions (e.g. Maximum or Average).
7.3 WOTpong
WOTpong is a simple Pong game, i.e. a basic two-dimensional simulation of table tennis2, where the user’s paddle is controlled using a physical input device of his choice. Any resource that is enabled for the Web of Things and features a Getter-functionality that provides values that are reasonable to be used as Pong input is eligible for being used to control WOTpong. Reasonable, here, means that it must be possible to automatically transform that input to a meaningful command for steering the paddle and that the user should be at least indirectly able to exercise control over the values generated by the selected input device. While it is possible to
2http://http://en.wikipedia.org/wiki/Pong 76 Applications and Prototypes control WOTpong via temperature sensors or even stock quotes, the preferred input interfaces are touch sensors of NXT bricks, Sun SPOT light sensors or, most intuitively, the output of a Sun SPOT’s Tilt resource. The data values received by WOTpong are interpreted using a similar algorithm to that in the WOTic Music Player that transforms input values either to an integer value between 0 and the width of the Pong canvas to directly place the paddle at a certain position or to a tri-ary value for steering the bar to the left or to the right. One main difference between these two applications is, however, that WOTpong itself includes an AutoWOT-generated web server and thus can be used to set up two-player games in a peer- to-peer fashion directly via HTTP and without a supporting infrastructure like InfraWOT. To enable this, the application’s web server publishes the current coordinates of the ball and the position of the local paddle on the web as an HTML, JSON and XML-encoded resource. Another WOTpong game may access this resource and retrieve these three values while itself publishing its own paddle position to set up a new two-player game via HTTP. The implementation process of WOTpong was fairly straightforward and took around two hours. The game features a simple interaction mechanism with the InfraWOT structure where the user is prompted to input a keyword that is used by the software to trigger a query for Web of Things resources. The program then starts polling the retrieved resources and interpreting the data using a similar algorithm to that in the WOTic Music Player.
7.4 Summary
The prototypes presented in this chapter show that it is feasible and convenient to make use of an infrastructure for the Web of Things when building mashups. We have demonstrated several simple mashups that exemplify how to use the InfraWOT Querying Service to rapidly implement physical-physical and virtual-physical mashups and have shown applications that enable advanced Human-Computer Interaction schemes. These mashups furthermore prove that, although HTTP introduces a communication overhead and increases average response latency, it is still sufficient for many pervasive scenarios where longer delays do not affect user experience [10]. Most prominently, this is true for the WOTic Music Player where we have wit- nessed no delay-related issues. As WOTpong relies on real-time data streams, though, we have at times noticed problems when the HTTP delay exceeds the inverse of the application’s frame rate and thus do not suggest using such an interaction mechanism for applications (especially games) that depend on strong real-time guarantees. Chapter 8 Conclusion and Future Work
This chapter presents an outline of potential future work in the context of the Web of Things and an overall conclusion.
8.1 Future Work
Within the context of the components of the Web of Things that have been designed and implemented during this thesis and with respect to the Web of Things in general, there are many issues to be resolved in the future. Here, we present a list of the topics that we believe to be most relevant during future work:
Expanding the Web of Things Ecosystem The AutoWOT Toolkit represents a first step towards the semi-automatic integration of smart things and other objects into the Web of Things. This idea of enabling anybody to specify the structure of resources to attach to the WoT using an easy-to-handle user interface does, in our opinion, hold great potential and should be explored further. Future investigations of this topic should include a revision and extension of the basic resource model that is used in AutoWOT, mainly to enhance its expressiveness with respect to resource properties.
Enhancing and Unifying Web of Things Infrastructures Including InfraWOT, three dif- ferent but partially overlapping infrastructures for the Web of Things have been designed and implemented neither of which offer a fully satisfying architecture or an all-round set of function- alities. However, we believe that by unifying those fragments that represent the focus of every individual implementation, it may be possible to arrive at a management infrastructure for the Web of Things that incorporates all the key features we desire within a single architecture:
• An open, flexible and runtime-extensible semantic and physical device discovery service.
• A self-stabilizing infrastructure maintenance unit that can adapt to reconfigurations. 78 Conclusion and Future Work
• Extensive support for hierarchical locations and associated location mapping (cf. [49]).
• A fast, expressive and client-friendly querying service.
• A robust and scalable eventing mechanism.
• A reliable security and access control mechanism, possibly incorporating social networks.
• A web interface that strictly follows the principles of REST and the ROA.
• A modular architecture to enable incorporating anything we do not yet anticipate.
Facilitating the construction of Web of Things Mashups While a distributed infrastructure for the Web of Things enables to easily construct mashups that utilize the data and functional- ities provided by physical objects attached to the WoT, a generic way of handling and mapping that data is required. As a possible alternative to tackle this issue, we suggest a concept that we call Web of Things Wrappers. These are data brokers that can convert arbitrary inputs to application-specific outputs according to a user-defined strategy and support runtime injection of such strategies via a RESTful interface. With an entity like that connected to the Web of Things, any application could, on startup, configure a Wrapper to its own needs and consume information on the Web of Things via this intermediary node.
8.2 Conclusion
In this thesis, multiple components of a Web of Things architecture were described and imple- mented, including a Web of Things Driver architecture for attaching smart devices to the WoT that was used to web-enable Sun SPOTs (Chapter4). We have presented evaluations where we compared this architecture to an existing one [20] and discussed the associated tradeoffs, especially with respect to response time, data age, power consumption and scalability under concurrent requests (Section 4.4). This discussion should facilitate future processes of deciding which of these strategies to use one for enabling a device for the Web of Things or whether to explore additional ways of achieving that goal. In Chapter5, we have presented AutoWOT, a semi-automatic fast prototyping toolkit that builds upon a generic description format for web resources. By using AutoWOT to attach multiple devices to the Web of Things (Section 5.4), we have shown that this toolkit is suitable for rapidly WoT-enabling things that are heterogeneous with respect to their complexity and functionality. For combining resources on the Web of Things to construct advanced mashups, InfraWOT, a distributed modular infrastructure for the Web of Things was proposed (Chapter6). This Smart Hub architecture features an extensible, strategy-based discovery mechanism (Section 6.3.2), infrastructure-assisted querying (Section 6.3.3) and a versatile messaging service (Section 6.3.5) on top of the layer of Web of Things Drivers. InfraWOT brings a hierarchical, location-based, structure to the Web of Things and heavily builds on that topology during device discovery and searching. It furthermore widely respects the Resource-Oriented Architecture thereby greatly facilitating interaction by providing a RESTful uniform interface. To illustrate the convenience that a Web of Things infrastructure offers together with a reliable querying service with respect to the construction of mashups and linking the functionalities of different devices, we have presented multiple prototypes for physical mashups (Chapter7) where the emphasis has been placed on the aspect of Human-Computer-Interaction. 8.3. Acknowledgements 79
We believe that we are approaching the realization of the vision of the Web of Things with every day that passes. In our opinion, physical mashups that are currently mostly an interesting topic of scientific research will, in time and with the further advancement of the computer in our personal lives, become an everyday experience for everyone, be it when people enter their smart home that had already switched on the heating when their owner got off the freeway [1], when their mobile phone advises them on how to economize their power consumption [23] or when their favorite chicken noodle soup is for once not out of stock exactly when they would like to enjoy one [15, 34].
8.3 Acknowledgements
I would like to thank my supervisors Dominique Guinard and Vlad Trifa for the possibility to be a part of such an absorbing endeavor as the Web of Things, for the numberless prolific and enjoyable discussions and for their support during this thesis. I furthermore thank Prof. Dr. Friedemann Mattern for his mentoring during my master studies and especially for taking the time for our conversations. I am grateful to my laboratory colleagues, especially to Azu- cena Guill´enAguilar, Oliver Senn and Soojung Hong, for their company and our cheerful and motivating chit-chat during the last six months. Finally, I want to thank my family for their continuing support during my academic studies. Thank You! 80 Conclusion and Future Work Appendix A Hints and How To-s
A.1 OSGi Setup
A large portion of the software developed within this thesis was based on the OSGi framework and especially on OSGi Declarative Services. This section shall provide support for developers when developing and running applications the make use of OSGi. In our experience, while it can be a challenge to set up the OSGi framework initially, it is a great tool for modular development once it is set up. Especially the Declarative Services extension that facilitates the providing and referencing of OSGi services has proven to be very useful during development. For an introduction to to OSGi DS, we refer to the excellent tutorial by N. Bartlett [2]. A general problem that we experienced when using OSGi for development is that debugging of the inter-bundle interactions can be very tedious as the framework is quite reluctant to provide debugging information (even with the logging enabled). More than once, we have come across situations where all bundles started without problems and everything was looking good, but the program still was not running. For this reason, we provide a kind of checklist with general hints on how to avoid and/or debug such problems:
• Before running an OSGi-based application, make sure to check the Problems/Warnings view of your IDE for OSGi-related warnings.
• Take care when refactoring classes as the OSGi-related documents (i.e. bundle manifests and component definitions) will not be updated. After every refactoring, re-check the warnings for OSGi-related issues.
• When debugging a running OSGi framework, the commands (Equinox framework) that have proven most helpful in our experience, are
– ss - to view the currently installed bundles and their state (Installed/Resolved/Ac- tive). – diag x - to display possibly unresolved constraints of the bundle x. – ls/list - to list the currently active components and their state (Satisfied/Unsat- isfied). – comp x - to display details on the component x. – services - to list the services that are currently provided and referenced together with the bundles that provide/reference them. 82 Hints and How To-s
• When encountering a bundle in Resolved-state, try to start it using the command start x where x is the ID of the bundle. This will display the error message that caused it to fail in the first place.
• Regularly perform a cleanup using the Eclipse Project → Clean... command. This will sometimes result in Eclipse detecting OSGi-related warnings that it did not display before.
• When experiencing NoClassDefFoundErrors, check the manifest of the exporting bundle: Every jar file containing a class that is exported by the bundle has to be added to the bundle classpath (select the Runtime tab in the manifest editor). Eclipse will not detect errors that are related to a bundle not fulfilling this requirement.
A.1.1 Running OSGi Frameworks with DS-support within Eclipse Before OSGi bundles can run within a framework in the Eclipse IDE, a new Run Config- uration has to be set up for the project. To do this, click “Run” → “Run Configurations...” to enter the corresponding dialog and double-click on OSGi Framework. Enter a name for this configuration and, as a first step, deselect all platform bundles by clicking the check box next to Target Platform. After making sure that the desired Workspace Bundles are still selected, click Add Required Bundles. Additionally to the modules that are now selected (be- tween five and nine additional bundles, depending on the OSGi version), we add the bundles org.eclipse.equinox.ds, org.eclipse.equinox.util and org.eclipse.osgi.services to enable the support for OSGi Declarative services. We click Apply to store the current configu- ration and click Run to execute it.
A.2 Sun SPOT Driver Manual
This manual gives instructions on how to use the synchronization-based Sun SPOT Driver developed during this thesis. For a minimal operation of this software, the two Plug-in Projects SunSPOTDriver-AutoRestletBundle and SunSPOTDriver-DriverCore are required. This project may be started from within the Eclipse IDE or exported into a standalone OSGi framework using an ANT script (for this script, see the PackagedGateway project). To launch it within that standalone OSGi framework, execute startGateway.sh. To run it within the Eclipse IDE, create a new OSGi framework Run Configuration according to the instructions in Section A.1.1 and use this configuration to run the software.
A.3 AutoWOT Manual
This manual gives step-by-step instructions on how to use the AutoWOT Toolkit for creating OSGi-based web server bundles that connect resources to the Web of Things. For facilitating the process of getting to know AutoWOT and its features, tool tips have been included at all relevant places in the GUI. The manual is built around a real-life example, namely the enabling process of a simple Sun SPOT Driver where we assume that the user already has a software package that is capable of accessing Sun SPOTs. The final software will expose a collection of Sun SPOTs as resources on the Web of Things, every single one of which will provide access to its temperature data via the Web. A.3. AutoWOT Manual 83
Figure A.1: The initial AutoWOT user interface.
Launching AutoWOT To launch AutoWOT, either use the corresponding jar-file (without arguments, but while keeping the resources-folder in the same location as the jar-file) or use an IDE of your choice. However, as AutoWOT has been developed using Eclipse, that is the program we recommend for extending it. After starting up the program, the initial interface of AutoWOT is displayed (cf. Figure A.1).
Resource Configuration and OSGi Web Server Bundle Creation To start enabling a new resource for the Web of Things, drag the -item from the list on the right into the configuration build-up area on the left. As soon as the item is dropped into the build-up area, a box appears and prompts for information on the created resource – enter SunSPOT Driver as the resource name and / as the relative URL of the resource and click Create Resource. AutoWOT will now create the SunSPOT Driver as the root of the new resource structure and display it in pseudo-XML style within the build-up area. Next, we want to create a runtime- dynamic collection of Sun SPOT resources as sub-resources of the SunSPOT Driver. To do this, drag the Child-item into the build-up area, let go of it and enter {spotName} and /{spotName} as the name and URI of the new resource. The spotName is enclosed in curly braces because it is a runtime-dynamic property and has to be resolved by the web server component on every call for a resource. As the web server also has to find out which Sun SPOTs are available at runtime, we furthermore have to set the type of the SunSPOT-resource to Collection and enter the name of the collection method (in our case, this is getSpotNames, see Figure A.2). Click Create Resource to create the new collection-type resource as a sub-resource of the SunSPOT Driver. Our next task is to add a Getter to the SunSPOT resource that gets and presents the current temperature measured by its respective parent Sun SPOT to clients. For this, we first enter the SunSPOT-resource by clicking on it and then drag a new Getter into the build-up area. We provide the information on the new Getter by specifying Temperature as the name, getTemperature as the callback method and temperatureChanged as the OnChange-method 84 Hints and How To-s
Figure A.2: Creating a runtime-dynamic collection of Sun SPOT resources.
Figure A.3: Create the OSGi bundle to expose the configured resource via the Web.
and confirm by clicking Create Getter. The new Getter is created and displayed in the build-up area. As we want to add an additional description to it, we enter the Getter and then drag the Description-item into the build-up area. We input Current Ambient Temperature in the pop-up box and confirm. This step completes the configuration of our SunSPOT Driver resource and its sub-resources. We now want AutoWOT to create an OSGi web server bundle that will expose our Sun SPOTs using the information we just entered – click Create OSGi Bundle (cf. Figure A.3) to bring up the OSGi bundle creation interface and enter the appropriate information. If additional instructions on the information to be entered is required, use the tool tips that are associated with the five input box labels.
Integration of the created Bundles After we have clicked the Create OSGi Bundle but- ton, AutoWOT will create the corresponding source codes, manifests and Declarative Service specifications and store them in a folder called AutomaticPrototypes. This directory is further structured into the OSGi-Restlet folder that contains all the data on the newly generated web server bundle and the OSGi-Driver folder that contains the data on the necessary modifications A.4. InfraWOT Manual 85 within the already existing bundle that implements the SPOT–Computer interface. As a first step, we copy the src/ folder within the OSGi-Driver directory to the appropriate location within that bundle, i.e. within the software that provides the callback-methods we specified earlier. Provided that our bundle does not already use OSGi Declarative Services, we also copy the OSGi-INF folder to our device driver project (otherwise, the information on these services has to be merged manually). The META-INF folder contains a manifest definition with two lines of information that have to be added to the current manifest of the device driver bundle which completes the configuration of that module. Next, we create a new Plug-in Project within Eclipse. The default name of this project is AutoRestletBundle (we may use a different name but this would require small modifications to the bundle manifest during a later step). We make sure to deselect the Generate an Ac- tivator-check box and click Finish. Once the project is created, we select all folders within AutomaticPrototypes/OSGi-Restlet and move them to the top-level directory of the new project, thereby replacing the /src and /META-INF directories and adding the /lib, /OSGi-INF and /resources folders to the project. The IDE will display that it encountered errors which we remedy by adding the /lib directory (or the four jar files within it) to the build path of our project. Before we can run the OSGi framework with these two bundles, we have to set up a new Run Configuration for the project according to the instructions in Section A.1.1. When running this configuration, the two bundles will be started and the temperature sensors of all connected Sun SPOTs are now “out on the Web” at port 8081. To change the server port, use the Java class RestletConstants.
A.4 InfraWOT Manual
This manual contains instructions on how to set up and configure an infrastructure of Infra- WOT Smart Hubs. For successful setup and operation of the infrastructure, the InfraWOT- software itself and the GatewayConfigurator project are required. Note that InfraWOT cur- rently can only be launched from inside the Eclipse IDE due to ongoing issues when exporting the OSGi bundles. Launch InfraWOT within the Eclipse IDE by creating a new OSGi Frame- work Run Configuration for the project according to the instructions in A.1.1. We launch as many instances of the InfraWOT Smart Hub as we require on the local machine. Every hub will automatically determine an open port (from 9090 upwards) and start its Restlet-based web server.
Configuring InfraWOT There are two ways to use InfraWOT’s RESTful configuration mech- anism to configure an infrastructure of Smart Hubs: The first method is to configure the Smart Hubs by sending HTTP POST requests to their /infrastructure-endpoints. A possible request to configure a Switzerland-Smart Hub is:
10 " postal ":{ 11 "country":"Switzerland" 12 }, 13 "geographical":{ 14 "longitude":8.227512, 15 "latitude":46.818188 16 } 17 }, 18 "parent":"http://host1.net:9090", 19 "hostname":"http://host2.net" 20 } As the manual construction of such JSON strings can be tedious, we provide a program that wraps low-level configurations within so-called Scenarios that can be loaded into a swarm of InfraWOT hubs. This GatewayConfigurator provides three scenarios with the names Europe, SxSW and DepthTest that can be executed by providing the argument -scenario=scenarioName during startup of the program. These scenarios assume that all Smart Hubs are running on the same machine and thus take a second argument, -hostname=hostName that gives the hostname of that computer. As this will in most cases not be satisfactory, the Configurator program provides a way to support writing user-defined scenarios. To do this, first create the configurations for individual hubs within the ConfigurationService class (see the examples in there for details) and then build a new Scenario by creating a Java class that inherits from the Scenario class and implementing the void execute() method that specifies what config- uration is to load into which Smart Hub by specifying a single configure(url, parenturl, configuration instruction per hub that provides information on the URL of the Smart Hub itself, the URL of its parent node and the configuration to be loaded (set this to null if the hub represents the root node of a hierarchy):
1 public void execute() { 2 ConfigurationService configurator = new ConfigurationService();
In this chapter, we will introduce the RESTful API of an InfraWOT Smart Hub. We will detail the most important external interaction mechanisms for every relevant endpoint resource and give some interaction examples. For every single endpoint, several properties are given:
• The HTTP methods supported by the resource.
• A description of the answer returned for a GET request with the given accept property.
• A description of the action performed for a POST or PUT request containing content in the given multimedia type.
• A description of the action performed for a DELETE request.
• The potential HTTP response codes where 200 OK and 500 INTERNAL SERVER ERROR are omitted whenever they are not explicitly implemented but rather returned in response to an unexpected error.
B.1 Messaging Service REST API
/messaging/ is a common parent resource for messaging-related resources.
Supported Methods: GET
GET, text/html Generic description of the resource. GET, text/xml Generic description of the resource. GET, application/json Generic description of the resource.
/messaging/consumers/ manages a list of Information Consumers.
Supported Methods: GET, POST, DELETE
GET, text/html Resource description + web form. GET, text/xml Generic resource description. 88 InfraWOT REST API
PUT, x-www-form-urlencoded Create a new consumption. B.1. Messaging Service REST API 89
DELETE Delete a single consumption.
Possible answers: 204 NO CONTENT, 404 NOT FOUND
/messaging/consumers/(...)/{consumptionID}/{consumptionProperty} represents a single property of a consumption (e.g. an Information Consumer’s “phone number”).
Supported Methods: PUT, DELETE
PUT, text/plain Change the value of the property.
DELETE Clear the value of the property
Possible answers: 204 NO CONTENT, 404 NOT FOUND, 500 SERVER ERROR
/messaging/consumers/{consumerID}/channels/ manages the channels of an Information Consumer.
DELETE Clear the values of all properties of this channel
Possible answers: 204 NO CONTENT, 404 NOT FOUND
/messaging/consumers/{consumerID}/channels/{channelName}/{channelProperty}/ represents a property of a channel (e.g. the “twitter password” property). 90 InfraWOT REST API
Supported Methods: PUT, DELETE
PUT, text/plain Change the value of the property.
DELETE Clear the value of the property
Possible answers: 204 NO CONTENT, 404 NOT FOUND, 500 SERVER ERROR
B.2 Discovery Service REST API
/infrastructure/strategies/ is used to inject a new strategy to the Smart Hub’s discovery mechanism.
Supported Methods: POST
POST, application/json Inject a new discovery strategy.
Listing B.1: Discovery strategy injection example: This content in an HTTP POST request to the /strategies-endpoint creates a new discovery strategy that maps the parameter ”myurlidentifier” to the internal ”resourceurl” property.
/hubs/ manages the list of attached Smart Hubs.
Supported Methods: POST
GET, text/html Lots of information on the attached Smart Hubs. GET, text/xml Generic resource description. GET, application/json Generic resource description.
POST, text/plain Any string that can be handled by the Discovery.
Possible answers: 201 CREATED, 400 BAD REQUEST, 500 SERVER ERROR B.3. Others 91
/hubs/{hubID}/ represents a single attached Smart Hub.
Supported Methods: POST
POST, application/json A review of the attached Smart Hub.
Possible answers: 204 NO CONTENT, 404 NOT FOUND, 400 BAD REQUEST
Listing B.2: Smart Hub review example: This content in an HTTP POST request to the /hubs/{hubID}-endpoint causes InfraWOT to update the review of the hub with the corresponding ID. Specifically, it removes the tag ”Something”, adds the tag ”Cool Resource” and causes the rating ”1.8” to be aggregated into the total rating of the resource.
/resources manages the list of attached resources.
Supported Methods: POST
GET, text/html Lots of information on the attached resources. GET, text/xml Generic resource description. GET, application/json Generic resource description.
POST, text/plain Any string that can be handled by the Discovery.
Possible answers: 201 CREATED, 400 BAD REQUEST, 500 SERVER ERROR
/resources/{resourceID}
Supported Methods: POST
POST, application/json A JSON review of the attached resource.
Possible answers: 204 NO CONTENT, 404 NOT FOUND, 400 BAD REQUEST
B.3 Others 92 InfraWOT REST API
/ may be used to configure the Smart Hub. Supported Methods: GET, PUT, POST, DELETE
POST, x-www-form-urlencoded Configure the Smart Hub.
DELETE Clear the configuration of the Smart Hub.
1 { 2 "resourceurl":"http://hostname:9090", 3 "uuids":[{"uuidtype":"infrawot","uuidvalue":"europe"}], 4 "name":"InfraWOT Gateway, Europe", 5 "context":{ 6 "hierarchical":{"hierarchystring":"europe/"," hierarchydelimiter":"/"}, 7 "postal":{}, 8 "geographical":{"longitude":15.254517,"latitude":54.525864} 9 } 10 } Listing B.3: Smart Hub configuration example: This content in an HTTP PUT request to the /infrastructure-endpoint configures the corresponding Smart Hub. To configure a Smart Hub using an x-www-form-urlencoded HTTP POST request, add the parameter ”jsonconfiguration=” at the start of the content.
/infrastructure may be used to configure the Smart Hub. Supported Methods: POST, DELETE
POST, x-www-form-urlencoded Configure the Smart Hub.
DELETE Clear the configuration of the Smart Hub.
/querying is the querying endpoint of an InfraWOT Smart Hub. Supported Methods: GET, POST
POST, x-www-form-urlencoded Submit a query. Appendix C Class Diagrams
In this appendix, we will present UML class diagrams to aid in the further development of the software developed during this thesis. The classes shown in the diagrams represent the most important parts of their respective projects.
[1] Azucena Guill´enAguilar. Exploring Physical Mashups on Mobile devices. Master’s thesis, Departement of Computer Science, ETH Zurich, 2010.
[2] Neil Bartlett. Getting Started with OSGi: Introducing Declarative Services. Online at http://www.eclipsezone.com/eclipse/forums/t96740.html, 2007.
[3] Tim Berners-Lee. Universal resource identifiers in WWW. Online at http://tools.ietf. org/html/rfc1630, 1994.
[4] Dan Cederholm and Tantek C¸elik. Microformats Launch Definition. Online at http: //microformats.org/wiki/what-are-microformats, 2005.
[5] Gong Chen, Nathan Yau, Mark Hansen, and Deborah Estrin. Sharing Sensor Network Data. Technical report, University of California Los Angeles (UCLA), March 2007.
[6] Vlatko Davidovski. A Web-oriented Infrastructure for Interacting with Digitally Aug- mented Environments. Master’s thesis, Departement of Computer Science, ETH Zurich, 2010.
[7] Philippe Debaty, Patrick Goddi, and Alex Vorbau. Integrating the Physical World with the Web to Enable Context-Enhanced Mobile Services. MONET, 10(4):385–394, 2005.
[8] Edsger W. Dijkstra. Self-stabilizing systems in spite of distributed control. Commun. ACM, 17(11):643–644, 1974.
[9] Shlomi Dolev and Ted Herman. Superstabilizing protocols for dynamic distributed systems. Chicago Journal of Theoretical Computer Science, 1997(4), December 1997.
[10] Witold Drytkiewicz, Ilja Radusch, Stefan Arbanowski, and Radu Popescu-Zeletin. pREST: a REST-based protocol for pervasive systems. In Proc. of the IEEE International Confer- ence on Mobile Ad-hoc and Sensor Systems, pages 340–348, Oct. 2004.
[11] Roy T. Fielding. Architectural Styles and the design of Network-based Software Architec- tures. PhD thesis, University of California, Irvine, 2000.
[12] Roy T. Fielding. REST APIs must be hypertext-driven. Online at http://roy.gbiv. com/untangled/2008/rest-apis-must-be-hypertext-driven, 2008.
[13] Elgar Fleisch and Friedemann Mattern. Das Internet der Dinge: Ubiquitous Computing und RFID in der Praxis: Visionen, Technologien, Anwendungen, Handlungsanleitungen. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2005. 100 BIBLIOGRAPHY
[14] Erich Gamma, Richard Helm, Ralph E. Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.
[15] S. Geary, S.M. Disney, and D.R. Towill. On bullwhip in supply chains–historical review, present practice and expected future impact. International Journal of Production Eco- nomics, 101(1):2–18, May 2006.
[16] Network Working Group. Hypertext Transfer Protocol – HTTP/1.1. Online at http: //tools.ietf.org/html/rfc2616, 1999.
[17] Network Working Group. Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence. Online at http://tools.ietf.org/html/rfc3921, 2004.
[18] Network Working Group. The application/json Media Type for JavaScript Object Notation (JSON). Online at http://tools.ietf.org/html/rfc4627/, 2006.
[19] Dominique Guinard, Mathias Fischer, and Vlad Trifa. Sharing Using Social Networks in a Composable Web of Things. In Proceedings of the 1st IEEE International Workshop on the Web of Things (WoT 2010) at IEEE PerCom 2010, Mannheim, Germany, March 2010.
[20] Dominique Guinard and Vlad Trifa. Towards the Web of Things: Web Mashups for Embedded Devices. In Workshop on Mashups, Enterprise Mashups and Lightweight Com- position on the Web (MEM 2009), in proceedings of WWW (International World Wide Web Conferences), Madrid, Spain, April 2009.
[21] Dominique Guinard, Vlad Trifa, Thomas Pham, and Olivier Liechti. Towards Physical Mashups in the Web of Things. In Proceedings of INSS 2009 (IEEE Sixth International Conference on Networked Sensing Systems), Pittsburgh, USA, June 2009.
[22] Dominique Guinard, Vlad Trifa, and Erik Wilde. Architecting a Mashable Open World Wide Web of Things. Technical Report 663, Institute for Pervasive Computing, ETH Zurich, February 2010.
[23] Dominique Guinard, Markus Weiss, and Vlad Trifa. Are you Energy-Efficient? Sense it on the Web! In Adjunct Proceedings of Pervasive 2009 (International Conference on Pervasive Computing), Nara, Japan, May 2009.
[24] Usman Haque. Pachube. Online at http://www.haque.co.uk/pachube.php, 2004.
[25] Soojung Hong. Mobile Discovery in a Web of Things. Master’s thesis, Departement of Computer Science, ETH Zurich, In progress, 2010.
[26] Jonathan W. Hui and David E. Culler. Extending IP to Low-Power, Wireless Personal Area Networks. IEEE Internet Computing, 12:37–45, 2008.
[27] Andreas Kamilaris. Web Service Enabled Gateway for Low-Power Mobile Devices. Mas- ter’s thesis, Departement of Computer Science, ETH Zurich, 2009.
[28] Aman Kansal, Suman Nath, Jie Liu, and Feng Zhao. SenseWeb: An Infrastructure for Shared Sensing. Multimedia, 14(4):8–13, 2007. BIBLIOGRAPHY 101
[29] Jacek Kopeck´y,Karthik Gomadam, and Tomas Vitvar. hRESTS: An HTML Microformat for Describing RESTful Web Services. Web Intelligence and Intelligent Agent Technology, IEEE/WIC/ACM International Conference on, 1:619–625, 2008.
[30] Jacek Kopeck´y,Tomas Vitvar, and Dieter Fensel. MicroWSMO: Semantic Description of RESTful Services. Online at http://www.wsmo.org/TR/d38/v0.1/, 2008.
[31] Thomas Luckenbach, Peter Gober, Stefan Arbanowski, Andreas Kotsopoulos, and Kyle Kim. TinyREST - A protocol for Integrating Sensor Networks into the Internet. In Proceedings of REALWSN, 2005.
[32] Sami M¨akel¨ainenand Timo Alakoski. Fixed-Mobile Hybrid Mashups: Applying the REST Principles to Mobile-Specific Resources. In WISE ’08: Proceedings of the 2008 interna- tional workshops on Web Information Systems Engineering, pages 172–182, Berlin, Hei- delberg, 2008. Springer-Verlag.
[33] Craig McClanahan. Why HATEOAS? Online at http://blogs.sun.com/craigmcc/ entry/why_hateoas, 2009.
[34] Mathias M¨uller. RESTful EPCIS - Design and Implementation of a Web-enabled Elec- tronic Product Code Information Service (EPCIS). Master’s thesis, Departement of Infor- matics, University of Fribourg, 2009.
[35] Noelios Technologies. RESTlet - an Open-Source Java REST framework. Online at http: //www.restlet.org, 2005.
[36] Tim O’Reilly. What Is Web 2.0. Design Patterns and Business Models for the Next Generation of Software. Online at http://www.oreillynet.com/pub/a/oreilly/tim/ news/2005/09/30/what-is-web-20.html, 2005.
[37] Cesare Pautasso, Olaf Zimmermann, and Frank Leymann. RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision. In 17th International World Wide Web Conference (WWW2008), Beijing, China, April 2008.
[38] Leonard Richardson and Ruby Sam. RESTful Web Services. O’Reilly Media, Inc, Se- bastopol, CA, USA, First edition, May 2007.
[39] Fabian Schlup. Design and Implementation of a Framework for the Web of Things. Mas- ter’s thesis, Departement of Computer Science, ETH Zurich, 2009.
[40] Amit P. Sheth, Karthik Gomadam, and Jon Lathem. SA-REST: Semantically Interoper- able and Easier-to-Use Services and Mashups. IEEE Internet Computing, 11:91–94, 2007.
[41] Andrew S. Tanenbaum. Computer Networks. Pearson Education, Inc, Upper Saddle River, NJ, USA, Fourth edition, 2003.
[42] The OSGi Alliance. OSGi Technology. Online at http://www.osgi.org/About/ Technology.
[43] Vlad Trifa, Dominique Guinard, Philipp Bolliger, and Samuel Wieland. Design of a Web- based Distributed Location-Aware Infrastructure for Mobile Devices. In Proc. of the First IEEE International Workshop on the Web of Things (WOT2010), Mannheim, Germany, March 2010. 102 BIBLIOGRAPHY
[44] Vlad Trifa, Samuel Wieland, Dominique Guinard, and Thomas M. Bohnert. Design and Implementation of a Gateway for Web-based Interaction and Management of Embedded Devices. In Proceedings of the 2nd International Workshop on Sensor Network Engineering (IWSNE 09), Marina del Rey, CA, USA, June 2009.
[45] Juan I. Vazquez, Aitor Almeida, Iker Doamo, Xabier Laiseca, and Pablo Ordu˜na. Flexeo: An Architecture for Integrating Wireless Sensor Networks into the Internet of Things, vol- ume 51/2009 of Advances in Soft Computing, pages 219–228. Springer Berlin / Heidelberg, September 2009.
[46] Mark Weiser. The Computer for the 21st Century. Scientific American, February 1991.
[47] Samuel Wieland. Design and Implementation of a Gateway for Web-based Interaction and Management of Embedded Devices. Master’s thesis, Departement of Computer Science, ETH Zurich, 2009.
[48] Erik Wilde. Putting Things to REST. Technical report, UCB iSchool Report 2007-015, School of Information, UC Berkeley, 2007.
[49] Erik Wilde. Location management for mobile devices. In WOWMOM ’08: Proceedings of the 2008 International Symposium on a World of Wireless, Mobile and Multimedia Networks, pages 1–8, Washington, DC, USA, 2008. IEEE Computer Society.
