A Data Sharing Strategy and a DSL for Service Discovery, Selection And

Available online at www.sciencedirect.com ScienceDirect

Procedia Computer Science 37 ( 2014 ) 92 – 100

The 5th International Conference on Emerging Ubiquitous Systems and Pervasive Networks (EUSPN-2014) A data sharing strategy and a DSL for service discovery, selection and consumption for the IoT Mehdi Addaa, Rabeb Saadb aMathematics, Computer Science and Engineering Dep. University of Quebec At Rimouski Rimouski, Quebec, Canada Email: mehdi [email protected] bComputer Science and Engineering Dep. University of Quebec At Chicoutimi Chicoutimi, Qubec, Canada Email: [email protected]

Abstract The development of the Internet and the increase in Internet-connected physical devices, offer new opportunities to reduce the gap between the physical world and the virtual world represented by the Internet. This Internet of Things (IoT) fosters the development of new platforms, services and applications that are not possible before. The work presented here proposes a data sharing model based on a propagation strategy for the IoT. It is composed of a formal theoretical model, a domain speciﬁc language and an IDE that implement this model. The developed language not only shows the feasibility of the model but also eases the integration of the proposed model and the related concepts. ©c 20142014 PublishedThe Authors. by Elsevier Published B.V.by This Elsevier is an B.V. open access article under the CC BY-NC-ND license (Selectionhttp://creativecommons.org/licenses/by-nc-nd/3.0/ and peer-review under responsibility of Elhadi). M. Shakshuki. Peer-review under responsibility of the Program Chairs of EUSPN-2014 and ICTH 2014. Keywords: Internet of Things; Web Services, Data Sharing; DSL;

1. Introduction

The Internet of Things (a.k.a IoT) consists mainly at connecting physical objects to the Internet. The GSM Association predicts that by 2020, there will be 24 billion physical devices connected to the internet and there business impact could be US$4.5 trillion 3. The Web of Things (a.k.a WoT ) is a more speciﬁc IoT that aims to bring Web technologies and standards to IoT. WOT eases the development of Web applications and services that interact with the connected objects.

∗ Corresponding author. Tel.: +1-418-723-9425 ; fax: +01-418-724-1879. E-mail address: mehdi [email protected]

1877-0509 © 2014 Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/3.0/). Peer-review under responsibility of the Program Chairs of EUSPN-2014 and ICTH 2014. doi: 10.1016/j.procs.2014.08.017 Mehdi Adda and Rabeb Saad / Procedia Computer Science 37 ( 2014 ) 92 – 100 93

The emergence of the IoT and WOT offers a great potential for developing new applications and services. As shown in Section 2, there exist many platforms and API for the IoT devices. However, and to the best of our knowledge, they generally limit their scope to a simple data storing and retrieval schema. In an attempt to take advantage of this opportunity, we present in this paper a theoretical model that offers a set of primitives and a collaborative strategy to share data in the IoT world. The proposed model is based on a specific service- centric approach that does not rely on a central entity for service discovery and delivery. Instead it relays on a propagation-like query/response model and a straightforward whitelist/blacklist strategy to enforce a minimalist access control policy. As the proposed model is composed of theoretical and abstract concepts, it is not sufficient to demonstrate its feasibility and effectiveness. To overcome this limitation we developed a set of tools to programmatically support the proposed theoretical model. This set is composed of two parts: i) a Domain Specific Language (DSL) called IOTCollab, and ii) a complete Eclipse IDE. The IOTCollab DSL is intended to ease the programming and the management of the different concepts introduced in the model at high level of abstraction. It is mainly motivated by the need to reflect in the implementation model the domain business by the fundamental domain concepts. This DSL helps us avoid tweaking existing languages in order to define IoT systems based on the proposed model. The IDE, which is based on Eclipse, supports IOTCollab with a rich feature set such as code completion, syntax coloring, static analysis, etc. Thus, working with IOTCollab is made easy and intuitive for the developers and programmers who are familiar with modern IDEs such Eclipse.

The rest of the paper is organized as follows. Section 2 summarizes related. Sections 3 presents the main concepts of the proposed model. The IOTCollab DSL is presented in Section 4. Concluding remarks and discussions on future work are given in Section 5.

2. Related work

Even if the IoT is receiving more attention recently, it is not a new idea. At the end of the last century and the beginning of the current century many attempts have been made to connect physical objects to computer networks. For example, Want et al. have presented the results of their implementations where they attempt to connect physical objects to wireless networks by means of RFID tags and other physical components 27. Pederson presented in 24 a method for tracking physical activities using a wearable computer technology. Later on, different approaches have been proposed to integrate physical objects to the Internet. An information sharing architecture for IoT is presented in 26. The authors suggested the concept of a user- centric architecture of the IoT that seamlessly integrates IoT objects, Web protocols, Web applications, and Social platforms, etc. Angulo-Lopez et al. proposed in 12 a collaboration framework for the IoT based on the multiagent paradigm. In order to avoid connecting physical objects directly to the Internet, some approaches suggested abstracting those objects as services by adopting the Service Oriented Paradigm 23,14,19,20,22,25,21. For instance, the work presented by Guinard et al. in 20 illustrates the adoption this paradigm by describing the architecture of the WoT based on the principles of the traditional Web such as scalability and modularity. They advocate the reuse and adaptation of existing Web technologies such as REST architectural style 16 to interact with IoT objects. In order to insure the interconnectivity of IoT devices, many API and technologies are developed. For example, Xively is a platform as a service (PAAS) for IoT that is intended to ease the connection of physical devices to the internet 7. Spark OS is an open source operating system for IoT 4. Right now, it is only compatible with Spark Core boards. ThingSpeak is an open source application platform and API for the IoT that aims to facilitate data storage and retrieval from IoT devices 5,6. One of the advantages of ThingSpeak is its openness to different hardware proﬁles. Crowsnest is a proprietary RESTful API that has to be coupled to a proprietary HUB in order to connect IoT devices 2. AllJoyn is a promising open source framework and services for IoT devices interoperability 1. Big companies and organisations, such as Microsoft, Cisco, D-Link, HTC, LG, AT&T, etc., are involved in this project. 94 Mehdi Adda and Rabeb Saad / Procedia Computer Science 37 ( 2014) 92 – 100

3. Data sharing model

We developed a a data sharing model for IoT based on a speciﬁc service architecture. It is composed of three phases: i) service discovery, ii) service selection, and iii) service consumption (See Figure 1). The main concepts used in this model are Actor and Service and they are deﬁned bellow (See Section 3.1).

Fig. 1: Collaboration model for IoT: service process

3.1. Main concepts: Service and Actor

In our IoT model, a service is deﬁned as a couple that holds information about the data a physical object is sharing. This information includes the type of data, how often these data are collected, and the geolocation of the physical device, etc. (See Deﬁnition 3.1).

Deﬁnition 3.1. Service A service S is a couple data, ctx such that:

• data = d, frq, ops where: – d = {t, u | t is a data type and u the unit of this data type}, – frq = start, end, crne wher start represents the start date, end the end date, and crn a Crontab-like1 string that deﬁnes the frequency at which the data is collected, – ops may be used to specify other options in the form of couples attribute, value. • ctx = lat, lon, options where: – lat, lon represent the latitude and the longitude, respectively, of the geographical point of the IoT object, – ops may be used to specify other options in the form of couples attribute, value.

The universe of all services is represented by US .

In our setting, an actor is an abstract concept that represents a set of IoT objects owned and managed by the same user. Thus, an actor is represented by a set of IoT objects and the services each object may offer (See Deﬁnition 3.2). Actor , , , Deﬁnition 3.2. Given UOIoT the universe of all IoT objects, an actor A is represented by O1 S 1 rating1 O2, S 2, rating2, ..., On, S n, ratingn such that for i ∈ [1, n] we have the following:

• ∈ Oi UOIoT , • S i ∈ US , • ratingi ∈ [1..10] and represent the rating of the service S i.

The universe of all actors is represented by UA.

Remarks 3.1.

1 Crontab:http://unixhelp.ed.ac.uk/CGI/man-cgi?crontab+5 Mehdi Adda and Rabeb Saad / Procedia Computer Science 37 ( 2014 ) 92 – 100 95

1. The brackets ([]) are used to refer to an element at a given position in a list. For example, A[1] refers to the ﬁrst element of A. 2. The dot (.) is used to refer to a component of an element. For instance, A[1].O refers to the element O of the ﬁrst element of A.

3.2. Service discovery

Service discovery in our IoT model relays on a propagation-like query/response model and a straightforward access control policy. This policy is based on the principle that friends of my friends are my friends and is enforced using whitelists and blacklists. While the whitelist contains actors that an actor trust and want to deal with, the blacklist contains actors that one do not want to collaborate and share data with. Thus, the propagation model is dictated by the network of acquaintances and not by the network topology. This strategy is depicted in Figure 2. It is noteworthy that right now witelist and blacklist are manually initialized by the users. The discovery process works as follows. First, an actor formulates a service request that describes the service he is looking for. After that, the request is sent to all actors in his whitelist. If a receiver is able to respond to it, he sends back a response describing the service he is offering that matches the requested service. He then forwards the request to all actors in his whitelist. The same thing is done by the other receivers so that the request is recursively propagated. The discovery and response phases are detailed in Section 3.2.1 and Section 3.2.2. After a period of time has elapsed, the actor who formulated the request may receive many service responses. It is then the beginning of the second phase where a service is selected (See Section 3.5).

* ** A … A 1n1 A12 1(n1Ͳ1)

A2n2 A2(n2Ͳ1) A1 A22 … … … …

Aknk Ak2 … Ak(nkͲ1)

: Service request : Service response : Forwarded request : Forwarded response : White listed actors : Actors that may offer the * ** requested service

Fig. 2: Data sharing model for IoT: Propagation-based service discovery

3.2.1. Service discovery request A service discovery request is a couple that holds information about the service an actor is looking for. The request also contains an ordered list of the IDs of the actors by which the request passes. Each time a request ar- rives at an actor, the list is updated (See Deﬁnition 3.3). This behaviour is depicted by the procedure of Algorithm 1. Deﬁnition 3.3. Service Discovery Request A service discovery request is a couple Rsd = S, IDS such that:

• S ∈ US , th • IDS = ID1, ID2, ..., IDn where IDi for i ∈ [1, n] represents the i ID of the actor that the request Rsd passes by. 96 Mehdi Adda and Rabeb Saad / Procedia Computer Science 37 ( 2014) 92 – 100

The universe of all service discovery requests is represented by URsd.

Algorithm 1 Service request processing procedure

1: procedure PROCESSSERVICEREQUEST(Rsd ∈ URsd; {aS ender, aCurrent}⊆UA: the sender and the current actor, respectively; wList, bList: the white and black list, respectively)

2: INITIALIZATION: 3: wListTemp ← wList −{aS ender}; Do not send the request to its sender

4: if aS ender ∈ bList or aCurrent ∈ Rsd.IDS then Exit if the sender actor is in the blank list or that a cycle is detected (the current actor has already processed the request) 5: exit 6: end if

7: if SERVICEMATCH(Rsd, aCurrent) then 8: RESPONDTOSERVICEREQUEST(Rsd, aSender) 9: end if

10: for all a ∈ wListTemp do 11: Rsd.IDS ← Rsd.IDS + {aCurrent}; 12: FORWARDTHESERVICEREQUEST(Rsd, a) 13: end for

14: end procedure

The service request procedure ProcessServiceRequest of Algorithm 1 works on an input made of the service request ( Rsd), the sender and the current actor (aS ender and aCurrent ), and the whitelist and blacklist (wList and bList ). At the initialization step, it creates a temporary list wListTemp where aCurrent , if it exists, is removed. This list is later on used by the for loop at lines between 10 and 13 to forward the request to the actors it contains. Moreover, the primitive SERVICEMATCH() checks if the service matches services offered by the current actor. If so, the primitive RESPONDTOSERVICEREQUEST() is called to respond to the request. However, no matter what the result of SERVICEMATCH() is, the request will be forwarded as seen above to the actors in wListTemp. It is noteworthy that if the sender is in the blacklist or if the current actor has already received the request Rsd, the procedure exits without any further processing. The pseudo-code of the primitives SERVICEMATCH(), RESPONDTOSERVICEREQUEST() and SERVICEMATCH() is straightforward, and due to space limitations it is not presented here.

3.2.2. Service discovery response A service discovery response is composed of the information about the service the responding actor may offer. The response includes the same list of IDS that the request contains plus the ID of the last actor that has responded to the request. It has the same format and structure as the service discovery request (See Deﬁnition 3.3). The universe of all service discovery responses is represented by URrd. The service response procedure of Algorithm 2 returns the response to the current actor in case it has reached its destination (line 5). Otherwise, it is forwarded to the actor in Rsd.IDS that is just before the current one using the primitive FORWARDTHESERVICERESPONSE() (line 3)

3.3. Service selection

Service selection starts directly after an actor receives a speciﬁed number of responses or after a speciﬁed amount of time has elapsed. It is a two phase process: i) pre-select valid candidates (See Section 3.4), and ii) Mehdi Adda and Rabeb Saad / Procedia Computer Science 37 ( 2014 ) 92 – 100 97

Algorithm 2 Service request response procedure

1: procedure PROCESSSERVICERESPONSE(Rsd ∈ URsd; aCurrent ∈ UA: the current actor) 2: if Rsd.IDS[aCurrent] > 1 then 3: FORWARDTHESERVICERESPONSE(Rsd, Rsd.IDS[aCurrent − 1]) 4: else 5: return(Rsd) 6: end if

7: end procedure based on a predeﬁned criteria, select from the pre-selected set the best services that match the request (See Section 3.5).

3.4. Service pre-selection

A valid service offer is an offer that matches the service request such as depicted by Deﬁnition 3.4.

Deﬁnition 3.4. Service pre-selection Given s1, s2 a service request and a service response, respectively (s1 ∈ URsd, s2 ∈ URrd). The response s2 matches the request s1, denoted s2 s1, if and only if the following conditions are satisﬁed:

• s1 is located near s2: the distance that is separating the two geographical points of those services is smaller or equal to a user ﬁxed threshold, • s1.data.d.t = s2.data.d.t, • s1.data.d.u = s2.data.d.u, • s1.data. frq.start ≥ s2.data. frq.start, • s1.data. frq.end ≤ s2.data. frq.,end • s1.data. frq.crn ⊆ s2.data. frq.crn (the frequency of s1 is covered by that of s2), • ∀op1 ∈ s1.data.ops, ∃op2 ∈ s2.data.ops such that: op1.attribute = op2.attribute∧op1.value(⊆∨=)op2.value, • ∀op1 ∈ s1.data.ctx.ops, ∃op2 ∈ s2.data.ctx.ops such that: op1.attribute = op2.attribute ∧ op1.value(⊆∨= )op2.value.

3.5. Service selection

To select a service, we have to go through the pre-selection process at first (See Section 3.4). By doing so, only valid service offers are considered for the selection process. Then a global rating value is associated to each service offer from the resulting list. The global rating value takes into account the length of each path (distance between the actor who is formulating the request and the actor how is responding to the service) and the average rating of each participating actor. The final expression we used is depicted by Definition 3.5.

Deﬁnition 3.5. Service Selection Given a service request s1 (s1 ∈ URsd), a service offer s2 (s2 ∈ URrd), and sList a list of service offers that match s1 (sList ⊆ URrd). s2 is selected to offer the service to s1, denoted s2 s1,if and only if:

Where: validS List = {s ∈ sList | s s1}, and |X| represents the cardinality of X. 98 Mehdi Adda and Rabeb Saad / Procedia Computer Science 37 ( 2014) 92 – 100

The formulas of Deﬁnition 3.5 can be dissected as follows:

Remark 3.2. In the case where more than one service offer have a maximum rating, the ﬁrst one is returned.

3.6. Service consumption

Service consumption refers to the delivery of the service as described by the service offer that has been selected. It has to be noted that a service delivery instance may occur more than once depending on the frequency conditions specified in the service request. Service delivery has to start (finish) at the start (end) time as specified in the service request, and the delivery may occur as many times as specified by the frequency parameter. For instance, one may get temperature and humidity values of the same geographical point at different times of the day.

4. Domain Speciﬁc Language: IOTCollab

We developed a domain-specific language (DSL) 10,17, called IOTCollab, which is designed to ease the integration of the different concepts introduced by the data sharing model at high level of abstraction. The DSL helps us avoid tweaking existing languages in order to be able to define dat sharing systems based on the proposed model. Technically speaking, there are two kinds of DSLs: i) internal DSLs and ii) external DSLs 17. While internal DSLs may be seen as layers on top of a given programming language and thus rely on the guest infrastructure, external DSLs are fully independent programming languages with their own infrastructure. In this research, we opted for the last version of Xte xt (version 2.6) 15 9 as our external DSL developing platform for its openness and its integration with other open source modeling and code generation tools such as EMF 18 and Xtend 811. The implementation of IOTCollab went through two stages: i) develop the grammar of the language, and then ii) develop a set of templates for code generation. While the grammar is used to represent the meta-model of the language and parse its concepts, the templates are used to generate artifacts as an output from a model. A partial view of the grammar is depicted in Figure 3. Figure 4 shows a view of the data sharing system completely written using IOTCollab language. This use case consists at developing a meteorology service for data sharing. Users at different locations may access the data generated by internet connected sensors of other users at different locations and likewise share their own data. In our ongoing experiments Arduino 13-compatible boards are used. This figure (Figure 4) also shows the generated Eclipse IDE that supports IOTCollab with features such as code completion, syntax coloring, static analysis, etc.

5. Conclusion and Future Work

We have presented in this paper the main building blocks of a formal model that is intended to ease collaboration and data sharing in the IoT. The model is based on a specific service-centric approach that does not rely on a central server/entity for service discovery and delivery. Instead it relays on a propagation query-response model and a straightforward whitelist/blacklist policy for access control. To show the feasibility of the proposed model and ease the integration of its concepts to a data sharing system, a dedicated domain specific language is developed. This language comes along with a full-fledged Eclipse IDE to support it. Mehdi Adda and Rabeb Saad / Procedia Computer Science 37 ( 2014 ) 92 – 100 99

Fig. 3: A partial view of the grammar of IOTCollab

Fig. 4: A partial view of a meteorology data sharing system written using the IOTCollab language

As IoT devices are generally resource-constrained, we plan to conduct real world experiments to test the scalability and performance of the proposed model; especially the potential network overload which may be induced by the propagation strategy. We are also planing to extend the proposed model and focus on the security issues that 100 Mehdi Adda and Rabeb Saad / Procedia Computer Science 37 ( 2014) 92 – 100

are generally facing any Internet-based system and go beyond the access control aspect by covering other security aspects such as identiﬁcation, authentication, data integrity, etc. The current version of the system assumes that the involved entities share a commun clock. It will be interesting to consider a more general case where the entities are not necessary synchronised. Finally, to offer more ﬂexibility we are also planning to bring service composition to the proposed IoT model.

References

1. Alljoyn. https://allseenalliance.org/developer-resources/alljoyn-open-source-project. Accessed: 2014-07-15. 2. Crowsnest. https://www.crowsnest.io/. Accessed: 2014-07-15. 3. Gsma announces the business impact of connected devices could be worth us$4.5 trillion in 2020. http://www.gsma. com/newsroom/gsma-announces-the-business-impact-of-connected-devices-could-be-worth-us4-5- trillion-in-2020/. Accessed: 2014-07-15. 4. Spark os. https://www.spark.io. Accessed: 2014-07-15. 5. Thingspeak. http://www.thingspeak.com/. Accessed: 2014-07-15. 6. Thingspeak github repository. https://github.com/iobridge/ThingSpeak. Accessed: 2014-07-15. 7. Xively platform. https://xively.com/platform/. Accessed: 2014-07-15. 8. Xtend (eclipse foundation). http://www.eclipse.org/xtend/. Accessed: 2014-05-27. 9. Xtext (eclipse foundation). http://www.eclipse.org/Xtext. Accessed: 2014-05-27. 10. Domain-Specific Program Generation, International Seminar, Dagstuhl Castle, Germany, March 23-28, 2003, Revised Papers, volume 3016 of Lecture Notes in Computer Science. Springer, 2004. 11. Mehdi Adda. A formal model of information retrieval based on user sensitivities. In Proceedings of the 4th International Conference on Ambient Systems, Networks and Technologies (ANT 2013), the 3rd International Conference on Sustainable Energy Information Technology (SEIT-2013), Halifax, Nova Scotia, Canada, June 25-28, 2013, volume 19 of Procedia Computer Science, pages 428–436. Elsevier, 2013. 12. Priscila Angulo-Lopez and Guillermo Jimnez-Prez. In Juan A. Bota, Hedda Rahel Schmidtke, Tatsuo Nakashima, Mohammed R. Al- Mulla, Juan Carlos Augusto, Asier Aztiria, Matthew Ball, Victor Callaghan, Diane J. Cook, James Dooley, John O’Donoghue, Simon Egerton, Pablo A. Haya, Miguel J. Hornos, Eduardo Morales, Juan Carlos Orozco, Otniel Portillo-Rodrguez, Alejandro Rodrguez Gonzlez, Oscar Sandoval, Paolo Tripicchio, Minjuan Wang, and Victor Zamudio, editors, Intelligent Environments (Workshops). 13. Steven F. Barrett. Arduino Microcontroller Processing for Everyone! Third Edition. Synthesis Lectures on Digital Circuits and Systems. Morgan & Claypool Publishers, 2013. 14. Jordn Pascual Espada. Service orchestration on the internet of things. IJIMAI, 1(7):76–77, 2012. 15. Moritz Eysholdt and Heiko Behrens. Xtext: implement your language faster than the quick and dirty way. In Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion, SPLASH ’10, pages 307–309, New York, NY, USA, 2010. ACM. 16. R.T. Fielding and R.N. Taylor. Principled design of the modern web architecture. In Software Engineering, 2000. Proceedings of the 2000 International Conference on , pages 407–416, 2000. 17. Martin Fowler. Domain Specific Langua ges. Addison-Wesley Professional, 1st edition, 2010. 18. Richard C. Gronback. Eclipse Modeling Project: A Domain-Specific Language (DSL) Toolkit. Addison-Wesley Professional, 1 edition, 2009. 19. D. Guinard, V. Trifa, T. Pham, and O. Liechti. Towards physical mashups in the web of things. In Networked Sensing Systems (INSS), 2009 Sixth International Conference on , pages 1–4, June 2009. 20. D. Guinard, V. Trifa, and E. Wilde. A resource oriented architecture for the web of things. In Internet of Things (IOT), 2010, pages 1–8, Nov 2010. 21. Dominique Guinard and Vlad Trifa. Towards the web of things: Web mashups for embedded devices. In 2nd Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web (MEM 2009), Madrid, Spain, April 2009. 22. Dominique Guinard, Vlad Trifa, Friedemann Mattern, and Erik Wilde. From the internet of things to the web of things: Resource- oriented architecture and best practices. In Dieter Uckelmann, Mark Harrison, and Florian Michahelles, editors, Architecting the Internet of Things, pages 97–129. Springer, 2011. 23. Sara Hachem, Thiago Teixeira, and Valerie´ Issarny. Ontologies for the internet of things. In Proceedings of the 8th Middleware Doctoral Symposium, MDS ’11, pages 3:1–3:6, New York, NY, USA, 2011. ACM. 24. Thomas Pederson. Magic touch: A simple object location tracking system enabling the development of physical-virtual artefacts in office environments. Personal Ubiquitous Comput., 5(1):54–57, January 2001. 25. Patrik Spiess, Stamatis Karnouskos, Dominique Guinard, Domnic Savio, Oliver Baecker, Luciana Moreira Sa´ de Souza, and Vlad Trifa. Soa-based integration of the internet of things in enterprise services. In Proceedings of the 2009 IEEE International Conference on Web Services, ICWS’09, pages 968–975, Washington, DC, USA, 2009. IEEE Computer Society. 26. Dieter Uckelmann, Mark Harrison, and Florian Michahelles. An architectural approach towards the future internet of things. In Dieter Uckelmann, Mark Harrison, and Florian Michahelles, editors, Architecting the Internet of Things, pages 1–24. Springer Berlin Heidelberg, 2011. 27. Roy Want, Kenneth P. Fishkin, Anuj Gujar, and Beverly L. Harrison. Bridging physical and virtual worlds with electronic tags. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI ’99, pages 370–377, New York, NY, USA, 1999. ACM.