PaperlayerView exact revision on arXiv

Source-linked AI summary

Middleware Technologies for Cloud of Things - a survey

Amirhossein Farahzadia, Pooyan Shams, Javad Rezazadeh, Reza Farahbakhsh

arXiv:1705.00387v1cs.DC

TL;DR

Large IoT environments face resource, storage, and scalability pressures, while heterogeneous objects make platform design challenging. This survey examines middleware technologies for CoT through features, architectures, platform comparisons, and open issues. It concludes that CoT-based middleware suits several massive-data applications without hard real-time needs, while non-CoT middleware may be more usable where hard real-time processing is needed.

  • Problem

    Large-scale IoT infrastructure faces resource, storage, and scalability challenges, and heterogeneity complicates CoT platform design.

    Source: §I · p. 2

  • Method

    The survey reviews middleware features and architectures, compares selected platforms, and discusses open challenges in CoT.

    Source: §VI · p. 9, §VIII · pp. 19–20

  • Results

    The survey finds CoT-based middleware suitable for several massive-data use cases without hard real-time needs, while non-CoT middleware may be more usable in domains requiring hard real-time processing.

    Source: H. Standardization needs · p. 19

  • Takeaways & Limitations

    The survey identifies standardization as a challenge and suggests a layered model as a possible future direction, while noting that heterogeneity may make it complex.

    Source: H. Standardization needs · p. 19

Abstract

from arXiv · show

The next wave of communication and applications rely on the new services provided by Internet of Things which is becoming an important aspect in human and machines future. The IoT services are a key solution for providing smart environments in homes, buildings and cities. In the era of a massive number of connected things and objects with a high grow rate, several challenges have been raised such as management, aggregation and storage for big produced data. In order to tackle some of these issues, cloud computing emerged to IoT as Cloud of Things (CoT) which provides virtually unlimited cloud services to enhance the large scale IoT platforms. There are several factors to be considered in design and implementation of a CoT platform. One of the most important and challenging problems is the heterogeneity of different objects. This problem can be addressed by deploying suitable "Middleware". Middleware sits between things and applications that make a reliable platform for communication among things with different interfaces, operating systems, and architectures. The main aim of this paper is to study the middleware technologies for CoT. Toward this end, we first present the main features and characteristics of middlewares. Next we study different architecture styles and service domains. Then we presents several middlewares that are suitable for CoT based platforms and lastly a list of current challenges and issues in design of CoT based middlewares is discussed.

I. INTRODUCTION

The paper examines middleware’s role in CoT, where cloud services address some resource and scalability pressures in large IoT systems, while middleware helps address heterogeneity. It reviews prior work, presents middleware features and architectures, compares platforms, and discusses open challenges.

I. INTRODUCTION

  • CoT combines IoT with cloud computing to address resource, storage, and scalability challenges in large-scale IoT infrastructure.The paper identifies middleware as a key CoT enabling technology.Source: §I · p. 2
  • Middleware sits between applications and objects, addressing heterogeneity, interoperability, security, and dependability in CoT.The paper focuses on middleware technologies and their roles and necessities in CoT.Source: §I · p. 2

II. LITERATURE REVIEW

  • Commercial CoT platforms described include GroveStreams for device data analytics, EVRYTHNG for digital product identification, and Fusion Connect for no-code operations.Fusion Connect is described as supporting analytics, maintenance automation, and supply-chain-related services.Source: §II · pp. 3–4
  • The literature review identifies a lack of dedicated studies on middleware in CoT as the study’s motivation.Prior work discussed CoT integration and middleware topics including service-oriented approaches, semantic interoperability, sensor processing, and e-healthcare.Source: §II · pp. 3–4

III. FEATURES AND CHARACTERISTICS OF MIDDLEWARES

Middleware provides a flexible abstraction layer between heterogeneous things and applications. The section describes flexibility and transparency while noting that flexibility must be matched to system requirements.

III. FEATURES AND CHARACTERISTICS OF MIDDLEWARES

  • Middleware provides an abstraction between things and applications, concealing complexity so they can communicate with limited knowledge of each other.The paper presents middleware as an enabler of communication among heterogeneous things.Source: §III · p. 4

A. Flexibility

  • Flexibility moves some concerns about application–thing communication to middleware, but its level should reflect system needs and resource constraints.High flexibility can require more connectivity APIs and processing workforce, which may not suit ultra-resource-constrained IoT networks.Source: A. Flexibility · p. 4

B. Transparency

  • Transparency hides platform and network details, allowing clients and servers to work without prior platform knowledge and users to access local or remote resources without knowing their location.The paper distinguishes platform transparency from network transparency.Source: B. Transparency · p. 4

C. Context Management

Middleware features address coordination, interoperability, reuse, portability, maintainability, resource discovery, and trust in heterogeneous CoT environments. Their descriptions connect these capabilities to changing contexts, device diversity, and service continuity.

C. Context Management

  • Context management coordinates service or subject settings across applications and supports programs or threads working across tasks.The paper describes it as important to context-aware systems and to handling the technical, logical, and physical diversity of CoT objects.Source: C. Context Management · p. 4

D. Interoperability

  • Interoperability enables applications on interconnected networks to exchange data and services despite differing protocols, data models, and configurations.The passage links interoperability to standardization and says its degree depends on environmental or component heterogeneity.Source: D. Interoperability · p. 5

E. Re-usability

  • SOA-based middleware can support software and hardware reuse because no specific technology imposes its service-implementation policies.The paper associates reuse with easier development and cost efficiency.Source: E. Re-usability · p. 5

F. Platform Portability

  • Portability supports movement across platforms and independence from network protocols, programming languages, and operating systems.The paper distinguishes platform independence, which uses virtual machines, from portability, which adapts applications to a new environment with reasonable user effort.Source: F. Platform Portability · p. 5

G. Maintainability

  • Maintainability matters as CoT deployments grow, since extending networks or fixing bugs without it can become overwhelming.The passage recommends defined procedures, infrastructure, documentation, and feedback checklists for stable, extendable middleware.Source: G. Maintainability · p. 5

H. Resource Discovery

  • Resource discovery searches network nodes for intended resources and selects a suitable service or data source, while needing to cope with frequent failures.The passage recommends self-stabilizing algorithms to return the system to an ordinary state despite transient failures.Source: H. Resource Discovery · p. 6

I. Trustworthiness Management

  • Trustworthiness management supports trust relationships among applications through mechanisms such as authentication, hashing, and encryption.The passage connects these mechanisms to checking that services and information come from trustworthy systems.Source: §I · p. 6

J. Adaptability

The section discusses middleware responses to changing environments, security and privacy needs, and heterogeneous connectivity. It also compares architecture styles and describes component-based design as modular and loosely coupled.

J. Adaptability

  • Adaptability concerns middleware response to changes such as mobility, power drain, and topology shifts, including through dynamic adaptation services.The passage describes adaptability as durability against long-term system changes and says it is critical in hard real-time systems.Source: J. Adaptability · p. 6

L. Connectivity Convergence

  • Connectivity convergence is needed because applications and objects use varied communication technologies, from WiFi and Bluetooth to Zigbee, RFID, and analog signals.The passage identifies connectivity APIs and management as essential and links this feature to interoperability.Source: L. Connectivity Convergence · p. 6

IV. ARCHITECTURAL COMPARISON OF MIDDLEWARES

  • The paper categorizes middleware architectures as distributed, component-based, service-based, node-based, centralized, and client-server, comparing their benefits and challenges.It also presents a table categorizing known middleware platforms by application domain and architecture style.Source: §IV · pp. 6–7, Table I · p. 7

A. Component-based

  • Component-based architecture uses loosely coupled, independent, cohesive modules, each responsible for part of a problem.Its stated objectives include encapsulation, minimal dependency, reusability, and easier troubleshooting.Source: A. Component-based · p. 7

B. Distributed

The section outlines middleware architecture styles and the characteristics that distinguish them. The styles vary in how components communicate, where services reside, and how client work is divided.

B. Distributed

  • Distributed architectures coordinate networked software and hardware components, offering fault tolerance, scalability, concurrency, flexibility, and resource sharing.Components on different platforms and machines can cooperate on a shared goal; CORBA, .NET, and J2EE are cited as supporting frameworks.Source: B. Distributed · p. 7

C. Service-based

  • SOA-based middleware lets devices expose functionality as standard services that can be discovered and invoked, either standalone or through cloud PaaS.Its synchronous consumer–producer communication makes it unsuitable for strict real-time response needs; tightly coupled architectures are preferred in that case.Source: C. Service-based · p. 7

D. Node-based

  • Node-based architectures use software components across mobile and sensor networks to communicate and process sensor data through streams between nodes.The passage describes this design as suitable for mobile devices.Source: D. Node-based · pp. 7–8

E. Centralized

  • Centralized architectures gather services at a resource-rich server, with thin devices sending requests and no direct communication between application instances.A central-server failure can disable the network unless a backup server takes over immediately.Source: E. Centralized · p. 8

F. Client-server

  • Client-server middleware separates request and reply roles, with thin clients providing the GUI, thick clients running applications, or multi-tier designs separating functions physically.Device roles can be ambiguous because a device may act as both client and server; CaSP uses this model to separate processing and sensing.Source: F. Client-server · p. 8

V. MIDDLEWARE SERVICE DOMAIN

Middleware service domains address the services needed in heterogeneous environments, from exchanging and managing data to object and application communication. The paper also compares selected middleware platforms across features and applications.

V. MIDDLEWARE SERVICE DOMAIN

  • Middleware service domains identify services for heterogeneous environments, and each domain may contain multiple subdomains.The paper introduces several domains and then discusses their functions.Source: §V · p. 8

A. Information exchange and storing

  • Information-exchange and storage services let users send requests through middleware to other nodes or store information in databases.The passage situates these services in distributed, ubiquitous, and pervasive IoT environments, including context-aware management of smart environments.Source: A. Information exchange and storing · p. 8

B. Data management and analytics

  • Data-management and analytics services cover databases, security, quality, metadata, acquisition, processing, and analysis, including statistics extraction and visualization for user applications.The passage also describes user-defined policies and identifies big-data management and processing as concerns these services address.Source: B. Data management and analytics · p. 8

C. Object middleware

  • Object middleware, including object request brokers, manages communication among objects; combined with RPC, it supports remote object and procedure calls with synchronous or asynchronous interactions.Source: C. Object middleware · p. 8

D. Communication

  • Communication middleware abstracts network protocols and provides a framework for applications to negotiate and exchange data in distributed systems; DDSS is one example.Search engines WebCrawler and GRank combine capabilities from multiple middleware domains.Source: D. Communication · p. 9

VI. COMPARISON OF SAMPLE MIDDLEWARES

  • The paper compares 20 middleware platforms by functionality and application, selecting examples for coverage of architecture styles, domains, commercialization, and infrastructure.LinkSmart is cited as a platform offering a wide range of services.Source: §VI · p. 9

A. C-MOSDEN

The section profiles C-MOSDEN, Xively, and ThingWorx as middleware platforms with distinct sensing, connectivity, management, and analytics capabilities. Their described functions range from on-demand mobile sensing to enterprise product management and application development.

A. C-MOSDEN

  • C-MOSDEN uses context-, activity-, and location-aware modules with on-demand distributed crowd sensing to collect requested data through cloud-supervised worker nodes.It aims to reduce processing and storage costs, time, battery use, and network traffic; its activity module recognizes six activities, and GSN supports sensor integration and distributed queries.Source: A. C-MOSDEN · pp. 9–10

B. Xively

  • Xively provides scalable connectivity, data engagement, and product-management features, using MQTT and Blueprint Templates to structure device and user information.Its connected product management platform supports product setup and data gathering, while integration features connect product data with existing business systems.Source: B. Xively · pp. 10–11

C. ThingWorx

  • ThingWorx supports MQTT, XMPP, CoAP, and DDS, and combines application-building tools with analytics for real-time pattern detection, anomaly alerts, and prediction.Mashup Builder enables interactive applications, dashboards, and mobile interfaces without coding; its platform also supports industrial connectivity and modeling of things and their properties.Source: C. ThingWorx · p. 11

D. Carriots

The section describes five middleware examples for cloud-connected IoT settings, spanning M2M project management, service composition, device interoperability, mobile-cloud integration, and car parking. Their architectures combine cloud services with gateways, sensors, or application tiers.

D. Carriots

  • Carriots is a PaaS for M2M projects that collects and stores device data, supports integrations and security controls, and lets users execute Groovy code in the cloud.It includes remote device management and is described as scaling from prototypes to millions of devices.Source: D. Carriots · pp. 11–12

E. CHOReOS

  • CHOReOS composes large-scale web services for IoT, cloud, and Internet-of-services settings through modules for service composition, access, discovery, and cloud/grid middleware.Its cloud/grid components include storage, grid computing, and an enactment engine; these components export RESTful services.Source: E. CHOReOS · p. 12

F. Rimware

  • Rimware places middleware between cloud and network-of-things components, using gateway adapters and cloud-side controls for interoperability, security, scalability, and energy savings.It uses profile-based protocols to support discovery across vendors and BLE to help lower energy consumption.Source: F. Rimware · p. 12

G. DropLock

  • DropLock demonstrates a mobile-device, sensor, and cloud architecture for smart cities, with network, data, system, and security-management service domains.The described framework calls for authentication, encryption during transfer, lightweight cryptography for resource-constrained devices, and cloud-based privacy management.Source: G. DropLock · pp. 12–13

H. ABC&S - based car parking middleware

  • The ABC&S car-parking middleware uses sensor, communication, and application layers, with cloud, web-server, and mobile-app tiers for parking services.Its cloud cluster combines Kafka for messaging and load balancing, Storm for processing, and HDFS for datasets accessible by web applications in real time.Source: H. ABC&S - based car parking middleware · p. 13

I. OpenIoT

The surveyed middleware platforms address different combinations of semantic interoperability, context awareness, mobility, adaptation, and sensor-network management. Their designs range from cloud-based services to peer-to-peer containers and mobile proxies.

I. OpenIoT

  • OpenIoT combines semantic interoperability in the Cloud with mobile-sensor discovery, privacy and security services, and visual application-development tools.Its SSN ontology supports semantic unification; CUPUS and X-GSN support sensor-data collection and cloud storage.Source: §I · p. 13

J. Aura

  • Aura uses a mobile personal proxy and nearby surrogate servers to adapt to new environments and amplify resource-limited clients through cyber foraging.The reliability and quality of connections between surrogates and nodes matter.Source: J. Aura · p. 14

K. Capnet

  • Capnet adapts component placement between mobile clients and fixed servers according to application or component resource requirements.It also supports context management, service discovery, and asynchronous messaging for mobile multimedia applications.Source: K. Capnet · p. 14

L. CARISMA

  • CARISMA uses reflection and policies for context-responsive messaging, supporting both deployment-time configurability and run-time reconfigurability.Its policies include plain, compressed, and encrypted message exchange.Source: L. CARISMA · p. 14

M. LinkSmart

  • LinkSmart collects context-provider data through push and pull protocols and targets secure, trustworthy, fault-tolerant applications in domains including health care and smart homes.Its design also supports distributed or centralized architectures.Source: M. LinkSmart · p. 14

N. GSN

  • GSN hides sensor-network complexity in peer-to-peer containers and uses virtual sensors as its main abstraction.Its Virtual Sensor Manager controls data delivery and resources; its stream-management component supports stream QoS.Source: N. GSN · pp. 14–15

O. COPAL

These middleware examples use different ways to manage context, devices, and services, including runtime context provisioning, active-space coordination, peer-to-peer reasoning, ontology-based context, and messaging for e-health.

O. COPAL

  • COPAL separates context sources from processing through runtime provisioning, using Publishers for devices and Listeners for context-aware services.Wrappers address device and communication heterogeneity, while loose coupling supports new sources, information models, and processing requirements.Source: O. COPAL · p. 15

P. Gaia

  • Gaia coordinates heterogeneous devices and software services in active spaces through a kernel, application framework, and five basic services.Its user-centric applications can use task context to detect meaningful information in incoherent data.Source: P. Gaia · p. 15

Q. UPnP

  • The UPnP-based home-network approach adds user profile and context management at an intermediate node to address limited context awareness in typical UPnP.Context aggregators provide uniform contextual information to the middleware’s context-management module.Source: Q. UPnP · p. 15

R. CoMiHoC

  • CoMiHoC supports peer-to-peer context management and situation reasoning in MANETs using location models and context relevancy ratings.Its context provisioner, request manager, and situation reasoner manage relevant contexts and buffered queries; the authors identify temporal relevancy, uncertainty, distributed control, and fault tolerance as challenges.Source: R. CoMiHoC · pp. 15–16

S. SOCAM

  • SOCAM represents context as ontology markup in a two-level hierarchy, linking domain-specific low-level ontologies with a generalized ontology.Its autonomous services acquire, discover, interpret, and provide access to context across pervasive systems.Source: S. SOCAM · p. 16

T. VIRTUS

  • VIRTUS uses XMPP-based publish/subscribe messaging for real-time communication among heterogeneous devices in e-health settings.It can acknowledge message arrival and report when a destination user is offline, and supports resource-rich, resource-poor, and simple devices.Source: T. VIRTUS · p. 16

VII. CHALLENGES AND ISSUES

The paper identifies open CoT middleware challenges spanning real-time prioritization, resource discovery, security and privacy, healthcare interfaces, constrained devices, and fog-versus-cloud placement.

A. Near Real-Time Prioritizing

  • CoT middleware often cannot prioritize unforeseen tasks in real time, although applications such as hospitals may need urgent patient data surfaced according to sickness severity.The paper calls for mechanisms to assess unforeseen situations and allocate cloud services according to request importance.Source: A. Near Real-Time Prioritizing · p. 16

B. Proper Resource Discovery Implementation

  • Dynamic topology, mobility, bursty networks, and asynchronous protocols complicate resource discovery, while existing approaches are described as incomplete.XMPP, UPnP, and WSDiscovery are identified as the most widely used discovery protocols.Source: B. Proper Resource Discovery… · p. 17

C. Users Security and Privacy Enhancement

  • CoT security depends on cloud-provider guarantees in the surveyed middleware, motivating user-side monitoring of cloud operations; frequent context changes and constrained devices also challenge common authentication methods.The paper also identifies exposure to malicious devices as a privacy concern.Source: C. Users Security and Privacy… · p. 17

D. Supporting Various Interface Protocol for Ehealtcare domain

  • E-health middleware must support flexible interface protocols for implanted or wearable devices, while the paper notes inadequate attention to possible harmful effects of communication signals on people.Millimeter-wave side effects and threats are cited as an example.Source: D. Supporting Various Interface… · p. 17

E. A light weight CoT-based Middleware for Ultra resources constrained devices

  • Internet of Nano Things devices constrain processing, energy, storage, and communication range, motivating lightweight dedicated CoT middleware.The paper links IoNT’s appeal to cost efficiency and high deployment density.Source: E. A light weight CoT-based Middleware… · p. 17

F. Finding optimal place for analysis data by Fog Computing

  • Fog can provide computation, storage, and networking near IoT end nodes, but selecting Fog, Cloud, or a combination for varied task deadlines remains challenging.The paper says recent work had not successfully implemented accurate assessment of the optimal processing location or resource combination.Source: F. Finding optimal place for analysis… · pp. 17–18

G. Providing Quality of Service

The paper presents Fog as a possible aid for CoT quality of service, identifies standardization as an unresolved challenge, and concludes that CoT and non-CoT middleware suit different application needs.

G. Providing Quality of Service

  • Dynamic networks and Cloud limitations make CoT service-level agreement and quality-of-service guarantees difficult; Fog can help meet basic bandwidth, delay, jitter, and packet-drop requirements.The authors say researchers still need mechanisms to deploy these requirements efficiently.Source: G. Providing Quality of Service · pp. 18–19

H. Standardization needs

  • The review identifies a lack of standardization in middleware design and suggests a layered model, while noting that IoT heterogeneity could add complexity.Source: H. Standardization needs · p. 19

VIII. CONCLUSION

  • The conclusion contrasts CoT middleware for massive-data applications without hard real-time needs with non-CoT middleware for domains needing hard real-time processing.The paper names social, smart-home, smart-city, agriculture, animal-farming, smart-grid, and retail applications for CoT, and industrial control, e-healthcare, and smart logistics for non-CoT.Source: H. Standardization needs · p. 19

Related papers

Loading 1705.00387v1…