1. Middleware for Internet of Things: A Survey
Aditya Bhanje
Athul Iddya

2. "Middleware for Internet of Things: A Survey" from IEEE Internet of Things Journal
Mohammad Abdur Razzaque, Marija Milojevic-Jevric, Andrei Palade, and Siobhán Clarke

3. Definition of “Internet of Things”
“A world-wide network of interconnected objects uniquely addressable, based on standard communication protocols”
Things include a very wide variety of elements such as:
Industrial Objects
Personal Objects
Elements in our environment

4. IoT Infrastructure Characteristics
Heterogeneous devices
Resource-constrained
Spontaneous interaction
Ultra-large-scale network and large number of events
Distributed and dynamic network
Context and Location-awareness
Intelligence

5. Middleware in IoT and its Requirements
Provides a software layer between applications, the operating system and the network communications layers
Facilitates and coordinates some aspect of cooperative processing
In brief, a middleware provides a layer between application software and system software
Middleware requirements can be grouped into two sets:
Functional and non-functional requirements
Architectural requirements

6. Functional Requirements

7. Resource Discovery Requirements Challenges Automated
Scale well and efficient distribution of load discovery
Challenges
Tradeoffs between registry discovery and number of registries
Research is required in probabilistic models for IoT
Deal with trade offs between distribution of registries and number of registries - smaller number provides consistency and speed, but doesn’t scale well for large networks
Probabilistic model is used for matching a search with its results - better as it scales well, but cannot guarantee service discovery

8. Resource Management Requirements Challenges
Monitoring of resource usage
Resolving resource conflicts and fair distribution of resources
Challenges
Frequent conflicts during resource allocation
Agent-based cooperative conflict resolution is a possible solution

9. Data Management Requirements Challenges
Data acquisition, data processing and data storage
Challenges
Data transmission is more expensive than local processing
Support for data filtering and data compression is sparse

10. Event Management Requirements Challenges
Real time analysis of high velocity data
Challenges
Rate of event handling is untested
Middleware might become a bottleneck

11. Code Management Requirements Challenges
Code allocation and code migration services
Challenges
Deploying updates is complicated
Some types of middleware support code management, but none of them support updating both application code and firmware code

12. Non-functional Requirements

13. Scalability Requirements Challenges
Accommodate growth in the network size and application/services
Challenges
Middleware designed for wireless sensor networks might not scale to ultra-large-scale networks
Each system component has to scale

14. Real Time Requirements Challenges Provide real-time services
On-time delivery of information or services
Challenges
Some middleware approaches are non-real time by design
Rest support soft-real time, none support hard-real time

15. Reliability Requirements Challenges
Each component needs to be reliable for overall reliability of system
Challenges
Not addressed in most middleware
Synergies between reliability and other requirements could be exploited

16. Availability Requirements Challenges
Zero or small recovery time and failure frequency to achieve desired availability
Challenges
Service availability should be resilient to hardware failure

17. Security and Privacy Requirements Challenges
Preserve owner’s privacy and provide security to all blocks of middleware
Challenges
Authentication-based security is insufficient
Holistic solution is needed

18. Ease of Deployment Requirements Challenges
No expert knowledge should be required
Challenges
Remote deployment without preconfiguration is a challenge

19. Popularity Requirements Challenges
Middleware should be continuously supported and extended
Challenges
Growing an active community is a challenge

20. Architectural Requirements

21. Programming Abstraction
Requirements
Isolation of applications or services development from the underlying, heterogeneous IoT infrastructures
Challenges
Steep learning curve
Providing an API is important any middleware
High-level interface to abstract away the underlying heterogeneity and network structure
APIs can often be complicated - challenge is to make a simple API that is easily understandable but also powerful

22. Interoperable Requirements Challenges
A middleware should work with heterogeneous devices/technologies/applications, without additional effort from the application or service developer
Challenges
Network interoperability is well-supported, but semantic and syntactic interoperability are not
Service-based approach offers the best semantic interoperability, but syntactic interoperability is rare
Middleware should be able to handle differences in network structure, syntax and semantics between IoT devices
Syntax - Structure of data/information should be understandable to the other
Semantics - Meaning of data/information should be understandable to the other

23. Service-based Requirements Challenges
Offer high flexibility for new and advanced functions added to middleware
Services like data management, reliability and security provide abstraction for complex functionality
Challenges
Services should be designed while keeping resource constraints in mind
Service discovery needs to be autonomous
Middleware should be service-based to allow easy addition of new functionality
It allows abstraction of complex functionality for easy application development

24. Adaptive Requirements Challenges
Able to evolve to fit itself into changes in circumstances such as in network or application demands
Challenges
Decision-making is often hard coded
Dynamic and context-aware adaptation to QoS requirements is absent
Middleware needs to be able to handle changes in network or application demands

25. Context-aware, Distributed and Autonomous
Requirements
Context-awareness is important for building adaptive systems and to establish values from sensed data
Middleware should be self-governed, without any human intervention
Support functions that are distributed across physical infrastructure of the IoT
Challenges
Exploitation of context in resource discovery, data management is missing
Most middleware cannot adapt themselves to self-* behaviour such as self-adaptiveness and machine-to-machine communication
Middleware should be able to aware of the context of users and devices
Sensed data should be accompanied by context such as location (spatial) and time (temporal)

26. Types of IoT Middleware
Event-based
Service-oriented
VM-based
Agent-based
Tuple-spaces
Database-oriented
Application-specific

27. Event-based Application components are split into publishers and users
Uses publish-subscribe pattern
Events are classified by topic and published through a database to select users that are subscribed
This design addresses non-functional requirements such as reliability, availability, real-time performance, scalability, and security

28. Service-oriented
Application components are split based on functionality into services
Services are reusable, loosely-coupled, composable and discoverable
Requirements have to be addressed through functionalities like service discovery, service, data and QoS management
Ultra-large-scale network and resource-constrained devices makes service discovery and composition challenging

29. VM-based
Applications are divided into smaller modules that are spread throughout the network
Each node holds a VM, which runs the modules
Provide safe-execution environment through virtualization
This provides high-level programming abstraction, self-management and adaptivity

30. Agent-based
Applications are divided into modular programs that spread through the network using mobile agents
This creates a decentralized system that can handle failures
This addresses requirements like resource and code management, availability, reliability and adaptiveness
This approach can work well with resource-constrained devices

31. Tuple spaces Each node has a local space to store tuples
The middleware creates a federated tuple space on a gateway that provides read and write access to users
The federated tuple space stores the tuples in tuple spaces of individual nodes
This approach works well with devices with mobile devices that stay connected to a gateway

32. Database-oriented
The sensor network is viewed as a virtual relational database system
Data is accessed through a SQL-like query language
This enables support for complex queries
Implementation is similar to a distributed database system
Somewhat similar to tuple-based approach
No support for real time access

33. Application-specific
Optimizes network infrastructure for specific application
Takes application domain requirements into consideration
Focuses on resource management such as QoS

34. Conclusion
The paper formulates a list of key characteristics of IoT and requirements for IoT middleware
It judges the middlewares based on how well each of them addresses the requirements
It classifies the middleware based on their architecture and identifies the requirements addressed by each type of middleware
It identifies gaps in the requirements addressed by each type of middleware and recommends areas of focus for future research

35. Thank you!