This section presents our middleware architecture, connector management mechanism, and connector generation process. At the end, we describe different deployment scenarios to emphasize the high compatibility of our proposal with different IoT system components (e.g., mobiles, gateways, and cloud-based platforms).
4.3.1 System Architecture Overview
Our framework simplifies the creation and management process of heterogeneous connec-tivity by wrapping the complex establishing and connecting functionalities in the RESTful web services that are efficiently handled by end-users. Figure 4.1 depicts our framework architecture composed of three different layers that are described below.
4.3. IoT Framework for Connectors 37
Figure 4.1 – The architecture overview of our framework.
• Service Enablement Layer: This layer consists of several web services used to directly interact with the framework. There are four primary services including con-nector management, concon-nector discovery, access control and concon-nector template man-agement. These services supports: (i) discovering connector, (ii) CRUD operations on connector and connector template, (iii) activating, de-activating connector and (iv) access control based on session token.
• Processing and Storage Layer: This layer contains databases and primary func-tions to generate the connectors and pre-process data. These databases store the configuration of the connectors, connector templates. The functions manages the Connector Generation Process and Data Processing Services. The details of these services are described in Section 4.3.4.
• Connection Layer: This layer consists of several connectors used to handle the connections from IoT Things. Our framework supports two types of connectors
-“Connector In” and -“Connector Out”. They are analogous to in” and “proxy-out” concepts introduced in [191]. Each type of connector supports HTTP, MQTT, CoAP and WebSocket (WS) connectivity respectively to retrieve data from sensor, actuator, gateway and open data sharing services. This is extending the “collection proxies” concept presented in [192]. Moreover, this layer keeps tracking the connector status via connector management module. The end user can manage this status via provide web services.
4.3.2 Connector Generation Elements
To facilitate the connector generation for end-user, we proposeConnectivity Configuration Template (CTT) files that contains the major configurations of connectivity like connec-tion properties, and data descripconnec-tions. This file is encoded under XML format is simplicity,
openness, and extensibility. The CTT’s content is coherent and convenient for both human and machine. Moreover, the structure of CTT is roughly equivalent to network packets cor-responding to supported connections. Fig. 4.2 illustrates an example of a CTT file used to establish an HTTP connection toAccuweather, an open data sharing service about weather information.
Figure 4.2 – An example of Connection Template.
From Figure 4.2, the necessary connection properties are a host address, port number, con-nection method, and path address. The header element defines the HTTP configurations such as content type, authentication information, and HTTP parameters. The next element describes the HTTP payload. Each data in this payload is defined by a “infor” tag that has three attributes: (i) a “place” attribute describes the HTTP object storing the payload, such as HTTP body or HTTP header, (ii) a “type” attribute describes the type of the data like string or number, (iii) a “path” attribute defines the specific location of data in the payload.
The connector is a piece of code, which is used to open connectivity and perform data acquisition. In addition, it anotates the raw data by using define vocabularies which in-crease the interoperability. In general, the connector structure consists of three distinct parts with the different responsibilities to (i) open the connection based on the received in the CTT file, (ii) de-capsulate and process the data from the received network packet, (iii) manage the connector status via the web services. The connector functionalities are triggered by incoming network packets or defined interval time to obtain data from open data sharing services. The framework effectively manages the connector by using a unique name. In case multiple devices connect to the same connector, their device identities are used. The position of the device identity is defined in the connector content. For example, in Figure 4.2, the device identity is retrieved via “device” parameter in HTTP header. The connector is created by combining CTT andConnector Template (CT). CT is a composed script with the marked position which is filled by the extracted information from CTT to create the connector. Each connector type has specific CT.
4.3. IoT Framework for Connectors 39
4.3.3 The Framework Process
Figure 4.3 – The framework in operation
The primary tasks of our framework are presented in Fig. 4.3. The end-users must follow these steps to create and manage the connectors. Firstly, they send a desired connection protocol (e.g., HTTP, MQTT) to the framework by the web services. Then, the framework responses a CTT file corresponding with the demanded connection. Secondly, the end-users fill the CTT file with connectivity configurations, such as host address, port number before returning to the framework to trigger the connector generation process. Finally, the framework generates the desired connector based on the received CTT file and responses the connector identity to the user.
4.3.4 Connector Generation Process
Figure 4.4 – The operational diagram.
The connector generation is triggered when the framework receives the CTT file via the Service Enablement Layer. To support the non-specialist end-users, the CCT file can be delivered to end-users in advance by using RESTful web services. In the next step, the framework extracts the vital information from received CTT and injects it into proper positions in the CT file. Then, this CT file is executed to generate the connector. In the end, the new connector is stored in the database and registered with connection layer. The general process is illustrated in Fig. 4.4.
4.3.5 Connector Management
To effectively manage the connectors, we propose Connector Management Component (CMP) located in the Connection Layer. CMP manages all existing connectors follow-ing Resource Oriented Model [193]. Each connector is identified via unique name used to discover connector resources via a “Connector discovery” component in the Service Enable-ment Layer. At first declaration, the framework registers the new connector with CMP using its name. Then, CMP allocates a set of RESTful web services to the registered connector. Our framework supports basic management actions on a connector including CRUD, activation, and deactivation. For instance, after successful creating, a connector is associated with “active” status and ready for operating. The end-user can deactivate the connector by triggering “deactivate” action.
4.3.6 Deployment Scenarios
Our framework is implemented using Node.js programming language, a JavaScript run-time built on Chrome’s V8 JavaScript engine supporting event-driven, non-blocking I/O model [194]. Therefore, it is lightweight enough to deploy in the wide-range M2M objects, such as gateways, cloud-based systems, and even smartphones. This capability makes the proposed framework flexible to integrate into various parts of the IoT ecosystem. For a large-scale enterprise using various communication technologies, our framework can be de-ployed to the gateways to facilitate the connection process for new devices and quickly adapt to the changes of configuration from network providers. In the real scenario, the framework is deployed in a cloud-based system used to simplify connecting process to het-erogeneous devices through LPWAN connectivity. In the other perspective, our framework can be implemented as a data acquisition layer in other frameworks like SIGHTED [195]
or as a proxy layer in a lightweight framework for efficient M2M device management in the oneM2M Architecture [196] to accelerate the connection process.