Design and Implementation of a Message-Service Oriented Middleware for Fog of Things Platforms Cássio Prazeres, Jurandir Barbosa, Leandro Andrade
Martin Serrano Insight @ NUIG Galway, Ireland
WISER @ DCC/UFBA Salvador, Bahia, Brazil
[email protected]
{prazeres,jurandirbarbosa,leandrojsa}@dcc.ufba.br
ABSTRACT
i.e., closer to devices, applications and/or users, working as a kind of “local and private cloud” (a Fog), thus enabling a new breed of applications and services [3].
Fog of Things (FoT) is a new paradigm for design and implementation of Fog Computing platforms for the Internet of Things (IoT). The FoT proposal goes further than the Fog Computing in some directions: i) by using all the processing capacity of the network edge through performing data processing and service delivery on devices, gateways (very small servers) and small local servers; ii) by defining profiles for gateways and servers at the edge of the network, in order to define and implement IoT Services to be delivered in a distributed way; iii) by distributing these IoT Services also at the network edge through a message-service oriented middleware. In this paper, we propose FoT-MSOM, which is a message-service oriented middleware for the FoT paradigm, and we show how this middleware can be deployed on a SelfOrganizing FoT-based platform (SOFT-IoT platform).
Prazeres and Serrano [7] proposed Fog of Things (FoT), which is a new way for design and implementation of Fog Computing platforms for the Internet of Things. Like in Fog Computing, part of data processing capacity and service delivery operations are performed locally in “small servers” and data processing that demands for heavy computational resources can occur in the cloud. Furthermore, Fog of Things paradigm goes further than the Fog Computing in some directions, such as: i) by using all the processing capacity of the network edge through performing data processing and service delivery on devices, gateways (very small servers) and small local servers; ii) by defining profiles for gateways and servers at the edge of the network, in order to define and implement IoT Services to be delivered in a distributed way; iii) by distributing these IoT Services also at the network edge through a message-service oriented middleware.
CCS Concepts •Information systems → Computing platforms;
As a step toward the FoT paradigm, we designed and implemented a distributed middleware for service delivery at the network edge. This middleware aims to offer IoT Services in a distributed way over the Fog and to exchange IoT data through messages between the network nodes (devices, gateways, servers, etc.). For that reason, we propose a MessageService Oriented Middleware for the FoT paradigm (FoTMSOM) and we show how this middleware can be deployed on a Self-Organizing FoT-based platform (SOFT-IoT).
Keywords Internet of Things; Fog Computing; Middleware; SOFT-IoT
1.
INTRODUCTION
Industry and academia have proposed several solutions [10] based on Cloud Computing for service delivery in the Internet of Things (IoT). However, cloud-based solutions have some limitations such as scalability, high demand for bandwidth, and high latency [1].
A FoT-based platform works over a constrained network, which can fail and make IoT Services undeliverable. For that reason, FoT-MSOM provides automatic deployment of IoT Services by migrating services from gateways that failed to other gateways with the same profile. As a result, in order to validate our proposal, we evaluated the execution time for the automatic deployment of IoT Services on gateways.
In order to avoid the aforementioned limitations of Cloud Computing, CISCO initially proposed a new paradigm of infrastructure for data and services: Fog Computing [4]. In the Internet of Things, Fog Computing aims to transfer some of the complexity from the cloud to the edge of network,
Several works have proposed middlewares for the Internet of Things, as those surveyed by Razzaque et al. [8] and Fersi [6]. These both surveys present IoT middlewares with different design approaches, as follows: event-based; serviceoriented; message-oriented; VM-based; agent-based; tuplespaces; database-oriented; and application-specific. However, comparing with the state of the art previously surveyed, to the best of our knowledge, the existing works do not cover an approach of middleware for Fog Computing similar to the FoT-MSOM proposed in this paper.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC 2017,April 03-07, 2017, Marrakech, Morocco
Copyright 2017 ACM 978-1-4503-4486-9/17/04. . . $15.00
http://dx.doi.org/10.1145/3019612.3019820
1814
As described in sections 2.2 and 2.3, in the FoT-MSOM proposed in this paper, each FoT-Gateway or FoT-Server has a FoT-Profile and offer IoT Services distributed over a FoTMSOM topology.
The remainder of this paper is organized as follows. Section 2 presents the design of FoT-MSOM middleware proposed in this paper. In Section 3, we present the SOFT-IoT platform, which is a proposal for a FoT-based platform implementation through FoT-MSOM. Section 4 presents some results about an experiment executed over our FoT-MSOM middleware deployed in the SOFT-IoT platform. Finally, we present final remarks and ongoing works in Section 5.
2.
2.2
FOT-MSOM
In this section, we describe FoT-MSOM in details and we start by presenting some basic concepts of the FoT paradigm (Section 2.1). Then, we describe profiles, services (Section 2.2), and topologies (Section 2.3), which are the main concepts related with the FoT-MSOM.
2.1
2.2.1
Fog of Things (FoT)
Basic Profile
Except for the profiles that are deployed on FoT-Servers, all profiles implement the basic IoT services that are: mapping from communication protocol to HTTP; access to devices (Thing as a Service paradigm - TaaS); automatic device configuration; and automatic publication (automatic generation of Web Service RESTful). The FoT-Gateways that have only basic services belongs to Basic Profile. However, if necessary, the gateway may receive new services, in order to turn it into one of the other profiles described below. Also in Basic Profile, aiming to parallelize the data processing and optimizing the use of bandwidth, data processing services for the enrichment and processing of data can be implemented. As previously mentioned, data processing in a FoT-based platform starts in FoT-Devices with transformation of raw data into structured data. However, this transformation is limited, given the limitations of FoT-Devices. Then, in FoTGateways, data may be enriched with semantic information and can be transformed into other formats required by applications, among others data processing.
According Prazeres and Serrano [7], some of terms used in definition of the FoT paradigm are based on the Architectural Reference Model for the Internet of Things (IoT ARM) defined by Bassi et al. [2] at the scope of IoT-A1 European project. Prazeres and Serrano [7] defined the main components of a FoT-based platform as follows. FoT-Device is the basic component in the FoT paradigm, and the concept of FoT-Device goes further than the general concept of Device proposed by Bassi et al. [2] because FoT-Devices must perform the most basic functionality of a FoT-based platform, in terms of local and parallel data processing: transformation of raw data into structured content. FoT-Gateway is the basic node managed by a FoT-based platform and can be called simply as a gateway, since its most basic and main objective is to map from communication layer protocols (Ethernet, WiFi, ZigBee, Bluetooth, etc.) to HTTP (RESTful Web Services). Therefore, FoTGateways must offer services to access FoT-Devices (Thing as a Service paradigm - TaaS) and other IoT services.
2.2.2
FoT-Server, like a FoT-Gateway, is also a basic node managed by a FoT-based platform. FoT-Servers should provide specifics capabilities or information that are not supported by devices and gateways, for example, long-term historical data from devices.
Localization Profile
FoT-Gateways with Localization Profile should implement all services of the Basic Profile and IoT Services related to geographical localization of FoT-Devices. Therefore, as in FoT-based platforms all devices are automatically configured and deployed over FoT-Gateways; and given that IoT devices in general are highly dependent from a geographical location, for example, a temperature measurement is meaningless if the location where it was monitored is not known; this profile must implement an IoT Service for discovery of geographical localization of FoT-Devices.
FoT-Profile is a new concept introduced by Prazeres and Serrano [7] to address aspects related to the distributed characteristic of the FoT paradigm. Each node (FoT-Gateways and FoT-Servers) in a FoT-based platform has a profile: basic, discovery, composition, management, etc. These profiles define a set of features a node should offer via an IoT service to a FoT-based platform as a whole or for externals users, applications or services.
2.2.3
Discovery Profile
FoT-Gateways with Discovery Profile should implement all services of the Basic Profile and IoT Services related to service discovery. Thus, Discovery Profile must provide services for an application/user to find and use an IoT Service as described by Bassi et al. [2]. These discovery services should be based on semantic descriptions of IoT Services. Therefore, to provide means for semantic description of every IoT Service is also a service provided by the Discovery Profile. However, the Storage Profile must provide the storage of semantic descriptions of IoT Services.
IoT Service in the FoT reuses the broad concept proposed by Bassi et al. [2]: “IoT Service offers an open and standardized interface that provides all the functionality needed to interact via network with resources or IoT devices”. It is important to note that in the FoT paradigm all IoT Services must be distributed on FoT-Gateways or FoT-Servers and must be implemented as a RESTful Web Service. 1
FoT-Profiles and IoT Services
The objective of FoT-Profiles is to facilitate and optimize the management of the distributed IoT Services in the FoTMSOM. In this paper, we initially defined seven FoT-Profiles to ensure the main IoT Services for the operation of a platform based on FoT-MSOM. However, other profiles may be defined and implemented even after the development and deployment of the platform. These seven FoT-Profiles and its related IoT Services, which have to be deployed on each FoT-Profile, are described as following.
http://www.iot-a.eu/
1815
2.2.4
2.3
Storage Profile
Storage Profile should be implanted in a FoT-Server (a storage server) and should implement all services related to IoT data description and storage. Therefore, the storage services should provide storage functionalities for data generated by devices (historical data) and for semantic description of FoTDevices and IoT Services.
2.2.5
Composition Profile
In heterogeneous and dynamic scenarios such as the Internet of Things, static and manual compositions are not suitable because it does not adapt to the requirements of changeability and scalability. Therefore, the FoT-Gateway with Composition Profile should implement all services of the Basic Profile more IoT Services related to service composition. Thus, the Profile Composition must implement IoT Services for automatic and dynamic composition, which take the semantic description of the service into consideration.
2.2.6
FoT-Gateways act as “small local servers” (close to devices, applications and/or users) and thus can be geographically distributed. As a result, FoT-Gateway is a unit with independent functioning, i.e., it should work even if there is no communication with other gateways. On one hand, this feature is important because the gateway can be used in smallscale scenarios (e.g., Smart Home), where no more than one gateway is necessary. On the other hand, in boarder scenarios like a college campus (Smart Campus), geographically distributed gateways can be isolated and without any kind of communication and cooperation. This aspect can generate some problems for a FoT-based platform: gateways are underutilized; the IoT services can not be distributed in the platform; and, failure in one of the gateways makes its services inaccessible; among others. Since these problems, the FoT paradigm proposes the integration of several FoTGateways through dynamic and self-organizing topologies build on top of a service-message oriented middleware.
Security Profile
Security Profile should be deployed in a FoT-Server (a security server) and should implement all services related to IoT security management: authentication, identification, authorization, privacy and trust [2].
2.2.7
FoT-MSOM Topology
In the FoT paradigm, a Message-Service Oriented Middleware (FoT-MSOM) is distributed among the several FoTGateways and FoT-Servers. FoT-MSOM has three main functions on FoT-based platforms: i) the service-oriented part provides communication between applications and the IoT Services deployed in the FoT-Gateways and FoT-Servers; ii) the message-oriented part provides communication between FoT-Gateways and FoT-Devices through a network protocol agnostic way; iii) the message-oriented part also provides communication among several FoT-Gateways. The last one should be used to define how the FoT-Gateways would be geographically distributed over a FoT-based platform through a definition of a node topology.
Management Profile
Profile Management should be deployed in a FoT-Server (a management server) and should implement all services related to the self-organizing features of a FoT-based platform. The main services that should be implemented in such servers are described as follows. Self-organizing Monitoring Service retrieves information about the platform to perform the dynamic and automated selforganization. This service should also be responsible for maintaining updated all critical information about FoT components (devices, gateways, etc.), and for providing such information for other services, which have focus on maintaining the systems consistency through management policies. Gateway Deployment Service uses information provided by the Self-organizing Monitoring Service for automatically deploying new gateways, which improves scalability based on automatic analysis of platform performance as a whole. For example, if the Self-organizing Monitoring Service alerts that the platform as a whole is “saturated” (based on management policies), i.e., there are bottlenecks causing the depreciation of performance, new gateways should be deployed.
Figure 1 shows three basic kinds of FoT topologies. A developer of a FoT-based platform can choose one of these three topologies or some combination of it, or even other kind of topology for specifics scenarios. In order to implement a FoT-Topology, FoT-Gateways can have a complete implementation of a FoT-MSOM and/or just the service-oriented (SOM) part – it will depend on the kind of topology being implemented. The topologies presented in Figure 1 are described as follows, as well as, two other topologies, which are variations of the topologies shown in Figure 1.
2.3.1
Hub-and-Spoke Topology
This topology (Figure 1-A) implements a complete MSOM only on one of the FoT-Gateways. Thus, all other gateways (SOM) are clients of a central gateway, which is the access point for IoT Services offered by a FoT-based platform, i.e., every user/application needs to connect to this gateway. It is a very centralized implementation, which can be a good choice for small scenarios: for example, a small building.
Failure Recovery Service uses information provided by the Self-organizing Monitoring Service for failure discovery in gateways at real time. In case of such failures, this service should also be responsible for automatically and dynamically rebuild the communication between FoT-Gateways in the FoT-Topology.
2.3.2
Balancing of Profiles Service uses information provided by the Self-organizing Monitoring Service in order to balance the use of gateways with the same profile. In case of failures in gateways, this service should also be responsible for migrating services from gateway that failed to other gateways with the same profile.
Multi-Hub Topology
This topology (Figure 1-B) is an extension of Hub-and-Spoke topology, in order to provide scalability and distributiveness. Every user/application needs to connect to one of the gateways that have the complete MSOM. This topology can be used, for instance, to integrate several small buildings.
1816
Figure 1: FoT Topologies: SOM (service-oriented) and MSOM (service-message-oriented) middlewares.
2.3.3
Hierarchical Topology
platform allows decoupling the applications together and reducing dependencies among IoT Services.
This topology is a variation of Multi-Hub topology (Figure 1-B) with one single point of access. In this topology, a central FoT-Gateway is at the highest level of a tree hierarchical structure and every user/application needs to connect to this central gateway.
2.3.4
Network-of-Nodes Topology
This topology (Figure 1-C) establishes a multicast network (fully connected network) of nodes FoT-Gateways. In this topology, all gateways implement the complete MSOM. Like Multi-Hub topology, Network-of-Nodes topology also provides scalability and distributiveness. Unlike Multi-Hub topology, users/applications can connect with any gateway.
2.3.5
Federation Topology
This topology generalizes Multi-Hub or Network-of-Nodes topologies for multi-protocols (heterogeneous) MSOMs. In this topology, FoT-Gateways implement message transformation for message and service oriented protocols such as: AMQP (Advanced Message Queuing Protocol); MQTT (Message Queue Telemetry Transport); REST; RSS and Atom; STOMP (Simple Text Orientated Messaging Protocol); among others.
3.
FOT-MSOM ON SOFT-IOT PLATFORM
SOFT-IoT (Self-Organizing Fog of Things for the Internet of Things) platform is a proposal for a concrete implementation of the FoT paradigm presented in Section 2.1, i.e., SOFTIoT is a FoT-based platform proposed by Prazeres and Serrano [7]. In this section, we describe how FoT-MSOM is being implemented in the SOFT-IoT platform.
3.1
The FoT-Gateway designed for SOFT-IoT platform was developed and evaluated on a previous work [5] and implements two middlewares: a message-oriented and a serviceoriented. To implement the FoT-Gateway the following components were deployed in low-cost devices with limited processing and memory capabilities (Raspberry Pi and Intel Galileo Gen2 : a message-oriented middleware (Mosquitto MQTT Broker); and a service-oriented middleware based on the OSGi implementation of Apache (Felix and Karaf in Figure 2). The message-oriented part provides communication between the FoT-Gateways and FoT-Devices. MQTTDriver in Figure 2 is a driver for communication between FoT-Gateways and FoT-Devices using the lightweight MQTT protocol. MQTTDriver helps the developer in the task of communicates with FoT-Devices by implementing a virtual communication between IoT Services and FoT-Devices. Some of features implemented on MQTTDriver are: changing the value of an actuator; reading the value of a sensor; getting properties from the device like the IP; editing the properties of the device; among others. The service-oriented part provides, via RESTful Web Services (Apache CXF in Figure 2), communication between applications with IoT Services deployed at FoT-Gateways, which aims to offer IoT Services on the network edge. All FoT-Gateways implement the paradigm Thing as a Service (microservice) (TaaS), which is related to the “Basic Profile”. TaaS paradigm exposes device functionality, for instance, get temperature, turn on/off a lamp and change temperature of the air conditioning, etc., as IoT Services in SOFT-IoT platform. Figure 2 presents several examples of TaaS: TemperatureTaaS, LuminosityTaaS, SoundTaaS, GasTaaS, and others.
SOFT-IoT: Microservice Infrastructure
In the SOFT-IoT platform FoT-MSOM is implemented as a microservice infrastructure, as shown in Figure 2. This infrastructure is distributed along FoT-Gateways and FoTServers in order to implement the proposed FoT-Profiles presented in Section 2.2. All IoT Services of SOFT-IoT platform are microservices developed and deployed on an Enterprise Service Bus (ESB) infrastructure based on the OSGi, which is a specification for middlewares that combines the functionality of a Service Oriented Architecture (SOA) and the modularity. The adoption of an ESB by the SOFT-IoT
In addition to “Basic Profile”, other IoT Services can be deployed on the microservices infrastructure as presented in Figure 2. Considering the distributed feature of a FoT-based platform as SOFT-IoT, FoT-Gateways will also provide services such as Storage, Configuration, Discovery, Composition and others. These services define the set of FoT-Profiles (see Section 2.2) for SOFT-IoT platform and are distributed on a FoT-Topology as described in Section 3.2.
1817
Figure 2: Microservice Infrastructure on an ESB powered by OSGi for the SOFT-IoT Platform.
3.2
SOFT-IoT: FoT-Profiles and FoT-Topology
FoT-Gateways and FoT-Servers). The Apache Cellar is a cluster solution for Apache Karaf OSGi, which allows to manage multiple OSGi instances with synchronization and operations as distribution, storage and management of resources in different nodes and topologies. By using Apache Cellar, a node with the “Management Profile” can organize, monitor and replicate IoT Services in other nodes.
Given the FoT’s feature related to geographical distribution, FoT-Gateways and FoT-Servers in SOFT-IoT platform are geographically distributed close to devices, users and/or applications. Thus, it is necessary to implement a way of communication among several FoT-Gateways and FoT-Servers. In SOFT-IoT platform, gateways and servers communicate among them via a well-defined FoT-Topology, i.e., one of such topologies described in Section 2.3: the Network-ofNodes topology, as shown in Figure 3.
In SOFT-IoT platform implementation, each FoT-Gateway in a FoT-MSOM topology need a configuration of Hazelcast2 , which is a distributed cache solution for Java applications. In FoT-MSOM, the Hazelcast is used inside Apache Cellar and allows that each node identifies the others nodes, in order to provide: network configuration, supporting for several protocols (eg. TCP/IP, IPv4, IPv6), use of SSL for encrypted communication, restriction on output ports, among others functionalities. Hazelcast also provides a multicast configuration, which in FoT-MSOM is used to provide multicast communication between the SOFT-IoT nodes presented in Figure 3. Furthermore, Apache Cellar provides the definition of groups of nodes with similar functionalities. In FoT-MSOM, we use this feature to implement the FoT-Profiles and its related IoT Services. Figure 3 shows that a FoT-Gateway can be member of several groups (FoT-Profiles). For example, the gateway “G-05” has three profiles: Basic, Discovery and Location. Karaf Cellar also makes run-time migration of IoT Services between FoT-Gateways possible. This functionality is important to provide the self-organization feature of the SOFT-IoT platform, allowing a FoT-Server with “Management Profile” to execute automatic deployment of IoT Services in FoT-Gateways.
Figure 3: SOFT-IoT topology and profiles. Figure 3 illustrates a network of nodes topology with six nodes. In real environments, such as a college campus (Smart Campus), which need to deploy a large number of nodes, static and manual configuration is not a scalable solution. Thus, an IoT Service from a FoT-Server with “Management Profile” (as described in Section 2.2) is designed to automate the management of gateways and the network of nodes in order to make them dynamically self-organizing. The Apache Cellar (deployed on each node - FoT-Gateways and FoT-Servers - see Figure 2) is the part of FoT-MSOM that is responsible to provide communication between different nodes (units that have an Apache Cellar, in our case,
4.
RESULTS
Automatic deployment of IoT Services is an important feature for a FoT-based platform, because it works over a constrained network, which can fail and make IoT Services undeliverable. As described in Section 3.2, a FoT-Server with “Management Profile”, as the “S-01” in Figure 3, implements 2
1818
http://hazelcast.org/
automatic deployment of IoT Services by migrating services from FoT-Gateways that failed to other FoT-Gateways with the same profile (“G-01” to “G-05” in Figure 3). For that reason, in order to analyze our proposed Network-of-Nodes topology for the SOFT-IoT platform presented in Figure 3, we evaluated the execution time for the automatic deployment of IoT Services in FoT-MSOM.
ing work, we are designing and implementing the interplay between our FoT-based platform (SOFT-IoT) and a Cloudbased middleware: the OpenIoT [9]. Acknowledgments: This work was partially funded by the European Union’s Horizon 2020 Programme under the framework of the FIESTA-IoT project (Federated Interoperable Semantic IoT/cloud Testbeds and Applications) under contract number CNECT-ICT-643943. Authors would like to thank: CAPES, CNPq and FAPESB for the financial support to Cassio Prazeres and Leandro Andrade.
We configured our experiment similarly to the topology presented in Figure 3: one FoT-Server and five FoT-Gateways. Furthermore, we ran the tests in five different configurations, which we increased the number of gateways in where an IoT Service was deployed: (1) one server and one gateway; (2) one server and two gateways; (3) one server and three gateways; (4) one server and four gateways; (5) one server and five gateways.
6.
Figure 4: Thirty deployments for each configuration. As can be viewed in Figure 4, for each configuration we executed a deployment of five IoT Services and repeated it for thirty times in order to avoid issues related with network traffic. As a result, Figure 4 shows the execution time (in milliseconds) for each configuration. Analyzing the results of Figure 4, we can observe the execution time for each experiment configuration always increases when the number of gateways increases. Therefore, to provide automatic deployment of IoT Services in the SOFT-IoT platform works well for small groups of gateways (configurations 1 to 3 in Figure 4). As a result, we conclude that to group FoT-Gateways in several small FoT-Profiles (groups of gateways), as proposed in this paper, can be a feasible solution to the management of large amount of gateways in a FoT-based platform as SOFT-IoT.
5.
REFERENCES
[1] M. Abdelshkour. IoT, from cloud to fog computing. http://blogs.cisco.com/perspectives/ iot-from-cloud-to-fog-computing, March 2015. [Online; accessed 02-December-2015]. [2] A. Bassi, M. Bauer, M. Fiedler, T. Kramp, R. van Kranenburg, S. Lange, and S. Meissner, editors. Enabling Things to Talk: Designing IoT solutions with the IoT Architectural Reference Model. Springer-Verlag Berlin Heidelberg, 1 edition, 2013. [3] F. Bonomi, R. Milito, P. Natarajan, and J. Zhu. Fog computing: A platform for internet of things and analytics. In N. Bessis and C. Dobre, editors, Big Data and Internet of Things: A Roadmap for Smart Environments, volume 546 of Studies in Computational Intelligence, pages 169–186. Springer International Publishing, 2014. [4] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli. Fog computing and its role in the internet of things. In Proceedings of the First Edition of the Workshop on Mobile Cloud Computing, pages 13–16. ACM, 2012. [5] N. de Andrade Jr, J. de Almeida, R. Costa, L. Andrade, G. Pinto, and C. Prazeres. Web of things gateway: A performance evaluation. In Proceedings of the 21st Brazilian Symposium on Multimedia and the Web, WebMedia ’15, pages 25–32. ACM, 2015. [6] G. Fersi. Middleware for internet of things: A study. In International Conference on Distributed Computing in Sensor Systems, pages 230–235, June 2015. [7] C. Prazeres and M. Serrano. SOFT-IoT: Self-Organizing FOG of Things. In 2016 30th International Conference on Advanced Information Networking and Applications Workshops (WAINA), pages 803–808, March 2016. [8] M. A. Razzaque, M. Milojevic-Jevric, A. Palade, and S. Clarke. Middleware for internet of things: A survey. IEEE IoT Journal, 3(1):70–95, Feb 2016. [9] J. Soldatos, N. Kefalakis, M. Hauswirth, M. Serrano, J.-P. Calbimonte, M. Riahi, K. Aberer, P. Jayaraman, A. Zaslavsky, I. ˚ A¡arko, L. Skorin-Kapov, and R. Herzog. Openiot: Open source internet-of-things in ˘ and ¨ G, the cloud. In I. Podnar ˚ A¡arko, K. Pripu˚ A¿iA M. Serrano, editors, Interoperability and Open-Source Solutions for the Internet of Things, volume 9001 of LNCS, pages 13–25. Springer, 2015. [10] W. Toll. Top 49 tools for the internet of things. https://blog.profitbricks.com/ top-49-tools-internet-of-things/, 2014. [Online] accessed 05-October-2016.
FINAL REMARKS
We have designed and implemented FoT-MSOM, which is a service-message oriented middleware for the Fog of Things paradigm. In the FoT paradigm, we advocated that IoT Services should be grouped as FoT-Profiles and that these profiles should be distributed on several FoT-Gateways. We also advocated that the FoT-Gateways should be integrated through a topology of nodes termed FoT-Topology. In this way, we defined some FoT-Profiles, in order to facilitate and optimize the management of the distributed characteristic of the FoT paradigm. We also defined some FoTTopologies, in order to design how FoT-Profiles can be distributed on a FoT network. Finally, we proposed and evaluated a FoT-MSOM implementation, which is based on known protocols and standards as MQTT, OSGi and RESTful Web Services. As an ongo-
1819
