IOT Middleware

There are several ways to process and integrate data but due the lack of standards and the heterogeneity of the “things”, a key role is played by the middleware.
Middleware is application-independent software that provides services that allow communications between applications. Middleware hides the complexities of the lower layers, like operating system and network, in order to ease the integration of new and legacy systems. It allows the “things” and the application layer to connect without having to worry about the different operating systems, networks or resources server layers [1].

Fig. 1. Layers of Data

Like the cloud, IoT brought with it a large number of middleware solutions as:

  • GSN abstracts the sensor through virtual sensors across XML files. The communication model is peer-to-peer, allows discovery, but does not support any kind of QoS or security.
  • DDS is a real time middleware that addresses peer-to-peer, device-to-device, device-to-cloud and cloud-to-cloud communication and also supports QoS and security.
  •  LinkSmart comes from a European research project to develop a middleware based on Service Oriented Architecture (SOA) for network embedded systems. As a result it was created a software gateway which acts as a bridge between the applications and the IoT devices. This middleware is so far the only one that allows, through a network manager that does registry and discovery, hot deployment and control of components during execution, which is an advantage when critical devices cannot be rebooted. Also provides a topic based publish-subscribe service, secure identity and encrypted communications.

Even if they aren’t middleware, I think it’s important to mention the Constrained Application Protocol (CoAP) and the Devices Profile for Web Services (DPWS), because they also help to provide integration between the devices and the application layer:

  •  CoAP is a protocol designed for M2M applications which provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources. CoAP is designed to ease the interface with HTTP for integration with the Web. It provides multicast support; very low overhead, and due it’s low requirements, it’s good for constrained environments. CoAP, in contrast to HTTP, uses asynchronous communication to push information from servers to clients with REST over UDP, which helps reduce the transfer overheads [2].
  •  DPWS, called also Web Services on Devices (WSD), is based on existing Web Services standards like XML, WSDL, XML Schema, SOAP, MTOM, and HTTP [3]. DPWS allows sending secure messages through web services, web service discovery, web service description and sub-scribe/receive events through a Web service [4].

Even though there is no standard architecture, it is possible to verify an attempt to use SOA as a way to standardise the integration between devices. And the lack of standardisation is one of the issues that we need to solve in IoT.

  1. Linthicum, D.S.: Enterprise Application Integration. Addison-Wesley, Boston (2000)
  2. The Constrained Application Protocol.
  3. Introducing DPWS
  4. Devices Profile for Web Services.

Leave a Comment

Your email address will not be published. Required fields are marked *