1 Introduction

The IoT and Service Oriented Computing (SOC) support cyber-physical systems where things offer capabilities as services that can be composed to create novel applications [2, 3]. This composition process is a transformation of consumer requests into the execution of a set of services [9]. A service plan defines the services to be executed but its discovery is challenging in IoT because of the large number of services [4]. The composition approaches in IoT can be classified as conversation-based, or interface-based [12]. Service conversations use process models [11] to represent service plans which are manually defined [8]. This considerable human intervention is not feasible in IoT because users cannot know about all available services. Interface-based approaches compose services based on planning algorithms. They can create service plans automatically, but incorrect services can appear, affecting search accuracy [12]. Search latency is also impacted by large search spaces and exhaustive exploration of all possible services combinations. Novel composition mechanisms for IoT should include historical data in progressive searches, with sensible ranking methods [10].

This paper proposes a model to discover service plans in IoT that uses consumer feedback to guarantee search efficiency minimising human intervention. Consumer feedback (i.e., historical data from previous searches) determines if a discovered plan was correct or incorrect and is used in our model to improve search accuracy. The latency of the process is reduced through two strategies: first, the use of consumers’ feedback avoids the exploration of incorrect combinations of services. Second, the model explores the plans according to how well each plan meets the request’s requirements. The model explores the most promising plans (i.e., search space reduction), and avoids wasting time on the less promising plans (i.e., progressive search). The proposed approach is evaluated and compared with a classic planning algorithm [6] and a conversation-based approach [12] on both centralised and distributed infrastructures.

This paper summarises the related work in Sect. 2. Section 3 presents the discovery process. Sections 4 and 5 present the evaluation and conclusions.

2 Related Work

Service composition in IoT can be classified as conversation-based and interface-based [12]. Deng et al. [7] propose an architecture where requesters specify a service conversation to select a composition with the lowest latency. Baker et al. [1] propose a service composition algorithm where cloud-providers define service conversations for each offered service. Users requests (i.e., I/O parameters) are matched with the service conversations. Urbieta et al. [12] present a service composition model that selects services whose capabilities conform a predefined service conversation. Conversation-based approaches offer good retrieval accuracy. However, they are time-consuming, error-prone, and require high human intervention [14]. It is not feasible to assume that users will know about all the available services and all their possible combinations in large-scale environments.

Interface-based approaches compose plans automatically. Zhao et al. [13] introduce a mechanism where sensors are grouped into classes that are chained using a planning algorithm to fulfill user goals (i.e., I/O parameters). The resulting plan is used to search services according to energy efficiency constraints. Chen et al. [6] present an approach that supports adaptive service composition. Service discovery is based on a planning algorithm that uses semantic matchmaking of I/O signatures. Interface-based approaches offer automatic planning. However, search precision can be affected negatively by the retrieval of incorrect services [12]. For example, a service s1 that provides readings about wind speed and a service s2 that consumes data of buses speeds are likely to match because the output type of s1 is equivalent to the input type of s2 (i.e., both are speeds). Both conversation and interface-based categories present performance problems in terms of response time as they perform complex processes in full search spaces and look for all the possible paths even when they are incorrect [6, 12].

3 Composition of Services in IoT Environments

We assume that a network of gateways manages the services offered by IoT environments. Figure 1 shows the service discovery engine (SDE) that is deployed on each gateway. It receives consumer requests and feedbacks, forwards discovery messages to other gateways, and sends response messages to consumers. Each gateway has a registry to store service descriptions that providers advertise through a registry engine described in our previous work [3]. Service descriptions are defined as \({{\varvec{s}}_{\textit{desc}}} =\langle id, I, O, D\rangle \), consisting of an identifier, inputs, outputs, and domains. A request is defined as \({\textit{r}} =\langle I, O\rangle \), consisting of inputs and outputs. The engine uses a set of ontologies (i.e., knowledge model) to annotate services and requests parameters and services domains. These ontologies are defined by the OWLS-TC V4Footnote 1 and our previous work [5]. The service planner and matchmaker use this semantic information to reduce the search space and identify service relations. The planner uses consumers feedback to generate accurate service plans. Consumers mark as correct or incorrect each discovered plan and the feedback manager stores this feedback in two data structures:

Fig. 1.
figure 1

Service discovery engine.

Full size image

  • Plans: This stores past discovered plans as graphs that include vertices (i.e., services in a plan), and edges (i.e., relations between two services in a plan).

  • Relationships: This stores each relation between two services (i.e., an edge between two vertices) discovered by the SDE in past plans. Each relation includes the source parameter type, the source service domain, the target parameter type, the target service domain, the number of plans that have included this relation, and the number of successful plans that have included this relation. This counter of successful plans is updated when a consumer sends the feedback of a plan that includes the relation.

Each identified relation between two services is validated against the consumer feedback in the registry. This knowledge represents relationships between domains and avoids the inclusion of services that have input/output relationships but belong to non-related domains. For example, service \(S_{1}\) has body temperature as output and belongs to the health domain, service \(S_{2}\) has room temperature as input and belongs to the buildings domain. They have an input/output relationship as \(S_{1}\) produces, and \(S_{2}\) consumes temperature measurements, but it is incorrect and will be ignored because of the negative feedback.

Fig. 2.
figure 2

Service discovery process.

Full size image

Figure 2 shows the discovery process where the SDE searches for plans that meet a request. This process starts when a gateway receives a request message from the consumer or other gateways. This message includes two inputs: the request that is the consumer requirement and includes the I/O parameters. And a list of previous plans that is a set of graphs that partially solve the request and was discovered previously. It is empty if the message comes from the consumer. The SDE performs the planning process based on these inputs as follows:

Step 1: Initial Plans and Search Space Definition

The planner receives the request and previous plans. If the list of previous plans is empty, the planner creates a graph with two vertices: initial and final. The outputs of the initial vertex are the inputs in the request and the inputs of the final vertex are its outputs. The final vertex is an unsolved vertex as there are no vertices that provide their inputs. If the list of previous plans is not empty, these partial plans are used as initial plans. The planner defines the search space as a set of services which outputs can match to the unsolved vertices in a plan. The planner queries the registry to get these services according to their I/O parameters. This query (i.e., progressive search) improves the search efficiency as the planner does less iterations in next steps.

Step 2: Candidates Plans Discovery

The planner tries to complete the initial plans using the search space from the step 1. It uses the matchmaker that discovers I/O relations comparing two service parameters and gives a score if the parameters match. This score is used to rank and select the candidate plans (i.e., plans that can solve the request). The matchmaker is based on matching methods that compare two parameters (i.e., \(P_{1}\), \(P_{2}\)) using their annotated types according to an ontology O as follows:

  • \(equivalent(P_{1},P_{2})\): The type of \(P_{1}\) is conceptually equivalent to the type of \(P_{2}\) in O. This method gives a score of 4 to the relation between \(P_{1}\) and \(P_{2}\).

  • \(plugin(P_{1},P_{2})\): The type of \(P_{1}\) is a sub-concept of the type of \(P_{2}\) in O. This method gives a score of 3 to the relation between \(P_{1}\) and \(P_{2}\).

  • \(subsume(P_{1},P_{2})\): The type of \(P_{1}\) is a super concept of the type \(P_{2}\) in O. This method gives a score of 2 to the relation between \(P_{1}\) and \(P_{2}\).

  • \(similarity(P_{1},P_{2})\): This method calculates the cosine similarity between \(P_{1}\) and \(P_{2}\). This method gives a score of 1 to the relation between \(P_{1}\) and \(P_{2}\).

The planner uses the consumers’ feedback to validate each discovered relation. It computes an historic success index (HSI) for a given edge (Eq. 1).

$$\begin{aligned} HSI(e) = \frac{successfulPlans}{totalPlans} \end{aligned}$$
(1)

where successfulPlans is the number of correct plans that have included the edge e and totalPlans is the number of plans that have included the edge e. The planner uses this index to determine whether a discovered relation is valid. If \(HSI>=feedbackThreshold\), the discovered relation is included in the plan. The planner creates a candidate plan for each combination of valid discovered relations for an initial plan. Previous planning approaches create and explore candidates for all possible combinations, which increases their latency. The number of candidates can be large even with this constraint. Our model ranks and selects the top k candidates based on the scores defined by the matchmaker. Each candidate has a functional matching index FMI that defines how well it meets the request’s functional requirements. This index follows the Eq. 2.

$$\begin{aligned} FMI(G(v,e)) = \frac{\sum _{i=1}^{n}x_{i}}{4n} \end{aligned}$$
(2)

where n is the number of edges in the candidate plan G, and \(x_{i}\) is the score for a particular edge according to the matchmaker. 4n is the maximum value that the plan can receive. The candidate is added to the list of candidates if the length of the list is less than or equal to K and \(FMI>=functionalThreshold\).

Step 3: Response Definition and Feedback Management

The planner uses the matchmaker to define which of the candidate plans solve the request. The matchmaker compares the outputs of the initial vertex (i.e., inputs of the request) with the inputs of the non-solved vertices in each candidate. The planner validates the discovered relations calculating the HSI and comparing it with the feedbackThreshold. If the request is solved after this process, the list of solutions is ranked using the FMI and published to the consumer. Otherwise, the request and the list of ranked candidates is sent to the next gateway where the process starts again with the candidates as a list of previous plans. The SDE stores the solutions in the registry and subscribes to a feedback message from the consumer. The consumer publishes feedback sending the plan identifier and a boolean mark that states if the plan is correct or not.

4 Evaluation

We implemented the SDE in Python 3.5, services and feedbacks are stored in a MongoDB, and the communication is based on MQTT. We compare our model against a classic planning algorithm [6] and a conversation based approach [12]. We measure search precision, latency in terms of response time (ms), and human intervention in terms of number of bytes in the request and feedback. We deploy the approaches in centralised and distributed infrastructures to evaluate its performance. The centralised infrastructure uses the Kelvin cluster managed at the Trinity Centre for High Performance Computing (TCHPC)Footnote 2. One node hosts the client that sends service requests and the SDE that solves them. The distributed infrastructure is composed by 5 Raspberry Pi3 that run Raspbian, have 1 GB of RAM and an SD card with 16 GB. One of the boards is the consumer and sends requests to the other boards. We run five rounds of 100 requests for each approach with different number of services in the environment. This number varies from 2000 to 10000, incremented by 2000. We repeated this process for all the combinations of the parameters in our model. The K value varies from 5 to 25, incremented by 10, the feedbackThreshold and the functionalThreshold values vary from 0.0 to 1, incremented by 0.2.

The dataset is composed by 946 services and 47 requests from which responses are composed plans that can include from 1 to 5 services. The composed plans were validated to determine the set of relevant responses, this set has 14937 plans. 9054 mockup services are added to evaluate scalability. The implemented approaches, and data sets used in this paper are available on the TCD GitLabFootnote 3.

4.1 Results

We evaluate our model (i.e., feedback-based) with different values for its parameters (i.e., Feedback and Functional Thresholds, K Value, and Number of Rounds). We apply a Kruskal-Wallis test with a multiple comparison of ranked means to measure how the values of each parameter affects our model. The feedback and functional threshold do not have a significant impact on the results. However, the best results are achieved when these thresholds have a value of 1.0. The K value has a significant effect in both search precision and response time (Fig. 3). The best results are achieved when K is 5. It improves the precision because only the five most promising candidates are explored. The response time is also minimised as the size of explored plans is small. The number of rounds significantly affects search precision and response time (Fig. 4). It means that our model is more efficient over the time when more consumer feedback is available. The best results are achieved when the number of rounds is 5. The rest of this section compares our model under these parameters against a classic planning algorithm [6] and a conversation-based approach [12].

Fig. 3.
figure 3

K value - Kruskal-Wallis analysis

Full size image
Fig. 4.
figure 4

Number of rounds - Kruskal-Wallis analysis

Full size image

Figure 5 shows the search precision with 10000 services. The classic approach achieves a precision mean of 0.63, the conversation-based approach achieves a mean of 0.81 and the feedback-based approach achieves a mean of 0.8 in the centralised infrastructure (Figure 5(a)). Figure 5(b) shows the search precision in the distributed infrastructure. The conversation-based approach achieves a precision mean of 0.4 and the feedback-based approach achieves a mean of 0.95. Our model has a similar mean for search precision to the conversation-based approach in the centralised infrastructure, but it overcomes its competitors in the distributed infrastructure. The conversation-based approach precision is affected when the registry is distributed because when a task is solved in a gateway it is not explored in others. Our model has a better precision in the distributed infrastructure because in the centralised architecture there is more chance to explore incorrect services. Conversation-based approach and feedback-based approaches overcome the classic planning approach because it does not validate the discovered services. The classic approach did not run properly in the distributed infrastructure as its intensive search overloads the raspberry Pi boards.

Fig. 5.
figure 5

Search precision with 10000 services

Full size image
Fig. 6.
figure 6

Discovery response time

Full size image
Fig. 7.
figure 7

Human intervention in bytes per request

Full size image

Figure 6 shows the average latency with different number of services. Figure 6(a) presents the results in the centralised architecture. The classic planning approach has the largest average latency, it varies from 11 min with 2000 services to 50 min with 10000 services. The conversation-based approach has the next latency, it varies from 1458 ms with 2000 services to 5191 ms with 10000 services. Our approach is slightly better, its latency varies from 1458 ms with 2000 services to 3048 ms with 10000 services. Figure 6(b) shows the results in the distributed infrastructure. Our approach offers the lowest average latency, it varies from 1723 ms with 2000 services to 2175 ms with 10000 services. The largest latency is 2290 ms with 6000 services. The conversation-based approach latency varies from 7419 ms with 2000 services to 24273 ms with 10000 services. Our approach has the best latency because it iterates over the services that match, the conversation-based approach iterates over all the services in the registry. Our approach outperforms the classic approach because of the K value that limits the number of explored candidates. We analyse the human intervention in each approach (Fig. 7). We measure the number of bytes per request and feedback against the number of services in the discovered plans. The classic and the feedback-based approaches have a human intervention around 700 bytes per request for different plan lengths in the centralised scenario. The human intervention in the conversation-based approach varies from 927 bytes with a plan length of 1 to 2924 bytes with a plan length of 5 (Fig. 7(a)). Our approach also has less human intervention in the distributed infrastructure (i.e., around 1000 bytes). The human intervention in the conversation-based approach varies from 914 bytes with plan length 1 to 3062 bytes with a plan length of 5. The conversation-based approach requires more human intervention when the plans length increases because the number of tasks to be defined is larger. Our approach minimise this intervention because the number of request parameters do not vary with the plans length. The human intervention in our approach is slightly bigger than in the classic approach because it includes the feedback.

5 Conclusions

This paper presents a model for services in IoT which guarantees an efficient service discovery. This model uses consumer feedback to validate the discovered service relations. It avoids the exploration and inclusion of incorrect options. Functional requirements are used to define the search space, and the selection of candidates’ plans minimising the number of options to reduce the latency. We compare our model against a classic planning algorithm and a conversation-based approach in centralised and distributed infrastructures. Results show that our model outperforms its competitors regarding search precision and response time with minimal human intervention. We will investigate how to adapt our model to larger environments such as smart cities in future work.