Keywords

1 Introduction

Explicit client-server nature of web service composition standards warrant determination and specification of WS provider address at the design time, resulting in applications that does not possess several important quality attributes such as loose coupling and separation of concern in a distributed computing environment (Venkatesan and Sridhar 2016, 2017). This deficiency shows up sorely in situations such as integration of IoT devices using web services standards where consumer cannot statically specify the provider URI addresses at the design time. This deficiency has forced IoT technology to groom kludges and low level ad-hoc protocol techniques to accomplish integration (Al-Fuqaha et al. 2015). This work presents a middleware based orchestration technology (that breaks off client-server nature of orchestration) and expand on the idea presented in Venkatesan and Sridhar (2016, 2017). A case based (Yin 2003) illustration is a good way to present and evaluate the outcome of the novel ideas and so this work adopts the case of IoT device integration. It should be noted the proposed protocol and middleware should be capable of handling integration with smart objects/small devices (that are power/resource constrained) that may have difficulties in dealing with protocols and SOA technologies designed for full-powered computers. Results obtained in this case may be extended subsequently to a more general situation and WS standards may be suitably amended.

This work is organized into 6 sections. Section 1 introduces the problem and outlines an approach and context of the solution. Section 2 describes over all architectural layout for message based orchestration (IEEE-FIPA 2018) using intelligent middleware namely OIMS. It describes the consumer application namely Intelligent Open Interaction Application Framework (IOIAF), messaging format used by IOIAF, its manner of interaction with OIMS and algorithm used by OIMS to determine and invoke WS providers. Section 3 describes the application layer level interaction protocol patterns, and implementation details of a working prototype (GitHub hosted) that uses Microsoft Windows Communication Foundation (WCF) technology (Sharp 2017). Section 4 analyses the results and makes a comparison with other popular IoT integration protocols. Section 5 provides a review of related literature. Section 6 provides a conclusion and proposal for further work. The suggested middleware technology is inspired by the works of Okouya et al. (2013).

2 The Open Interaction System Middleware

Venkatesan and Sridhar (2016) and Chap. 8 of Venkatesan (2018) propose an application layer protocol for integration of IoT devices using speech act messages and WS technology (as depicted in Fig. 1). This application involve a centralized web services consumer namely Intelligent Open Interaction Application Framework (IOIAF) based controller/dashboard, an agent oriented middleware service namely OIMS that provides facility to receive and transmit (IEEE-FIPA standard like speech act messages that carry information to carry out WS orchestration on providers using SOAP messages) across an ecosystem of IoT compute nodes connected to it. OIMS services act as intermediaries in relaying the messages to appropriate WS provider destination. The deployment level block diagram of this environment is depicted in Fig. 1.

Fig. 1.
figure 1

Block diagram of IoT integration environment

Full size image

A schematic of the proposed integration environment is provided in the Fig. 2. This environment utilizes Microsoft Windows WCF ver. 4.5 technology at OIMS to realize discovery of partnerlink services, enumerate them, enumerate services interfaces/input and output parameters and bind with them to invoke. Interaction between IOIAF service and OIMSs take place using Microsoft Message Queue (MSMQ) technology where the messages are of FIPA-ACL kind as described in subsequent section. For light-weight cases where performance and simplicity is the criteria, the interaction between IOIAF and OIMS is alternatively realized designed using WCF itself as it is the case between OIMS and IoT leaf nodes. A IOIAF server shall connect with one or more OIMS middleware servers using user supplied configuration information. OIMS in turn connect with other OIMS or IoT leaf nodes to execute the contract as indicated by IOIAF application.

Fig. 2.
figure 2

Schematic of IOIAF orchestrator, OIMS middleware and IOT device (WS-Partner Link) leaf nodes

Full size image

The operational algorithm of IOIAF service is described in the Fig. 3. The designer and programmer decide on the syntax and semantics of speech act messages based on nature of requirement demanded by the end user or business case. IOIAF service sends this message to various connected OIMS middleware service nodes. OIMS middleware service receives the IOIAF messages and decodes them to understand the nature of partner link invocation to be performed by it (for example asking for a specific set of sensor data from IoT node service). Based on the SA it communicates with various IoT nodes connected to it and consolidate the result and reply back to IOIAF server. The SA based interaction models (requirement scenarios) also provides hints that can be translated into system level functional test cases.

Fig. 3.
figure 3

IOIAF application (WS-Consumer) node “Processing” logic

Full size image

The algorithmic description of OIMS capability is depicted in Fig. 4. Typically the IoT integration specific OIMS network shall have one or more controller or dashboard, each subscribing to an unspecified number of leaf IoT nodes and collect/control information and process (in accordance with the type of collaboration as listed in Table 1). While the centralized dashboard (such as closed loop video surveillance network) shall use “ask” and “tell” speech acts through OIMS and other network gateways on the IP network, a local dashboard application of an operation theater instruments shall use subscription to selective IoT devices without intervention of gateways or centralized servers but with the help of OIMS alone).

Fig. 4.
figure 4

Processing control loop in OIMS

Full size image
Table 1. Patterns of interaction between IOIAF and OIMS
Full size table

The OIMS makes use of WS-Addressing technology (for synchronous real-time data processing/Message queues (for asynchronous data processing) along with WS-Eventing technology to realize much of its infrastructure based loosely coupled integration capability. It may be noted OIMS and IOIAF support scalability like per-instance, per-session or per-call semantics based service provisioning to support state based, configuration based, service rendering in the case of multiple IOIAF dashboards on the same shared physical network infrastructure – say a server farm - as in the case of, for example a hospital network that has separate dashboards (IOIAF applications) for video surveillance, visitor service, patient service, hospital housekeeping, patient monitoring etc.… that all still uses same OIMS middleware – say that are running on the network intermediary hardware – capable of supporting and sustaining multiple conceptual logical IoT networks using same WS executable using scalability (per-session invocation) logic.

The number of OIMS middleware attached to IOIAF server can be handled using different approaches. A straightforward approach is to provide a configuration file to IOIAF server that lists the IP addresses of the attached OIMS middleware servers. This work uses ioiafconfig.ini (Fig. 5a) to supply a list of OIMS nodes connected to IOIAF server. Alternatively the available list of OIMS nodes connected to an IOIAF server can be determined and discovered by a dynamic discovery protocol for OIMS middleware (like the case of DHCP or DNS server discovery). In turn, OIMS middleware server node is further configured using a “oimsconfig.ini” (Fig. 5b) file. This file provides a list of class of connected IoT networks its network-interface. OIMS search periodically over the entire subnet address space (wired or wireless) to discover available leaf nodes (i.e. IoTClient nodes), at the given moment, using node discovery protocols. This work uses a polling scheme for each IP address. Once the connected IoT leaf nodes are determined, OIMS will start interrogating the IoT leaf nodes for data as indicated by OIMS messages delivered to it by IOIAF server.

Fig. 5.
figure 5

(a) IOIAFconfig.ini (b) OIMSconfig.ini (C) IoTNodeSvc.ini

Full size image

The IoT sensor nodes can also be configured to inform like the name of the sensors connected to it and the port details of the sensors (or hardware connection Id) (Fig. 5c). All these configuration information should use a shared ontology so that the received “commands” (from IOIAF application and OIMS messages) and reported “data values” are understood without ambiguity. This will help the entire IoT network work in a standardized manner and able to serve various custom queries. In cases where no standard compliance is available in IoI node, the IOIAF application need to specialize its messages taking into account specific terminology adopted by custom IoT device class. This research work uses a configuration file namely Iotnodesvc.ini (Fig. 5c) to supply configuration information of (simulated) IoT leaf node. This research assumes each IoT node runs a WS to permit data acquisition or else has at least provides a proprietary custom WS for data acquisition details of which can be supplied to the interfacing OIMS as customized node specific orchestration information for a specified unique node Id.

End users will invoke IOIAF application with a process initialization argument (i.e. command-line argument) specifying its application identification. Corresponding application identification must be there in the ioiafconfig.ini so that this particular instance of IOIAF service goes on to initialize OIMS service instance belonging to it completing the bootstrap of network of monitoring application chain (to accomplish a given business functionality). Based on the logic of application architecture, a single IOIAF application instance can serve multiple business functionality.

OIMS and IOIAF server instances are controlled as to how these instances are created and destroyed by setting ServiceBehavior’s InstanceContextMode along with configuration details to be used at the service deployment/invocation time. The implementation details of IOIAF, OIMS and simulated IoT services are documented and hosted in GitHub for easy exploration and experimentation (SIVAN 2018).

3 The Business Logic Based Patterns of Integration in IOIAF Environment

Various kind of business use case served by this arrangement involves, IOIAF application (WS-consumer) periodically sending messages encoding its intention of gathering IoT data from WS-providers (IoT nodes) as Agent Communication Language (IEEE-FIPA 2018) like-message payload (as illustrated in Table 1). This message can have different level of sophistication in describing the URI of the intended providers starting from syntactic encoding (as implemented in this work) to OWL-S based semantic encoding (Sect. 3 in Venkatesan and Sridhar 2017). OIMS in turn determine choice of WS providers to connect to and the nature of the contract to execute (SIVAN 2018; Venkatesan and Sridhar 2016, 2017). Some examples of the syntactic messages originated by IOIAF server is depicted in Table 1.

The mechanism of the orchestration of IoT services described here gives rise to the possibility of realizing application layer level protocol that permit creation of complex integration applications. This capability is called as Message Based Service Integration (MBSI) protocol in this work. Section 4 provides a survey and comparison of capabilities of various IoT (application level) integration protocols including that of MBSI. Table 2 reveal the nature and technical implication of using these protocols for developing data gathering or monitoring end user applications.

Table 2. Comparison of popular IoT protocols
Full size table

A snapshot of the sample experiment carried out to gather data from an IoT network of nodes involving multiple OIMS is illustrated in Fig. 6 below.

Fig. 6.
figure 6

A snapshot of IOIAF dashboard gathering sensor data from IoT network

Full size image

The manner of OIMS based WS orchestration envisaged here is quite a different kind of business workflow compared to regular Process Aware Information Systems (PAIS)/business applications (Aalst 2009). Presently PAIS typically invoke providers using flow based technology (i.e. events, activities, gateways) and is entirely based on design time decisions. The proposal made here is not disruptive and only adds a new layer of features above existing standards and infrastructure. Hence it is a kind of incremental innovation or suggestion.

4 Related Work

Higher-level business processes can be created – that are solution to business problems - by composing web services together. Service composition standards (Dustdar and Wolfgang 2005) provide standards-based, an open approach to connect web services with reduced complexity. WS standards (Weerawarana et al. 2005) reduces time and costs, and increase overall efficiency in formulating software for businesses problems. A well-established method of composing web services to create business applications is to use WS-BPEL (WS-BPEL 2007). BPEL is a model based, flow based, XML-based, imperative WS composition language which supports WS technology stack fully. However due to static nature of the orchestration provided in this language, it is not suited for IoT integration unless extensions are implemented to the BPEL engine/language (Venkatesan and Sridhar 2017). Okouya et al. (2013) propose middleware technology for integrating applications using speech-act like messages. This work draws inspiration and hints from that work to formulate the novelty presented here. Blake and Gomaa (2005) provides an early account of agent based cross organizational workflow composition. However it lacks a rigorous specification and description of capabilities of agent oriented middleware. It also did not provide an operational description how to realize the system making it a theoretical treatise.

The hardware limitations of IoT devices make design of software application unique and challenging. Jawad et al. (2017) provides a survey of various issues involved in integrating constrained devices in agricultural field monitoring including IoT integration issues. For example regular application level protocols like HTTP, SOAP may not work if one ignores network topology, packet size limitation and data rates and frequency of packet transaction. Hence software applications should explicitly address these constraints in designing IoT application such as minimize unwanted processing, reduce network data transaction.

Most of the existing application level protocols (given in Table 2) do not anticipate or take into account future changes in network topology, application architectures and IoT software stack evolution. Protocol innovations for IoT integration related can be applied to any layers of the network such as physical layer, data link layer, network layer and application layer. This work specifically addresses problems of integration at the application level protocol only. New IoT specific protocols (Al-Fuqaha et al. 2015) tends to reduce data errors, avoid unwanted re-transmission, keep simple flow of data, avoid complex buffering/computation algorithms (saving on RAM/CPU cycles) to reorganize packets, increase reliability and wireless range. But one of the main issues here is difficulty of writing device integration, control and monitoring applications using these protocols. They do not offer satisfying experience for varying technical and practical reasons and offer little room for evolution and capability to coexist with newer developments. Presently bus based and broker based approaches are popular to network these devices. Some popular application level protocols include Message Queue Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP), Constrained Application Protocol (COAP), Java Message Service (JMS), Data distribution Service (DDS), Representational State Transfer (REST) and Extensible Message and Presence Protocol (XMPP). Table 2 provides a survey and comparison of capabilities of various IoT application level integration protocols including the Message Based Service Integration (MBSI) protocol proposed here. Venkatesan and Sridhar (2019) argues agent metaphor based system modeling and software development result in manageable and intuitive information systems. Venkatesan and Sridhar (2018a) argues agent metaphor based information system modeling and development result in superior model driven development software environment. Hence this work embraces agent oriented approach to realize the middleware solution.

5 Conclusion

This work presented an agent oriented approach to WS application composition and business logic enactment that fuses technological sophistication of WS technologies/standards and theoretical depth of agent oriented system modelling and engineering. Due to space limitation a comparative and experimental evaluation MBSI protocol with other IoT application level protocol is not carried out here. This work highlighted only a few elementary cases of patterns of interaction between IOIAF, OIMS and IoTNode services. This work did not carry out a comparative experimental evaluation of (possibility of) realization of patterns of interaction in other IoT protocols discussed here. These deficiencies need to be addressed in an elaborate study in the near future. From the conceptual viewpoint, the pattern of interaction described here in purely syntactical. This environment can be extended to permit varieties of application integration such as semantic web technology standard based partner/provider identification (using SPARQL, for example). The results arrived here can be utilized to formulate and extend orchestration standards by incorporating WS infrastructure support for the kind of orchestration approach envisaged here. These extensions remain to be carried out in the future.