Integration Approaches for the Internet of Things (IoT) Era

Abstract

The aura and era of the Internet of Things (IoT) have started to beckon and dawn upon us, with the overwhelming use of promising, proven, and potential technologies. Our living, working, social, edutainment, and entertainment places are being decked to be lively and lovely. The systematic adoption and adaption of digital technologies are to bring a series of disruptions and transformations in our lives. The dreamt digital living is bound to see the light at the end of the long tunnel. Such kinds of local as well as remote connectivity capability of all kinds of constituents and participants in any particular environment make the environment smart. In this chapter, we aim to exclusively describe the connectivity technologies and tools and their contributions for setting up and sustaining smarter environments (smarter homes, hospitals, hotels, etc.) and ultimately the smarter planet.

Glossary

Devices Profile for Web Services (DPWS )

Is for the device world, that is, creating, consuming, connecting, and controlling Web services for the resource-constrained embedded devices. A key concept is the creation of a distributed SOA within heterogeneous environments. DPWS defines a minimal set of standards and specifications in order to provide Web service-based communication for embedded devices. It identifies a core set of Web service specifications comprising the following areas: secure message transmission, dynamic discovery, description, subscription, and event notification.

OSGi

Caters for the integration of the pre-built reusable and collaborative components, reducing maintenance costs by delivering and updating provided services dynamically. The core of the OSGi specification comprises the OSGi framework which provides an execution platform for Java-based components, called bundles. The platform allows install, uninstall, start, stop, and update bundles at runtime without restarting the entire system. Attaching a fragment bundle to its host bundle provides the ability to extend the host bundle’s class path with classes or additional resources. Bundles offer their functionality in the form of services by means of a publish-find-bind mechanism. For this purpose, a service registry is used where bundles can register their services under one or more interfaces and search for other services. Moreover, the OSGi framework contains a service tracker which notifies registered listeners about service registration changes. A generic mechanism to subscribe and receive events from services or the framework itself is provided through the event admin service. OSGi runs in a Java virtual machine (JVM) and offers an intra-JVM SOA .

Service Component Architecture (SCA)

Is a set of specifications which describe a model for building applications and systems using a SOA . SCA models solutions as sets of service components offering services and making references to services supplied by others, which are combined together by composites which wire references to services and which declaratively apply bindings for communication methods and also apply policies for aspects such as security and transactions. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.

Service-oriented architecture (SOA )

SOA is an emerging architectural style to achieve high interoperability of heterogeneous software components and systems. Web services implement this principle and provide a convenient way of creating flexible service-oriented solutions.

WS-Addressing

The main objective of WS-Addressing is to provide an addressing mechanism for Web services as well as messages in a transport-neutral matter. By introducing both concepts, endpoint references (EPR) and message information headers (MI), WS-Addressing overcomes the lack of SOAP ’s independence of underlying protocols and secondly support of asynchronous message exchange. Both limitations are historically caused by the default SOAP to HTTP binding.

WS-Discovery

Is a discovery protocol based on IP multicast for enabling services to be discovered automatically. Discovery introduces three different endpoint types: target service, client, and discovery proxy. Target services are Web services offering themselves to the network. Clients may search for target services and discover them dynamically. Discovery proxy is an endpoint enabling discovery in spanned networks since simple discovery is limited to a multicast group and hence to local managed networks only. WS-Discovery defines four operations or messages to discover target services in a network. To explicitly discover target services in a network, a client can use the Probe operation and send as multicast message. Matching target services will answer with the Probe matches operation sent as UDP unicast message to the client. To implicitly discover target services, a client can listen for hello and bye messages. A target service announces its availability with these messages sent as UDP multicast. To resolve logical addresses introduced with the endpoint structure in WS-Addressing, a client can use the resolve operation sent as UDP multicast message. The corresponding target service responds with the resolve matches operation sent as UDP unicast to the client. The discovery proxy does not need any additional operations.

WS-Eventing

Defines a protocol for managing subscriptions for a Web service-based eventing mechanism. This protocol defines three endpoints: subscriber, event source, and subscription manager. Subscribers request subscriptions on behalf of event sinks to receive events from event sources. Subscription requests contain an event delivery mode and event filter mechanism to negotiate event delivery mechanisms and event filter mechanism. Subscription managers are responsible of holding subscriptions of event sources.

WS-MetadataExchange/WS-Transfer—WS-MetadataExchange

Is a specification that defines data types and operations to retrieve metadata associated with an endpoint. This metadata describes what other endpoints need to know to interact with the described endpoint. WS-MetadataExchange defines the MetadataSection that divides the metadata into separate units of metadata with a dialect specifying its type. Until the latest version of DPWS, only WS-MetadataExchange was used for service and device description and retrieval. In the latest DPWS version of February 2006, WS-Transfer is used to retrieve the metadata. The structure of the metadata is still as specified in WS-MetadataExchange. The main difference is that WS-MetadataExchange defined operations to retrieve all or parts of the metadata of an endpoint, whereas WS-Transfer only can be used to retrieve all metadata of an endpoint.