This section presents QoDisco, our QoC-aware discovery service for the IoT. Section 2.1 describes the QoDisco architecture. Section 2.2 details the synchronous and asynchronous search processes that can be performed using QoDisco. Section 2.3 describes the information model used to describe IoT resources, services, and QoC information. Section 2.4 presents a prototype implementation of our proposal. Further information about QoDisco is publicly available at http://consiste.dimap.ufrn.br/projects/qodisco/.
2.1 Architecture
QoDisco relies on a collection of repositories to perform discovery tasks. This approach provides several advantages over using a single repository, mainly scalability, fault-tolerance, independent control of repositories, and data distribution [22]. In the context of this work, QoDisco clients can be: (i) IoT devices and gateways publishing resources; (ii) applications searching for records, i.e., descriptions of resources, services and context data in repositories; or (iii) record repositories accessible through QoDisco. For becoming available through QoDisco, each repository must provide operations for both querying and updating records as defined by its Repository API.
After receiving a discovery request containing a domain name and a query, QoDisco searches for records stored in the repositories pertaining to the domain specified by the client. In this work, a domain is an area of knowledge specified through an ontology document, called repository domain ontology (RDO) document. Figure 1 illustrates the modules composing the QoDisco architecture, described as follows.
The Ontology Module consists of repository domain ontology (RDO) documents describing the concepts composing the information model of QoDisco. In this module, the Ontology Manager provides operations for adding, removing, and modifying RDO documents, whereas the QoC Criteria Manager is responsible for adding, removing, and modifying QoC criteria (also defined in RDO documents). A QoC criterion represents an attribute that qualifies a context information (e.g., accuracy, up-to-dateness) and it can be calculated in different ways according to the situation in which it is used. In QoDisco, QoC criteria are described through ontologies to allow for unambiguous identification and representation.
The Repository Module manages repositories and maps each one to (a group of) specific RDO document(s) in the Ontology Module. As the search and management of records is based on domains, a repository joining QoDisco has to be mapped to at least one domain specified by an RDO document and multiple repositories can be mapped to the same domain by their respective owners.
The Record Manager is responsible for adding, removing, and modifying records in repositories. As repositories maintain their operational and managerial independence, their owners can manage their own records independently from QoDisco. Nonetheless, the information model of QoDisco (see Section 2.3) is shared among all of these repositories.
The Search Module encompasses the Query Mediator, which forwards queries to the repositories belonging to QoDisco. To perform the search, this component specifies an RDO document name (i.e., domain name) to the Repository Manager, which provides the IP addresses and port numbers of the repositories mapped to the domain.
The Operation Module encompasses five components. The Request Handler receives requests to search and manage repositories and records for both synchronous and asynchronous operation modes. The Synchronous Search Handler performs requests by querying the Query Mediator. The Asynchronous Search Handler notifies clients (i) about the discovery of a new resource matching the search query and (ii) about the modification or removal of a resource description. The Repository Manager Handler and the Record Manager Handler respectively interact with the Repository Manager and the Record Manager to add/remove repositories and records.
The functionalities of the Operation Module and the Ontology Module are provided through the Client Interface. This interface operations regard both synchronous and asynchronous operations as well as the management (insertion, removal, update) of records, repositories, RDO documents, and QoC criteria. More information on the Client Interface is also available at http://consiste.dimap.ufrn.br/projects/qodisco/.
2.2 Interaction patterns
Due to the dynamic context where the IoT resources operate, a discovery service in IoT should be able to handle both synchronous calls and asynchronous notifications [23, 24]. The former relies on request-reply interactions towards providing resource information at the moment of the search whereas the latter are based on publish-subscribe interactions to notify clients in case of resource removal, insertion or update.
The synchronous operation follows the simple request-reply message exchange pattern. This process starts with a client request containing the query and a domain name to be searched for. QoDisco identify the repositories that pertain to the specified domain and sends requests to all the matching repositories. Each requested repository searches on its own set of records and returns a response with the set of results. Finally, QoDisco combines all results returned by each repository and sends them to the client as a single response. Figure 2 illustrates an example of this process with the Air Pollution domain. In this example, only repositories matching the domain name specified by the client are searched by QoDisco, i.e., repositories one and three.
The publish-subscribe interaction pattern fosters loose coupling and scalability. In many implementations of this model, information producers (publishers) send messages to a topic from which information consumers (subscribers) interested into such a topic receive all published messages as notifications [25]. This is managed by an intermediary message broker (a.k.a. event bus) that uses a store-and-forward technique to route messages from publishers to subscribers. Figure 3 illustrates this process, which encompasses the following steps:
-
(1)
The client makes a request to the QoDisco API with a query and a domain name identifying the records of interest; QoDisco stores both query and domain name and sends a response containing the address of the broker within the Asynchronous Search Handler and a topic name created to identify the client request;
-
(2)
The client subscribes to the broker by sending the topic name provided by QoDisco;
-
(3)
Whenever a record insertion operation is requested, QoDisco verifies if such a record meets both query and domain specified by other clients; and
-
(4)
QoDisco notifies the new record to interested clients through the broker contained in the Asynchronous Search Handler.
2.3 Information model
The information model of QoDisco is depicted in Fig. 4. It comprises an ontology-based vocabulary of concepts related to IoT resources and services, relationships among them, and QoC-related information. To semantically describe resources, such an information model takes advantage of the SAN ontology [26], an extension of the W3C’s SSN ontology [27] that provides concepts, attributes, and properties to model both sensors and actuators. Additionally, we have incorporated part of the SOUPA ontology [28] aiming at including location-related concepts to describe location-related information (e.g., latitude, longitude, altitude, distance, surface) as well as symbolic representations of space and spatial relationships, being associated with both resources and data (observations).
The QoDisco information model also comprises the OWL-S ontology [29], which has been widely used in both academia and industrial applications for semantically modeling Web services. To represent the relationship between resources and services, we have created the exposes property, which links the Sensor and Actuator concepts (representing resources) to the Service concept (representing services), as shown in Fig. 4.
To cope with QoC-related concerns, we have incorporated part of the QoCIM meta-model [30] by describing its concepts as an ontology. The QoC Criterion concept can be used to represent a QoC parameter associated with context data, e.g., accuracy, precision, completeness, up-to-dateness. In turn, the QoC Indicator concept expresses the QoC level of an observation (measured data) made by a resource. In the QoDisco information model, the has_qoc property associates a QoC level (QoC Indicator concept) to an observation made by a resource (SensorOutput concept) whereas the qoc_criterion property indicates that a QoC indicator must be associated with a QoC criterion. This information model follows the same flexible ideology as QoCIM, i.e., defining a basis to design and represent any QoC criterion instead of providing a predefined list of supported QoC criteria. Moreover, a given QoC criterion can be built upon other primitive or composed QoC criteria.
2.4 Implementation
QoDisco is implemented as a Web application using the Java programming language and the Spring framework, being deployed to an Apache Tomcat server. Spring provides support for multithreading using a thread pool, which was required towards implementing the parallel search request to the repositories (see Section 2.2). For the sake of performance, QoDisco uses multithreading facilities to throw searches in parallel.
In the current implementation of QoDisco, search queries are specified in SPARQL [31], a semantic query language standardized by W3C for information retrieval. SPARQL supports both multi-attribute and range queries over documents in OWL, the W3C’s recommended language to semantically describe ontologies. SPARQL is one of most popular approaches for discovery services due to its relative simplicity of implementation, besides being an open standard. Experimental results reported by Bröring et al. [32] recommend the use of SPARQL for discovery services based on directories (such as QoDisco) since it provides queries with richness and result ranking. In particular, search queries in QoDisco comply with SPARQL 1.1, the latest version made available by W3C.
The underlying infrastructure for Operation, Search, Repository, and Ontology Modules is implemented using Apache Jena [33], an open-source framework to search for, add, and modify OWL descriptions while supporting SPARQL queries. QoDisco uses Jena-ARQ as query engine and it follows five steps to perform a query:
-
(1)
Parsing – structuration of the query string as query object;
-
(2)
Algebra Generation – translation of the query object to an algebra expression using the SPARQL specification algorithm;
-
(3)
High-level Optimization – transformations applied to the algebra expression, e.g., replacing equality filters with a more efficient graph pattern;
-
(4)
Low-level Optimization – choice of the evaluation order for basic graph patterns; and
-
(5)
Evaluation – execution of algebra expressions to generate solution graph patterns.
Information about repositories (HTTP address and supported operations), RDO documents (name and URI), and topics (topic name) is handled by their respective modules to be registered at a relational database.
Repositories are implemented using Apache Fuseki [34], a server providing SPARQL query, update, and storage operations via HTTP requests. Fuseki was chosen due to its easy deployment and because it provides a SPARQL HTTP endpoint built upon the Jena framework, but other existing technologies could be used to implement repositories. The broker service within the Asynchronous Search Handler uses Moquette [35], a lightweight open-source Java library to implement publish-subscribe message brokers for the MQTT messaging protocol. With the broker address and a topic name, a client can interact directly with the Moquette broker in the Asynchronous Search Handler using the MQTT protocol.
Finally, the Client Interface is implemented as a RESTful Web service using the Spring framework. Clients can access the main functionalities offered by QoDisco either through a user-friendly Web graphical interface or through the REST API Client Interface.