Advertisement
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf
Advertisement
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf
A_Middleware_based_on_Service_Oriented_Architectur.pdf
Upcoming SlideShare
SEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEMSEMANTIC TECHNIQUES FOR IOT DATA AND SERVICE MANAGEMENT: ONTOSMART SYSTEM
Loading in ... 3
1 of 9
Advertisement

More Related Content

Similar to A_Middleware_based_on_Service_Oriented_Architectur.pdf(20)

Advertisement

A_Middleware_based_on_Service_Oriented_Architectur.pdf

  1. A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT) Yasser Mesmoudi a,⇑ , Mohammed Lamnaour a , Yasser El Khamlichi a , Abderrahim Tahiri a , Abdellah Touhafi b , An Braeken b a Computer Engineering Department, National School of Applied Sciences of Tetuan, Abdelmalek Essaadi University, Tetuan, Morocco b Department of Electronics and Informatics, Faculty of Engineering Sciences, Vrije Universiteit Brussel, Brussels, Belgium a r t i c l e i n f o Article history: Received 24 July 2018 Revised 9 November 2018 Accepted 21 November 2018 Available online xxxx Keywords: Middleware Smart gateway SOA RESTfull webservices IoT a b s t r a c t Nowadays, many Internet of Things (IoT) applications have been emerging as innovative solutions for daily life issues, in different fields such as smart cities, environmental surveillance, health care, traffic monitoring, etc. However, most of these solutions are built in a vertical way using proprietary solutions, which increase heterogeneity problems. To solve this issue, many research works have focused on mid- dleware solutions. Nevertheless, such approaches have some kind of limitations. Throughout this work, we have designed and implemented a middleware based on service oriented architecture, capable to deal with the heterogeneity issues. The solution was implemented in three steps starting by collecting data from many heterogeneous sensors hardware using REST API, then heterogeneous networking interfaces have been introduced and finally the middleware have been tested on gateways working on different operating systems. Ó 2018 The Authors. Production and hosting by Elsevier B.V. on behalf of King Saud University. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). 1. Introduction The use of networked sensing devices is growing at a fast pace. This phenomenon entails an increasing volume of data, hetero- geneity of devices, data formats and measurement procedures. Managing the sensor nodes and valorizing the accompanying vol- ume of data is today’s challenge. The network of those sensing devices which enables things to connect and exchange data is called Internet of Things (IoT). Each and every day, many new sens- ing devices are made, they are implemented on smart-phones, smart-watches or simply on sensor nodes that can be called smart objects or things. Recently, several vertical IoT solutions have been developed for particular domains of interest like smart home, smart buildings, automotive, smart environment, smart health etc. In the best case, these solutions handle the whole process, from data collection and processing to the provisioning of data on open cloud based platforms used by application developers. Examples of big industry player’s ecosystems are: IoTivity (Intel + partners), AgileIoT (Huawei), AllJoyn (Qualcomm), Homekit (Apple), Brillo (Google). In order not to be locked in one of these systems, open standards or at least publicly documented Applica- tion Program Interfaces (APIs) are needed. Today, new technology cannot be sold as a component because the market is not ready yet. Consequently, if one is interested in combining features from those different ecosystems, they need to be able to discover and have access to the data sources and understand the semantics used by those heterogeneous systems. As described in a summary extracted from the most influential articles (Liu et al., 2017), most of these solutions do not support heterogeneity of different communication technologies and use diverse formats of exchanged data. Hence, there is a need for devel- oping a middleware as intermediate software layer between the hardware side and the application one. In order to efficiently exploit the capabilities of the current communication technologies and provide more flexible, reconfigurable and efficient networks, the proposed middleware model should provide data compatibil- ity, bandwidth management, ensure connectivity between hetero- geneous devices and solve security problems. Our middleware architecture is a service oriented based on REST API, which permit support various smart objects using differ- ent networking interfaces (IP and NOT IP based) and OS systems, as https://doi.org/10.1016/j.jksuci.2018.11.011 1319-1578/Ó 2018 The Authors. Production and hosting by Elsevier B.V. on behalf of King Saud University. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). ⇑ Corresponding author. E-mail address: mesmoudi.yasser@gmail.com (Y. Mesmoudi). Peer review under responsibility of King Saud University. Production and hosting by Elsevier Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx Contents lists available at ScienceDirect Journal of King Saud University – Computer and Information Sciences journal homepage: www.sciencedirect.com Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
  2. well as unifying various data formats that is used to provide the information needed to the end user working on different platforms. The recommended middleware can be implemented on different gateways, in our case a Raspberry PI equipped with different net- working interfaces, making this gateway smart so that it can man- age communications at the edge of the network and deals with heterogeneity issues cited above. The rest of the paper is organized as follow: Section 2 provides middleware concepts and preliminar- ies, and then related work is presented in Section 3. Section 4 describes software and hardware architecture of our middleware. Section 5 focuses on the implementation scenarios of our middle- ware and discusses the result. Finally, section 6 concludes the paper. 2. IoT middleware concepts and preliminaries Generally, the middleware performs the role of an interpreter that fills up the gap between the high level requirements of different IoT applications and the complexity of different opera- tions in the underlying sensor node hardware (Bhuyan et al., 2014). The design of an IoT middleware needs to meet several chal- lenges (Cecílio and Furtado, 2014; Ajana et al., 2015): Managing limited battery power and resources: middleware designed for smart objects should provide a suitable mecha- nism for the use of limited memory and ensure efficient power consumption. Scalability, mobility and dynamic network topology: Middle- ware should maintain the required performance while the net- work environment is growing. Heterogeneity: The heterogeneity among the hardware, com- munication devices and configuration operations, have to be handled by the middleware. Real world integration: Middleware should provide real time services to be adapted to the eventual changes and data update. Data Aggregation: The aggregation of data within the network ensures that redundant data is not generated, saving costs through memory usage and energy through processing time. Application knowledge: The middleware must include mecha- nisms for injecting application knowledge of IoT infrastructure. Quality of Service (QoS): is important on the application level as well as on the network level, since it defines the accuracy of data, coverage and tolerance. Security: It is necessary to achieve data confidentiality and integrity, since the collected information transmitted over the network can be easily hacked by malicious intrusions. Fault tolerance: The integration of recovery methods in the sys- tem is necessary for enabling failure-resistant networks. Following (Cecílio and Furtado, 2014), middleware approaches can be classified into two main groups, based on how they work: those that run only inside the network (classical approaches) and others that integrate and process data which works only outside the network. 2.1. WSN middleware approaches within the network Based on (Razzaque et al., 2016; Cecílio and Furtado, 2014; Alshinina and Elleithy, 2017) WSN middleware approaches inside the network are classified as presented in Fig. 1. There are several middleware for each approach such as Cougar (Yao and Gehrke, 2002) and SINA (Shen et al., 2001) for Database approach, Agila (Fok et al., 2005) and Impala (Liu and Martonosi, 2003) for Modular approach, Maté (Levis and Culler, 2002) and SwissQM (Mueller et al., 2007) for Virtual Machine approach, Mires (Souto et al., 2005) and TinySOA (Rezgui and Eltoweissy, 2007) for Message-Oriented approach and MiLAN (Murphy and Heinzelman, 2002) For Application Driven Apprach. Studies in (Ajana et al., 2015; Bhuyan et al., 2014; Cecílio and Furtado, 2014; Delicato et al., 2014) describe the advantages and hinders of each middleware like those cited previously and conclude that classical approaches were developed for specific platforms. They do not offer heterogeneity support and interoper- ability among heterogeneous parts of the network. Consequently, developing and deploying end-to-end applications for sensor net- works remains highly complex. 2.2. WSN middleware approaches outside the network Internet-Based Integration of Sensor Data: Traditionally, sensor networks are not IP based. Their integration into IP-based WAN infrastructures requires the deployment of proxies at the edge of both networking domains that transform between non-IP commu- nication in the sensor network and IP communication in the Internet. Several research projects were developed such as GSN (Aberer et al., 2006), Borealis (Abadi et al., 2005), IrisNet (Gibbons et al., 2003), Hourglass (Shneidman et al., 2004), HiFi (Franklin et al., 2005), SStreaMWare (Gurgen et al., 2008), EdgeServers (Rooney et al., 2006), and ESP framework (Kobialka et al., 2007). These mid- dlewares were developed to integrate sensor data into the Internet. Consequently, they are only focused on wrapping data coming from sensor sources for sharing and processing over the Internet. Those works provide heterogeneity outside the network (Cecílio and Furtado, 2014). IP-Based Homogeneous Middleware: There have been several efforts to implement the Internet protocol stack on small con- strained devices. The 6LoWPAN (Mulligan, 2007) ports the IPv6 protocol to small devices. This enables running services on the application layer directly on sensor nodes, which enables the inte- gration of a Service-Oriented Architecture (SOA) into the design of middleware (Cecílio and Furtado, 2014). 2.3. The Service oriented middleware The Service oriented middleware (SOM) architecture is the best platform to develop IoT applications to address hardware chal- lenges such as QoS, security, and heterogeneity (Alshinina and Elleithy, 2017). (For instance) The SOM logically views the network as a service provider for consumer applications; it permits end users to communicate with the network components and provides Fig. 1. Middleware architecture classification. 2 Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
  3. developers with a flexible programming model to build efficient systems (Delicato et al., 2014). Researchers point out that SOA enables organizations to create new applications dynamically to meet changing business needs; its functionality is considered as an important benefit (Xu, 2011). The SOM architecture should provide different functionalities supporting the system. However, most of the approaches do not provide all of them, including: interoperability heterogeneity, scal- ability, security, data aggregation and QoS support. Data or service aggregation is supported in approaches like OASiS, oneM2M (Marino et al., 2017), Fiware (López-Riquelme et al., 2017), InerIoT (mila, n.d.), MiSense, SensorsMW (Anastasi et al., 2010), and ESOA. The security mechanisms have been taken into account through approaches like SOMM (Faghih and Moghaddam, 2011), ESOA, and SAWM (Sheikhha and Moghaddam, 2012). The most disseminated technology for service implementation is Web Services technology. It is often used to connect and access sensors and actuators through the Internet. Two standards in this area have emerged; the Representational State Transfer (REST)- based approach and Simple Object Access Protocol (SOAP) based web services. REST utilizes the common Hypertext Transfer Proto- col (HTTP) methods (get, post) to transfer data, and SOAP uses mes- sages to communicate among services. The structure of the messages and the way to handle those are predefined in the web service specification. As mentioned in (Guinard et al., 2009), Web services are to be preferred for professional enterprise application integration sce- narios with a longer lifespan and advanced QoS requirements. Con- versely, thanks to their simplicity, lightweightness and uniform interface, RESTful services are preferred for tactical, ad-hoc inte- gration over the Web. Since the Web services technology uses XML as the encoding system, data is easily exchanged between computing systems with incompatible architectures and incom- patible data formats. Another lightweight protocol that shows effi- ciency instead of XML format is called JavaScript Object Notation (JSON) (Smith, 2015). As mentioned in (Al-Fuqaha et al., 2015), IoT devices can be classified into two major categories: resource-constrained devices and resource-rich devices. Resource-rich devices, on which we will focus in our research work, are those that have the hardware and software capabilities to support the TCP/IP protocol suite. Thus, IoT applications are based on a variety of application-level proto- cols, such as the Constrained Application Protocol (CoAP (Daud and Suhaili, 2016)), Message Queue Telemetry Transport (MQTT), MQTT (Luoto and Systä, 2017) for Sensor Networks (MQTT-SN), Extensible Messaging and Presence Protocol (XMPP (Ferrera et al., 2017)), as described in Table 1. Those resources are communicating according to network com- munication models such as Request/Response and Publish/sub- scribe. In the request and response architecture, client resource or software requests data or services, meanwhile a server com- puter or software responds to the request by providing the data or service. Whereas, in the Publish and subscribe architecture, a central source called the broker receives and distributes all data, here clients can publish/subscribe data to/from the broker to get the data. On the other hand, devices that do not have the required resources to support TCP/IP cannot easily interoperate with resource-rich devices that support the TCP/IP suite which will be treated in our proposed model. 3. Related work In a different category of related work, Morabito et al. (2018) propose a new model of IoT Gateway called LEGIoT: Lightweight Edge Gateway for the IoT architecture, which relies on the modular characteristic of micro-services and the flexibility of lightweight virtualization technologies to guarantee an extensible and flexible solution at the edge of the network. (Trifa et al., 2009) propose an approach which makes the nodes to become part of a web of things and interact with them using the RESTfull architecture. It is based on lightweight and extensible software components that enable Web-based interactions with all kinds of embedded devices. For non-request/response commu- nication model, (Cirani et al., 2013) proposed a constrained version of the Session initialization protocol (CoSIP) which allows con- strained devices to instantiate communication sessions in a light- weight and standard way. It can be adopted in several application scenarios, such as service discovery and publish/sub- scribe applications. (Bai et al., 2016) proposes the design and implementation of an IoT multi-interface gateway, which can transform the information into data in order to be recognized by various smart objects using heterogeneous wireless technologies such as Bluetooth, Wi-Fi, ZigBee and IR. (Rahmani et al., 2018) propose a smart e-health gateway that supports various wireless protocols and take care of inter-device communication. This gateway is implementing several features such as acting as a repository (i.e., local database) in order to tem- porarily store sensors’ and users’ data, and incorporating it with data fusion, aggregation, and interpretation techniques. It is also providing local pre-processing of sensors’ data, security mecha- nism and interoperability. Table 2 presents an overview of some approaches characteristics cited above. All the previous works has tried to deal with the heterogeneity issues, whether it was communication technologies or circulating data format, in their own way. In the next section we will present our model in details. 4. Proposed middleware architecture 4.1. Software architetcure The design of our middleware should be capable to: - Deal with the problem of heterogeneous communication technologies, - Generalize the implemented code for the most used platforms, - Treat the problem of heterogeneous circulating data. Fig. 2 demonstrates that the proposed architecture can handle various networking interfaces such as Bluetooth; WiFi; Zigbee etc, platforms such as TinyOs, Contiki etc and format data collected from each sensor node/smart object monitoring different activities such as smart home (in our case), healthcare, traffic monitoring etc. Table 1 IoT protocols for application level. MQTT CoAP XMPP (Luoto and Systä, 2017) (Daud and Suhaili, 2016) (Ferrera et al., 2017) Client-Server publish/subscribe messaging transport protocol Request-respond based Client-Server publish/subscribe messaging transport protocol For M2M connections and the IoT RESTful, designed for constrained M2M For asynchronous and long live connection Lightweight, open, simple and designed so as to be easy to implement Low header overhead and parsing complexity Open Binary protocol. Quality of Service (QoS) Built-in discovery, Support for URIs and Content-type headers Instant messaging, group chat, VOIP, etc. On top of TCP (ensures reliability) usually over UDP On top of TCP Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx 3 Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
  4. As we can see, when a person gets into his house, his smartphone is automatically connected to the gateway via WiFi, so they can check through a mobile app all the available smart things with their offered services. The user may check the temperature in the living room (10°) measured by the sensor node which is accessible via Bluetooth and working on ‘TinyOS’ and turn ON the air conditioner which is accessible via WiFi by a simple click. In order to save time and get a warm shower, they can open the smart tap accessible through the 6LowPAN technology in the bath- room. Then, before sleeping and while checking e-mails on the PC; connected with Ethernet and has ‘windows’ as an Operating sys- tem; in the bedroom, they remember not to turn off the TV which is accessible via WiFi and works on ‘WebOS’, so they can also do it by a simple click. Finally, they turn off by their own phone, the light of the bedroom by manipulating the smart bulb connected via WiFi working on Contiki. The above scenario describes briefly the result obtained by implementing our model. Next, we will see in details how the proposed middleware works. Fig. 3 demonstrates how the middleware can make the commu- nication between heterogeneous devices possible through the fol- lowing implemented methods: Phase 1: Service deployment In this phase, the initialization method deploys a web service to discover and initiate connections with all devices connected through WiFi. In addition to that, it opens a web socket for devices connected through Bluetooth. In the first case we use Apache Tom- cat software, which is an open source implementation of the Java Servlet, JavaServer Pages and Java WebSocket technologies, to install a web server and to deploy a web service in order to dis- cover each detected smart object on the Wifi network. In the sec- ond case, we create a script that permits to detect smart devices using Bluetooth and initialize connections through sockets. Initialization (): This method allows the middleware to create a communication link using current communication interfaces (for example Web services for WiFi connection and Web socket for Bluetooth). Phase 2: Core development This phase describes the core of our middleware which contains the following methods: ThingDiscovery (): allows the middleware to get information of available smart object in order to create a database which con- tains several device information, such as communication inter- face, UUID (Xu et al., 2014), name, operating system, and the proposed services etc. We use a MAC address and an IP address as a UUID, respectively for Bluetooth and WiFi connections in order to ensure unique connexion. Table 3 shows an example of table structure. ServiceAvailable (): This method allows to consult saved ser- vices from database, through specific applications for each end user platform (web application in our case). Phase 3: Web application In this phase we develop a web application to manipulate smart things and available services in the network besides managing the application. Table 2 Overview of similar approaches characteristics. LEGIoT WoT CoSIP Multi-Interface Smart E-health (Morabito et al., 2018) (Trifa et al., 2009) (Cirani et al., 2013) (Bai et al., 2016) (Rahmani et al., 2018) Micro-services. RESTfull architecture. Constrained version of SIP. IoT multi-interface gateway. Inter-device communication. Flexibility of lightweight virtualization technologies. Lightweight and extensible software components. Sessions in a lightweight and standard way. Heterogeneous wireless technologies. Data fusion, aggregation, and interpretation techniques. Extensible and flexible solution. Interacting with a sensor node through a URI. Adopted in several application scenarios. Transform the information into a recognized data. Acting as a repository, local pre-processing, security mechanism and interoperability. Edge of the network. Cloud. Edge of the network. Edge of the network. Edge of the network. Fig. 2. Middleware implementation scenario. 4 Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
  5. LoadingService (): This method provides specific implementa- tion (for example get/set methods) for service seeker using specific environment (specific end user browser). 4.2. Software implementation The proposed middleware is developed by using the Java Platform Enterprise Edition (Java EE) architecture that permits to build distributed web and enterprise applications. This architecture helps to focus on presentation and application issues, rather than on systems issues, thus interoperability between sys- tems is ensured. The Java EE tools and features help to create appli- cations that are structured around modules with different purposes. Different tools used in the development of our middle- ware are listed below: JAX- RS (Java API for RESTful Web Services): is a Java program- ming language API for creating RESTful web services. It provides portable APIs for developing, exposing and accessing Web applications designed and implemented in compliance with principles of REST architectural style (Patni, 2017). JSF framework 2.2: Java Server Faces is a Java-based web appli- cation framework intended to simplify development and inte- gration of web-based user interfaces. Developers can build web applications by assembling reusable UI components in a Fig. 3. The proposed Middleware architecture. Table 3 Example of the connected device information table structure. Com Int UUID Name OS Proposed Service WiFi 192.168.43.2 Torch Android Light BLE 00:21:13:00:CA:87 DHT11 Arduino Temperature Fig. 4. Scenario 1 architecture. Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx 5 Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
  6. page, connecting these components to an application data source and wiring client-generated events to server-side event-handlers (Juneau, 2018). JSON or JavaScript Object Notation API is a specification that exposes an implementation for data stores and data structures and permits to optimize HTTP requests, both in terms of the number of requests and the size of data packages exchanged between clients and servers (Smith, 2015). SQLite is a relational database management system contained in a C programming library. In contrast to many other database management systems, it is embedded into the end of the pro- gram, does not have a separate server process and reads/writes directly to ordinary disk files. Since we work with limited resource components, such as memory capacity and CPU, we use SQLite for storage (Feiler, 2015). By using the Raspberry Pi as a gateway to host the proposed middleware, and Arduino which is an open-source electronics plat- form that senses the environment, we allow the middleware to col- lect data from different smart objects connected through different networking interfaces such as Wi-Fi, Bluetooth and Zigbee. Fig. 5. List of services available in the network – Scenario 1. Fig. 6. Details of IoT devices and services – Scenario 1. Fig. 7. Scenario 2 architecture. 6 Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
  7. Arduino is an easy-to-use hardware and software that connects to computer via USB, receives inputs from a variety of digital and ana- log sensors, and affects its surroundings by controlling lights, motors, and other actuators. Arduino is accessible and can be cus- tomized by writing code in the Arduino programming language. 5. Results discussion In order to present the developed middleware we propose three scenarios, in the first one the middleware installed on a Raspberry Pi as a gateway should collect data from various smart objects con- nected via Wi-Fi. Consequently, this proves that data exchange is ensured between heterogeneous smart objects. Then, in the second case the installed middleware should handle data coming from various smart objects connected through different networking interfaces. While in the third one, we use a personal computer working on windows as a gateway to prove that our middleware deal with the operating system heterogeneity. 5.1. Scenario 1 In this step, we test the heterogeneity between various sensors used in order to prove that heterogeneity of hardware is supported by the developed middleware. Thus, we connect on Arduino plat- form a temperature sensor DHT11, a red LED and a Wi-Fi module to exchange data with the gateway, besides we use a Smartphone equipped with a WiFi module and a pedometer that permit to cal- culate the number of walks. The goal is to list all available services on the network, such as temperature, switching on or off light and the number of walks, and manipulate the connected objects. Fig. 4 describes the smart objects and equipment used in the first sce- nario. The Id of all connected objects on the Wi-Fi network is the IP address. In Fig. 5, we list all services available on the network loaded by the developed middleware, using the web application developed to consult specific information of the smart objects connected and manipulate them. Then details and commands are accessible as demonstrated by Fig. 6. 5.2. Scenario 2 In this step, we address the networking interface heterogeneity issue using the proposed middleware. Thus we connect on the first Arduino platform a temperature sensor DHT11 that will send data using the Bluetooth module HC-06, in the second one a red LED is connected and can be switched on/off via Wi-Fi module; then like the previous scenario, we use a Smartphone equipped with a WiFi module and a pedometer that permits calculate the number of walks. Smart objects are identified on Wi-Fi network using Ip address and on Bluetooth using their Mac address. Fig. 7 describes all equipments used in the second scenario. Fig. 8 shows all services available on the WIFI and Bluetooth network loaded by our middleware. The web application shows also all details and commands to manipulate the detected objects. Hence, heterogeneity is ensured for smart object hardware as well as for networking interfaces. Fig. 9 show details about a smart objet and if it can be manipulated. 5.3. Scenario 3 In order to prove that interoperability is ensured, we decide to install our middleware on a Personal computer that uses Windows and search for available services on the WiFi and Bluetooth net- work. We keep all the equipments used in the previous scenario; Fig. 10 shows the implemented architecture. The main goal of using a web application for consulting and commanding things over the network, and a JAVA based web ser- vices to collect and exchange data, is besides extending the net- work lifetime since the REST Api consumes low energy, to solve interoperability issue between systems such Windows, Linux, IoS, Fig. 8. List of services available in the network – Scenario 2. Fig. 9. Details of IoT devices and services – Scenario 2. Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx 7 Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
  8. and Android, so the developed middleware can be installed on dif- ferent gateway. Thus, we prove that our middleware is portable and compatible with different systems. Before we conclude, we provide a summary of our work pro- gression in Table 4. 6. Conclusions All in all, nowadays, IoT applications have been introduced in every filed, because of the facility and low cost of their implemen- tation. Consequently, many IoT objects equipped with heteroge- neous sensors and networking interfaces can exist in the same network. Thus, a large amount of data with different format is gen- erated and must be managed, so it can be easily provided to devel- opers and end user application. Furthermore, most of IoT middlewares are developed in a verti- cal way for particular domain applications, so they can just handle a part of these issues but not all of them. In this paper, we are pre- senting existed approaches of IoT middlewares, as well as develop- ing a middleware based on service oriented architecture that search for connected devices from different networking interfaces and make its offered services available through web service using REST API. Via different uses cases we’ve proved that our middle- ware manages and processes data generated from heterogeneous IoT devices connected in Bluetooth or WiFi network. The first case, the middleware exchanged data between different kinds of IoT objects in the same WiFi network. In the second one, we consider the same previous scenario but, in this case, things are connected via different technologies; for instance Bluetooth or WiFi. Finally, by Using JAVA technology we activate network inter- faces, we make connected IoT devices available as web services and we offer a web application for the end user. Thus, our middle- ware is portable and compatible with Linux and windows plat- forms. In the future work and in order to prove that full interoperability is ensured we focus on adapting our middleware for Android and iOS platforms. References Abadi, D.J., Ahmad, Y., Balazinska, M., Cetintemel, U., Cherniack, M., Hwang, J.-H., Lindner, W., Maskey, A., Rasin, A., Ryvkina, E., 2005. The design of the borealis stream processing engine. In: CIDR Conference, pp. 277–289. Aberer, K., Hauswirth, M., Salehi, A., 2006. The Global Sensor Networks middleware for efficient and flexible deployment and interconnection of sensor networks. Tech. Rep. LSIRREPORT- 2006-006. Ajana, M.E.K., Harroud, H., Boulmalf, M., Elkoutbi, M., 2015. Middleware architecture in WSN. In: Wireless Sensor and Mobile Ad-Hoc Networks. Springer, New York, NY, pp. 69–94. https://doi.org/10.1007/978-1-4939-2468- 4_4. Al-Fuqaha, A., Khreishah, A., Guizani, M., Rayes, A., Mohammadi, M., 2015. Toward better horizontal integration among IoT services. IEEE Commun. Mag. 53, 72– 79. https://doi.org/10.1109/MCOM.2015.7263375. Alshinina, R., Elleithy, K., 2017. Performance and challenges of service-oriented architecture for wireless sensor networks. Sensors 17, 536. https://doi.org/ 10.3390/s17030536. Anastasi, G.F., Bini, E., Romano, A., Lipari, G., 2010. A service-oriented architecture for QoS configuration and management of Wireless Sensor Networks. In: Presented at the Proceedings of the 15th Conference on Emerging Technologies Factory Automation (ETFA 2010). IEEE, pp. 1–8. https://doi.org/10.1109/ ETFA.2010.5641336. Bai, Z., Kuo, C.-H., Wang, T.-C., 2016. Design and implementation of an IoT multi- interface gateway for establishing a digital art interactive system. Int. J. Ad Hoc Ubiquitous Comput. 21, 157–170. https://doi.org/10.1504/IJAHUC.2016. 075376. Bhuyan, B., Sarma, H.K.D., Sarma, N., 2014. A survey on middleware for wireless sensor networks. J. Wirel. Netw. Commun. 4, 7–17. Fig. 10. Scenario 3 architecture. Table 4 Work progress summary. Heterogeneity Issues Operating System Windows Linux Android iOS Supported Supported In progress In progress Network Interfaces WiFi Bluetooth ZigBee LoRA Supported Supported In progress In progress Hardware Asynchronous Streaming Temperature Supported Acoustic In progress Humidity Supported Video In progress 8 Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
  9. Cecílio, J., Furtado, P., 2014. Existing middleware solutions for wireless sensor networks. In: Wireless Sensors in Heterogeneous Networked Systems, Computer Communications and Networks. Springer, Cham, pp. 39–59. https:// doi.org/10.1007/978-3-319-09280-5_4. Cirani, S., Picone, M., Veltri, L., 2013. CoSIP: a constrained session initiation protocol for the internet of things. In: Advances in Service-Oriented and Cloud Computing, Communications in Computer and. Springer, Berlin, Heidelberg, pp. 13–24. https://doi.org/10.1007/978-3-642-45364-9_2. Daud, M.A., Suhaili, W.S.H., 2016. CoAP and HTTP protocol: a study on which protocol suits IoT in terms of performance. In: Computational Intelligence in Information Systems, Advances in Intelligent Systems and Computing. Presented at the International Conference on Computational Intelligence in Information System. Springer, Cham, pp. 165–174. https://doi.org/10.1007/978- 3-319-48517-1_15. Delicato, F.C., Pires, P.F., Zomaya, A.Y., 2014. Middleware platforms: state of the art, new issues, and future trends. In: The Art of Wireless Sensor Networks, Signals and Communication Technology. Springer, Berlin, Heidelberg, pp. 645–674. https://doi.org/10.1007/978-3-642-40009-4_19. Faghih, M.M., Moghaddam, M.E., 2011. SOMM: a new service oriented middleware for generic wireless multimedia sensor networks based on code mobility. Sensors 11, 10343–10371. https://doi.org/10.3390/s111110343. Feiler, J., 2015. Understanding What SQLite Is. In: Introducing SQLite for Mobile Developers. Apress, Berkeley, CA, pp. 9–14. https://doi.org/10.1007/978-1- 4842-1766-5_2. Ferrera, E., Conzon, D., Brizzi, P., al, et,, 2017. XMPP-based infrastructure for IoT network management and rapid services and applications development. Ann. Telecommun. 72, 443–457. Fok, C.-L., Roman, G.-C., Lu, C., 2005. Rapid development and flexible deployment of adaptive wireless sensor network applications. In: Distributed Computing Systems, 2005. ICDCS 2005. Proceedings. 25th IEEE International Conference On. IEEE, pp. 653–662. Franklin, M.J., Jeffery, S.R., Krishnamurthy, S., Reiss, F., Rizvi, S., Wu, E., Cooper, O., Edakkunni, A., Hong, W., 2005. Design Considerations for High Fan-In Systems: The HiFi Approach. In: Proceedings of Second Biennial Conference on Innovative Data Systems Research (CIDR), pp. 24–27. Gibbons, P.B., Karp, B., Ke, Y., Nath, S., Seshan, S., 2003. IrisNet: an architecture for a worldwide sensor Web. IEEE Pervasive Comput. 2, 22–33. https://doi.org/ 10.1109/MPRV.2003.1251166. Guinard, D., Trifa, V., Pham, T., Liechti, O., 2009. Towards physical mashups in the Web of Things. Presented at the Proceedings of the Sixth International Conference on Networked Sensing Systems (INSS), pp. 1–4. https://doi.org/ 10.1109/INSS.2009.5409925. Gurgen, L., Roncancio, C., Labbé, C., Bottaro, A., Olive, V., 2008. SStreaMWare: a service oriented middleware for heterogeneous sensor data management. In: Proceedings of the 5th International Conference on Pervasive Services, ICPS ’08. ACM, New York, NY, USA, pp. 121–130. https://doi.org/10.1145/1387269. 1387290. Juneau, J., 2018. The Basics of JavaServer Faces. In: Java EE 8 Recipes. Apress, Berkeley, CA, pp. 103–189. https://doi.org/10.1007/978-1-4842-3594-2_3. Kobialka, T., Buyya, R., Leckie, C., Kotagiri, R., 2007. A Sensor Web Middleware with Stateful Services for Heterogeneous Sensor Networks, in: Intelligent Sensors, Sensor Networks and Information ISSNIP 2007. Presented at the 3rd International Conference on Intelligent Sensors, IEEE, pp. 491–496. https://doi.org/10.1109/ISSNIP.2007.4496892 Levis, P., Culler, D., 2002. MatÉ: A Tiny Virtual Machine for Sensor Networks. In: Proceedings of the 10th International Conference on Architectural Support for Programming Languages and Operating Systems. ASPLOS X. ACM, New York, NY, USA, pp. 85–95. https://doi.org/10.1145/605397.605407. Liu, F., Tan, C.-W., Lim, E.T., Choi, B., 2017. Traversing knowledge networks: an algorithmic historiography of extant literature on the Internet of Things (IoT). J. Manag. Anal. 4, 3–34. Liu, T., Martonosi, M., 2003. Impala: A middleware system for managing autonomic, parallel sensor systems. ACM Sigplan Notices. ACM, 107–118. López-Riquelme, J.A., Pavón-Pulido, N., Navarro-Hellín, H., Soto-Valles, F., Torres- Sánchez, R., 2017. A software architecture based on FIWARE cloud for Precision Agriculture. Agric. Water Manag. Special Issue: Adv. ICTs for Water Manag. Agric. 183, 123–135. https://doi.org/10.1016/j.agwat.2016.10.020. Luoto, A., Systä, K., 2017. IoT Application Deployment Using Request-Response Pattern with MQTT. In: Current Trends in Web Engineering, Lecture Notes in Computer Science. Presented at the International Conference on Web Engineering,. Springer, Cham, pp. 48–60. https://doi.org/10.1007/978-3-319- 74433-9_4. Marino, F., Maggiani, L., Nao, L., Pagano, P., Petracca, M., 2017. Towards softwarization in the IoT: Integration and evaluation of t-res in the oneM2M architecture. In: Presented at the Proceedings of The 3rd IEEE Conference on Network Softwarization (NetSoft). IEEE5, p. 1. https://doi.org/10.1109/ NETSOFT.2017.8004202. mila, n.d. INTER-Iot - Interoperability Internet of Things [WWW Document]. INTERIOT. URL http://www.inter-iot-project.eu/ (accessed 7.18.18). Morabito, R., Petrolo, R., Loscrì, V., Mitton, N., 2018. LEGIoT: a lightweight edge gateway for the internet of things. Future Gener. Comput. Syst. 81, 1–15. https://doi.org/10.1016/j.future.2017.10.011. Mueller, R., Alonso, G., Kossmann, D., 2007. SwissQM: Next Generation Data Processing in Sensor Networks. In: Proceedings of the 3rd Biennial Conference on Innovative Data Systems Research CIDR07. 9, p. 1. Mulligan, G., 2007. The 6LoWPAN Architecture, in: Proceedings of the 4th Workshop on Embedded Networked Sensors, EmNets ’07. ACM, New York, NY, USA, pp. 78–82. https://doi.org/10.1145/1278972.1278992 Murphy, A., Heinzelman, W., 2002. Milan: Middleware linking applications and networks. Univ. Rochester Tech Rep TR-795, 1–16. Patni, S., 2017. Introduction to JAX-RS. In: Pro RESTful APIs. Apress, Berkeley, CA, pp. 49–62. https://doi.org/10.1007/978-1-4842-2665-0_4. Rahmani, A.M., Gia, T.N., Negash, B., Anzanpour, A., Azimi, I., Jiang, M., Liljeberg, P., 2018. Exploiting smart e-Health gateways at the edge of healthcare Internet-of- Things: a fog computing approach. Future Gener. Comput. Syst. 78, 641–658. https://doi.org/10.1016/j.future.2017.02.014. Razzaque, M.A., Milojevic-Jevric, M., Palade, A., Clarke, S., 2016. Middleware for Internet of Things: A Survey. IEEE Internet Things J. 3, 70–95. https://doi.org/ 10.1109/JIOT.2015.2498900. Rezgui, A., Eltoweissy, M., 2007. Service-oriented sensor–actuator networks: promises, challenges, and the road ahead. Comput. Commun., Sensor- Actuated Networks 30, 2627–2648. https://doi.org/10.1016/j.comcom.2007. 05.036. Rooney, S., Bauer, D., Scotton, P., 2006. Techniques for integrating sensors into the enterprise network. IEEE Trans. Netw. Serv. Manag. 3, 43–52. https://doi.org/ 10.1109/TNSM.2006.4798306. Sheikhha, F., Moghaddam, M.E., 2012. Service-Oriented Wireless Multimedia Sensor Network Middleware Using Infra-Red Cameras. In: Presented at the Proceedings of the Third FTRA International Conference on Mobile, Ubiquitous, and Intelligent Computing, pp. 230–235. https://doi.org/10.1109/MUSIC.2012.47. Shen, C.-C., Srisathapornphat, C., Jaikaeo, C., 2001. Sensor information networking architecture and applications. IEEE Pers. Commun. 8, 52–59. https://doi.org/ 10.1109/98.944004. Shneidman, J., Pietzuch, P., Ledlie, J., Roussopoulos, M., Seltzer, M., Welsh, M., 2004. Hourglass: An infrastructure for connecting sensor networks and applications. Citeseer. Smith, B., 2015. Beginning JSON. Apress. Souto, E., Guimarães, G., Vasconcelos, G., Vieira, M., Rosa, N., Ferraz, C., Kelner, J., 2005. Mires: a publish/subscribe middleware for sensor networks. Pers. Ubiquitous Comput 10, 37–44. https://doi.org/10.1007/s00779-005-0038-3. Trifa, V., Wieland, S., Guinard, D., Bohnert, T.M., 2009. Design and implementation of a gateway for web-based interaction and management of embedded devices. Submitt. DCOSS, 1–14. Xu, L.D., 2011. Enterprise systems: state-of-the-art and future trends. IEEE Trans. Ind. Inform. 7, 630–640. https://doi.org/10.1109/TII.2011.2167156. Xu, L.D., He, W., Li, S., 2014. Internet of Things in Industries: A Survey. IEEE Trans. Ind. Inform. 10, 2233–2243. https://doi.org/10.1109/TII.2014.2300753. Yao, Y., Gehrke, J., 2002. The cougar approach to in-network query processing in sensor networks. SIGMOD Rec 31, 9–18. https://doi.org/10.1145/601858. 601861. Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx 9 Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues within the Internet of Things (MSOAH-IoT), Journal of King Saud University – Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011
Advertisement