Middleware Applications

#### **Chapter 1**

## Middleware Solutions for the Internet of Things: A Survey

*Mehdia Ajana El Khaddar*

#### **Abstract**

The Internet of Things (IoT), along with its wider variants including numerous technologies, things, and people: the Internet of Everything (IoE) and the Internet of Nano Things (IoNT), are considered as part of the Internet of the future and ubiquitous computing allowing the communication among billions of smart devices and objects, and have recently drawn a very significant research attention. In these approaches, there are varieties of heterogeneous devices empowered by new capabilities and interacting with each other to achieve specific applications in different domains. A middleware layer is therefore required to abstract the physical layer details of the smart IoT devices and ease the complex and challenging task of developing multiple backend applications. In this chapter, an overview of IoT technologies, architecture, and main applications is given first and then followed by a comprehensive survey on the most recently used and proposed middleware solutions designed for IoT networks. In addition, open issues in IoT middleware design and future works in the field of middleware development are highlighted.

**Keywords:** Internet of Things (IoT), WSNs, radio frequency identification (RFID), virtual machine, events, services, middleware architecture, context awareness, ubiquitous computing, machine-to-machine (M2M) communication

#### **1. Introduction**

Nowadays, various new generation-connected objects or things are invading our daily lives including sensors, radio frequency identification (RFID) tags, smartphones, wearables, and actuators among others, due to the emergence of new technologies. With the development of cloud computing and wireless technologies, and the emergence of new connected devices at a decreasing price, the IoT market is expected to grow rapidly fostering the development of applications in different domains, including but not limited to healthcare, manufacturing, logistics and transportation, traffic management, home automation, smart cities, smart grids, smart agriculture, etc. [1]. These applications will use the raw data generated by the different connected things/ objects and provide new services in the targeted domains [2]. The Global System for Mobile Communications Association (GSMA) forecasts that "by 2025, the IoT connections will reach almost 25 billion globally" [3]. These predictions are therefore highlighting the role of IoT in providing new ways of communication over the Internet.

The IoT network is considered a heterogeneous network with a complex structure, connecting a wide range of devices using different evolving technologies such as Bluetooth, ZigBee, Wi-Fi, 3G, 4G, 5G. The ubiquitous computing environment of IoT connecting heterogeneous devices, technologies, and applications, and generating a

large number of events continuously brings in important and new challenges, such as interoperability, security, confidentiality, privacy, and energy-efficient operations [4]. For example, location tracking by the IoT devices may be allowed by some people to get personalized services; however, it may violate their privacy. The middleware, which is a software application, can hide the things details from the applications by communicating with the heterogeneous connected devices/things, filtering the raw captured data, and processing them before dissemination to the connected applications, and therefore easing the backend applications' development and offering multiple common services [5]. The middleware can also deal with the interoperability, security, and privacy issues facing the IoT. The IoT middleware development is an active research area; there exist many middleware solutions addressing the IoT environment requirements in terms of context awareness, scalability, interoperability across heterogeneous things, device management, data storage and management, security, privacy, and service deployment. A major challenge faced by application developers today is finding the most appropriate IoT middleware solution in terms of the provided functionalities that should meet the application requirements and the underlying used technologies. Therefore, the existing works on IoT middleware architecture need to be analyzed to address their existing technical challenges, issues, and gaps in this domain and suggest further improvements. This chapter provides a detailed overview of existing middleware solutions for IoT and is organized as follows: Section 2 provides background about IoT characteristics, architecture, and applications, and gives an overview of the IoT middleware general architecture. Section 3 presents the IoT middleware design considerations and requirements. Section 4 provides a comprehensive review of currently existing research work in designing IoT middleware platforms. Section 5 discusses criteria for choosing the right platform according to the application requirements, along with some open issues and challenges, and the last Section 6 provides some concluding comments recommending future research directions in this area.

### **2. Background**

#### **2.1 IoT architecture and applications**

The Internet of Things (IoT) consists of two words: The "Internet" is defined "a network of networks and a global system of interconnected computer networks that use TCP/IP as a standard Internet Protocol (IP) to connect millions of users and multiple private, public, academic, business, and government networks," and "Things" include "any real-world object/physical element such as home appliances, clothes, smartphones, etc. or living things like people, animals, or plants" [6]. The International Telecommunication Union (ITU) considers IoT as "a worldwide network of interconnected objects, allowing anything and anyone to be connected, anytime and anyplace using any network and any service" [7]. Therefore, in IoT, many heterogeneous devices will be connected to the Internet and will provide a large volume of data and even services. The major components of IoT include wireless sensors and actuators networks, machine-to-machine (M2M) communications, and RFID/near-field communication (NFC) as shown in **Figure 1**.

#### *2.1.1 IoT infrastructure characteristics*

#### *<IP_ADDRESS> Heterogeneous intelligent devices*

In IoT, heterogeneous devices in terms of features, capacities, sensor computing natures (high end, middle end, and low end), costs, embedded intelligence

*Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

(adapting to the context, environment, and circumstances), and from different vendors are expected to communicate and exchange information [8]. Also, new types of devices are emerging continuously in the future as new technologies are developed [8]. **Figure 2** shows the main technologies used in IoT.

#### *<IP_ADDRESS> Context and location awareness*

The different connected devices/things capture large volumes of data that need further processing; it should be filtered, interpreted, and put in a context to have a meaning. Context awareness helps to make the interpretation of data easier by adding context information to the raw data captured by the IoT things, which allows performing M2M communication that is considered a core element in an IoT environment [9].

**Figure 2.** *IoT technologies.*

Also, the spatial/location information about things is important to understand their interactions with other surrounding things (e.g., objects and people) [10].

#### *<IP_ADDRESS> Limited resources*

IoT devices including small embedded sensors, RFID tags and readers, actuators, etc., are constrained in terms of processing, communication capacity, battery, and memory [8]. Also, the cost of these devices may increase when their performance increases in terms of processing, communication capacity, or the use of the battery to power them (e.g., active RFID tags are more expensive than the passive ones [5]).

#### *<IP_ADDRESS> Voluminous data and a continuous generation of spontaneous events*

There are trillions of connected objects that are exchanging and storing hundreds of Exabytes of noisy data in IoT, and therefore forming an ultra-large-scale network [11]. These sudden interactions among things will also continuously generate events causing network congestion [11].

#### *<IP_ADDRESS> Dynamic distributed infrastructure*

The IoT network is considered as an *ad hoc* network; there is no dedicated server for managing the resources of devices/things, and devices can join or leave the network anytime they want, or they can disconnect due to battery power shortage or connectivity problems. Cooperation between nodes will be needed to keep an active and stable network, and support multiple applications' development [11]. Therefore, the IoT network is considered a globally distributed network like the Internet and a local one within an application domain/context.

#### *2.1.2 IoT applications characteristics*

#### *<IP_ADDRESS> Diverse application domains*

The IoT applications can be developed to cater to the needs of different domains and environments, having different requirements and deployment architectures, such as logistics and supply chain management, healthcare, environmental monitoring, smart home/buildings, smart agriculture [6]. **Figure 3** gives an overview of the potential IoT applications.

#### *<IP_ADDRESS> Real-time delivery of data and services*

IoT applications in some specific domains such as transportations and healthcare need to communicate real-time data and deliver on-time services to avoid critical situations [6].

#### *<IP_ADDRESS> Security and privacy concerns*

In the IoT network, the security of applications and communications among the different nodes should be considered, along with the privacy of people's captured data such as location, daily activities, buying habits [12]. An efficient and scalable security mechanism should be implemented considering the *ad hoc* nature of the IoT network, and also, the privacy issues should be considered not to prohibit the deployment of applications that violate citizen's privacy by the law [12].

*Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

**Figure 3.** *IoT potential applications.*

#### **2.2 IoT middleware platform general architecture**

Given the IoT infrastructure and applications' characteristics stated above, and based on my previous research work done on middleware architecture for RFID [5], context aware, and ubiquitous computing [13], an IoT middleware solution can generally provide the following functionalities:

The IoT middleware architecture is depicted in **Figure 4**. The main layers include device abstraction and resource management layer, which handle the interoperability and interaction with the heterogeneous devices, and manage the low-level hardware parameters such as the used protocols, communication technologies, standards, and air interface; data management layer is responsible for storing

**Figure 4.** *IoT middleware architecture.*

and processing (filtering, aggregation, inference, etc.) the raw data captured by the different devices/things; event management and context detection layer include the application of policies and business rules requested by the applications (e.g., security and privacy rules); and application abstraction layer allows the communication of applications with the different devices and helps them to get the desired processed data and generated events from the middleware.

#### **3. IoT middleware design considerations and requirements**

The role of a middleware platform is to provide a software layer shielding the complexities of the hardware layer including the operating systems from the applications and allowing the applications' developers to be concentrated mainly on the requirements/problem to be solved. As described in Section 2, in the context of IoT, there is a considerable variation in the used technologies, standards, and network communications. We describe herein, a set of design considerations and requirements for a middleware to suit the IoT infrastructure and application characteristics.

#### **3.1 Resource discovery and management**

Since the IoT infrastructure is dynamic by its nature, the IoT middleware should provide an automatic device discovery and enable the IoT heterogeneous hardware devices (e.g., RFIDs, sensors, smartphones) to detect their neighbors in the network and show their presence and available resources to them. In this case, the middleware should consider the characteristics of the resource-constrained IoT devices and be scalable in terms of the number of connected devices in the network. The middleware should also manage the devices, monitor their resource usage, and resolve any resource conflicts when potential and spontaneous new devices are connected to satisfy the application requirements.

#### **3.2 Data management, context awareness, and event management**

The IoT middleware should provide data management and processing functionalities to the backend applications; these include but are not limited to data detection and acquisition from the different connected devices/things, data preliminary

*Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

processing, such as filtering, duplicate removal, compression, aggregation, and data storage. The IoT middleware should also manage the high number of generated events in an IoT environment, such as real-time dissemination of events to the applications, event transformation based on contextual/location data, and inferences.

The IoT-middleware should provide context detection and processing for it to adapt to smart applications requirements; it should collect context data and then process them to generate inferences and decisions. This could be achieved by using different techniques such as knowledge database, data mining algorithms, semantic context aware multimodal visualization approach, and the use of optimized message communication between the middleware users.

#### **3.3 Scalability and adaptability**

The IoT network can include a large number of connected things/devices and provide multiple services; therefore, the IoT middleware should be scalable allowing the growth of the IoT network, including the emergence of new heterogeneous devices that could be monitored, added, or removed without any impact on existing middleware functionalities, the provision of new services/functionalities, the addition/removal of network nodes, and the connection of multiple interesting applications in the middleware services without complexity. The use of IPv6, loose coupling, and virtualization are considered as useful ways for improving scalability in middleware solutions. Also, the use of a service-oriented architecture (SOA) makes the middleware flexible to the applications' requirements in terms of new services. The IoT middleware should also be dynamically adaptive to the different circumstances and changes in the IoT environment.

#### **3.4 Real-time data capture and services**

The IoT network deals with multiple real-time/time-critical applications requiring a timeliness delivery of processed data and services without any delay, for example, healthcare applications; therefore, the middleware should provide realtime services and information to these applications. In this case, the middleware should manage the large data volumes detected from the multiple connected devices and therefore use novel methods to detect, process, and disseminate these data to the interested applications. The challenge of transaction handling, indexing, and querying these data should also be handled. This could be ensured through the use of agents, query processors, notification managers, etc.

#### **3.5 Reliability and availability**

Every component or layer in the IoT middleware should be operational including communication, data processing, events management, technologies, devices connectivity, and application management, even when failures occur. It should provide a stable service for applications/users even at times of failure. The middleware must also be available at all times for mission-critical applications that require a high fault tolerance, for example, medical applications; in the case of failure, the recovery time should be reduced to cater to the applications' availability requirements.

#### **3.6 Security and privacy**

The IoT middleware should consider the security and privacy rules and policies required by the connected applications. The use of context awareness in the middleware can disclose some personal information about individuals such as location;

therefore, it needs to protect people's privacy using policies/rules/ontologies depending on the applications' specific needs [12]. Also, most of IoT middleware solutions are evolving into the cloud, which requires more mechanisms to be put in place to deal with the security and privacy issues, making users safe and protecting their personal data.

#### **3.7 Ease of use and deployment**

The IoT middleware should be lightweight, and easily used and deployed by the end-users of devices or applications without any complicated setup procedures.

#### **3.8 Distributed implementation**

If the IoT infrastructure is distributed, the middleware implementation should also be distributed, for example, when the devices, applications, and users are located in different geographical areas.

Some of the requirements stated above are considered to be mandatory for some applications while optional for others; for example, the real-time data capture and services are highly required in the case of medical applications, but it is optional for other applications that do not use timeliness information. However, the security, privacy, and interoperability functionalities are strictly required by all types of applications.

#### **4. Overview of existing IoT middleware solutions**

Many middleware solutions, using a single design approach (e.g., servicebased, agent-based, database-based) or a hybrid one (combining different design approaches), and providing different functionalities in many application domains have been proposed and implemented in the IoT. These initiatives aim to offer a standard platform used to abstract the lower-level details of the connected physical devices and offer multiple services to the users and/or applications. In this chapter, the existing IoT middlewares are surveyed based on their used design approach and are grouped into six categories: service-oriented middleware, agent-based middleware, event-based middleware, virtual machine-based middleware, databaseoriented middleware, and application-oriented middleware. A comparison of these design approaches is given in **Table 1**.

#### **4.1 Service-oriented middleware solutions**

The service-oriented middleware (SOM), based on the service-oriented design pattern, provides services to the applications, such as service discovery and management, data management, and quality of service (QoS) management. There exist many service-oriented IoT middleware solutions. Some of the commonly used service-oriented IoT middleware solutions are described as follows:

*Hydra* is a SOM for ubiquitous computing providing many management components for resources, security, and services [19]. Hydra is a lightweight middleware supporting dynamic self-reconfiguration and optimizing energy consumption in battery-constrained devices. The security and privacy requirements are ensured by Hydra through the use of Web Services enriched by semantic resolution [20].

The *SenseWrap* [21] middleware solution uses virtual sensors with the Zeroconf protocols to abstract the sensors' low-level details from the applications, and allow them to discover sensor-hosted services. This middleware solution applies virtualization only to sensors, which makes it unsuitable for IoT environments including heterogeneous devices and application domains.

#### *Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

#### *Middleware Architecture*

#### *Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

**Table 1.**

*Comparison of existing IoT middleware solutions.*

#### *Middleware Architecture*

The *MUSIC* middleware [22] supports building systems in ubiquitous environments where service providers and consumers may change dynamically based on context. Its architecture is composed of different managers providing different functionalities, including the context manager, service discovery manager, QoS manager, SLA monitoring, and adaptation manager. The use of context data by the MUSIC middleware may increase the risk of privacy leakage in an IoT environment. *SENSEI* [23] is another middleware solution including context services and a context model for the real world Internet including IoT. Its resources use ontologies for their semantic modeling, which makes it unsuitable for large-scale IoT networks since there are no standard established ontologies yet.

*TinySOA* [24] is a service-oriented middleware used for WSN applications development. It provides a management of WSN devices and communications, and allows applications to get processed data from the connected sensors. TinySOA allows only a few functionalities, such as abstraction and resource discovery related to WSNs, and does not support other devices; therefore, it could not be used fully within an IoT network [24]. Another SOM providing the management of quality of service in WSNs is called *SensorsMW* [25]. *Servilla* middleware also facilitates application development using heterogeneous WSNs; however, it is not widely used due to the privacy and security threats caused by the individual sensor-level access [26].

*SOCRADES* middleware [27] contains a layer for devices and services monitoring responsible for devices/things management and service discovery, and another one for application services such as event storage. The middleware provides a security solution by using authentication to control access to the different devices. However, the privacy of sensitive information is not ensured, since a direct access to the connected devices and their offered services is allowed by the middleware.

There exist many other cloud-based service-oriented IoT middleware solutions, such as *Google Fit*, *Xively*, *CarrIoTs*, *Echelon*; however, there are still many concerns about the cloud platform security and privacy, especially for mission-critical IoT applications [28].

Recent studies have been conducted concerning the design and implementation of service-oriented IoT middleware solutions including the one in [29] that suggests a middleware based on REST API to collect data from different devices, intending to deal with the heterogeneity issues. The authors in [30] presented a 3SOA (Sensingas-a-Service run-time Service-Oriented Architecture) middleware solution that allows interoperability among IoT platforms, and highly abstracts the applications from the low-level details of IoT hardware platforms and communication languages.

In conclusion, most old SOMs manage only WSNs and do not scale to the use of multiple heterogeneous devices as in the context of IoT. Recent suggested service-based middleware platforms provide solutions for the interoperability and heterogeneity problems; however, they still offer a limited security through the use of authentication, do not use unified service standards, and require automation for service configuration and optimization due to the recurring demands of new services by the interesting applications.

Another type of microservices-based architecture has been recently proposed to develop IoT platforms that meet the heterogeneous and distributed nature of IoT devices, and provide dynamic, scalable, maintainable, and interoperable IoT environments. Delsing et al. [14] propose an Arrowhead Framework architecture enabling scalability, security, and real-time performance in a multi-cloud setting. This architecture supports multiple IoT devices based on SOA architecture in local clouds to exchange inter- and intra-cloud information, and allows organizations to move toward a multi-stakeholder cooperation catering to market requirements and supporting efficiency, flexibility, and sustainability [14].

A general microservice architecture for IoT applications development is proposed by Sun et al. [15], providing flexibility, scalability, maintainability, light-weightness, and loose coupling to deal with the different challenges of the continuous IoT development. The authors focus on the system design based on microservices and device communication protocols used between the service layer and physical device layer. This framework allows, therefore, more interoperability, automation, and intelligence and provides big data and geo-localization services [15].

Another recent architecture based on microservices is proposed by Lai et al. [16] to provide IoT services for multi-mobility in a smart city. The architecture provides flexibility and scalability to efficiently manage the different heterogeneous IoT devices using independent microservices, which could be separately deployed in a distributed system [16]. The authors used real-case scenarios to test the architecture using multi-mobility services for citizens in a smart city.

A recent study [17] also shows how the use of a framework based on microservices allows to mitigate the critical challenges of IoT devices and applications, and increases their scalability when deployed in the ocean where there is a continuous increasing growth of big data.

Many other microservices-based IoT platforms have been proposed in various application domains such as smart farms [31], smart logistics/factories [32], smart cars [33], and smart commerce [34]. Jarwar et al. [18] also proposed a crossdomain/general-purpose Web of Objects Architecture for IoT service provisioning in which a virtual object is used as an abstraction of a physical object.

#### **4.2 Agent-based middleware solutions**

Agent-based middleware solutions use mobile agents to facilitate distribution throughout the network and allow a partial failure tolerance. The use of mobile agents in the IoT network provides many advantages including interoperability with the heterogeneous devices, reliability and availability, resource and code management taking into consideration the resource-constrained devices, and application management. Some of the most commonly used agent-based middleware solutions are highlighted below.

*Impala* [35] is an agent-based middleware solution enabling code management, application modularity, resource management, mobility, and openness in WSNs. Its architecture also allows an improvement of the efficiency of resource-constrained nodes. However, Impala middleware does not provide the raw data cleaning functionality, which is necessary for an IoT setting.

Other examples of agent-based WSN middleware solutions include *ActorNet* [36] that provides context management and allows application development taking into consideration the limited resources in a WSN environment. However, ActorNet uses a service discovery mechanism leading to a slow network. *Agilla* [37] is another example of agent-based platforms, which deploys independent event-related mobile agents in every sensor node; however, this is limited due to the constrained resources of nodes, which may cause message loss and interference with programmability and code management tasks.

*Ubiware* [38] is considered a dedicated agent-based middleware solution for IoT, which supports resource discovery, invocation, monitoring, and the development of multiple extensible applications. Ubiware is a Java-based solution with a three-layer architecture where resources are interpreted as Java components; it uses ontologies and policies to satisfy the security and interoperability requirements; however, these policies do not include all the available WSN standards. There exist many other Java-based middleware solutions dedicated to WSN applications, such as *AFME*, *MAPS*, *MASPOT*, and *TinyMAPS* to name a few [39].

*Smart messages* [40] middleware is a highly flexible solution for dynamic network configurations; it overcomes the limitations of volatile, heterogeneous, and resource-constrained embedded systems using agent migration. However, it is limited in terms of the number of connected applications and its support to multiple devices in the case of an IoT context.

The authors in [41] present a new approach for increasing the smart objects' selfadaptation and allowing them to make autonomous decisions and be smarter based on a multi-agent system (MAS). The authors in [42] also presented a new multiagent-based approach called ACOSO (Agent-based Cooperating Smart Objects) and its related middleware catering for the heterogeneous IoT platforms. The flexibility and effectiveness of this middleware were proved through the implementation of a "Smart University system."

The autonomous behavior of agents used in middleware solutions may lead to the IoT network's self-organization and fault tolerance. However, the dynamic behavior of agents may lead to message loss; therefore, most of the above-discussed middleware solutions could not be used within the large-scale IoT networks requiring a heterogeneous infrastructure, including resource-constrained devices.

#### **4.3 Event-based middleware solutions**

All the components of an event-based middleware solution use a publish/ subscribe model; the event sending component is called the producer or publisher, and the receiving component is called the consumer or subscriber. The consumers are registered for a particular event published by the producers for which they are frequently receiving notifications. The event-based approach provides timeliness, security, scalability, availability, reliability, and fault tolerance.

*EMMA* [43] is an available Java Message Service middleware, which is a type of event-based approach designed for video communication systems to provide many types of messaging. However, it is not energy efficient and provides only a limited reliability.

*Hermes* middleware [44] also provides scalability, interoperability, and reliability, and it is also fault tolerant. However, it provides only a limited adaptation and does not allow a composite and persistent storage of events.

The authors in [45] proposed an event-based middleware solution implemented using the publish-subscribe pattern to solve the problem of interoperability in IoT. The interoperability assessment methodology was used to test the middleware performance, and it was shown that it is qualified compared to previous systems.

There exist many other event-based middleware solutions including *GREEN* [46], *RUNES* [47], *Steam* [48], *PSWare* [49], *PRISMA* [50], and *TinyDDS* [51], which are appropriate for systems involving a high mobility and failure occurrence. However, they do not adequately address the context awareness, adaptability, interoperability, security, privacy, and timeliness requirements of the IoT. Also, the concurrency of the event in this type of middleware solutions may lead to reduced system reliability.

#### **4.4 Virtual machine-based middleware solutions**

The virtual machine (VM) middleware approach considers virtualizing the network infrastructure, where the different network nodes are holding a VM and applications are designed as separate modules distributed throughout the network. This ensures self-management, and a high level of abstraction and adaptability. *Maté* [52] is a middleware solution based on VM, which addresses the different challenges in WSNs and is designed for nodes with limited energy and bandwidth

resources. Mate is based on a VM approach and provides byte code interpretation and tackles the different challenges in WSNs; however, it does not provide event management and does not allow a single sensor node to support multiple applications. Some other middleware solutions based on the VM approach were built on top of Mate to extend its capabilities, including *VM\** [53] and *Melete* [54]. These provide resource management, code dissemination, and an easy concurrent application deployment; however, they do not handle a dynamic network topology.

There exist some middleware solutions based on Java virtual machine (JVM), such as *MagnetOS*, *Squawk*, and *Sensorware* which allows them to support multiple portable applications; however, they are unsuitable for the IoT resource-constrained devices since they use heavy mechanisms for interlayer communication and computation consuming memory and processing power [55]. These constraints make the VM-based approach suitable only for resource-rich devices.

The application-specific virtual machine (ASVM) approach has been developed to target specific application domains. Middleware solutions based on this approach include but are not limited to *TinyVM* [56], *SwissQM* [57], and *TinyReef* [58]. However, the ASVM approach is still heavyweight, which makes it unsuitable for the limited-resource devices in an IoT network deployment.

#### **4.5 Database-oriented middleware solutions**

The whole network in this type of middleware solution is viewed as a relational database, managed using a query language like SQL. For example, the *Sensor Information Networking Architecture (SINA)* middleware [59] enables applications to send queries, collect results, and monitor network changes in a WSN setting. It also supports resource management and monitoring, event monitoring, data preprocessing, while clustering sensor nodes to ensure scalability and energy-efficient operations. However, SINA is not context aware, and it does not support security, privacy, and interoperability. *IrisNet* [60] is another distributed and lightweight database-oriented middleware solution providing simultaneous heterogeneous WSN services using queries over the collected data from the sensor nodes. However, it does not resolve the issues related to energy efficiency, interoperability, adaptiveness, and context awareness. Other examples of database-oriented middleware solutions include *Sensation* [61], *TinyDB* [62], and *HyCache* [63]. In these solutions, database queries are used to get approximate data of interest from the sensor nodes; they do not support the real-time requirement of the IoT infrastructure. They are also energy inefficient and use a centralized model, which does not scale to the ultra-large dynamic IoT networks [59]. Also, they do not provide the data aggregation and knowledge discovery functionalities.

#### **4.6 Application-oriented middleware solutions**

Application-oriented middleware solutions are dedicated to specific domain requirements and infrastructure. For example, the *Automatic Service Composition (AutoSec)* middleware supports one application at a time using resource provisioning and information collection policies set by the different applications [64]. *Adaptive middleware* is designed for smart home applications providing context awareness, and it also supports adaptation for other applications and ensures the quality of information collection and transmission between the network nodes [65]. Other examples include *MlLAN* middleware [59] that targets the healthcare applications and adapts to their QoS requirements at runtime, *MidFusion* [66] designed for information fusion applications such as intrusion detection systems,

#### *Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

and *TinyCubus* [59] designed for driver assistance systems that satisfies the application requirements by customizing its generic components.

The application-specific approach leads to the design of special-purpose middleware systems dedicated to a specific application domain, using a centralized mechanism for resource discovery. This makes them unsuitable for the distributed and fault-tolerant nature of IoT environments.

#### **4.7 Hybrid approach middleware solutions**

There exist some middleware platforms using a hybrid approach, combining two or more design approaches stated above. For example, both *SOCRADES* [27] and *Servilla* [26] service-oriented middleware solutions use also the virtual machine (VM)-based approach. The VM in Servilla, for example, serves to execute application tasks, while the service provisioning framework (SPF) (the service-oriented part) is used to discover and execute services on individual sensor nodes in a WSN. A middleware solution designed for the manufacturing domain using the hybrid approach is also proposed in [67], taking the advantages of both the databaseoriented and semantic modeling approaches for ensuring an accurate and efficient data management and communication among the different devices and applications.

**Table 1** shows the IoT requirements/features available in each middleware design approach and provides a comparison of the different IoT middleware solutions described in Section 4. The choice of the comparison criteria is based on the works cited above, from which the most common, essential, critical, and important characteristics that are shared between the different IoT platforms have been extracted. The description of each criterion is given above in Section 3 (IoT Middleware Design Considerations and Requirements). There exist many additional/non-functional criteria and features, which could be available in some IoT platforms such as recoverability, fault-tolerance, maintainability, configurability, mobility, reusability. But these are not subject of this review since it targets only the most essential design features/functionalities of IoT middleware solutions.

#### **5. Open issues in IoT middleware design**

According to the previous comparison, most of the works concentrate their efforts on providing basic functionalities such as ease of deployment, data management, event management, and real-timeliness. A considerable effort must be made in interoperability and adaptability, which allows devices/things using heterogeneous protocols to connect. Context awareness is also a feature that is not considered by most of the described middleware solutions and still encounters many shortcomings. In addition, security and privacy features need particular attention from researchers, because they are missed in almost all the reviewed middleware solutions above.

In summary, the most challenging issues that still persist in IoT-middleware design, implementation, and deployment are listed below:

• Standardization: The use of heterogeneous devices within a variety of application domains in the IoT makes the use of a single standard for a middleware solution impossible. However, many research works tend to implement a standardized middleware solution for a specific domain, such as semantic web applications domain, sensor networking environments, and smart offices [59, 65]. This will allow application developers to select a middleware solution following the desired standard within a certain domain.

### **6. Conclusion and future work**

Middleware is becoming a necessity for managing heterogeneous devices in the IoT network and developing applications in different domains. There exist a variety of middleware platforms designed for IoT. This chapter provides a detailed overview of existing IoT middleware solutions, and discusses the technical challenges and open issues involved in designing these platforms including device and application abstraction, scalability, context awareness, event management, unfixed infrastructure, security, and privacy. In future work, the open issues in IoT could be further investigated to suggest possible new approaches to solve them. Also, a new middleware design approach may be proposed to include a new perspective for managing the IoT devices/things and applications, including a solution for the unexplored open issues in a specific application domain, such as security, privacy, and interoperability. A test of this new approach could be performed using my previous proposed middleware solution for RFID described in [5].

*Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

#### **Author details**

Mehdia Ajana El Khaddar Alakhawayn University, Ifrane, Morocco

\*Address all correspondence to<EMAIL_ADDRESS>
© 2021 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/ by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

### **References**

[1] Mahmoud Elkhodr M, Shahrestani S, Cheung HS. Internet of Things applications: Current and future development. In: Hassan QF, editor. Innovative Research and Applications in Next-Generation High Performance Computing. 1st ed. Hershey, Pennsylvania: IGI Global; 2016. pp. 397-427. DOI: 10.4018/978-1-5225- 0287-6.ch016

[2] GLOBE NEWSWIRE. Internet of Things (IoT) Market—Growth, Trends, Forecasts (2020-2025) [Internet]. 2020. Available from: https://www. globenewswire.com/news-release/ 2020/05/13/2033070/0/en/The-global-IoT-market-is-expected-to-reach-avalue-of-USD-1256-1-billion-by-2025 from-USD-690-billion-in-2019-at-a-CAGR-of-10-53-during-the-period-2020- 2025.html [Accessed: 01 March 2021]

[3] GSMA. IoT Connections Forecast: The Rise of Enterprise [Internet]. 2019. Available from: https://www.gsma.com/ iot/resources/iot-connections-forecastthe-rise-of-enterprise/ [Accessed: 21 February 2021]

[4] Jason IH, James AL. Four Technological Challenges in Ubiquitous Computing and their Influence on Interaction Design [Internet]. Available from: https:// citeseerx.ist.psu.edu/viewdoc/download? doi=<IP_ADDRESS>9.5005&rep=rep1&type=pdf [Accessed: 21 February 2021]

[5] Ajana ME, Boulmalf M, Harroud H, Elkoutbi M. RFID middleware design and architecture. In: Turcu C, editor. Designing and Deploying RFID Applications. Rijeka: InTechOpen; 2011. DOI: 10.5772/16917. ISBN: 978-953-307- 265-4. Available from: http://www. intechopen.com/books/designing-anddeploying-rfid-applications/ rfid-middleware-design-and-architecture

[6] Ajana ME, Boulmalf M. Smartphone: The ultimate IoT and IoE device. In:

Mohamudally N, editor. Smartphones from an Applied Research Perspective. Rijeka: IntechOpen; 2017. DOI: 10.5772/ intechopen.69734. Available from: https://www.intechopen.com/books/ smartphones-from-an-appliedresearch-perspective/smartphone-theultimate-iot-and-ioe-device

[7] Gopalsamy BN. Communication trends in Internet of Things. In: Sugumaran V, editor. Developments and Trends in Intelligent Technologies and Smart Systems. 1st ed. Hershey, Pennsylvania: IGI Global; 2018. pp. 248-305. DOI: 10.4018/978-1-5225- 3686-4.ch014

[8] Yacchirema Vargas DC, Palau Salvador CE. Smart IoT gateway for heterogeneous devices interoperability. IEEE Latin America Transactions. 2016;**14**(8):3900-3906. DOI: 10.1109/ TLA.2016.7786378

[9] Ntalasha D, Renfa L, Wang Y. Internet of thing context awareness model. EAI Endorsed Transactions on Context-aware Systems and Applications. 2016;**3**(7):151084. DOI: 10.4108/eai.12-2-2016.151084

[10] Cristea V, Dobre C, Pop F. Contextaware environments for the Internet of Things. In: Bessis N, Xhafa F, Varvarigou D, Hill R, Li M, editors. Internet of Things and Inter-cooperative Computational Technologies for Collective Intelligence. USA: Springer; 2013. pp. 25-49. DOI: 10.1007/978- 3-642-34952-2\_2

[11] Krishnamurthi R, Kumar A, Gopinathan D, Nayyar A, Qureshi B. An overview of IoT sensor data processing, fusion, and analysis techniques. Sensors. 2020;**20**(21):6076. DOI: 10.3390/ s20216076

[12] Oorschot P C Van, Smith S W. The Internet of Things: Security challenges. IEEE Security & Privacy. 2019;**17**(5):7-9. DOI: 10.1109/MSEC.2019.2925918

[13] Ajana ME, Chraibi M, Harroud H, Boulmalf M, Elkoutbi M, Maach A. FlexRFID: A security and service control policy-based middleware for context-aware pervasive computing. International Journal of Advanced Research in Artificial Intelligence (IJARAI). 2014;**3**(10):26-34. DOI: 10.14569/IJARAI.2014.031004

[14] Delsing J et al. The arrowhead framework architecture: Arrowhead framework. In: Delsing J, editor. IoT Automation. United States: CRC Press Publisher; 2017. DOI: 10.1201/97813 15367897-4. ISBN:<PHONE_NUMBER>754

[15] Sun L, Li Y, Memon RA. An open IoT framework based on microservices architecture. China Communications. 2017;**14**(2):154-162. DOI: 10.1109/ CC.2017.7868163

[16] Lai C, Boi F, Buschettu A, Caboni R. IoT and microservice architecture for multimobility in a smart city. In: Proceedings of the IEEE 7th International Conference on Future Internet of Things and Cloud (FiCloud); 26-28 August 2019; Istanbul, Turkey. New York: IEEE; 2019. pp. 238-242. DOI: 10.1109/FiCloud.2019.00040

[17] Razzaq A. Microservices architecture for IoT applications in the Ocean: Microservices architecture based framework for reducing the complexity and increasing the scalability of IoT applications in the Ocean. In: Proceedings of the 20th International Conference on Computational Science and Its Applications (ICCSA); 1-4 July 2020; Cagliari, Italy. New York: IEEE; 2020. pp. 87-90. DOI: 10.1109/ICCSA50381. 2020.00025

[18] Jarwar MA, Kibria MG, Ali S, Chong I. Microservices in web objects enabled IoT environment for enhancing reusability. Sensors. 2018;**18**(2):352. DOI: 10.3390/s18020352

[19] Eisenhauer M, Rosengren P, Antolin P. HYDRA: A development platform for integrating wireless devices and sensors into ambient intelligence systems. In: Giusto D, Iera A, Morabito G, Atzori L, editors. The Internet of Things. New York: Springer; 2010. pp. 367-373. DOI: 10.1007/978-1-4419-1674-7\_36

[20] Reiners R, Zimmermann A, Jentsch M, Zhang Y. Automizing home environments and supervising patients at home with the hydra middleware: Application scenarios using the hydra middleware for embedded systems. In: Proceedings of the First International Workshop on Context-aware Software Technology and Applications; 24 August 2009; Amsterdam, The Netherlands. New York: ACM; 2009. pp. 9-12. DOI: 10.1145/1595768.1595772

[21] Zgheib R, Conchon E, Bastide R. Semantic middleware architectures for IoT healthcare applications. In: Ganchev I, Garcia N, Dobre C, Mavromoustakis C, Goleva R, editors. Enhanced Living Environments. Cham: Springer; 2019. pp. 263-294. DOI: 10.1007/978-3-030-10752-9\_11

[22] Rouvoy R, et al. MUSIC: Middleware support for self-adaptation in ubiquitous and service-oriented environments. In: Cheng BHC, de Lemos R, Giese H, Inverardi P, Magee J, editors. Software Engineering for Self-Adaptive Systems. Berlin: Springer; 2009. pp. 164-182. DOI: 10.1007/978-3-642-02161-9\_9

[23] Tsiatsis V et al. The SENSEI real world internet architecture. In: Georgios T, et al., editors. Towards the Future Internet—Emerging Trends from European Research. Amsterdam, The Netherlands: IOS Press; 2010. pp. 247- 256. DOI: 10.3233/978-1-60750-539-6-247

[24] Avilés-López E, García-Macías JA. TinySOA: A service-oriented

architecture for wireless sensor networks. Service Oriented Computing and Applications. 2009;**3**:99-108. DOI: 10.1007/s11761-009-0043-x

[25] Anastasi G F, Bini E, Lipari G. Extracting data from WSNs: A serviceoriented approach. In: Anastasi G, Bellini E, Di Nitto E, Ghezzi C, Tanca L, Zimeo E, editors. Methodologies and Technologies for Networked Enterprises. Berlin: Springer; 2012. p. 329-356. DOI: 10.1007/978-3- 642-31739-2\_17

[26] Chien-Liang F, Gruia-Catalin R, Chenyang L. Servilla: A flexible service provisioning middleware for heterogeneous sensor networks. Science of Computer Programming. 2012;**77**(6):663-684. DOI: 10.1016/j. scico.2010.11.006

[27] de Souza LMS, Spiess P, Guinard D, Köhler M, Karnouskos S, Savio D. SOCRADES: A web service based shop floor integration infrastructure. In: Floerkemeier C, Langheinrich M, Fleisch E, Mattern F, Sarma SE, editors. The Internet of Things. Berlin: Springer; 2008. pp. 50-67. DOI: 10.1007/ 978-3-540-78731-0\_4

[28] Ngu AH, Gutierrez M, Metsis V, Nepal S, Sheng QZ. IoT middleware: A survey on issues and enabling technologies. IEEE Internet of Things Journal. 2017;**4**(1):1-20. DOI: 10.1109/ JIOT.2016.2615180

[29] Mesmoudi Y et al. A Middleware based on service oriented architecture for heterogeneity issues within the Internet of Things (MSOAH-IoT). Journal of King Saud University— Computer and Information Sciences. 2020;**32**(10):1108-1116. DOI: 10.1016/j. jksuci.2018.11.011

[30] Hammoudeh M et al. A service oriented approach for sensing in the Internet of Things: Intelligent

transportation systems and privacy use cases. IEEE Sensors Journal. 2020; **21**(14):15753-15761. DOI: 10.1109/ JSEN.2020.2981558

[31] Taneja M et al. SmartHerd management: A microservices-based fog computing-assisted IoT platform towards data-driven smart dairy farming. Software Practice and Experience. 2019;**49**:1055-1078. DOI: 10.1002/spe.2704

[32] Herrera-Quintero LF et al. Smart ITS sensor for the transportation planning using the IoT and Bigdata approaches to produce ITS cloud services. In: Proceedings of the IEEE 8th Euro American Conference on Telematics and Information Systems (EATIS); 28-29 April 2016; Cartagena, Colombia. New York: IEEE; 2016. pp. 1-7. DOI: 10.1109/ EATIS.2016.7520096

[33] Kanti Datta S et al. IoT and microservices based testbed for connected car services. In: Proceedings of the IEEE 19th International Symposium on "A World of Wireless, Mobile and Multimedia Networks" (WoWMoM); 12-15 June 2018; Chania, Greece, Piscataway, NJ: IEEE; 2018. pp. 14-19. DOI: 10.1109/ WoWMoM.2018.8449768

[34] Banerjee A, Jiang B. A Blockchainbased IoT platform integrated with cloud services. In: Proceedings of the International Conference on Parallel and Distributed Processing Techniques & Applications; July 29th - August 1st 2019; Las Vegas, Nevada. C. S. R. E. A., 2020.

[35] Liu T, Martonosi M. Impala: A middleware system for managing autonomic, parallel sensor systems. ACM SIGPLAN Notices. 2003;**38**(10):107-118. DOI: 10.1145/966049.781516

[36] Kwon Y, Sundresh S, Mechitov K, Agha G. ActorNet: An actor platform for wireless sensor networks. In:

*Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

Proceedings of the 5th International Joint Conference on Autonomous Agents and Multiagent Systems; 8-12 May 2006; Hakodate, Japan. New York: ACM, 2006. DOI: 10.1145/1160633.1160871

[37] Fok CL, Gruia-Catalin Roman GC, Lu C. Agilla: A mobile agent middleware for self-adaptive wireless sensor networks. ACM Transactions on Autonomous and Adaptive Systems. 2009;**4**(3):1-26. DOI: 10.1145/1552297.1552299

[38] Vasile-Marian Scuturici VM, Surdu S, Yann G, Petit JM. UbiWare: Web-based dynamic data & service management platform for AmI. In: Proceedings of the Posters and Demo Track Conference; 3 December, 2012; Montreal Quebec Canada. New York: ACM; 2012. DOI: 10.1145/2405153.2405164

[39] Aiello F, Fortino G, Galzarano S, Vittorioso A. TinyMAPS: A lightweight java-based mobile agent system for wireless sensor networks. In: Proceedings of the 5th International Symposium on Intelligent Distributed Computing (IDC 2011); October 2011; Delft, the Netherlands: Springer-Verlag Berlin Heidelberg; 2012. DOI: 10.1007/ 978-3-642-24013-3\_16

[40] Kang P et al. Smart messages: A distributed computing platform for networks of embedded systems. The Computer Journal. 2004;**47**(4). DOI: 10.1093/comjnl/47.4.475

[41] Chekati A, Riahi M, Moussa F. Agent-based modelling approach for decision making in an IoT framework. In: Barolli L, Woungang I, Enokido T, editors. Advanced Information Networking and Applications. AINA; 2021. Lecture Notes in Networks and Systems, vol 226. Springer, Cham. DOI: 10.1007/978-3-030-75075-6\_21

[42] Fortino G et al. An Agent-Based Middleware for Cooperating Smart Objects. In: Proceedings of the 11th International Conference on Practical Applications of Agents and Multi-Agent Systems; 22-24; May, 2013; Salamanca, Spain: Springer-Verlag Berlin Heidelberg; 2013. pp. 387-398. DOI: 10.1007/978-3-642-38061-7\_36

[43] Rausch T, Nastic S, Dustdar S. EMMA: Distributed QoS-aware MQTT middleware for edge computing applications. In: Proceedings of the IEEE International Conference on Cloud Engineering (IC2E); 17-20 April, 2018; Orlando, FL, USA: IEEE; 2018. pp. 191-197. DOI: 10.1109/IC2E.2018.00043

[44] Pietzuch PR. Hermes: A scalable event-based middleware. University of Cambrige Computer Laboratory Technical Report N° 590; 2004. ISSN 1476-2986. Available from: https://www. cl.cam.ac.uk/techreports/UCAM-CL-TR-590.pdf

[45] Pramukantoro ES, Anwari H. An event-based middleware for syntactical interoperability in Internet of Things. International Journal of Electrical and Computer Engineering. 2018;**8**(5):3784. DOI: 10.11591/ijece.v8i5.pp3784-3792

[46] Sivaharan T, Blair G, Coulson G. Green: A configurable and reconfigurable publish-subscribe middleware for pervasive computing. In: Meersman R, Tari Z, editors. On the Move to Meaningful Internet Systems. Berlin: Springer; 2005. pp. 732-749. DOI: 10.1007/978-3-540-78731-0\_4

[47] Costa P, et al. The runes middleware for networked embedded systems and its application in a disaster management scenario. In: Proceedings of the IEEE 5th Annual International Conference on Pervasive Computing and Communication (PerCom'07); 19-23 March 2007; White Plains, NY, USA: Computer Society; 2007; pp. 69-78. DOI: 10.1109/PERCOM.2007.36

[48] Meier R, Cahill V. Steam: Eventbased middleware for wireless ad hoc networks. In: Proceedings of the IEEE 22nd International Conference on Distributed Computing Systems Workshops; 2-5 July 2002; Vienna, Austria: IEEE; 2002. pp. 639-644. DOI: 10.1109/ICDCSW.2002.1030841

[49] Lai S, Cao J, Zheng Y. Psware: A publish/subscribe middleware supporting composite event in wireless sensor network. In: Proceedings of the IEEE International Conference on Pervasive Computing and Communication (PerCom'09); 9-13 March 2009; Galveston, TX, USA: IEEE Computer Society; 2009. pp. 1-6. DOI: 10.1109/PERCOM.2009.4912862

[50] Silva JR, et al. PRISMA: A publishsubscribe and resource-oriented middleware for wireless sensor networks. In: Proceedings of the 10th Advanced IEEE International Conference on Telecommunications; 20-24 July 2014; Paris, France. International Academy, Research, and Industry Association (IARIA); 2014. pp. 87-97

[51] Boonma P, Suzuki J. TinyDDS: An interoperable and configurable publish/ subscribe middleware for wireless sensor networks. In: Hinze A, Buchmann A, editors. Principles and Applications of Distributed Event-Based Systems. Hershey, Pennsylvania: IGI Global; 2010. p. 206. DOI: 10.4018/978- 1-60566-697-6.ch009

[52] Levis P, Culler DE. Maté: A tiny virtual machine for sensor networks. In: Proceedings of the Tenth ACM International Conference on Architectural Support for Programming Languages and Operating Systems; 5-9 October 2002; San Jose, California, United States: ACM; 2002. DOI: 10.1145/605406.605407

[53] Koshy J, Pandey R. Vm: Synthesizing scalable runtime environments for sensor networks. In: Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems (SenSys '05); 2-4 November 2005; San

Diego, California, USA: ACM; 2005. pp. 243-254. DOI: 10.1145/1098918.1098945

[54] Khalid Z, Fisal N, Rozaini M. A survey of middleware for sensor and network virtualization. Sensors. 2014;**14**(12):24046-24097. DOI: 10.3390/ s141224046

[55] Costa N, Pereira A, Serodio C. Virtual machines applied to WSN's: The state-of-the-art and classification. In: Proceedings of the Second International Conference on Systems and Networks Communications (ICSNC 2007); 25-31 August 2007; Cap Eterel, France, IEEE Computer Society; 2007. pp. 50-50. DOI: 10.1109/ICSNC.2007.83

[56] Hong K et al. Tinyvm: An energyefficient execution infrastructure for sensor networks. Software: Practice and Experience. 2012;**42**(10):1193-1209. DOI: 10.1002/spe.1123

[57] Mueller R, Alonso G, Kossmann D. SwissQM: Next generation data processing in sensor networks. In: Proceedings of the Third Biennial Conference on Innovative Data Systems Research (CIDR); 7-10 January 2007; Asilomar, CA, USA. Online Proceedings. Available from: www.cidrdb.org 2007. pp. 1-9. DOI: 10.3929/ethz-b-000004843

[58] Marques IL, Ronan J, Rosa NS. TinyReef: A register-based virtual machine for Wireless Sensor Networks. In: Proceedings of the IEEE International Conference on SENSORS; 25-28 October 2009; Christchurch, New Zealand: IEEE; 2009. pp. 1423-1426. DOI: 10.1109/ ICSENS.2009.5398437

[59] de Freitas EP. A Survey on Adaptable Middleware for Wireless Sensor Networks. Halmstad University Technical Report IDE0851; 2008. Available from: http://www.diva-portal.org/smash/get/ diva2:239429/FULLTEXT01.pdf

[60] Deshpande A, Suman N, Gibbons PB, Seshan S. IrisNet: *Middleware Solutions for the Internet of Things: A Survey DOI: http://dx.doi.org/10.5772/intechopen.100348*

Internetscale Resource-Intensive Sensor Services. In: Proceedings of the ACM SIGMOD International Conference on Management of Data; 9-12 June 2003; San Diego, California, USA: ACM; 2003. p. 667. DOI: 10.1145/872757.872856

[61] Hasiotis T et al. Sensation: A middleware integration platform for pervasive applications in wireless sensor networks. In: Proceedings of the IEEE Second European Workshop on Wireless Sensor Networks; 31 January - 2 February 2005; Istanbul, Turkey: IEEE; 2005. pp. 366-377. DOI: 10.1109/EWSN.2005. 1462028

[62] Madden S, Franklin MJ, Hellerstein JM, Hong W. TinyDB: An acquisitional query processing system for sensor networks. ACM Transactions on Database Systems. 2005;**30**(1):122- 173. DOI: 10.1145/1061318.1061322

[63] Zhao D, Raicu I. HyCache: A user-level caching middleware for distributed file systems. In: Proceedings of the IEEE International Symposium on Parallel & Distributed Processing, Workshops and PhD Forum(IPDPSW); 20-24 May 2013; Cambridge, MA, USA: IEEE; 2013. pp. 1997-2006. DOI: 10.1109/IPDPSW.2013.83

[64] Han Q, Venkatasubramanian N. Autosec: An integrated middleware framework for dynamic service brokering. IEEE Distributed Systems Online. 2001;**2**(7):22-31

[65] Huebscher MC, McCann JA. Adaptive middleware for context aware applications in smart-homes. In: Proceedings of the 2nd Workshop on Middleware for Pervasive and Ad-hoc Computing; 18-22 October 2004; Toronto, Ontario, Canada, United States: ACM; 2004. pp. 111-116. DOI: 10.1145/1028509.1028511

[66] Alex H, Kumar M, Shirazi B. MidFusion: An adaptive middleware for information fusion in sensor network

applications. Information Fusion. 2008;**9**(3):332-343. DOI: 10.1016/j. inffus.2005.05.007

[67] Grevenitis K et al. A hybrid framework for industrial data storage and exploitation. Procedia CIRP. 2019;**81**:892-897. DOI: 10.1016/j.procir. 2019.03.221

#### **Chapter 2**

## Middleware Architecture - History and Adaptation with IEEE 802.11

*Rochak Bajpai, Atul Bansal, Jyoti Tripathi and Sridhar Iyer*

#### **Abstract**

Communication, which intends to provide a link between any two people, is now moving towards man-to-machine and machine-to-machine connection for transferring different types of data. This transmission scenario, with and ever expanding number of active and passive users, lays the foundation to variety of communication protocols owing to the different types of data which is involved in the process. Within this ever expanding communication arena, Middle-ware can be thought of as a set of hardware and software which is used to connect different platforms with the end-users that are increasing in number day-by-day, with a possible wide spread over any region spanning from few meters to several kilometers. IEEE 802.11 is the set of standards which guides the wireless technology for device implementation and demands seamless integration across the entire protocol stack. This in turn demands an overview of the middleware architecture in broader perspective. This chapter explores the concept of middleware in the existing communication scenario, current trends and future scope.

**Keywords:** Middleware architecture, Communication protocols, IEEE 802.11, Network layer, Application layer, TPM, RPC, MOM, ORB

#### **1. Introduction**

Widespread usage of communication technology, intended to transfer information from one person to another, is moving rapidly towards information exchange between man and machine. The advent of computer along with digital formatted communication in light of advanced algorithms, low cost VLSI (Very Large Scale Integration) and high efficiency in computation paves the way for massive information exchange among individuals.

Simultaneously, ubiquitous computing paradigm with sensor based data communication presents unique man-to-machine information exchange which not only spread across large area but is also found to be a source of voluminous data, that needs to be carefully segregated and segmented for figuring out intelligence from a large pile of existing data.

Conventionally, middleware is said to be collection of algorithms, components and devices which enables the information exchange between different entities. As per the OSI model, middleware can be placed between the transport and the application layer, as shown in **Figure 1**.

In existing literature, the concept of middleware was discussed starting in the year 1968 in a report of the North Atlantic Treaty Organization [1], where it was placed between the application programs and the service routines. This paradigm

#### **Figure 1.**

*Location of middleware in OSI reference model.*

was quite pragmatic due to its ability to interconnect new components with the existing hardware within the same distributed system.

With the advent of the recent 5G technologies along-with strong data networking capability, a plethora of innovative sensor-based application are appearing over the horizon. This motivates us to look at the middleware architecture at a microscopic level as it involves different sensors with their applications without considering the interconnection involved i.e. it hides the heterogeneous nature of the underlying sensing data to yield the support system with the help of unified interface for the final application. This results in an easy access of the network by sensors as well as different applications, which can call the sensing network with the middleware open interface. This helps in the reduction of the design and the development cost with improved efficiency.

#### **2. History and motivation**

The initial development of the computer was based on the premise and promise of high-speed calculations which was iterative in nature. It was initially proposed through mechanical gear system but was found to be excessively time consuming. With the advent of vacuum tubes, the hurdle of timing is attended to and further, investigation in the field of solid state electronics which results in devices such as, diodes, transistors and operation amplifiers paves way for low power consuming, portable size devices which are termed as analog computers. This was the first era of computers [2]. The more robust, fast and complex Integrated Circuits (IC) were responsible for the design and development of digital computers which are having tremendous capability to perform high speed and complex calculations [3].

With the elaboration of theoretical concepts and their implementation in terms of ideas such as, distributed computing, abstraction, object-oriented programming, etc., results in the coding of complex software programs to an easily solvable problem at hand. At the same time, in order to reduce the design and development cost of the software and its interaction with the hardware, the concept of re-usability comes into software design paradigm [4].

The parallel progress in networking paradigm, which was simply started with possible interconnection of machines, later resulted in the development of OSI

*Middleware Architecture - History and Adaptation with IEEE 802.11 DOI: http://dx.doi.org/10.5772/intechopen.97124*

model to yield a layered structure of communication among different machines [5]. The layered architecture is profoundly based on the software abstraction model which felicitates a very specific section/property of the network to change without hampering the process of communication among other machines through different layers. This paradigm was the primary basis of middle ware architecture which was placing it between the transport and the application layer, as shown in **Figure 1**.

With the expansion of networking paradigm, Middleware architecture found its place among the widely used concepts, especially in the era of plug and play design methodology. In the subsequent section, we will look at the different attributes which Middleware workable.

#### **2.1 Features of middleware**

As discussed in the introduction, middleware is a set protocol for data exchange between the transport and the application layer. It helps different machines to share the data with the network and vice versa without considering the heterogeneity of the underlying data from both sides, and results in reduced development cost and improvement in the efficiency [6].

The following features are the major attributes of the middleware architecture:

Depending on the different attributes, the middleware architecture can be classified into four types [8, 9].

These types are based on the varied services offered by the specific process.

**Transaction Processing Monitors (TPM)** is designed to monitor the successful transactions from one stage to another stage. In case of any error, TPM takes an appropriate action to rectify the error. A TPM supports optimal resource sharing among the applications with the following functionalities:

**Remote Procedure Call (RPC)** is an inter-process communication facility generally used in a client server based model with the following functionalities:

**Message-Oriented Middleware (MOM)** is an asynchronous technique that passes the messages between transmitting and receiving application with a communication channel. Its asynchronous nature makes the applications decoupled from each other as MOM is responsible for message management system.

**Object Request Brokers (ORB)** acts like a broker between a client request for a service from a distributed object and the completion of that request with following functionalities:

*Middleware Architecture - History and Adaptation with IEEE 802.11 DOI: http://dx.doi.org/10.5772/intechopen.97124*

In view of the above-mentioned services offered by the different types of middleware, following are the major attribute of services offered by any middleware structure [8]:

#### **3. IEEE 802.11 adaptation with middleware**

The emerging trend of wireless technology and the associated innovative applications has changed the communication landscape drastically. Now, the reduced cost of data, high computation power of smartphones and the 5G enabled sensor technology is the major driving force behind the widespread adaptation of network services such as, map enabled movement, shipment tracking, and interactive gaming such as, Pokemon.

Inherently, multimedia services are found to be wideband in nature which, with the unpredictable channel characteristic of wireless medium, place a challenging condition to maintain reliable communication with a predefined Quality of Service (QoS).

IEEE 802.11 standard, proposed by IEEE for local area network (LAN) protocol, specifies the physical layer (PHY) and media access control (MAC) protocols for the implementation of wireless local area network (WLAN) communication in the frequency bands such as, 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. Presently, various tributaries of IEEE 802.11 are framing our day-to-day communication across the world. As per the convention, IEEE 802.11 standards are defined for physical and data link layer of the OSI data communication network protocol and become the de facto standard for wireless communication.

Moreover, the heterogeneous nature of different services such as, Wi-max, Wi-Fi, Bluetooth, and many more, with their unique data link layer presentation have their own quality control mechanism for data transmission. This results in a complex connection strategy management at network, data link, and physical layer.

In comparison, at the application layer, the QoS management parameters such as, semantic, presentation etc., have their own constraints to be followed. These constraints may not be followed every time due to resource limitations at the physical layer or multiplexing issue due to the fluctuating number of users sharing the resource pool in the end system and the network.

In the process of communication, wireless channel demands adaptive QoS implementation for peer-to-peer communication, due to its dynamic behavior. This places a bound on the middleware to manage the communication as it connects the lower layers of the communication protocol (which actually perform the communication at the data level) to the application layer (which is responsible for communication in the correct semantic and form) [10, 11]. Thus, the unique position of middleware demands a monitoring as well as an adaptive perspective such that the desired QoS requirements can be maintained at the application layer without disturbing the underneath communication.

This QoS maintenance requires a two-fold strategy, first is the monitoring of application performance and the second is adaptation of service to maintain pre-specified quality of service [11]. This adaptation strategy requires a perfect synchronization of middleware level with lower level of protocols.

These conditions lay the foundation for the middleware control framework. The middleware control framework has three primary concerns to address [12]:

#### **3.1 IEEE 802.11 - an interesting journey**

IEEE 802 project was aimed to establish the standards for physical layer (PHY) and medium access control (MAC) layer to support deployment of the local area network. The first candidate was IEEE 802.3, popularly known as Ethernet. It was a wired connection mechanism to connect devices based on carrier sense multiple access with collision detection (CSMA/CD) mechanism. Its wide acceptability with industry and home users, motivates the researcher to look for its replication in wireless domain as well which yields the IEEE 802.11 standard [13, 14].

Due to inherent unpredictable nature of radio/wireless medium paves the way for numerous deliverables of IEEE 802.11 standards, which have been flourished over the last twenty years [15, 16], such as 802.11a, 802.11e, 802.11f, 802.11 t and so on. Readers are encouraged to refer [17] to explore the need and their solutions under IEEE 802.11 horizon.

#### **3.2 Middleware in IEEE 802.11 environment**

Under the middleware architecture a brief account of various cases has been summarized below.

Authors in [18] address the issue of mobility management in increasing integration of Internet with telecommunication network which give rise to distributed computing environment. Authors proposed three mobile computing services by incorporating user virtual environment (UVE), mobile virtual terminal (MVT), and virtual resource management (VRM) based on mobility middleware solution for mobile agent.

In [19], the Authors illustrate Quality of Service (QoS) maintenance for multimedia applications over wireless network which are characterized by their limited bandwidth. Authors proposed a novel two level QoS architecture by providing service differentiation at network level and service adaptation at the middleware level. Authors validate their results with experiments and show that specific QoS levels for multimedia applications can be optimally achieved in IEEE 802.11 based wireless network.

Costa et al. in their path breaking work proposed the real time-WiFi architecture to address the issues faced by IEEE 802.11 networks in high density industrial environment [20]. Authors compare the performance of proposed architecture against the standard distributed coordination function (DCF), point coordination function (PCF), hybrid coordination function (HCF) controlled channel access (HCCA) and enhanced distributed channel access (EDCA) medium access control mechanism. Authors used a realistic error-prone model to monitor the impact of message losses in the real time Wi-Fi architecture and their result confirm that the proposed architecture performs better as compared to existing IEEE 802.11 standard mechanisms. Their architecture also offers almost consistent access delay which is one of the major requirements for real time applications.

Authors in [21] use context meta-information to improve the system performance by describing a context management middleware that can successfully handle context irrespective of the execution environment's heterogeneity.

Cruz et al. in [22], reviewed the middleware framework for Internet of Things (IoT) from software perspective. Authors rigorously explored the existing literature and analyzed the reference model for IoT platforms and proposed the basic security feature for this software. Authors also detailed the difficulties in achieving and enforcing a universal standard for middleware in the IoT structure.

Authors in [23], present a fundamental analysis to quantify the goodput performance parameter for IoT. Authors show the closed form expression of goodput as a function of the data payload length, frame retry count, data rate of transmission and wireless channel condition. Authors proposed a novel link adaptation scheme for MAC protocol data units for known wireless channel model.

Increasing use of mobile devices for location sharing applications such as Google map, OLA, Uber, pose a challenge of maintaining adequate user privacy with location sharing services and exchange of information across high heterogeneity among connecting technologies and devices. Authors in [24] proposed a middleware prototype to answer these challenges with two level proxy-based architecture as a solution.

Hamidreza et al. in [25], proposed service-oriented architecture for middleware to resolve the issue of heterogeneity among various sensors in IEEE 802.15 based wireless sensor network.

Authors in [26] discuss different types of sensor network applications with overview of related middleware and infer that none of the existing approaches can provide all the management tools required by sensor network applications. Authors showcase their new middleware MILAN with sensor-based health monitoring system.

In [27], the authors explored the concept of inter-vehicular communications. The field of vehicle to infrastructure and vehicle to vehicle communications were undertaken as well. This work provides detailed account of underlying technology under each layer with rich resource references.

Authors in [28], address the combination of vehicular ad-hoc networks (VANETs) with the social Internet of things (SIoT). Their work describes two fold relations which can be established between the vehicles and between the vehicle and road side unit (RSU). Authors proposed a social Internet of vehicle middleware to incorporate the functionalities of the intelligent transportation systems station architecture, defined by ISO and ETSI standards to integrate VANET with SIoT. They present their proof of concept with simulation results.

Pease et al. in [29] present an adaptive middleware methodology to provide robust mission critical/ military communication by providing timely MANET communications with predictive selection and dynamic contention reduction, without going for invasive protocol modification. To address the issue they proposed a novel Real-time Optimized Ad hoc Middleware based architecture (ROAM). They demonstrate the adaptability, scalability of the architecture along-with the capability to bound maximum delay, jitter and packet loss in complex and dynamic MANET's with extensive simulations.

In [30], the authors elaborated a novel mobile collaboration architecture (MoCA), a service oriented middleware architecture which support the development and deployment of distributed context-aware applications for mobile users. Authors explained the compatibility of proposed MoCA with existing software engineering principles responsible for design and implementation of context aware applications. Authors also present different prototype applications that have been developed on the top of MoCA.

Authors in [10] addressed end to end delays and security issues in application implementation. Authors proposed an integrated solution with middleware adaptation to provide tunable delay and security support according to network condition. To Support the proof of concept, authors perform test-bed experiments to showcase successful meeting of delay and security requirements in IEEE 802.11 based wireless environment.

#### **4. Conclusion**

Middleware architecture defines the connection protocol between the network layer and the application layer. In view of the on-going advances in the mobile communication, there is a requirement of a better understanding about Middleware functionality with IEEE 802.11 protocols which are responsible for the design rules of modern wireless communication.

In this chapter, we addressed the key functionalities of the middleware architecture in addition to its adaptation to the IEEE 802.11 protocols.

In the current scenario, where the need of ubiquitous connectivity is reality, the need of minimum end to end delay with almost no loss in data i.e. maintaining stringent Quality of Service at every end, is a challenging task.

This monograph will be helpful for the researchers to investigate middleware architecture in IEEE 802.11 framework to deliver robust design solution in wireless network.

#### **Conflict of interest**

"The authors declare no conflict of interest."

*Middleware Architecture - History and Adaptation with IEEE 802.11 DOI: http://dx.doi.org/10.5772/intechopen.97124*

#### **Author details**

Rochak Bajpai1 \*, Atul Bansal<sup>2</sup> , Jyoti Tripathi3 and Sridhar Iyer4

\*Address all correspondence to<EMAIL_ADDRESS>
© 2021 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/ by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

### **References**

[1] Bauer F.L., Bolliet L., Helms H. J., "Software Engineering: Report on a conference sponsored by the NATO science committee", Garmisch, Germany, Tech. Rep. Jan. 1969. \url{ http://homepages.cs.ncl.ac.uk/brian. randell/NATO/nato1968.PDF} [Accessed: 04 January 2021]

[2] Mindell DA. "Between human and machine: feedback, control, and computing before cybernetics". JHU Press; 2002 Oct 11.

[3] Graham S, Baliga G, Kumar PR. "Abstractions, architecture, mechanisms, and a middleware for networked control". IEEE Transactions on Automatic Control. 2009 Jun 30;54(7):1490-503.

[4] Prieto-Diaz R. "Status report: Software reusability". IEEE software. 1993 May;10(3):61-6.

[5] Kumar S, Dalal S, Dixit V. "The OSI model: Overview on the seven layers of computer networks". International Journal of Computer Science and Information Technology Research. 2014 Jul;2(3):461-6.

[6] Dong H. "Middleware Technologies". Journal of Anhui Vocational College of Electronics \& Information Technology. 2006:04.

[7] Lu ZJ, Yan Z. "Middleware Technology Research and Interface Design in Ubiquitous Network". In2015 Seventh IEEE International Conference on Measuring Technology and Mechatronics Automation 2015 Jun 13 (pp. 659-662).

[8] Bernstein PA. "Middleware: a model for distributed system services". Communications of the ACM. 1996 Feb 1;39(2):86-98.

[9] Tian Y, Geiger JV, Su H, Kumar SV, Houser PR. "Middleware-based sensor web integration". IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing. 2010 Jun 21;3(4):467-72.

[10] Li B, Nahrstedt K. "A control-based middleware framework for quality-ofservice adaptations". IEEE journal on selected areas in communications. 1999 Sep;17(9):1632-50.

[11] Ong CS, Xue Y, Nahrstedt K. "A middleware for service adaptation in differentiated 802.11 wireless networks". InProceedings. 2004 12th IEEE International Conference on Networks (ICON 2004)(IEEE Cat. No. 04EX955) 2004 Nov 19 (Vol. 1, pp. 364- 368). IEEE.

[12] Li B, Nahrstedt K. A control-based middleware framework for quality-ofservice adaptations. IEEE journal on selected areas in communications. 1999 Sep;17(9):1632-50.

[13] Tanenbaum AS, Wetherall D. Computer networks. Prentice-Hall international editions. 1996 Mar:I-XVII.

[14] Peterson LL, Davie BS. Computer networks: a systems approach. Elsevier; 2007 Apr 16.

[15] Stallings W. Local networks. ACM Computing Surveys (CSUR). 1984 Mar 29;16(1):3-41.

[16] Stallings W. Data and computer communications. Pearson Education India; 2007.

[17] Hiertz GR, Denteneer D, Stibor L, Zang Y, Costa XP, Walke B. The IEEE 802.11 universe. IEEE Communications Magazine. 2010 Jan 22;48(1):62-70.

[18] Bellavista P, Corradi A, Stefanelli C. Mobile agent middleware for mobile computing. Computer. 2001 Mar;34(3):73-81.

*Middleware Architecture - History and Adaptation with IEEE 802.11 DOI: http://dx.doi.org/10.5772/intechopen.97124*

[19] Ong CS, Xue Y, Nahrstedt K. A middleware for service adaptation in differentiated 802.11 wireless networks. InProceedings. 2004 12th IEEE International Conference on Networks (ICON 2004)(IEEE Cat. No. 04EX955) 2004 Nov 19 (Vol. 1, pp. 364- 368). IEEE.

[20] Costa R, Lau J, Portugal P, Vasques F, Moraes R. Handling real-time communication in infrastructured IEEE 802.11 wireless networks: The RT-WiFi approach. Journal of Communications and Networks. 2019 May 29;21(3):319-34.

[21] da Rocha RC, Endler M. Middleware: Context management in heterogeneous, evolving ubiquitous environments. IEEE Distributed Systems Online. 2006 May 15;7(4).

[22] da Cruz MA, Rodrigues JJ, Al-Muhtadi J, Korotaev VV, de Albuquerque VH. A reference model for internet of things middleware. IEEE Internet of Things Journal. 2018 Jan 23;5(2):871-83.

[23] Qiao D, Choi S, Shin KG. Goodput analysis and link adaptation for IEEE 802.11 a wirelessLANs. IEEE transactions on Mobile Computing. 2002 Oct;1(4):278-92.

[24] Bellavista P, Corradi A, Giannelli C. Efficiently managing location information with privacy requirements in wi-fi networks: a middleware approach. In2005 2nd International Symposium on Wireless Communication Systems 2005 Sep 5 (pp. 91-95). IEEE.

[25] Abangar H, Barnaghi P, Moessner K, Nnaemego A, Balaskandan K, Tafazolli R. A service oriented middleware architecture for wireless sensor networks. InProceedings of future network and mobile summit conference 2010 Jun.

[26] Heinzelman WB, Murphy AL, Carvalho HS, Perillo MA. Middleware to support sensor network applications. IEEE network. 2004 Jun 28;18(1):6-14.

[27] Jawhar I, Mohamed N, Zhang L. Inter-vehicular communication systems, protocols and middleware. In2010 IEEE Fifth International Conference on Networking, Architecture, and Storage 2010 Jul 15 (pp. 282-287). IEEE.

[28] Nitti M, Girau R, Floris A, Atzori L. On adding the social dimension to the internet of vehicles: Friendship and middleware. In2014 IEEE international black sea conference on communications and networking (BlackSeaCom) 2014 May 27 (pp. 134-138). IEEE.

[29] Pease SG, Phillips IW, Guan L. Adaptive intelligent middleware architecture for mobile real-time communications. IEEE Transactions on Mobile Computing. 2015 Apr 27;15(3):572-85.

[30] Viterbo J, Sacramento V, Rocha R, Baptista G, Malcher M, Endler M. A middleware architecture for contextaware and location-based mobile applications. In2008 32nd Annual IEEE Software Engineering Workshop 2008 Oct 15 (pp. 52-61). IEEE.

#### **Chapter 3**

## Middleware Application, Suitable to Build an Automated and Connected Smart Manufacturing Environment

*Muzaffar Rao and Thomas Newe*

#### **Abstract**

The current manufacturing transformation is represented by using different terms like; Industry 4.0, smart manufacturing, Industrial Internet of Things (IIoTs), and the Model-Based enterprise. This transformation involves integrated and collaborative manufacturing systems. These manufacturing systems should meet the demands changing in real-time in the smart factory environment. Here, this manufacturing transformation is represented by the term 'Smart Manufacturing'. Smart manufacturing can optimize the manufacturing process using different technologies like IoT, Analytics, Manufacturing Intelligence, Cloud, Supplier Platforms, and Manufacturing Execution System (MES). In the cell-based manufacturing environment of the smart industry, the best way to transfer the goods between cells is through automation (mobile robots). That is why automation is the core of the smart industry i.e. industry 4.0. In a smart industrial environment, mobile-robots can safely operate with repeatability; also can take decisions based on detailed production sequences defined by Manufacturing Execution System (MES). This work focuses on the development of a middleware application using LabVIEW for mobile-robots, in a cell-based manufacturing environment. This application works as middleware to connect mobile robots with the MES system.

**Keywords:** MES, Robots, Cell-based manufacturing, Middleware, ROS

#### **1. Introduction**

Initially, the drive of automation was to upturn productivity and to decrease the cost associated with human operators. But now the automation also emphasizes to improve flexibility and quality in a manufacturing process [1]. Automation is an essential part of the Industry 4.0 strategy, which is fully reshaping the old manufacturing process and supporting the growth of the business. Industrial automation refers to a mechanism that combines hardware and software. Industrial automation is the use of control systems and information technologies to handle different types of machinery and processes in an industry to replace a human being. Robotic automation [2–4] is used in several areas of manufacturing industries. Robots can be used to perform tasks like assembly, welding, shipping, product packing, and handling raw materials. Many manufacturers are leveraging robotic automation

for many applications. Robotic automation offers manufacturers growing opportunities and to remain competitive. Currently available industrial robots are multi-functional, so a single robot can be used for several different tasks. Sharing of the same workspace for robots and humans is becoming necessary in a smart manufacturing environment. To achieve this, robots should have the capabilities to sense and communicate. Modern mobile-robots (AIVs) can move autonomously from one place to another to achieve defined goals. For two decades, mobile-robots are in continuous research, and the rapid advances in robotics, computer vision & artificial intelligence are resulting in robots that can potentially hear and see more precisely than humans. This advancement in mobile-robots demands their rapid deployment in an industrial environment. The manufacturing process is evolving and from the robotics aspect, the industries are moving from Autonomous Guided Vehicles (AGVs) to Autonomous Intelligent Vehicles (AIVs). The use of AIVs is also reshaping the production lines in a smart factory.

A production line is a configuration of a factory that consists of a sequence of manufacturing steps. The current ideology of manufacturing depends on the linear production line. This ideology works in case of high volume demand of identical goods. But, the linear production line is not the most efficient way in the case of a large volume of goods with several choices. Manufacturers are looking for a cell-based approach to offer products with different varieties. As the cellbased approach involves more complex production flows so for this, conveyor line production systems are not suitable [5]. In cell-based manufacturing, the best way to handle the goods shifting between cells is the use of mobile-robots. Intelligent mobile-robot that knows the environment in which it operates, and that can calculate the optimized route between different cells are the best to use in the above mentioned cell-based manufacturing system. The linear and cell-based production line concept in a factory that manufactures PCBs is shown in **Figure 1**.

This work is about the development of a middleware application using LabVIEW software to control/manage the mobile-robot. This middleware

#### **Figure 1.**

*Linear vs. cell-based production line concept. (a) Traditional linear production line. (b) Cell-based production line.*

*Middleware Application, Suitable to Build an Automated and Connected Smart Manufacturing... DOI: http://dx.doi.org/10.5772/intechopen.97397*

#### **Figure 2.**

*Controlling of mobile-robots from a remote system using LabVIEW.*

application is installed on the remote system mentioned in **Figure 2**. This work is part of an ongoing project, which involves the integration of fleets of mobilerobots and Manufacturing Execution System (MES) [6–8]. Here, the focus is on the development/testing of the LabVIEW application that can communicate with mobile-robots. The LabVIEW software is used by keeping in mind the future advancement of this application, which needs communication of fleets of robots with MES and this can be achieve using LabVIEW as middleware. The designed software application can be used with any ROS (Robot Operating System) based Robot. Here, turtlebot-3 [9, 10] and RB-1 (Robotnik) [11] are used for real-time testing.

This paper is organized as follows: Section 2 covers the industrial automation details and Section 3 discusses Mobile Robots (AIVs). Section 4 is about Robot Operating System (ROS) and Section 5 provides details of the target application. In Section 6 development of the LabVIEW application is given while Section 7 provides a discussion and Section 8 concludes.

#### **2. Industrial automation**

Manufacturers continuously face pressure to increase productivity and as mentioned in the introduction section, automation is the key to enable manufacturers to move closer to that goal in addition to meet the flexibility and quality requirements. There are numerous advantages of industrial automation, out of which some are given as [12]:

#### **2.1 Quality control**

Quality control is needed to build the customers' trust. A high level of quality compliance can be achieved by using robots in a manufacturing environment.

#### **2.2 Repeatability**

To be sure about consistency and the same quality end product is difficult without automation and this is achievable using repeatability. While, repeatability can be achieved using robots that are capable to perform the exact similar task in exactly the same way, repeatedly. This can help to save time as fewer errors result in less wasted time.

#### **2.3 Waste reduction**

The repeatability (mentioned above) allows manufacturers to minimize overall waste. Less error, as a result of repeatability, helps not only to save time, but it also minimizes the amount of material needed to yield the product. For example, robots can use less wire for welding, cut closer to the edge, and can use less amount of paint.

#### **2.4 Faster cycle times**

The production cycle time can be greatly improved using a robot. The more production helps to get the higher demand and ultimately brings more money.

#### **2.5 Improved workplace**

Safety Robots can be used in places which are not suitable for human. So, automation also helps to build safety environment.

#### **2.6 Reduction of labor costs**

Robots can replace jobs by removing workers from tough roles, which can help to reduce labor costs.

#### **2.7 Reduced floor space**

It's easy to start spreading out across the shop floor with extra materials, machinery, and tools. Robots can help to reduce the footprint of the required workspace by optimizing everything into a smaller, confined space.

#### **2.8 Integration with business systems**

Machinery and Robots can talk with each other to give a better view of the operating environment. This can help to make a smart decision on how to improve their process.

The next section describes mobile-robots with the focus on the robotic platform used here for testing.

#### **3. Mobile-robots (AIVS)**

Almost half a century ago, the first simple robot stepped onto the factory floor [13]. Today, a modern manufacturing business can be hardly imagined without the involvement of robots. The integration of robots with smart technologies allows the creation of more independent robotic systems that are not only able to carry out basic repetitive operations such as assembling, loading or modifying parts, but can also perform cognitive tasks, improving processes without human intervention and making instant decisions. In this work, turtlebot-3 and RB-1 (Robotnic) robots are used for the real-time testing of the developed LabVIEW application.

Turtlebot is a robot that is based on ROS Standard. There are three versions of turtlebot, turtlebot-1, turtlebot-2 and turtlebot-3 released in 2010, 2012, and 2017 respectively. There are two models of turtlebot-3 namely burger and waffle. Here, the burger model of turtlebot-3 is used, which is an affordable, small, and the ROS based mobile-robot. The core technology of the turtlebot-3 is SLAM (Simultaneous Localization and Mapping), Navigation, and Manipulation. Turtlebot-3 uses a Laser Distance Sensor (LDS-01), which is a 2D laser scanner capable of sensing 360 degrees that collects a set of data around the robot to use for SLAM. The turtlebot is connected/controlled through a remote system using wifi connection. The designed LabVIEW software is also tested with RB-1, which is used for real-time implementation in a factory environment. RB-1 is an autonomous and configurable robot, focused on the field of research in indoor applications. RB-1 is also based on ROS and uses an open architecture and modular control. The RB-1 platform comes with

*Middleware Application, Suitable to Build an Automated and Connected Smart Manufacturing... DOI: http://dx.doi.org/10.5772/intechopen.97397*

**Figure 3.** *Turtlebot-3(burger) and RB-1(Robotnik).*

a Hokuyo URG-04LX-UG01 [14], a 2D laser range finder for navigation. Turtlebot-3(burger) and RB-1 are shown in **Figure 3**.

The mobile-robots used in this work are based on Robot Operating System (ROS), which detail is given in the next section.

#### **4. Robot operating system (ROS)**

ROS is a meta-operating system for robots [15]. This is an open-source platform which functions are equivalent to what we expect from an operating system. These functions include low-level device control, hardware abstraction, message passing between processes, implementation of commonly-used functionality, and package management. The ROS meta operating system (shown in **Figure 4**) also provides libraries and tools for obtaining, building, writing, and running code across multiple computers. This meta-operating system is different than conventional operating systems in a way that it can be used for a different combination of hardware implementation.

However, unlike conventional operating systems, it can be used for numerous combinations of hardware implementation. Furthermore, it is a robot software platform that gives many development environments specialized for developing robot application programs. ROS runs on Ubuntu operating system; here we used Ubuntu 16.40 LTS. ROS supports many programming languages; here we used C++. There are different versions of ROS; here ROS Kinetic is used. In ROS, the smallest running unit of the processor is called a node. The first step is to run ROS\_Master. Upon startup of the master, a node registers information such as name, message type, URI address, and port number of the node. The registered node can act as a publisher or subscriber based on the registered information, and nodes can exchange messages using topics and services. In this work, as mentioned earlier, the software application is developed using LabVIEW, which has support for ROS. The ROS for LabVIEW is a set of LabVIEW VIs that enables two-way communication

**Figure 4.** *Meta-operating system [15].*

between ROS (running on Ubuntu machine) and LabVIEW (running on a windows machine). The LabVIEW ROS allows users to initialize nodes, publish and subscribe to various types of topics, and creates a ROS\_Master within LabVIEW.

The next section mentioned target application details, which will help to understand the overall project concept.

#### **5. Target application**

This work is part of an ongoing project related to the integration of a fleet of mobile-robots and MES, targeted to design for the cell-based manufacturing environment. The target plant used traditionally linear manufacturing production lines for the assembly of its products. This approach takes a continuous flow in-line with balanced operations. The concern with this approach moving forward is the high up-front investment cost to achieve a Return On Investment (ROI). The line is designed for one product type, it is not flexible and is unsuitable for new product demand due to new product business or product revisions that may arise. The development of new smart manufacturing assembly lines i.e. cell-based will allow for flexibility to volume fluctuations, will support product ramp up/down, and the use of the latest automation technologies such as Industry 4.0 and the Internet of Things (IoT). The smart manufacturing assembly line will be used for multiple products, having the capability of a flexible production system for all production operations.

In cell-based manufacturing, different cells will be connected by an automatic product delivery system which will transport the product through the manufacturing process from process cell to process cell as defined by detailed production sequences using an MES. The automatic product delivery system will take the form of a fleet of AIVs with the ability to collect and deliver products to process cells in a format suitable for product feed. As mentioned earlier, this work focuses on one part of this target application i.e. development of a LabVIEW application that can communicate between the fleet of robots and MES. Details of this development are given in the next section.

#### **6. Development of LabVIEW application**

To prepare the ROS package for mobile-robots, ROS Kinetic is installed on Ubuntu 16.04 system and a code is prepared in C++ to publish and subscribe messages. This code declares a subscriber that subscribes to a topic (published by LabVIEW publisher) to receive commands for the robot and publishes a topic (subscribed by LabVIEW subscriber) to send an acknowledgment. Therefore, we can say that here publisher/subscriber sends/receives data to/from LabVIEW respectively. To take coordinates of physical location a map is generated using SLAM. Initially, the robot is taken around the workplace and allowed to scan the surrounding area with its main LiDAR sensor. It stitches that information together to form a complete static map of the workplace. The robot uses the map to calculate the best route between any two points. Here we are using hard codded coordinates of physical locations. The coordinates are taken using amcl node, which takes laser scans, transforms messages and outputs estimated pose.

The LabVIEW code consists of two while loops; one for publisher and the other for a subscriber. The ROS node is initialized using ROS\_Topic\_init subVI. The input of this subVI is connected with topic name, topic type, action (publisher or subscriber), and update rate and queue size. The node name (/LV1) is also

*Middleware Application, Suitable to Build an Automated and Connected Smart Manufacturing... DOI: http://dx.doi.org/10.5772/intechopen.97397*

assigned using the 'node' terminal of ROS\_Topic\_init.vi. The ROS\_Topic\_init.vi is connected to ROS\_Topic\_Read.vi (in case of subscriber) and ROS\_Topic\_Write. vi (in case of publisher). The 'msg\_in' input of ROS\_TOPIC\_Write.vi is connected with 'msg\_out' of add\_string.vi. The message which needs to publish is connected with the 'String' terminal of add\_String.vi. While, in subscriber the 'Reply' terminal of ROS\_TOPIC\_Read.vi is connected with 'msg-in' of parse\_string.vi. The string output of the parse\_string.vi is connected as an indicator, which shows the robot response. The subscriber and publisher topics are closed using ROS\_Topic\_Close.vi. Multiple instances of the LabVIEW application are used to control more than one Mobile-Robots.

The developed software application is initially tested using turtlebot-3, as mentioned in Section 3. For this testing, two Linux systems and one windows system are used. Out of two Linux systems, one is used as remote-PC (Ubuntu 16.04) and the other is referring to turtlebot-PC (Raspbian). The ROS packages and all dependent packages are installed on remote PC and turtlebot-PC. All steps mentioned in [16] are followed to setup turtlebot, remote-PC, and turtlebot-PC. The Windows PC is used to run the LabVIEW. ROS communicate between systems using IP addresses; so, the turtlebot-PC, remote-PC, and windows-PC connected to the same wifi router. The .bashrc file is edited on turtlebot-PC and remote-PC in such a way that ROS\_Master runs on remote-PC. The map is generated using SLAM node and then we noted coordinates of target physical locations. These coordinates are needed for ROS packages. Testing is started by running ROS\_Master on remote-PC and then bring-up packages of turtlebot are executed. Navigation node runs as a next step (on remote-PC), which opens the rviz (visualization tool) with the selected map. The map shows turtlebot at some random point, so the estimated posture of robot is set in rviz. Upon running the ROS node, it keeps looking for a message from LabVIEW. The LabVIEW application pops-up a window to enter the Master\_IP\_address that is the address of remote-PC where ROS\_Master is running. LabVIEW application sends some predefined strings that receive by subscriber running on remote-PC. Based on the received strings, target location coordinates are transferred to turtlebot. Upon reaching the target location, turtlebot sends an acknowledgment. This shows a successful communication between LabVIEW and mobile-robots. The same testing is done using RB-1, only the difference is that here we need only two systems (LabVIEW system and RB-1 system) as in this case ROS\_Master runs on RB-1.

This work provides the foundation to develop a software application to control mobile- robots that can be used to integrate a fleet of mobile-robots to the MES system. Direct communication between MES and the mobile-robots is not possible that's why we introduced the middleware LabVIEW application and presented this idea in [17], which summary is given below.

Previously presented work [17] emphases on the integration of an MES and AIV that is needed to develop a completely automated, connected smart manufacturing environment. This integration requires a middleware application to execute the command translations between MES and AIVs. Here, a LabVIEW based application is built as the middleware. The middleware application development is divided into 03 major parts: (1) LabVIEW & MES communication, (2) LabVIEW & AIV communication, and (3) scheduler. In part (1), the middleware application imports relevant webservices of MES and produce corresponding LabVIEW VIs. The produced LabVIEW VIs are configured using the LabVIEW. NET functions. In part (2), the middleware application utilizes the 'ROS for LabVIEW' (LabVIEW add-on) to establish communication with an AIV. Part (3) comprises of a full cycle of scheduler operation, that consists of eight steps. These eight steps are: checking of pickup locations status, selection of one pickup location, pick the product, confirm

to the MES about completion of pickup operation, checking of drop-off locations status, selection of one drop-off location, drop the product, and confirm to the MES about the completion of the drop-off operation. The middleware application was tested in two stages, during the development phase, the Turtlebot-3 robot was used for testing and finally, the middleware application was commissioned using the Robotnik 'RB-1′robot in an actual factory environment. The developed middleware application supports 03 pickup and 03 drop-off locations. The pickup and drop-off locations are chosen based on pre-defined rules. The interface of the developed middleware application can be easily used by a non-technical operator and it displays a live log of operation.

The presented concept can be expended at a fleet level using the following: (a) Communication between multiple instances of LabVIEW application with each robot on the factory floor – this is a decentralized approach and the problem with this approach is the risk of assigning the same tasks at the same time to more than one robot. But this approach is ideal when each robot is assigned a dedicated zone in a manufacturing environment (b) Running ROS\_Master using LabVIEW application and control all robots in the field – The issue with this centralized approach is that there will be no communication with robots in the field in case if the system running LabVIEW stops working. This chapter focused on the case (a). The LabVIEW application will take the instructions from MES and send the command to robots in the field accordingly. The LabVIEW-MES communication is not the focus of this chapter.

#### **7. Conclusion**

This work is part of an on-going project which involves the integration of a fleet of mobile-robots (AIVs) with MES. This integration can be achieved using LabVIEW software as middleware because it can support both LabVIEW-to-Robots and LabVIEW-to-MES communication. This work focuses on the development/ testing of LabVIEW-to-Robots communication. In the final setup, the LabVIEW system will work as a middleware between multiple Robots and MES. The designed LabVIEW application will be further developed to meet the overall requirements of fleet management. The updated version of the application will allow more complex production flows and the process of calling robot to pick the load; will be more intelligent by linking with MES in a fleet environment. This will provide an even larger boost to productivity, flexibility, and quality in a smart manufacturing environment.

#### **Acknowledgements**

This publication has emanated from research supported in part by a grant from Science Foundation Ireland under Grant numbers 13/RC/2094 and 16/RC/3918. For the purpose of Open Access, the author has applied a CC BY public copyright license to any Author Accepted Manuscript version arising from this submission.

#### **Conflict of interest**

The authors declare no conflict of interest.

*Middleware Application, Suitable to Build an Automated and Connected Smart Manufacturing... DOI: http://dx.doi.org/10.5772/intechopen.97397*

#### **Author details**

Muzaffar Rao and Thomas Newe Centre for Robotics and Intelligent Systems (CRIS), Department of Eelectronic and Computer Engineering, University of Limerick, Ireland

\*Address all correspondence to<EMAIL_ADDRESS>
© 2021 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/ by/3.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

### **References**

[1] M. Wiktorsson , A. Granlund, M., Lundin, B. Södergren, "Automation and Flexibility: Exploring Contradictions in Manufacturing Operations" Conference: 23rd EurOMA conference, Trondheim, Norway

[2] R. Szabó and A. Gontean, "Industrial robotic automation with Raspberry PI using image processing," 2016 International Conference on Applied Electronics (AE), Pilsen, 2016, pp. 265-268

[3] S. Choi, W. J. Eakins and T. A. Fuhlbrigge, "Trends and opportunities for robotic automation of trim & final assembly in the automotive industry," 2010 IEEE International Conference on Automation Science and Engineering, Toronto, ON, 2010, pp. 124-129

[4] B. Chu et al., "Robotic automation system for steel beam assembly in building construction," 2009 4th International Conference on Autonomous Robots and Agents, Wellington, 2009, pp. 38-43

[5] B. Shishir, (2010). Changing from conveyor to work-cell-based systems to deal with fluctuations in demand. Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture, 224(1), 169-176. URL: https://doi. org/10.1243/09544054JEM1374

[6] Hennessey, T. MES is an Essential Part of Smart Manufacturing URL: https://www.ibaset.com/blog/ mes-is-an-essential-part-ofsmartmanufacturing/(online)

[7] MESA International. MES Explained: A High Level Vision for Executives.Available online: https://services.mesa.org/ resourcelibrary/showresource/334444c 5-388f-4360-beb4-3c86dc0f4de4

[8] SAP MES. Available online: https:// www.sap.com/uk/produc ts/executionmes.html.

[9] D. Singh, E. Trivedi, Y. Sharma and V. Niranjan, "TurtleBot: Design and Hardware Component Selection," 2018 International Conference on Computing, Power and Communication Technologies (GUCON), Greater Noida, Uttar Pradesh, India, 2018, pp. 805-809.

[10] Turtlebot (online), URL: https:// www.turtlebot.com/

[11] Robotnik(RB-1) (online), URL: https://www.robotnik.eu/ manipulators/rb-one/

[12] RobotWorx, "Advantages of Industrial Automation with Robots" Robotic Articles(online), URL: https:// www.robots.com/articles/ advantages-of-industrialautomationwith-robots

[13] SaM Solutions, "Five Reasons to Implement Robotics in Manufacturing" (online), URL: https://www. samsolutions.com/blog/category/ manufacturing/

[14] Hokuyo "Distance Data Output/ URG-04LX-UG01"(online), URL: https://www.hokuyo-aut.jp/search/ single.php?serial=166

[15] Y. Pyo, H. Cho, R. Woon J., T. Lim, "ROS Robot Programming " First Edition Dec 22, 2017 Published by ROBOTIS Co.,Ltd ISBN 979-11- 962307-1-5

[16] Robotics e-manual Turtlebot-3 (online), URL: http://emanual.robotis. com/docs/en/platform/turtlebot3/ overview/

[17] M. Rao; L. Lynch; J. Coady; D. Toal; T. Newe, "Integration of an MES and AIV Using a LabVIEW Middleware Scheduler Suitable for Use in Industry 4.0" Applications. *Appl. Sci.* 2020, *10*, 7054. https://doi.org/10.3390/ app10207054

Section 2

## Cloud Computing Middleware

**Chapter 4**

## Middleware Patterns for Cloud Platforms

*Gary S.D. Farrow*

#### **Abstract**

This chapter explores how traditional system architectures are being affected by the emergence of 'Uber' style platform models that provide business services with huge global reach. The specific demands and characteristics of such platforms are discussed which in turn dictate their technical requirements. The chapter will explain how middleware technologies have evolved to support today's requirements for such massively scalable platform solutions. The latest preferred architectural paradigms dictate the use of micro-services and APIs are central to the design of such platforms. Similarly, event based architectures are another key paradigm that must be supported. The role of modern middleware and cloud technologies to support these newly dominant paradigms will be explained. Key architectural patterns pertinent to global platform solutions are illustrated. The role of modern middleware in fulfilling these patterns is highlighted using real-world examples from the field of open finance.

**Keywords:** Cloud architecture, migration patterns, API ecosystem, event-based architecture, microservices, cloud migration, PSD2, open banking

#### **1. Introduction**

This Chapter describes advanced patterns relating to the use of cloud platforms in hosting IT solutions. The context for the patterns is the evolution towards open information ecosystems, mandated to a large degree by regulatory initiatives such as PSD2 [1], but also by competitive necessity. In this future business environment, there is an expectation of a significant increase in transaction volumes as new and innovative services become available for consumers.

The Chapter describes why cloud platform are the essential technology to provide cost effective scalability for IT solutions. The patterns highlight how new application components in the cloud are used in conjunction with existing on premises applications in a hybrid approach to deployment. Further, the Chapter also highlights how the patterns can then be used as part of a phased, but fully complete, migration to the cloud. Finally, specific real world usage scenarios for the patterns are highlighted.

The patterns are presented in a cloud vendor agnostic way and can be implemented in any of the key cloud provider technologies; Amazon Web Services (AWS), Google Cloud Platform (GCP) or Microsoft Azure.

The Chapter is structured as follows; Section 2 provides the background in terms of the business environment and the associated business drivers that necessitate the move to cloud. It further explores the technology perspectives of cloud that provide the specific advantages over conventional infrastructure technologies to support

the emerging business environment. Section 3 introduces the definition of a cloud platform in the specific business context outlined.

Section 4 provides the underpinnings of the key cloud platform patterns in the form of relevant established architecture patterns and outlines the essential building blocks for cloud solutions. Section 5 then uses these underpinnings to describe the proposed cloud platform architecture patterns. Section 6 illustrates the use of the cloud patterns to achieve a migration from conventional IT solution deployment via a multi-phased approach. Finally, in Section 7, real-world scenarios are described to which the cloud patterns are directly applicable.

#### **2. Background**

Cloud computing has revolutionised the provisioning of infrastructure for IT services. As the maturity of the cloud offerings has increased, the richness of the of capability has progress from, initially, Infrastructure as a Service (IaaS), through to Platform as a Service (PaaS) and then Software as a Service (SAAS). The latest generation of cloud services relate to the availability of cloud platforms; domain specific applications connecting users of a particular services with the service providers via the concept of a cloud platform. There are numerous examples now appearing but, one of the earliest and a classic example of such is Uber.

The Chapter introduces some key business drivers for the use of cloud platforms. Specifically, the context of regulatory changes relating to open banking are used to illustrate trends in financial services domain. Its consequences in terms of impacts to IT system non-functional requirements, particularly those relating to the ability to scale on demand and cost effectively, are highlighted. This creates a problem for an organisation's IT function in supporting these trends.

The use of cloud technology and cloud platforms is now ubiquitous in most organisations IT architectural thinking, with the promise of providing:

Various patterns for the migration of components to the cloud have been identified previously [2]. These have focussed on basic technology migration patterns such as:

This focus of this Chapter is in defining advanced, application migration patterns that exploit the advantages of cloud computing for use in emerging and future open information ecosystems. The patterns highlight the essential adoption and use of cloud platforms through:

#### **2.1 Business drivers**

The introduction of new financial market regulation, notably the revised Payments Services Directive [1] (or PSD2), has mandated banks to open up account information and payment services to third parties. The regulation is considered an important enabler for the creation of new and innovative customer propositions. PSD2 is recognised as a trigger for the wider concepts of 'open banking' and, beyond this, 'open finance' in which ultimately a rich variety of financial services are accessible to an ecosystem of third parties comprising third parties, business partners and industry bodies.

Open banking has led to a corresponding rise in financial technology organisations – namely the "*fintechs*". Indeed, information pertaining to the take up of open banking services confirms that 94% of fintechs view open banking as a major area of opportunity [3].

The net effect of this is that there is likely to be a growth in financial transactions accessing customer accounts as new services, founded on the open access regulation, are brought to market. This presents a challenge for financial institutions; that of scaling their IT systems cost effectively to support the new market dynamics with increased transaction volumes.

To summarise:

Organisations are therefore faced with a key problem to address of how to combine the value of their existing mature core applications with the advantages that cloud technology provides. Superficially, they are faced with a number of high-level architecture challenges:

#### *Middleware Architecture*

This Chapter helps organisations to address these key issues by describing a variety of patterns highlighting relevant cloud platform usage scenarios including hybrid deployments and patterns to support, ultimately, the full migration of services to a cloud platform.

#### **2.2 Cloud technology drivers**

In this Section, a precis of the features of cloud technologies is provided. These reinforce what makes a cloud platform suitable for supporting the provision of scalable information services in general and the specific emerging trends in banking. The notable technology features are:

Consider now a traditional IT architecture that supports banking and other information systems. The underlying customer information will typically reside in a 'system of record', the implementation of which typically fall into one of two categories:

In the context of open information access, the ability to scale on demand and at a cost that is linear to the transaction load becomes a key requirement. However,

#### *Middleware Patterns for Cloud Platforms DOI: http://dx.doi.org/10.5772/intechopen.98884*

both of the above implementation options present challenges in meeting the nonfunctional characteristics of a new open information ecosystem outlined since the ability to scale cost effectively becomes difficult.

One reason for this is that both legacy and vendor product pricing are typically very dependent on supporting hardware and the number of CPUs required. Hence cost breaks relating to hardware and vendor product licencing tend to be highly non-linear. To accommodate the open information ecosystem and expected transaction growth via a traditional IT architecture typically means over-engineering to allow for sufficient headroom in the capacity. Thus, mitigating the scalability risk in a traditional IT architecture is likely to be highly cost inefficient given the wide range of loads that could be experienced.

#### **2.3 Open information ecosystem requirements**

The difference in usage profiles between open banking and traditional banking are now explored. In general, traditional banking is subject to highly predictable loads based on:

	- Daily processing cycles such as overnight batch processing
	- Monthly processing cycles, such a billing

It is reasonable to assume that net transaction volumes will inevitably increase substantially as third parties develop their propositions and these gain maturity in the marketplace. This alone will result in customers interacting with their bank more frequently, albeit indirectly via the third parties applications in '*customer present'* scenarios. Also, there will be an increase in transaction volume driven from the third parties directly. Third parties, having obtained consent from the customer for specific account information, will exercise their right under PSD2 to access that information up to four times daily in '*customer not present'* scenarios.

However, with open banking, transactional loads are likely to be significantly less predictable. The open banking transaction volumes have a more complex and less deterministic relationship with existing customer volumes and their access patterns:

	- i.The percentage of account holders that subscribe to use PSD2 services is not yet known
	- ii.The number of PSD2 services that customers subscribe to is likely to be highly variable

• Information access patterns are less predictable and determined by the third party rather than via predictable customer access patterns that are well understood by the banks'.

These characteristics translate to specific IT issues for the account information provider, notably:

### **3. Cloud platform approach**

Given the challenges highlighted for open information access, the role of a cloud platforms in the providing solutions to this problem have previously been identified [4].

#### **3.1 Platform definition**

In brief, a platform is a business based on enabling value-creating interactions between external producers and consumers. The platform provides an open, participative infrastructure for these interactions and operates within governance conditions set for them. The platform's overarching purpose: to consummate matches among users and facilitate the exchange of goods, services, or social currency, thereby enabling value creation for all participants.

#### **3.2 Technical service provider platforms**

A Technical Service Provider (TSP) is a non-regulated participant in the PSD2 ecosystem. They provide services on behalf of a regulated entity and provide the necessary IT components to implement the required PSD2 services, intermediating between an Account Provider and a Third Party Provider via their platform, as illustrated in **Figure 1**. Standards for PSD2 access to account services (e.g. from the Berlin Group [5]) universally employ application programming interfaces (APIs), these being the de facto standard for B2B interfaces over the Internet. Further, as the ecosystem expands to accommodate broader open banking services, there is an expectation that additional, non-regulatory, services will also be implemented using APIs.

**Figure 1.** *Cloud platform context.*

*Middleware Patterns for Cloud Platforms DOI: http://dx.doi.org/10.5772/intechopen.98884*

TSP platforms can accommodate such open banking services on behalf of an account provider.

#### **3.3 Summary**

The concept of a cloud platform has been introduced and the associated advantages highlighted. In practice such a platform can either be provided by a third party, known as a TSP, or by the bank themselves in the form of a private cloud. For the purposes of the patterns now described below and their rationale, this distinction is not significant.

### **4. Pattern building blocks**

#### **4.1 Command query response segregation**

Command Query Response Segregation (CQRS) is a fundamental design pattern identified by Young [6] and Fowler [7]. Up until recently, the use of this pattern was quite limited and, furthermore, its usage came with caveats about the additional implementation complexity required. Through an implementation of this pattern,

**Figure 2.** *Abstract CQRS pattern.*

it will be shown that certain key benefits of a cloud platform can be realised. The pattern is shown conceptually in **Figure 2**.

In its abstract form, the pattern is very simple:

The pattern is unspecific regarding implementation.

The significant feature of this pattern is that is reduces loading on the Data Master, since only write operations are performed on this data store. In the context of financial services this is highly significant. Consider the Data Master as supporting a system of record such as an accounting application. Since the majority of transactions on accounts are in fact read operations (typically 80%), by having a separate data cache for read only transactions, this approach becomes highly effective in reducing the net load on the system of record.

In the cloud patterns described in this Chapter, it will be shown how the query service and the command service can be implemented independently and deployed to a cloud platform in a phased approach if necessary. This enables scalability and performance and ultimately can facilitate a complete migration of a system to a cloud platform.

#### **4.2 Publish-subscribe architecture**

Publish-Subscribe is an architectural pattern that is exploited in the proposed patterns for cloud platforms. The components of the pattern are illustrated in **Figure 3**. The pattern is fundamentally about message distribution:

**Figure 3.** *Publish - subscribe architecture.*

#### *Middleware Patterns for Cloud Platforms DOI: http://dx.doi.org/10.5772/intechopen.98884*

The Publish/Subscribe engine manages the distribution of messages based on the set of subscriptions. When an event is published, the engine matches the subscribers, typically based on the assignment of 'topics' and transports the message to the destination accordingly.

#### **4.3 API gateway**

A brief description of an API Gateway is provided here for the purpose solely of illustrating its role in the cloud patterns. In short, an API Gateway provides services for the management of APIs. These services broadly equate to a set of policy driven capabilities that dictate the characteristics and behaviour of an API. Typical policies relate to:

In addition, an API Gateway acts as an audit point and the logging of API usage. A number of commercial and open source API Gateway offerings are available.

#### **4.4 Micro services architecture**

The Service Oriented Architecture (SOA) paradigm has previously dominated architectural thinking. This paradigm relied on the constructs of a layered hierarchy of web services to fulfil a request. The services were specified and implemented via strongly typed interface definitions using XML. Similarly the invocation protocol, SOAP, was a verbose XML implementation.

Microservices have a similar concept of an interface definition but this is specified and implemented using a much simpler data typing language, namely JSON with services invocation via a 'lighter', stateless protocol, denoted Representational State Transfer (ReST).

However, whilst there are technical differences in the way that web services and microservices are specified and invoked, the difference in architectural style goes much deeper that the underlying technologies. Specifically, a microservice architecture has the following characteristics: