Based on the functional models, various types of IoT middleware have been proposed. Middlewares have been used in various application domains to facilitate communication between heterogeneous systems. For instance, in the industrial automation, OPC is used to bridge communication between the device on the shop floor with the supervisory control and data acquisition (SCADA) (Zheng & Nakagawa, 2002).
IoT middlewares proposed different IoT architectures. Some works followed a layered architecture to mimic the 7 OSI layer, for instance, the five-layer architecture depicted in the Figure 31 (D. Bandyopadhyay & Sen, 2011). It places the internet in the middle as the main communication media. The edge layer manages devices such as embedded systems, sensors, actuators, and ID tags. The access gateway layer manages the bridge for different communication technologies to the internet protocols. The main task of this layer is performing a routing optimization, bridging the different communication protocols to the internet protocols (e.g., TCP/IP), and forwarding data from the edge nodes to the other end
49
across the internet. The middleware layer provides generic interfaces for the applications to communicate with the IoT.
Figure 31. Generic Layered Architecture for IoT (D. Bandyopadhyay & Sen, 2011) In addition, many approaches have been used for abstracting IoT devices as well as the programming model. Figure 32 shows the classification of approaches taken in designing a middleware used for wireless sensor networks (Hadim & Mohamed, 2006). It shows that the current WSN middleware abstract sensor networks, e.g., as a database which can be queried using SQL-like language or the application may communicate with the nodes through messages.
Interestingly, SOA middleware has been proposed quite often to support the integration of between “Things” and the legacy systems while providing interoperable Web Services for the applications to access (Jammes & Smit, 2005; de Souza et al., 2008; Markus Eisenhauer et al., 2009; Spiess et al., 2009).
Figure 32. Classification of middleware approaches for wireless sensor network (Hadim & Mohamed, 2006)
SOA middleware for IoT exposes device capabilities as Web Services that can be accessed from any programming language that supports HTTP and XML. It introduces a service management layer whose task is to deal with service discovery, execution monitoring, and configuration. For the discovery purposes, a service registry such as Universal Description, Discovery and Integration (UDDI)31 is usually used. Supporting the applications, some of the SOA middlewares provide a Service-Composition. Service-Composition allows developers to create an executable workflow indicating the order and conditions to execute the services. The workflow could be expressed in Web Service composition languages such as Web Services
Business Process Execution Language (WSBPEL)32 which then fed to a processing engine which executes the Web Service calls accordingly.
Although Web Services have been widely adopted within the enterprise environment, its reliance on XML format made it difficult to penetrate IoT scenarios, particularly when dealing with embedded system with limited computing resources. There exist more efficient data formats that can be used for embedded system communication such as JSON (Crockford, 2006) or binary XML (W. Lu et al., 2006).
Figure 33. SOA-based architecture for the IoT middleware (Atzori et al., 2010)
4.1.3.1 LinkSmart Middleware
LinkSmart is a service-oriented middleware that facilitates IoT communications through Web Services. LinkSmart represents real-world objects by software proxies running on physical devices or gateways that are able to run an OSGi Framework33. The proxies communicate with the physical devices through heterogeneous communication protocols. On the other end, the proxies provide Web Services that encapsulate these various communication protocols for the applications.
32 https://www.oasis-open.org/committees/ tc_home.php?wg_abbrev=wsbpel (Retrieved on June 20, 2014) 33 http://www.osgi.org/Technology/WhatIsOSGi (Retrieved on June 20, 2014)
51
Figure 34. LinkSmart Architecture34
Additionally, LinkSmart makes all Web Service calls to remote proxies appear as local Web- Service calls since the applications have to consume Web Services through a component called Network Manager with a local host address(Milagro et al., 2009). When the network manager receives a Web Service call from the applications, it is responsible for forwarding the calls through an overlay P2P network to the actual service providers as well as the responses from the remote services to the local applications as depicted in Figure 34. Moreover, the Network Manager can be used as a service registry where the proxies could register their services, and the applications could discover the ID of the services of the proxies. Every Network Manager keeps a list of services that have registered to it and exchange the list with other Network managers that are connected to the same P2P network. This makes the network manager to act as a decentralized service registry for the LinkSmart applications.
Enabling publish-subscribe communication pattern, LinkSmart provides an event broker that works based on Web Services. The event subscribers may subscribe to the events with particular topics. The subscriber must provide a Web Service callback method that conforms to the LinkSmart event subscriber interface. The event broker relays events from the event publishers to the corresponding event subscribers by calling the callback Web Service. This is useful for the input and sensor devices to notify the applications when new data are available. LinkSmart does not offer a structured approach for IoT application development as it assumes that the application could simply consume the Web Service provided by the proxies. Alternatively, application developers could take advantage of the existing service orchestration approaches to orchestrate services offered by the proxies. However, the existing service orchestration frameworks such as Business Process Model and Notation (BPMN) (White, 2004) are designed to orchestrate high-level software services that have different characteristics than physical devices. For instance, many embedded devices operate in a more time critical environment. Moreover, sensor data usually contain measurement noise and
34 https://linksmart.eu/redmine/projects/linksmart-opensource/wiki/LinkSmart_Architecture_2x (Retrieved on Oct 20, 2014)
without a proper context, they provide less meaningful data. Therefore, complex calculations sometimes must be done on the sensor data to provide a contextualized information, which is more meaningful than the raw sensor data.