The vision of Ambient Intelligence cannot be realized without integrating heterogeneous sensor and actuator networks in a framework of global scale that makes them available via unified service interfaces. Integration of these things into the Web has not been done on such a large scale and the effects on finding and interacting with physical resources are not known. This paper presents a scalable discovery mechanism, augmented with semantic web elements, based on RESTful principles that enables a plug and play experience for heterogeneous sensor and actuator networks in the “Web of Things”. 1. Introduction
Networked sensors and actuators will play a vital role in realizing the vision of Ambient Intelligence, where services and application self-react to people’s presence and the physical environment they are in. Deployed everywhere, inside private or public buildings, outdoor environment, on the body of users or embedded in objects such as vehicles, clothes, books or any other goods; wired or wirelessly connected they provide the fabric that allows networked applications and computing systems to interact with the physical world. Predictions foresee that the number of sensors and actuators attached to the network of the future will exceed the number of network computers by several orders of magnitude [1]. To achieve this ubiquity goal, the capabilities of sensors and actuators must be integrated in a scalable manner into the wider Internet ecosystem and exposed to an "open market" for increased added value services creation.
Up to now, the sensors and actuator networks (SAN) have been generally investigated as dedicated systems with particular environments in mind, typically closed and interacting over proprietary interfaces. These design decisions, although efficient for the target environment, have led to vertical
solutions that are difficult to adapt and reuse in alternative environments. Opening up these systems is essential to enable an ecosystem for context information and actuation services that allows creation of horizontal solutions across different application domains.
The objective of this paper is to provide an overview of the system that will enable heterogeneous SANs to expose their sensing (sensor based context information) and actuation (the ability to act upon the environment and entities within it) capabilities in a plug and play fashion, thus creating the "open market" for creation of increased added value context aware services. At the core of the system sits a middleware that defines a set of constraints, support services and interaction patterns that follow the REST architectural style principles [2].
This paper is structured as follows. Section 2 provides an overview of work already done on enabling unified access interfaces to physical objects. Section 3 describes the main concepts of the global heterogeneous SAN framework. Section 4 outlines the building blocks of a plug and play experience and their realization using the architectural principles of the Web. Section 5 presents an apparatus for scalable discovery using simple discovery relationships. Section 6 presents areas that need further investigation. Concluding remarks are provided in section 7. 2. Background and related work
The following section describes existing web technologies and methodologies relevant for scenarios where context-aware applications interact with the physical world. 2.1. Web Services
The Web Services contain a set of protocols that allow clients and servers to communicate using XML messages that follow the SOAP standard [17]. The assumption is that there is also a machine-readable
The IEEE International Conference on Semantic Computing
description of the operations supported by the server using the Web Services Description Language (WSDL) [18]. Web Services can be used in remote procedure call (RPC) or service-oriented architecture (SOA). Both approaches use the Web as a transport infrastructure and attempt to directly map existing concepts in building middleware and distributed system as extensions of the basic SOAP/WSDL model. The problems with the already large number of Web Services additions have roots in the world of tightly coupled distributed systems. Only the peers supporting a complex set of technologies can interact with the system.
In the space of Web Services, the Device Profiles for Web Services (DPWS) [16] and UPnP [15] are attempts to provide unified access interfaces to instances of physical objects.
The approach is appropriate in some scenarios, but we argue that the scalability goal for the heterogeneous SAN framework can be achieved through loose coupling and low entry barriers. 2.2. REST architectural style
The Representational State Transfer (REST) architectural style proposes to design application in such a manner that their functionality is implemented as a set of resources that can be referred to using an URI identifier. Clients interact with the application resources via the GET, PUT, POST and DELETE methods provided by the HTTP protocol [12] to exchange well defined representations of them. Resources are stateless (no state between requests) and loosely coupled (no relationships with other resources). 2.3. The “Internet of Things”
The term “Internet of Things” [13] describes a vision in which networks and networked devices are omnipresent and provide relevant content and information whatever the location of the user. Advances in computing power, miniaturization and nanotechnology will accelerate the integration of everyday physical object with communication networks; everything from tires to toothbrushes will be in communication range. Sensors and actuators will play an essential role in realizing this vision. 2.4. The “Web of Things”
While the “Internet of Things” establishes the transport capabilities that allow networked applications and computing systems to interact with the physical world, the “Web of Things” proposes to integrate the
networked “Things” into the Web, thus making them available as resources via standard Web mechanisms.
The advantage of this integration approach is that the “Things” are like any other Web resources. Further, the REST architectural style provides the low entry barrier that enables the loosely coupled “Things” to be reused in different contexts and applications. 3. System concepts
In this section we provide an overview of the global heterogeneous sensor and actuator networks (SAN) system, its logical components, and the interactions among them. Additionally, we will have a detailed look at the nature of SAN islands attached to the global SAN system. 3.1. System overview
The global SAN system is composed of heterogeneous SAN islands and a scalable architectural framework that allows easy integration of these islands into a global infrastructure via the plug and play SAN island interface.
SAN islands are deployed at the proximity of the real world entities (e.g. people, places, things) and phenomena. They are expected to be highly heterogeneous, thus reflecting the specialization and complexity of the physical world environment they reside in. The islands provide the means for direct interaction between the physical world and the networked applications and computing.
!"#$
%&'()*$
!"#$
%&'()*$
!"#$
%&'()*$
+%,-.('$
!"#$
%&'()*$
/0)-12-$
"3(,1$
!1,4%51&$
/0)-12-$
"3(,1$
!1,4%51&$
/0)-12-$
"3(,1$
!1,4%51&$
6'07('$!"#$8,(9130,:$
!1,4%51$
";<$
;);$!"#$<&'()*$
";<$
Figure 1. Global SAN system concept
The global SAN framework provides mechanisms
and protocols to ensure the scalable integration and management of large numbers of SAN islands. It facilitates the communication and information exchange between the SAN islands and context aware
530513
services, and enables an open market space for context-awareness and real world interactions.
Context aware services are able to access information and actuation services through unified interfaces via the global SAN framework. They may use the raw sensor information and simple actuation tasks provided by SAN islands to produce high level context information, more complex actuation tasks and control loops. Some of these may be provided back into the global SAN framework in the shape of virtual SAN islands. Additionally, it is expected that some of the SAN islands will have built-in context processing capabilities. 3.2. The SAN islands
The SAN island is the logical component of the system that resides closest to the physical world. The nature of the SAN islands varies considerably depending on specific requirements for the environment in which they are deployed. In the context of this paper, the only criterion for categorizing the SAN islands is the addressability from the wider Internet of the nodes hosting the sensors and actuators.
Some of the SAN nodes have the networking capabilities to be directly accessible from the Internet while others have just the capabilities that allow them to interact only with other nodes in the local SAN island. The nodes in the second category require the mediation of a service gateway to enable interaction with non-local entities over Internet.
Figure 2. SAN islands
The SAN operators can choose the sensors and
actuator infrastructure that suits their environment best leading to deployments of SAN islands having all nodes directly addressable, all nodes addressable via a service gateway, or a hybrid model combining the two options.
3.4. The global SAN framework
The global SAN framework is the component that facilitates the interaction between the SAN providers and the context aware service providers. These providers are interacting following commercial, social or other types of relationships existing between them in the physical worlds. Some of these relationships are long lasting while others are temporary. Some context aware services may use information provided by several SAN islands or interact with actuators located in different SAN islands in order to complete an actuation task.
The SAN island providers can use the virtual SAN island concept to provide back into the system high-level context information or complex actuation tasks that can be used by other context aware services to produce higher levels of abstractions for the context information or more complex actuation tasks.
The framework should provide the necessary information management, security and trust, privacy and accounting mechanisms and protocols that allow the realization of the above-mentioned interactions, leading to the creation of hierarchical, federated or peer overlays. 3.5. The virtual SAN island
The virtual SAN island is a flexible tool that allows context aware services to make available back into the system abstract context information or more complex actuation tasks.
Inside a virtual SAN island, the service provider can interact with 3rd party services that provide context information that cannot be obtained directly from a SAN island, e.g. a weather forecast service. Is it possible that large service providers are deploying an internal architecture that resembles at micro-scale the global SAN framework. 4. Putting Plug and Play into the “Web of Things”
This section describes the support infrastructure that will make the SAN islands to behave in a plug and play fashion when being part of the “Web of Things”. 4.1. Building blocks of Plug and Play Experience
A plug and play experience is obtained when all the parties involved in the ecosystem conform to a common set of conventions on how resources are named, how they are discovered, how clients can
531514
interact with entities providing services and, depending on the case, how event notifications are deliver to the consumers.
Figure 3. Building blocks of plug and play experience 4.2. Representing Things
For the “Web of Things”, the sensors and actuators
are all represented as resources. In the previous section, we have introduced the concept that sensors and actuators can be directly addressable or accessible via a service gateway. As a convention, the resources available on nodes that are directly accessible can have URIs like http://a-sensor.example.com/, while resources available via the service gateway are modeled as available under the service gateway realm http://servicegateway.example.net/sensors/a-sensor/.
4.3. Discovering Things
The discovery process is build around a Resource Repository that keeps context information about the capabilities of the sensors and actuators available. The Resource Repository is represented as a feed compliant with the Atom syndication format [7].
Sensor and actuators publish essential information about their nature as well as where the resource can be accessed using the Atom publishing protocol (AtomPub) [8]. For example, a sensor that is added to the SAN island will send an AtomPub POST request to the Resource Repository to create a new entry in the feed. The sensor must include in the request the resource URI and the sensor type. Additional information that improves narrowing the results of a search query (e.g. node location) may be included as “tag” elements:
it provides context information about the “Web of Things” by publishing an OpenSearch [10] description document that indicates its search capabilities and how they can be used. In the following example the Resource Repository accepts search queries having parameters “type” and “loc”:
capabilities search the Resource Repository for resources of interest via the OpenSearch interface. The response is an Atom feed pointing to the available resources matching the search criteria. For example to find the sensor published earlier, a consumer sends to the Resource Repository the following query:
While the inner works of the APIs used to interact with the sensors and actuators conform to the REST architectural style, it is worth mentioning that these APIs will typically use HTTP GET method to obtain sensor information and HTTP POST method for sending actuation tasks to actuators.
More complex sensors and, especially, actuators may have their APIs documented using machine-readable languages like Web Application Description Language (WADL) [9]. 4.5. Notifications from Things
There are situations where a resource representation cannot be returned immediately. In such a case, blogging ping mechanisms (e.g. Weblogs Update Ping [11]) can be used to get notifications when resources representations change or become available.
532515
5. Scalability by discovery relationships
As the goal for the framework is to scale globally, we need to pay special attention to how the discovery is done. We propose a strategy to partition the discovery along the administrative domains of the entities that are managing the resources. The end result is a two-step discovery process, the first one at the SAN island level and the second one at framework level.
Typically, SAN islands deploy specific link layer technologies that are very effective at discovering sensors and actuators for which the access is mediated by the SAN service gateway. In such cases the gateway itself is publishing information to the Resource Repository (1). The SAN nodes that have the ability to be accessed directly can use local service discovery protocols [14] to find the resource URI and the service type of the Resource Repository and to publish the information about their capabilities using the AtomPub protocol (1).
The complex business interactions existing in the physical world between the providers of SAN islands and the providers of context aware services must be modeled in the discovery relationships at framework layer.
Figure 4. Discovery relationships
The key concept in establishing relationships
between different discovery domains is the Resource Repository, which itself is a regular Web resource. An aggregation relationship can be easily established by creating a new entry in the Resource Aggregator feed using the AtomPub protocol. The newly created entry points to the aggregated Resource Repository (2). Similarly, two Resource Repositories can create a federation relationship (3) by each creating a new entry in the corresponding repository.
Discovery relationships are private agreements between the search domain operators and do not have to be revealed to third parties. A Resource Repository
searches only the Resource Repositories that has relationships with. Furthermore, relationships have certain restrictions (described in the OpenSearch description document via the SyndicationRight element) that determine how the receiving party handles the information. In this context we are interested only in the open and private restrictions, meaning that the receiving Resource Repository is allowed to forward search results to other repositories or they can use the received information only for the consumers in their own search domain.
Having the discovery relationships established, the Resource Repositories can include in the responses to locally received search queries information about resources that are available on other Resource Repositories.
Aggregation and federation relationships can be chained to emulate more complex relationships that often exist in the physical world. For example, in Figure 5 we describe an environment where we have two open discovery aggregation relationships (e.g. RR3-to-RR2 and RR2-to-RR1) and one private discovery aggregation relationship (e.g. RR4-to-RR 2). In this environment, the search space for Consumer 1 is formed of RR1, RR2 and RR3 while for Consumer 2 it is formed of RR2, RR3 and RR4.
Figure 5. Discovery environment example 6. Future Work
The principles and technologies used in this paper although compliant with the REST architectural style are still under active research. The following areas can be identified as needing further study.
The handling of the resources on the Web assumes that they are conceptual entities. In the “Web of Things” there are a large number of physically instantiated Web resources that have a set of specific characteristics: they have location, they cannot be replicated, they cannot be cached. To enable the plug and play experience in an environment where large numbers of physical objects are mobile, the discovery infrastructure needs to react fast to reflect the changes in the physical world. Even if the Resource Repositories are conceptual entities, the nature of the context information maintained there raises the
533516
question if they behave closer to physically instantiated resources, so far there is only little work in this area.
Resource discovery performance can be improved significantly if consumers are able to include in the search queries specific capabilities of the sensors and actuators of interest. Formats such as OWL [20] and RDF [19] provide ways to semantically describe and align disparate resources. However, the current lack of uniform taxonomy or ontology to describe, in a lightweight manner, the capabilities of the sensors and actuators may lead to an inconsistent model. While the REST APIs provided by the sensors and actuators can be easily represented with unique URIs, work should start in identifying the key capabilities that are relevant for resource discovery so they can be included in the information published to the feeds. 7. Conclusions
This paper outlines an approach for using the architectural model of the Web, especially the Representational State Transfer (REST), to create a semantically augmented scalable discovery infrastructure that enables a plug and play experience for the heterogeneous sensor and actuator networks (SAN) that form the fabric of the “Web of Things”. We argue that the loose coupling approach, that worked remarkably well for the Web, should not be limited to requesting resource representation from the services of interest [4][5], but be used to model also the interactions with support resources that contribute to the creation of the plug and play experience. 8. Acknowledgements
We would like to thank Prof. Tommi Mikkonen, from Tampere University of Technology, and Christian Prehofer for their valuable feedback and comments. 9. References [1] D. Clark et al., “Making the World (of Communications) a Different Place”, End-to-End Research Group, IRTF, ACM SIGCOMM Computer Communication Review, Vol. 35, No. 2, pp. 91-96, July 2005. [2] Roy Thomas Fielding, “Architectural Styles and the Design of Network-based Architectures”, PhD thesis, University of California, Irvine, Irvine, California, 2000. [3] Erik Wilde, “Putting Things to REST”, UCB iSchool Report 2007-015, School of Information, UC Berkeley, November 2007 [4] Y. Kawahara, N. Kawanishi, M. Ozawa, H. Morikawa, and T. Asami, “Designing a Framework for Scalable
Coordination of Wireless Sensor Networks, Context Information and Web Services”, 27th International Conference on Distributed Computing Systems Workshops ICDCSW '07, 2007.pp. 44-44. [5] C. Prehofer, J. van Gurp, and C. di Flora, “Towards the Web as a Platform for Ubiquitous Applications in Smart Spaces”, Second Workshop on Requirements and Solutions for Pervasive Software Infrastructures (RSPSI), at UBICOMP 2007, Innsbruck, 16-19 Sebtember, 2007. [6] T. Berners-Lee, R.T. Fielding, and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, Internet Engineering Task Force, RFC 3986, January 2005. [7] M. Nottingham, R. Sayre, “The Atom Syndication Format”, Internet Engineering Task Force, RFC 4287, December 2005. [8] J. Gregorio, B. de hOra, “The Atom Publishing Protocol”, Internet Engineering Task Force, RFC 5023, October 2007. [9] M. Hadley, “Web Application Description Language (WADL)”, https://wadl.dev.java.net/wadl20061109.pdf, November 2006. [10] OpenSearch 1.1 (Draft 3), available online at http://www.opensearch.org/Specifications/OpenSearch/1.1. [11] WeblogsUpdate.Ping API, http://www.weblogs.com/api.html [12] R. Fielding, et al., “Hypertext Transfer Protocol -- HTTP/1.1”, Internet Engineering Task Force, RFC 2616, June 1999 [13] “The Internet of Things”, ITU Internet Reports, 2005 [14] S. Chishire, M. Krochmal, “Multicast DNS”, draft-cheshire-dnsext-multicastdns-06.txt, August 2006 [15] UPnP: http://www.upnp.org [16] Devices Profile for Web Services, 2006 [17] N. Mitra, Y. Lafon, “SOAP Version 1.2 Part 0: Primer (Second Edition)”, W3C Recommendation REC-soap12-part0-20070427, April 2007 [18] R. Chinnici, M. Gudgin, J-J. Moreau, S. Weerawarana, “Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language”, W3C Recommendation REC-wsdl20-20070626, June 2007 [19] D. Beckett (Ed.), “RDF/XML Syntax Specification (Revised)”, W3C Recommendation REC-rdf-syntax-grammar-20040210, February 2004 [20] D. L. McGuinness, F. van Harmelen, “OWL Web Optology Language Overview”, W3C Recommendation REC-owl-features-20040210, February 2004
![Page 1: [IEEE 2008 Second IEEE International Conference on Semantic Computing (ICSC) - Santa Monica, CA, USA (2008.08.4-2008.08.7)] 2008 IEEE International Conference on Semantic Computing](https://reader030.documents.pub/reader030/viewer/2022020409/575096a41a28abbf6bcc6005/html5/thumbnails/1.jpg)
![Page 2: [IEEE 2008 Second IEEE International Conference on Semantic Computing (ICSC) - Santa Monica, CA, USA (2008.08.4-2008.08.7)] 2008 IEEE International Conference on Semantic Computing](https://reader030.documents.pub/reader030/viewer/2022020409/575096a41a28abbf6bcc6005/html5/thumbnails/2.jpg)
![Page 3: [IEEE 2008 Second IEEE International Conference on Semantic Computing (ICSC) - Santa Monica, CA, USA (2008.08.4-2008.08.7)] 2008 IEEE International Conference on Semantic Computing](https://reader030.documents.pub/reader030/viewer/2022020409/575096a41a28abbf6bcc6005/html5/thumbnails/3.jpg)
![Page 4: [IEEE 2008 Second IEEE International Conference on Semantic Computing (ICSC) - Santa Monica, CA, USA (2008.08.4-2008.08.7)] 2008 IEEE International Conference on Semantic Computing](https://reader030.documents.pub/reader030/viewer/2022020409/575096a41a28abbf6bcc6005/html5/thumbnails/4.jpg)
![Page 5: [IEEE 2008 Second IEEE International Conference on Semantic Computing (ICSC) - Santa Monica, CA, USA (2008.08.4-2008.08.7)] 2008 IEEE International Conference on Semantic Computing](https://reader030.documents.pub/reader030/viewer/2022020409/575096a41a28abbf6bcc6005/html5/thumbnails/5.jpg)
![Page 6: [IEEE 2008 Second IEEE International Conference on Semantic Computing (ICSC) - Santa Monica, CA, USA (2008.08.4-2008.08.7)] 2008 IEEE International Conference on Semantic Computing](https://reader030.documents.pub/reader030/viewer/2022020409/575096a41a28abbf6bcc6005/html5/thumbnails/6.jpg)
