Comparison of existing IoT middleware solutions.
The Internet of Things (IoT), along with its wider variants including numerous technologies, things, and people: the Internet of Everything (IoE) and the Internet of Nano Things (IoNT), are considered as part of the Internet of the future and ubiquitous computing allowing the communication among billions of smart devices and objects, and have recently drawn a very significant research attention. In these approaches, there are varieties of heterogeneous devices empowered by new capabilities and interacting with each other to achieve specific applications in different domains. A middleware layer is therefore required to abstract the physical layer details of the smart IoT devices and ease the complex and challenging task of developing multiple backend applications. In this chapter, an overview of IoT technologies, architecture, and main applications is given first and then followed by a comprehensive survey on the most recently used and proposed middleware solutions designed for IoT networks. In addition, open issues in IoT middleware design and future works in the field of middleware development are highlighted.
- Internet of Things (IoT)
- radio frequency identification (RFID)
- virtual machine
- middleware architecture
- context awareness
- ubiquitous computing
- machine-to-machine (M2M) communication
Nowadays, various new generation-connected objects or things are invading our daily lives including sensors, radio frequency identification (RFID) tags, smartphones, wearables, and actuators among others, due to the emergence of new technologies. With the development of cloud computing and wireless technologies, and the emergence of new connected devices at a decreasing price, the IoT market is expected to grow rapidly fostering the development of applications in different domains, including but not limited to healthcare, manufacturing, logistics and transportation, traffic management, home automation, smart cities, smart grids, smart agriculture, etc. . These applications will use the raw data generated by the different connected things/objects and provide new services in the targeted domains . The Global System for Mobile Communications Association (GSMA) forecasts that “by 2025, the IoT connections will reach almost 25 billion globally” . These predictions are therefore highlighting the role of IoT in providing new ways of communication over the Internet.
The IoT network is considered a heterogeneous network with a complex structure, connecting a wide range of devices using different evolving technologies such as Bluetooth, ZigBee, Wi-Fi, 3G, 4G, 5G. The ubiquitous computing environment of IoT connecting heterogeneous devices, technologies, and applications, and generating a large number of events continuously brings in important and new challenges, such as interoperability, security, confidentiality, privacy, and energy-efficient operations . For example, location tracking by the IoT devices may be allowed by some people to get personalized services; however, it may violate their privacy. The middleware, which is a software application, can hide the things details from the applications by communicating with the heterogeneous connected devices/things, filtering the raw captured data, and processing them before dissemination to the connected applications, and therefore easing the backend applications’ development and offering multiple common services . The middleware can also deal with the interoperability, security, and privacy issues facing the IoT. The IoT middleware development is an active research area; there exist many middleware solutions addressing the IoT environment requirements in terms of context awareness, scalability, interoperability across heterogeneous things, device management, data storage and management, security, privacy, and service deployment. A major challenge faced by application developers today is finding the most appropriate IoT middleware solution in terms of the provided functionalities that should meet the application requirements and the underlying used technologies. Therefore, the existing works on IoT middleware architecture need to be analyzed to address their existing technical challenges, issues, and gaps in this domain and suggest further improvements. This chapter provides a detailed overview of existing middleware solutions for IoT and is organized as follows: Section 2 provides background about IoT characteristics, architecture, and applications, and gives an overview of the IoT middleware general architecture. Section 3 presents the IoT middleware design considerations and requirements. Section 4 provides a comprehensive review of currently existing research work in designing IoT middleware platforms. Section 5 discusses criteria for choosing the right platform according to the application requirements, along with some open issues and challenges, and the last Section 6 provides some concluding comments recommending future research directions in this area.
2.1 IoT architecture and applications
The Internet of Things (IoT) consists of two words: The “Internet” is defined “a network of networks and a global system of interconnected computer networks that use TCP/IP as a standard Internet Protocol (IP) to connect millions of users and multiple private, public, academic, business, and government networks,” and “Things” include “any real-world object/physical element such as home appliances, clothes, smartphones, etc. or living things like people, animals, or plants” . The International Telecommunication Union (ITU) considers IoT as “a worldwide network of interconnected objects, allowing anything and anyone to be connected, anytime and anyplace using any network and any service” . Therefore, in IoT, many heterogeneous devices will be connected to the Internet and will provide a large volume of data and even services. The major components of IoT include wireless sensors and actuators networks, machine-to-machine (M2M) communications, and RFID/near-field communication (NFC) as shown in Figure 1.
2.1.1 IoT infrastructure characteristics
188.8.131.52 Heterogeneous intelligent devices
In IoT, heterogeneous devices in terms of features, capacities, sensor computing natures (high end, middle end, and low end), costs, embedded intelligence (adapting to the context, environment, and circumstances), and from different vendors are expected to communicate and exchange information . Also, new types of devices are emerging continuously in the future as new technologies are developed . Figure 2 shows the main technologies used in IoT.
184.108.40.206 Context and location awareness
The different connected devices/things capture large volumes of data that need further processing; it should be filtered, interpreted, and put in a context to have a meaning. Context awareness helps to make the interpretation of data easier by adding context information to the raw data captured by the IoT things, which allows performing M2M communication that is considered a core element in an IoT environment . Also, the spatial/location information about things is important to understand their interactions with other surrounding things (e.g., objects and people) .
220.127.116.11 Limited resources
IoT devices including small embedded sensors, RFID tags and readers, actuators, etc., are constrained in terms of processing, communication capacity, battery, and memory . Also, the cost of these devices may increase when their performance increases in terms of processing, communication capacity, or the use of the battery to power them (e.g., active RFID tags are more expensive than the passive ones ).
18.104.22.168 Voluminous data and a continuous generation of spontaneous events
There are trillions of connected objects that are exchanging and storing hundreds of Exabytes of noisy data in IoT, and therefore forming an ultra-large-scale network . These sudden interactions among things will also continuously generate events causing network congestion .
22.214.171.124 Dynamic distributed infrastructure
The IoT network is considered as an
2.1.2 IoT applications characteristics
126.96.36.199 Diverse application domains
The IoT applications can be developed to cater to the needs of different domains and environments, having different requirements and deployment architectures, such as logistics and supply chain management, healthcare, environmental monitoring, smart home/buildings, smart agriculture. . Figure 3 gives an overview of the potential IoT applications.
188.8.131.52 Real-time delivery of data and services
IoT applications in some specific domains such as transportations and healthcare need to communicate real-time data and deliver on-time services to avoid critical situations .
184.108.40.206 Security and privacy concerns
In the IoT network, the security of applications and communications among the different nodes should be considered, along with the privacy of people’s captured data such as location, daily activities, buying habits . An efficient and scalable security mechanism should be implemented considering the
2.2 IoT middleware platform general architecture
Given the IoT infrastructure and applications’ characteristics stated above, and based on my previous research work done on middleware architecture for RFID , context aware, and ubiquitous computing , an IoT middleware solution can generally provide the following functionalities:
Device abstraction, discovery, management, and control: It includes interoperation among the heterogeneous connected devices/things using different standards. Application programming interfaces (APIs) are used for abstracting the communication with the physical layer and also for disseminating data and services to the different connected backend applications, hiding all details and complexities.
Data management and dissemination: It provides the different data preprocessing functionalities, such as filtering, duplicate removal, aggregation.
Context detection and processing
Security, privacy, and business rules processing
The IoT middleware architecture is depicted in Figure 4. The main layers include device abstraction and resource management layer, which handle the interoperability and interaction with the heterogeneous devices, and manage the low-level hardware parameters such as the used protocols, communication technologies, standards, and air interface; data management layer is responsible for storing and processing (filtering, aggregation, inference, etc.) the raw data captured by the different devices/things; event management and context detection layer include the application of policies and business rules requested by the applications (e.g., security and privacy rules); and application abstraction layer allows the communication of applications with the different devices and helps them to get the desired processed data and generated events from the middleware.
3. IoT middleware design considerations and requirements
The role of a middleware platform is to provide a software layer shielding the complexities of the hardware layer including the operating systems from the applications and allowing the applications’ developers to be concentrated mainly on the requirements/problem to be solved. As described in Section 2, in the context of IoT, there is a considerable variation in the used technologies, standards, and network communications. We describe herein, a set of design considerations and requirements for a middleware to suit the IoT infrastructure and application characteristics.
3.1 Resource discovery and management
Since the IoT infrastructure is dynamic by its nature, the IoT middleware should provide an automatic device discovery and enable the IoT heterogeneous hardware devices (e.g., RFIDs, sensors, smartphones) to detect their neighbors in the network and show their presence and available resources to them. In this case, the middleware should consider the characteristics of the resource-constrained IoT devices and be scalable in terms of the number of connected devices in the network. The middleware should also manage the devices, monitor their resource usage, and resolve any resource conflicts when potential and spontaneous new devices are connected to satisfy the application requirements.
3.2 Data management, context awareness, and event management
The IoT middleware should provide data management and processing functionalities to the backend applications; these include but are not limited to data detection and acquisition from the different connected devices/things, data preliminary processing, such as filtering, duplicate removal, compression, aggregation, and data storage. The IoT middleware should also manage the high number of generated events in an IoT environment, such as real-time dissemination of events to the applications, event transformation based on contextual/location data, and inferences.
The IoT-middleware should provide context detection and processing for it to adapt to smart applications requirements; it should collect context data and then process them to generate inferences and decisions. This could be achieved by using different techniques such as knowledge database, data mining algorithms, semantic context aware multimodal visualization approach, and the use of optimized message communication between the middleware users.
3.3 Scalability and adaptability
The IoT network can include a large number of connected things/devices and provide multiple services; therefore, the IoT middleware should be scalable allowing the growth of the IoT network, including the emergence of new heterogeneous devices that could be monitored, added, or removed without any impact on existing middleware functionalities, the provision of new services/functionalities, the addition/removal of network nodes, and the connection of multiple interesting applications in the middleware services without complexity. The use of IPv6, loose coupling, and virtualization are considered as useful ways for improving scalability in middleware solutions. Also, the use of a service-oriented architecture (SOA) makes the middleware flexible to the applications’ requirements in terms of new services. The IoT middleware should also be dynamically adaptive to the different circumstances and changes in the IoT environment.
3.4 Real-time data capture and services
The IoT network deals with multiple real-time/time-critical applications requiring a timeliness delivery of processed data and services without any delay, for example, healthcare applications; therefore, the middleware should provide real-time services and information to these applications. In this case, the middleware should manage the large data volumes detected from the multiple connected devices and therefore use novel methods to detect, process, and disseminate these data to the interested applications. The challenge of transaction handling, indexing, and querying these data should also be handled. This could be ensured through the use of agents, query processors, notification managers, etc.
3.5 Reliability and availability
Every component or layer in the IoT middleware should be operational including communication, data processing, events management, technologies, devices connectivity, and application management, even when failures occur. It should provide a stable service for applications/users even at times of failure. The middleware must also be available at all times for mission-critical applications that require a high fault tolerance, for example, medical applications; in the case of failure, the recovery time should be reduced to cater to the applications’ availability requirements.
3.6 Security and privacy
The IoT middleware should consider the security and privacy rules and policies required by the connected applications. The use of context awareness in the middleware can disclose some personal information about individuals such as location; therefore, it needs to protect people’s privacy using policies/rules/ontologies depending on the applications’ specific needs . Also, most of IoT middleware solutions are evolving into the cloud, which requires more mechanisms to be put in place to deal with the security and privacy issues, making users safe and protecting their personal data.
3.7 Ease of use and deployment
The IoT middleware should be lightweight, and easily used and deployed by the end-users of devices or applications without any complicated setup procedures.
3.8 Distributed implementation
If the IoT infrastructure is distributed, the middleware implementation should also be distributed, for example, when the devices, applications, and users are located in different geographical areas.
Some of the requirements stated above are considered to be mandatory for some applications while optional for others; for example, the real-time data capture and services are highly required in the case of medical applications, but it is optional for other applications that do not use timeliness information. However, the security, privacy, and interoperability functionalities are strictly required by all types of applications.
4. Overview of existing IoT middleware solutions
Many middleware solutions, using a single design approach (e.g., service-based, agent-based, database-based) or a hybrid one (combining different design approaches), and providing different functionalities in many application domains have been proposed and implemented in the IoT. These initiatives aim to offer a standard platform used to abstract the lower-level details of the connected physical devices and offer multiple services to the users and/or applications. In this chapter, the existing IoT middlewares are surveyed based on their used design approach and are grouped into six categories: service-oriented middleware, agent-based middleware, event-based middleware, virtual machine-based middleware, database-oriented middleware, and application-oriented middleware. A comparison of these design approaches is given in Table 1.
|IoT middleware requirements/features|
|Middleware approach||Middleware solutions||Target environment||Interoperability||Scalability||Adaptability||Real timeliness||Security and privacy||Reliability||Context awareness||Ease of use and deployment||Data management||Event management|
|Cloud-based Serivce-oriented||IoT, cloud||Yes||Yes||Yes||Yes||Yes||No||Yes||Yes||Yes||No|
|Microservices-based||Arrowhead Framework ||IoT||Yes||Yes||Yes||Yes||Yes||No||No||Yes||Data exchange||Yes|
|General microservice architecture ||IoT||Yes||Yes||Yes||Yes||Yes||No||Yes||Yes||Yes||Yes|
|Smart City ||IoT||Yes||Yes||Yes||Yes||Yes||No||Yes||Yes||Yes||Yes|
|Web of Objects Architecture ||IoT||Yes||Yes||Yes||Yes||No||No||Yes||yes||Yes||No|
|WSNs, Embedded Systems||No||No||No||Yes||Yes||No||Yes||Yes||No||No|
|Hermes||Large-scale distributed and ubiquitous systems||Yes||Yes||Yes||Yes||Yes||Yes||No||Yes||No||Yes|
|TinyCubus||Driver Assistance Systems||Yes||Yes||Yes||Yes||No||No||No||Yes||Yes||No|
4.1 Service-oriented middleware solutions
The service-oriented middleware (SOM), based on the service-oriented design pattern, provides services to the applications, such as service discovery and management, data management, and quality of service (QoS) management. There exist many service-oriented IoT middleware solutions. Some of the commonly used service-oriented IoT middleware solutions are described as follows:
There exist many other cloud-based service-oriented IoT middleware solutions, such as
Recent studies have been conducted concerning the design and implementation of service-oriented IoT middleware solutions including the one in  that suggests a middleware based on REST API to collect data from different devices, intending to deal with the heterogeneity issues. The authors in  presented a 3SOA (Sensing-as-a-Service run-time Service-Oriented Architecture) middleware solution that allows interoperability among IoT platforms, and highly abstracts the applications from the low-level details of IoT hardware platforms and communication languages.
In conclusion, most old SOMs manage only WSNs and do not scale to the use of multiple heterogeneous devices as in the context of IoT. Recent suggested service-based middleware platforms provide solutions for the interoperability and heterogeneity problems; however, they still offer a limited security through the use of authentication, do not use unified service standards, and require automation for service configuration and optimization due to the recurring demands of new services by the interesting applications.
Another type of microservices-based architecture has been recently proposed to develop IoT platforms that meet the heterogeneous and distributed nature of IoT devices, and provide dynamic, scalable, maintainable, and interoperable IoT environments. Delsing et al.  propose an Arrowhead Framework architecture enabling scalability, security, and real-time performance in a multi-cloud setting. This architecture supports multiple IoT devices based on SOA architecture in local clouds to exchange inter- and intra-cloud information, and allows organizations to move toward a multi-stakeholder cooperation catering to market requirements and supporting efficiency, flexibility, and sustainability .
A general microservice architecture for IoT applications development is proposed by Sun et al. , providing flexibility, scalability, maintainability, light-weightness, and loose coupling to deal with the different challenges of the continuous IoT development. The authors focus on the system design based on microservices and device communication protocols used between the service layer and physical device layer. This framework allows, therefore, more interoperability, automation, and intelligence and provides big data and geo-localization services .
Another recent architecture based on microservices is proposed by Lai et al.  to provide IoT services for multi-mobility in a smart city. The architecture provides flexibility and scalability to efficiently manage the different heterogeneous IoT devices using independent microservices, which could be separately deployed in a distributed system . The authors used real-case scenarios to test the architecture using multi-mobility services for citizens in a smart city.
A recent study  also shows how the use of a framework based on microservices allows to mitigate the critical challenges of IoT devices and applications, and increases their scalability when deployed in the ocean where there is a continuous increasing growth of big data.
Many other microservices-based IoT platforms have been proposed in various application domains such as smart farms , smart logistics/factories , smart cars , and smart commerce . Jarwar et al.  also proposed a cross-domain/general-purpose Web of Objects Architecture for IoT service provisioning in which a virtual object is used as an abstraction of a physical object.
4.2 Agent-based middleware solutions
Agent-based middleware solutions use mobile agents to facilitate distribution throughout the network and allow a partial failure tolerance. The use of mobile agents in the IoT network provides many advantages including interoperability with the heterogeneous devices, reliability and availability, resource and code management taking into consideration the resource-constrained devices, and application management. Some of the most commonly used agent-based middleware solutions are highlighted below.
Other examples of agent-based WSN middleware solutions include
The authors in  present a new approach for increasing the smart objects’ self-adaptation and allowing them to make autonomous decisions and be smarter based on a multi-agent system (MAS). The authors in  also presented a new multi-agent-based approach called ACOSO (Agent-based Cooperating Smart Objects) and its related middleware catering for the heterogeneous IoT platforms. The flexibility and effectiveness of this middleware were proved through the implementation of a “Smart University system.”
The autonomous behavior of agents used in middleware solutions may lead to the IoT network’s self-organization and fault tolerance. However, the dynamic behavior of agents may lead to message loss; therefore, most of the above-discussed middleware solutions could not be used within the large-scale IoT networks requiring a heterogeneous infrastructure, including resource-constrained devices.
4.3 Event-based middleware solutions
All the components of an event-based middleware solution use a publish/subscribe model; the event sending component is called the producer or publisher, and the receiving component is called the consumer or subscriber. The consumers are registered for a particular event published by the producers for which they are frequently receiving notifications. The event-based approach provides timeliness, security, scalability, availability, reliability, and fault tolerance.
The authors in  proposed an event-based middleware solution implemented using the publish-subscribe pattern to solve the problem of interoperability in IoT. The interoperability assessment methodology was used to test the middleware performance, and it was shown that it is qualified compared to previous systems.
There exist many other event-based middleware solutions including
4.4 Virtual machine-based middleware solutions
The virtual machine (VM) middleware approach considers virtualizing the network infrastructure, where the different network nodes are holding a VM and applications are designed as separate modules distributed throughout the network. This ensures self-management, and a high level of abstraction and adaptability.
There exist some middleware solutions based on Java virtual machine (JVM), such as
The application-specific virtual machine (ASVM) approach has been developed to target specific application domains. Middleware solutions based on this approach include but are not limited to
4.5 Database-oriented middleware solutions
The whole network in this type of middleware solution is viewed as a relational database, managed using a query language like SQL. For example, the
4.6 Application-oriented middleware solutions
Application-oriented middleware solutions are dedicated to specific domain requirements and infrastructure. For example, the
The application-specific approach leads to the design of special-purpose middleware systems dedicated to a specific application domain, using a centralized mechanism for resource discovery. This makes them unsuitable for the distributed and fault-tolerant nature of IoT environments.
4.7 Hybrid approach middleware solutions
There exist some middleware platforms using a hybrid approach, combining two or more design approaches stated above. For example, both
Table 1 shows the IoT requirements/features available in each middleware design approach and provides a comparison of the different IoT middleware solutions described in Section 4. The choice of the comparison criteria is based on the works cited above, from which the most common, essential, critical, and important characteristics that are shared between the different IoT platforms have been extracted. The description of each criterion is given above in Section 3 (IoT Middleware Design Considerations and Requirements). There exist many additional/non-functional criteria and features, which could be available in some IoT platforms such as recoverability, fault-tolerance, maintainability, configurability, mobility, reusability. But these are not subject of this review since it targets only the most essential design features/functionalities of IoT middleware solutions.
5. Open issues in IoT middleware design
According to the previous comparison, most of the works concentrate their efforts on providing basic functionalities such as ease of deployment, data management, event management, and real-timeliness. A considerable effort must be made in interoperability and adaptability, which allows devices/things using heterogeneous protocols to connect. Context awareness is also a feature that is not considered by most of the described middleware solutions and still encounters many shortcomings. In addition, security and privacy features need particular attention from researchers, because they are missed in almost all the reviewed middleware solutions above.
In summary, the most challenging issues that still persist in IoT-middleware design, implementation, and deployment are listed below:
Standardization: The use of heterogeneous devices within a variety of application domains in the IoT makes the use of a single standard for a middleware solution impossible. However, many research works tend to implement a standardized middleware solution for a specific domain, such as semantic web applications domain, sensor networking environments, and smart offices [59, 65]. This will allow application developers to select a middleware solution following the desired standard within a certain domain.
Storage capacity: The storage capacity of the heterogeneous connected things within the IoT should be considered when implementing a middleware solution. For example, if the middleware solution offers many services and data management functions, it will be difficult to use it with low-level storage devices. This issue could be addressed by defining storage requirements by the different types of backend applications, taking into consideration the application domain, before choosing an adequate middleware solution.
Security and privacy: IoT middleware solutions can rely on a single layer for providing security and privacy to the backend applications, or distribute the security and privacy support among all the middleware layers. Either way, security and privacy support will add more processing overhead to the middleware platform, and it should also take into consideration the security and privacy requirements and rules for each specific application with minimum overhead.
Applications abstraction: The IoT middleware should include an application abstraction layer to allow multiple backend applications to be registered with the middleware, and to specify the set of services and data processing functions needed. The applications can also specify policies/rules concerning some functionalities, such as context awareness, security, privacy, data processing, and event processing and inferences.
6. Conclusion and future work
Middleware is becoming a necessity for managing heterogeneous devices in the IoT network and developing applications in different domains. There exist a variety of middleware platforms designed for IoT. This chapter provides a detailed overview of existing IoT middleware solutions, and discusses the technical challenges and open issues involved in designing these platforms including device and application abstraction, scalability, context awareness, event management, unfixed infrastructure, security, and privacy. In future work, the open issues in IoT could be further investigated to suggest possible new approaches to solve them. Also, a new middleware design approach may be proposed to include a new perspective for managing the IoT devices/things and applications, including a solution for the unexplored open issues in a specific application domain, such as security, privacy, and interoperability. A test of this new approach could be performed using my previous proposed middleware solution for RFID described in .