A Java middleware for High Performance Computing (HPC) and Internet of Things (IoT)

(1)

A Java middleware for High

Performance Computing (HPC) and

Internet of Things (IoT)

Leonardo de Souza Cimino

Universidade Federal de Ouro Preto

UNIVERSIDADE FEDERAL DE OURO PRETO

Orientador: Joubert de Castro Lima

Disserta¸c˜ao submetida ao Instituto de Ciˆencias

Exatas e Biol´ogicas da Universidade Federal de

Ouro Preto para obten¸c˜ao do t´ıtulo de Mestre

em Ciˆencia da Computa¸c˜ao

(2)

Catalogação: www.sisbin.ufop.br

C490j Cimino, Leonardo de Souza.

A Java middleware for High Performance Computing (HPC) and Internet of Things (IoT) [manuscrito] / Leonardo de Souza Cimino. - 2017.

81f.: il.: color; grafs; tabs.

Orientador: Prof. Dr. Joubert de Castro Lima.

Dissertação (Mestrado) - Universidade Federal de Ouro Preto. Instituto de Ciências Exatas e Biológicas. Departamento de Computação. Programa de Pós-Graduação em Ciência da Computação.

Área de Concentração: Ciência da Computação.

1. Internet . 2. Computação de alto desempenho. 3. Middleware. I. Lima, Joubert de Castro. II. Universidade Federal de Ouro Preto. III. Titulo.

(3)

(4)

A Java middleware for High

Performance Computing (HPC) and

Internet of Things (IoT)

Leonardo de Souza Cimino

Universidade Federal de Ouro Preto

(5)

ii

Um middleware Java para Computa¸c˜

ao de Alta

Performance (HPC) e Internet das Coisas (IoT)

Resumo

(6)

iii

(7)

iv

A Java middleware for High Performance Computing

(HPC) and Internet of Things (IoT)

Abstract

(8)

v

(9)

vi

Declara¸c˜

ao

Esta disserta¸cão é resultado de meu próprio trabalho, exceto onde referência expl´ıcita é feita ao trabalho de outros, e não foi submetida para outra qualifica¸cão nesta nem em outra universidade.

(10)

vii

Agradecimentos

Primeiramente a Deus por mais um objetivo alcan¸cado;

Ao meu pai, minha m˜ae e meu irm˜ao por estarem sempre presentes e me darem for¸cas nos momentos dif´ıceis;

`

A minha namorada por ser meu porto seguro, por todo apoio e compreens˜ao durante esse per´ıodo;

Ao professor Joubert por todo conhecimento transmitido e pela dedica¸c˜ao aplicada a este trabalho;

A toda equipe do laborat´orio HPC por toda ajuda;

(11)

List of Figures

3.1 JCL Services . . . 31

3.2 JCL multi-computer deployment view . . . 31

3.5 Runtime to register an application, requiring code conversions - Java to Android . . . 35

3.6 Runtime to register an application, requiring code conversions - Android to Java . . . 35

3.7 Business logic - Hello World . . . 37

3.8 Distribution logic - Hello World . . . 38

3.9 Distribution logic - Complex Hello World . . . 39

3.10 1 to 16 concurrent UA getSensingDataNow() calls . . . 41

3.11 1 to 250 concurrent UA getSensingDataNow() calls . . . 41

3.12 Logical network partition using JCL-Super-Peer components . . . 42

3.13 JCL-Super-Peer managing different number of JCL-Hosts . . . 43

3.14 Overhead when the number of JCL-Super-Peers increased . . . 43

3.15 Runtime to store sensing data when the number of sensors varied . . . . 45

3.16 Runtime to store sensing data when the interval time varied . . . 45

3.17 Runtime to store sensing data when the number of devices increased . . . 46

(15)

xii LIST OF FIGURES

3.18 JCL-Host CPU usage to publish sensing data periodically from several sensors . . . 48 3.19 JCL-Host CPU usage to publish sensing data according to different intervals 48 3.20 Arduino memory usage to publish sensing data periodically from several

sensors . . . 49 3.21 JCL-Host memory usage to publish sensing data periodically from several

sensors . . . 49 3.22 JCL-Host memory consumption to publish sensing data according to

(16)

List of Tables

2.1 Essential IoT/HPC middleware requirements . . . 8 2.2 Comparison of middleware solutions . . . 23

3.1 Comparison of middleware solutions and the JCL IoT/HPC version . . . 28 3.2 JCL-Host battery and memory consumption with a camera sensor

con-figured . . . 50 3.3 JCL-Host battery consumption to publish sensing data periodically from

3 sensors . . . 51 3.4 JCL-Host battery consumption to publish sensing data according to

dif-ferent intervals . . . 51 3.5 Battery and memory consumption comparison between JCL and Zanzito

with a camera sensor . . . 53

(17)

Chapter 1 Introduction

Big data (Brynjolfsson, 2012), Internet of Things (IoT) (Perera, Liu, Jayawardena, & Chen, 2014) and elastic cloud services (Zhang, Cheng, & Boutaba, 2010) are technolo-gies that provide this new decentralized, dynamic and communication-intensive society. In (El Baz, 2014), it is highlighted the demand of an integration of IoT and High Per-formance Computing (HPC) in near future, since applications like smart buildings and smart logistics are requiring both alternatives. The main challenge when two technolo-gies are integrated is related to heterogeneity, since both alternatives have their own particularities in terms of processing, storage and communication, for instance. The consequence is the increased complexity of the development, deployment, maintenance and management of these applications.

HPC is based on the concurrence principle, so high speedups are achievable, but the development process becomes complex when concurrence is introduced. Therefore, it is practically impossible to build HPC applications without a middleware or frame-work (Al-Jaroodi & Mohamed, 2012a). Middleware are everywhere and most likely will remain everywhere for a long time to help reduce the complexity of application develop-ment (Al-Jaroodi & Mohamed, 2012a). The challenging issue is how to provide sufficient support and general high-level mechanisms using middleware for rapid development of distributed and parallel applications.

On the other hand, IoT represents the third wave in the development of the Internet. The first wave occurred in the 1990 decade, connecting about 1 billion users to the In-ternet through their desktops. The second wave connected 2 billion users to the InIn-ternet with the introduction of mobile devices on the first decade of the 21th century. The third

(18)

2 Introduction

wave, which is the wave we are living, will connect more than 20 billion things to the Internet (Rustad, 2015). Such things can be lamps, sensors, locks, vehicles, wearables and almost any object we can imagine. IoT is one of the pillars of the Industry 4.0, which represents a great transformation on the industry, explaining the global investment of US$_{29 billions in 2015 (Greenough, 2016). As well as HPC applications, IoT ones are}

usually complex and distributed, thus developed over middleware solutions.

Although there are applications that demand an integrated environment between IoT and HPC, there is no middleware alternative that addresses solutions for both technolo-gies requirements. In terms of HPC, the presented middleware solutions did not simplify services for sensing, actuating, and context awareness. In terms of IoT, the presented middleware solutions did not simplify the general-purpose parallel/distributed process-ing and storage services. Some IoT alternatives, like XGSN (Calbimonte, Sarni, Eberle, & Aberer, 2014), mentioned sensing storage in cloud environments and others, like Kaa (KaaIoT Technologies, 2017), mentioned sensing analytics services as HPC issues, but a HPC middleware is by far more complex than that since they offer task scheduling, the instantiation of every-day code variables and data structures over clusters transpar-ently and the execution of general-purpose tasks over massive parallel servers or clusters of commodity PCs and laptops. Programming primitives to develop pipelines, graph processing or mappers and reducers are also common in HPC middlewares to facilitate the development of applications. In summary, nowadays the development of IoT/HPC applications demand the utilization of different middleware solutions, requiring the in-tegration of them from scratch. Besides turning the development more complex, the integration rises problems regarding to deployment, maintenance and management is-sues, as cited before. Thus, it is desirable that the integration is done by a middleware solution transparently, where a single deploy step occurs, a single management process is made and a single API to develop IoT, HPC and IoT/HPC applications are feasible. This way, the main problem stated in this work is:

How to develop integrated IoT/HPC applications using a single middleware?

(19)

Introduction 3

1.1 Goal

The main goal of this work is to present a middleware solution to reduce the gap be-tween two technologies, precisely IoT and HPC, enabling the development of integrated IoT/HPC applications.

1.1.1 Specific Goals

• _{Define a set of requirements that an IoT/HPC middleware solution should attend;} • _{Establish a comparison among a large number of existing IoT, HPC and Cloud of}

Things (CoT) middleware solutions, evaluating them according to the requirements previously specified;

• _{Present and evaluate an integrated middleware solution alternative, named JavaC´a&L´a}

(JCL) 1, to attenuate the existing gap between IoT and HPC. JCL is always eval-uated according to the requirements previously specified;

1.2 Contributions and Results

The main contributions of this work are: i) the definition of a list of requirements that an integrated IoT/HPC middleware solution should attend; ii) a literature review and a comparative analysis of a large number of middleware solutions using the set of re-quirements defined in i; iii) a middleware that supports most of the rere-quirements defined in i, outperforming the state-of-art in this perspective; and iv) a detailed experimental evaluation of JCL in terms of runtime, battery usage and memory consumption to prove that it is a feasible and simple solution to attenuate the integration of IoT and HPC technologies.

1.3 Work organization

The rest of this work is organized as follows: in Chapter 2, we detail the existing integration between IoT and HPC, as well as the set of fundamental requirements that

1

(20)

4 Introduction

(21)

Chapter 2 IoT and HPC integration: revision and

perspectives

2.1 Abstract

In this chapter, we review the main middleware requirements applied to IoT and HPC combined, here called IoT/HPC. The goal is to describe a unified set of requirements that middleware systems should address to support the development of integrated ap-plications. Among many core complex services, the IoT/HPC challenges are related to the support for sensing, actuating, storage and processing services combined in a single middleware solution. We evaluated a set of Java solutions classified separately into IoT, CoT and HPC solutions, and compared them following the same IoT/HPC requirements. The conclusion is that there is still a substantial gap in the integration of both technologies in the middleware literature, but there are user-applications (UAs) that require this integration; thus, a middleware proposal project becomes fundamental for simplifying such a development.

2.2 Introduction

The main idea of IoT (Atzori, Iera, & Morabito, 2010) is to transform the everyday rou-tine and behavior of people when using connected objects, some of which are connected directly to the Internet, enabling their interactions and cooperations to achieve common goals. Recently, Cloud Computing (Zhang et al., 2010) was added to IoT, primarily to

(22)

6 IoT and HPC integration: revision and perspectives

provide analytics and storage services. This integration is called CoT (D´ıaz, Mart´ın, & Rubio, 2016), however, for instance, these works do not detail how sensing and pro-cessing operate together in the same API. Meanwhile, there are decades of development of HPC middleware systems (Al-Jaroodi & Mohamed, 2012a), where it is necessary to specify how to schedule tasks, optimize groups of tasks, store global variables of a code or even their internal data structures. In general, HPC alternatives continue innovating not only in storage services to support Big Data but also in processing services to ad-dress computational problems using efficient techniques, like pipelines, graph processing or mappers and reducers abstractions.

Even with the considerable advances in the development of middleware solutions, where most of them are becoming increasingly simpler to program and deploy, there is still a substantial gap in IoT and HPC integration; thus, it is not possible to expose services such as processing, storage, sensing, security, context awareness and actuating in a unified manner and preferably following the same programming model to make it easier to develop applications. As El Baz (El Baz, 2014) described, there are real UAs that require the integration of IoT and HPC, such as smart houses, smart buildings, smart factories and smart logistics. For instance, the management of a smart building with thousands of sensors in real-time arises problems that need HPC techniques. Another example is the real-time management and routing of a fleet to optimize the delivery schedule.

(23)

IoT and HPC integration: revision and perspectives 7

on data analytics and non-volatile storage; thus, they are also not considered in the comparisons of this work.

Therefore, this chapter goal is to answer the following question:

Is there a minimal set of requirements for IoT/HPC middlewares that out-lines a real integration between these technologies?

To answer this question, initially, we define a list of requirements based on previ-ous HPC, IoT and CoT works, avoiding concept overlapping and then we perform a comparative and detailed analysis based on the previously defined requirements. After discussions, the conclusion is that there is no integrated solution; however, there are indications of how it will work due to the UA demands.

The remainder of this chapter is organized as follows: Section 2.3 presents some fundamental requirements for an IoT/HPC middleware. Section 2.4 discusses whether the state-of-the-art alternatives address solutions for the requirements. Section 2.5 gives the conclusions for this investigation.

2.3 IoT/HPC middleware requirements

This section presents the main requirements that an IoT/HPC middleware solution should attend. Table 2.1 summarizes the requirements from IoT (Bandyopadhyay et al., 2011; Perera, Zaslavsky, et al., 2014; Razzaque et al., 2016), HPC (Engelmann et al., 2007; Diaz, Munoz-Caro, & Nino, 2012; Taboada et al., 2013; Almeida et al., 2016) and the ones they have in common. The sensing analytics services provided by CoT solutions are also part of the requirements.

2.3.1 Security and Privacy

(24)

Table 2.1: Essential IoT/HPC middleware requirements

Requirements HPC IoT

Security and Privacy (SaP) X X

Context Awareness (CA) – X

Different Programming Models (DPM) X X

Distributed Storage (DS) X X

Heterogeneity (H) X X

Simple Deployment (SD) X X

Fault Tolerance (FT) X X

General-purpose Computing (GPC) X _–

Code Refactoring (CR) X _–

Task Scheduler (TS) X _–

Super-peer Support (SP) X _–

Collaborative Development (CD) X X

Performance and Scalability (PaS) X _–

Sensing Analytics (SA) – X

cause low overhead to retain the global performance of the HPC solutions. In IoT/HPC integration, there are massive parallel HPC applications that require on-line sensing and actuating, as well as general-purpose tasks started by IoT contexts; therefore, managing identities and encrypting communications become even more complex, which justifies a middleware solution that supports both. JCL uses the Advanced Encryption Standard (AES) (Daemen & Rijmen, 2002) allowing secure communication. Besides that, it sup-ports enabling or disabling cryptography programmatically through the API making it possible to ensure secure communication only on a certain block of code.

2.3.2 Context Awareness

(25)

how-IoT and HPC integration: revision and perspectives 9

ever, no attention has been given to context awareness in HPC. When a solution is IoT/HPC both contexts and notifications which can occur when certain criteria are met are of crucial importance; therefore, programming models common to HPC need to im-prove their usability. Task-oriented programming models, for instance, can be a good alternative to both create contexts and wait for their occurrences. JCL supports the creation of contexts using regular expressions to trigger the context. It also supports general-purpose HPC tasks executions when contexts are reached.

2.3.3 Different Programming Models

A programing model determines the code core abstractions and thus the code style to build any UA. The event-based model is the most adopted model in IoT. In HPC, mid-dleware systems normally support one of the following models: message-passing (Forum, 1994) based models such as Bulk-Synchronous Parallel (Valiant, 1990), distributed shared memory (DSM) (Protic, Tomasevic, & Milutinovic, 1996) and task-oriented (Shahrivari & Sharifi, 2011) models. Typically, in HPC, there is a main code and a main process orchestrating the other started processes and threads, where the main process is the last to finish. In IoT, there is very often a background process running while applications of publishers and subscribers are added. An IoT/HPC middleware should normally sup-port more than one programming model; however, the idea of an integrated environment for the development of UAs must be kept. JCL supports three programming models: DSM, task-oriented and event-based.

2.3.4 Distributed Storage

(26)

Chansler, 2010) and NoSQL (Han, Haihong, Le, & Du, 2011) based solutions to store sensing data in a distributed way in the cloud. They represent typical non-volatile and transactional services; therefore, they do not mention distributed data structures and how they store ordinary objects. In general, it is fundamental for an IoT/HPC middleware to offer some type of distributed storage not only for sensing but also for general-purpose computing, particularly for Java objects and data structures. JCL has a distributed implementation of the Map interface from JCF, allowing the usage of dis-tributed data structures with minimal code refactoring. It also supports user-typed or native objects stored remotely and transparently using two alternatives: i) local instan-tiation and remote storage; and ii) remote instaninstan-tiation and storage, passing the object constructor arguments to be instantiated remotely. The second alternative avoids large objects being transmitted through the network.

2.3.5 Heterogeneity

(27)

2.3.6 Simple Deployment

The deployment process can be a complex and time-consuming activity in middleware systems. In some cases, any live update of an application module or class often interrupts the execution of all on-line services. Furthermore, the service discovery and manage-ment sometimes are done manually, becoming very expensive. In IoT, it is important to keep the deployment as simple as possible; this way, many approaches enable new sensors to be included or new contexts to be created without restarting the device and the cluster (Calbimonte et al., 2014; KaaIoT Technologies, 2017), as well as they very often implement discovery services. Some IoT middleware solutions (Westlin & Laine, 2014) use third-party frameworks to partition the deployment into modules. In HPC, it is important to register and instantiate the UA objects and dependencies without interrupting the cluster operation. Some middleware systems (ZeroC Inc., 2017) adopt third-party solutions to distribute and update modules in a cluster. Regardless of the application type (IoT, HPC or IoT/HPC), runtime updates without interruptions and service discovery are mandatory. Occasionally, registering services should also be per-formed programmatically in the API. JCL has a auto-discovery mechanism and it also allows the register of classes or modules during runtime without interrupting the cluster. Sensors or actuators or contexts can also be modified without restarts.

2.3.7 Fault Tolerance

(28)

2.3.8 General-purpose Computing

General-purpose computing support indicates that the solution is capable of executing any function or method of a certain class of a programming language, as well as storing an instance or an object of any class, with or without code refactoring. Normally, general-purpose computing is not discussed in IoT; thus, alternatives that support processing and storage services are almost nonexistent in IoT, despite the existing computational resources available (RAM, CPU cores, GPU cores and disk space, for instance) in de-vices like smartphones or single-board computers (Raspberry Pi, Onion, Beaglebone, Cubieboard and others). This requirement is commonly attended in HPC and it must be a part of IoT/HPC solutions without becoming a solution that is basically a bag of drivers and binders to existing IoT and HPC middlewares, which normally increase both development complexity and maintenance cost. JCL supports general-purpose computing, but also IoT features that together with HPC produce a unique middleware solution.

2.3.9 Code Refactoring

(29)

2.3.10 Task Scheduler

HPC applications can be modeled as an SIMD solution; thus, the workload depends on the data partitioning. However, other problems can be modeled as a pipeline solution, where each pipe step can execute a different set of instructions or a method; thus, pipeline steps normally have different workloads in a typical MISD solution. Unfortunately, the load-balancing problem emerges from both SIMD and MISD alternatives, as highlighted by Boneti et al. (Boneti, Gioiosa, Cazorla, & Valero, 2008). To reduce load-balancing problems, we adopt scheduling algorithms. Task scheduling is not discussed in IoT, but in HPC there are many scheduler methods (Y. Jiang, 2016). In IoT/HPC, the concerns with scheduling must be re-designed because the properties considered by HPC are no longer sufficient since location, speed, direction and battery, for instance, are now essential for providing an effective storage/processing scheduling service. JCL uses a two-phase collaborative scheduler to guarantee a fair load balance for HPC tasks. Even non-deterministic tasks, like optimization heuristics, can be efficiently scheduled by JCL, as experiments demonstrated.

2.3.11 Super-peer Support

(30)

2.3.12 Collaborative Development

Cloud computing can handle collaborative development or development as a service in the cloud service stack. HPC solutions (Walker et al., 2006) expose ordinary Java class methods as Web services. In IoT, the idea of collaboration and shared resources is mandatory because we can provide or consume sensing as a service. In summary, an IoT/HPC middleware that provides a multi-developer environment where applications can access methods and objects without explicit references, as well as obtain sensing data or send actuating commands in a collaborative way, are very important. In JCL all sensing data, ordinary variables, data structures and compiled modules are available to every application running in the same JCL cluster or even in a multi-cluster grid environment by using the JCL-Super-Peer component.

2.3.13 Performance and Scalability

(31)

2.3.14 Sensing Analytics

The CoT solutions normally support sensing data analytics, which represents the capac-ity to analyze sensing data. Currently, visualization options, large-scale data support, machine learning support and math libraries are adopted to perform analytics. General-purpose computing enables building analytic services from scratch, but in IoT/HPC integration it is mandatory to have API facilities for this requirement. At the present moment, JCL does not have such API facilities.

2.4 IoT/HPC integration: discussion and perspectives

In this section, several Java solutions are evaluated according to the previously explained requirements. These solutions are separated into IoT, CoT and HPC middlewares.

2.4.1 IoT Middlewares

In terms of security and privacy, SMEPP (Caro et al., 2009) is one of the most promising solutions. SMEPP offers three different security models, including encryption and user authentication. In addition to SMEPP, there are other middleware systems with security and privacy services: X-GSN (Calbimonte et al., 2014), Sofia2 (Smart & Cloud Archi-tectures and Platforms, 2017) and Cayenne (myDevices, 2017) have authentication and access control mechanisms. FamiWare (G´amez & Fuentes, 2011) and VIRTUS (Bazzani, Conzon, Scalera, Spirito, & Trainito, 2012) allow data encryption. Hydra (Sarnovsky, Butka, Kostelnik, & Lackova, 2007) uses XACML (eXtensible Access Control Mark-up Language) (Oasis, 2017) to provide policies for access control.

(32)

scripts can only perform specific actions, such as sending an e-mail, invoking a URL or managing an ontology instance in Sofia2.

Some of the evaluated IoT middleware systems provide easy deployment in different ways. X-GSN and C-MOSDEN have similar strategies using XML files. VIRTUS and SIXTH (O’Hare et al., 2012) use the Open Services Gateway Initiative (OSGi) (OSGi Alliance, 2017) to partition the application into modules that can be installed or removed dynamically. X-GSN and C-MOSDEN are the IoT solutions with the easiest deployment. SIXTH and SMEPP provide fault-tolerance services where anomalies are not propagated to the other services, keeping the correct functioning of the application. However, it was not clearly specified how this is achieved.

Heterogeneity is considered by all IoT middleware but at different levels. Java porta-bility is part of all alternatives; thus, X-GSN, using a semantic approach with the Se-mantic Sensor Network (Compton et al., 2012) ontology, can be considered the most promising solution. In terms of multiple language support, SMEPP is implemented in the Java and nesC programming languages. C-MOSDEN and Cayenne allow sensing data retrieval using RESTful services. Cayenne can be managed using popular browser applications or using iOS and Android applications. It can be executed on different Arduino and Raspberry Pi models. VIRTUS and FamiWare can be executed on many operating systems, such as TinyOS, VxWorks, Symbian, Windows and Linux. Hydra was evaluated in more than 40 different devices and it adopts Web services protocols for this purpose. SIXTH also supports many communication protocols. Sofia2 uses proto-cols such as JSON and a RESTful API. It also has an API for many languages, such as Java, Android, C and Python, among others. Regarding sensing analytics, Cayenne offers a drag-and-drop dashboard that allows the user to filter data or to generate charts. Sofia2 is integrated with Hadoop and has a module that allows the user to apply machine learning algorithms over the sensing data.

(33)

UA development, attempting to avoid common mistakes.

There are also solutions focused on specific IoT protocols, like the MQTT. The Zanz-ito (Gianluca Barbaro, 2017) solution is one promising MQTT publisher for Android that has a very simple deployment process, allowing the publication of sensing data via MQTT brokers in few steps. It supports safe communication through SSL/TLS con-nections, the creation of alarms through text messages and it has a module to remotely manage other Zanzito devices.

The main limitations of IoT solutions in integrating IoT/HPC are as follows: i) few approaches deal with processing and storage services. They limit the processing services to sensing analytics and data aggregation tasks; and ii) the contexts are normally restricted to few options and there are few notification mechanisms to users or other applications. No general-purpose computing tasks can be started when contexts are reached, thereby limiting several development opportunities.

2.4.2 CoT Middlewares

In terms of security and privacy, OpenIoT (Soldatos et al., 2014), Kaa (KaaIoT Tech-nologies, 2017), Xively (LogMeIn, 2017) and Mango (Infinite Automation Systems, 2017) provide authentication, authorization and encryption services, and they are the CoT middleware solutions with more advanced techniques for data safety. SensorCloud (LORD MicroStrain, 2017) and CloudPlugs (CloudPlugs Inc., 2017) only provide encryp-tion services. Kaa (KaaIoT Technologies, 2017) and SensorCloud (LORD MicroStrain, 2017) provide context awareness services that allow notifications via custom alarms, such as sending e-mails or SMSs. ThingSpeak (The MathWorks Inc., 2017) allows actu-ating services, started in remote devices and when contexts are triggered. CloudPlugs (CloudPlugs Inc., 2017) has geo-location based triggers that allow both mobile devices management and e-mail/SMS delivery.

OpenIoT uses X-GSN as one of its modules; therefore, it adopts the same mechanism for simple deployment, being the most promising alternative in this requirement. Mango has a USB utility that can be used to configure various settings; thus, the user only has to edit configuration files and plug them into a device.

(34)

amount of communication protocols. It also implements a RESTful API. SensorCloud has a RESTful API to allow sending data in its infrastructure. Xively, Nimbits (Nimbits Inc., 2017), ThingSpeak and Mango support different communication protocols and data formats. CloudPlugs has various libraries for different platforms and programming languages. All CoT middleware solutions offer different ways for achieving heterogeneity, but Kaa is by far the most advanced alternative and it is hardware-agnostic according to its authors.

In terms of collaborative development, all evaluated CoT middleware support sharing the sensing data, allowing different users or applications to concurrently access the same historical sensing data source. Kaa is fault tolerant with no single point of failure and it also has geographical redundancy. Kaa enables distributed sensing data storage using NoSQL technologies. All other CoT middlewares are able to store sensing data in the cloud, but they did not mention how the sensing data are partitioned and distributed in such elastic environments.

Kaa, SensorCloud and Mango mentioned that they provide scalable IoT services and for this purpose they integrate with different technologies, such as Cassandra (The Apache Software Foundation, 2016) and Hadoop (Shvachko et al., 2010). The same integration strategies apply to the data analytics and storage services, guaranteeing performance by using different technologies, like the Spark (The Apache Software Foun-dation, 2017b) solution.

All evaluated CoT solutions provide sensing analytics services and Kaa is the most advanced CoT solution in this requirement. It uses Spark for large-scale data processing, including machine learning services. ThingSpeak provides sensing analytics with MAT-LAB (The Mathworks Inc., 2017), allowing different chart options, data conversions and many math analysis methods for pattern discovery. SensorCloud has a MathEngine module that allows users to deploy Python and Octave applications to analyze sensing data. Xively integrates with Amazon Kinesis (Amazon Web Services, 2017) and Nimbits uses Google Analytics Management (Google, 2017). OpenIoT, CloudPlugs and Mango have iterative dashboards, but it was not clearly specified which tools are used to analyze the sensing data.

(35)

are not detailed. Collaborative development is limited to sharing sensing data accesses, e.g., it is not possible to share variables, class methods or data structures to simulate a DSM address space. Moreover, different programming models are not provided to the user in an integrated manner. In general, processing and storage services do not operate concomitantly with sensing, actuating and context awareness services. Kaa is one of the most robust solutions; however, its idea of distributed processing and storage is based on Hadoop technology only, and thus code refactoring is mandatory, as well as other limitations (Wang et al., 2015).

2.4.3 HPC Middlewares

Middleware solutions such as JPPF (Cohen, 2017), RAFDA (Walker et al., 2006), Jes-sica (Zhu, Wang, & Lau, 2002), Infinispan (RedHat, 2017b), Hazelcast (Hazelcast Inc., 2017), Gridgain (GridGain Systems, Inc, 2017) and Apache Ignite (The Apache Software Foundation, 2017a) have low or minimal code refactoring to provide distribution issues. Safety is achieved by Hazelcast, JPPF, Oracle Coherence (Oracle Corporation, 2017), RAFDA, PJ (Kaminsky, 2007), ProActive (Baduel, Baude, & Caromel, 2005) and ICE (ZeroC Inc., 2017) via encrypted communication. Infinispan and Gridgain have authen-tication and auditing services, and they are the most advanced middleware in terms of this requirement. In terms of heterogeneity, PJ can be executed on devices with JDK support. Apache Ignite, Gridgain, JPPF, Hazelcast, Oracle Coherence and ICE have support for many programming languages. Infinispan supports numerous communica-tion protocols. JPPF is able to run over small mobile devices, like phones and tablets using Android.

Infinispan, Hazelcast and Oracle Coherence have storage fault tolerance. ICE, Apache Ignite, Open MPI (Graham et al., 2006), P2P-MPI (Genaud & Rattanapoka, 2007), Gridgain and ProActive have processing fault tolerance. JPPF implements both, being the most advanced solution for this requirement. None of the HPC alternatives address solutions for Byzantine faults.

(36)

Ignite the most promising solutions since they implement service discovery facilities. Distributed implementations of JCF data structures are offered by Hazelcast, Infin-ispan, Apache Ignite and Gridgain. Oracle Coherence has a Partition Backing Map, which is a Map-like structure, but it is incompatible with JCF code. Infinispan, Hazel-cast, Oracle Coherence, RAFDA, Apache Ignite and Gridgain provide a multi-developer environment where applications can access methods and user-typed objects from each other without explicit references. RAFDA and Gridgain support super-peers; thus, they can be considered the most promising middleware solutions in terms of the collaborative development requirement.

Most of the evaluated middlewares offer different mechanisms and integrations with different technologies to provide performance and scalability; however, few solutions de-tail how they guarantee performance. PJ implements several high-level programming abstractions, such as ParallelRegion (code to be executed in parallel), ParallelTeam (group of threads that execute a ParallelRegion) and ParallelForLoop (work paralleliza-tion among threads). Hazelcast and Oracle Coherence allow the execuparalleliza-tion of a task in a specific device of the cluster or a task to handle multiple method invocations.

We also evaluated a previous version of JCL presented at (Almeida et al., 2016) without the improvements done in this work. The existing JCL version has low code refactoring, separating distribution issues from business logic ones, what can simplify the development process. In terms of heterogeneity, it can be executed on devices with support to JDK, including small devices, such as Raspberry Pi. It has a two phase col-laborative scheduler to provide fair load balancing for HPC tasks. The HPC version has a simple deployment process, but without introducing service discovery facilities, and it has a distributed implementation of JCF Map interface. All the variables instantiated and classes registered on JCL are available for every application deployed in the same cluster without explicit references. Finally, JCL HPC also supports the Super-peer con-cept, enabling multi-cluster grid environments, as well as the interconnection of devices with invalid IPs.

(37)

in this section, which reaffirms the existing gap between IoT and HPC technologies.

2.4.4 Perspectives

Table 2.2 presents a comparison of the IoT, CoT and HPC middleware solutions using the same set of requirements. Solutions that have improved versions, changing their names, such as GSN and X-GSN, are omitted. Table 2.2 has two new requirements that were not previously explained because they are simple: i) if the solution is active and ii) if it is free of charge. Each requirement can be solved or attenuated, therefore we consider three different levels to attend a requirement (X_, XX_{, and} XXX_{), where} X_{indicates basic implementations,} XX_{indicates fundamental ones, and} XXX_indicates

advanced designs. The ’–’ wildcard indicates that no information was found about the ability of the middleware in attending the requirement.

Some IoT applications with HPC needs are common in businesses related to smart buildings, factories and logistics; therefore, their demands are explained in some studies (El Baz, 2014; Botta, De Donato, Persico, & Pescap´e, 2016), but the existing IoT/-CoT/HPC middleware solutions did not combine sensing, context awareness, actuating, processing and storage services in a unique solution. Thus, it is currently impossible to develop a single code demanding all services. HPC simulators, particularly spatial-temporal, WSN, game and robotic ones, should provide context, sensing and actuating services in their models, and some of them will require real sensing and actuating ser-vices operating with virtual ones. As a main code normally exists in HPC solutions, the event-based programming model is not suitable, even though it is common in IoT and CoT. Therefore, redesigns should occur in the integrated solutions, probably with support for more than one programming model.

(38)

2.5 Conclusion

(39)

Io T a nd H P C in te g r a ti o n: r e v is io n a nd p e r sp e ct iv e s 2 3

Table 2.2: Comparison of middleware solutions

Solution Type SaP CA DPM DS H SA SD FT GPC CR TS SP CD PaS Active Free

X-GSN (Calbimonte et al., 2014) IoT XX X – – XX – XX – – – – – – – Yes Yes

C-MOSDEN (Perera et al., 2015) IoT – XXX _– _– X _– XX _– _– _– _– _– _– _– _Yes _Yes

FamiWare (G´amez & Fuentes, 2011) IoT X X – – X – – XX – – – – – – – –

SMEPP (Caro et al., 2009) IoT XXX X _– _– X _– _– _– _– _– _– _– _– _– _No _–

SIXTH (O’Hare et al., 2012) IoT – – – – X – X X – – – – – – – –

Hydra (LinkSmart) (Sarnovsky et al., 2007) IoT XX XX _– _– XX _– _– _– _– _– _– _– _– _– _Yes _Yes

VIRTUS (Bazzani et al., 2012) IoT X – – – XX – XX – – – – – – – – –

Sofia2 (Smart & Cloud Architectures and Platforms, 2017) IoT XX XX _– XXX XX XX _– _– _– _– _– _– _– XXX _Yes _Yes

Cayenne (myDevices, 2017) IoT XX XX _– _– XX XX _– _– _– _– _– _– _– _– _Yes _Yes

OpenIoT (Soldatos et al., 2014) CoT XX X – – XX XX XX – – – – – X – Yes Yes

Kaa (KaaIoT Technologies, 2017) CoT XX X _– XXX XXX XXX _– X _– _– _– _– X XXX _Yes _Yes

SensorCloud (LORD MicroStrain, 2017) CoT X X – – XX XX – – – – – – X XXX Yes No

Xively (LogMeIn, 2017) CoT XX _– _– _– XX XX _– _– _– _– _– _– X _– _Yes _No

CloudPlugs (CloudPlugs Inc., 2017) CoT X X – – XX XX X – - – – – X – Yes No

Nimbits (Nimbits Inc., 2017) CoT – – – – X XX _– _– _- _– _– _– X _– _Yes _Yes

ThingSpeak (The MathWorks Inc., 2017) CoT – X – – X XX – – - – – – X – Yes No

Mango (Infinite Automation Systems, 2017) CoT X _– _– _– X XX X _– _- _– _– _– X XXX _Yes _No

JCL (Almeida et al., 2016) HPC – – – XXX X – XX – XXX XXX XXX XXX XXX XXX Yes Yes

Infinispan (RedHat, 2017b) HPC XX _– _– XXX XX _– _– XX XXX XX _– _– XX XXX _Yes _Yes

JPPF (Cohen, 2017) HPC X – – – XX – XXX XXX XXX XXX XXX XXX – XXX Yes Yes

Hazelcast (Hazelcast Inc., 2017) HPC X _– _– XXX XX _– _– XX XXX XX _– _– XX XXX _Yes _Yes

Oracle Coherence (Oracle Corporation, 2017) HPC X – – XXX XX – XX XX XXX – – – XX XXX Yes No

RAFDA (Walker et al., 2006) HPC X _– _– _– XX _– XX _– XXX XXX _– XXX XXX _– _– _–

PJ (Kaminsky, 2007) HPC X – – – XX – XX – XXX – – – – XXX Yes Yes

ProActive (Baduel et al., 2005) HPC X _– _– _– XX _– _– XX XXX _– _– _– _– XXX _Yes _Yes

Apache Ignite (The Apache Software Foundation, 2017a) HPC – – – XXX XX – XXX XX XXX XX – – XX XXX Yes Yes

Gridgain (GridGain Systems, Inc, 2017) HPC XX _– _– XXX XX _– _– XX XXX XX XXX XXX XXX XXX _Yes _No

ICE (ZeroC Inc., 2017) HPC X – – – XX – – XX XXX – – – – XXX Yes Yes

Jessica (Zhu et al., 2002) HPC – – – – – – XX _– XXX XXX _– _– _– XXX _No _Yes

Open MPI (Graham et al., 2006) HPC – – – – X – – XX XXX – – – – XXX Yes Yes

P2P-MPI (Genaud & Rattanapoka, 2007) HPC – – – – X _– _– XX XXX _– _– _– _– XXX _No _Yes

MPJava (Pugh & Spacco, 2003) HPC – – – – X – – – XXX – – – – XXX – Yes

MPJ Express (Baker, Carpenter, & Shafi, 2006) HPC – – – – X _– _– _– XXX _– _– _– _– XXX _No _Yes

F-MPJ (Taboada, Touri˜no, & Doallo, 2012) HPC – – – – X _– _– _– XXX _– _– _– _– XXX _Yes _Yes

Java RMI (Pitt & McNiff, 2001) HPC – – – – X – – – XXX – – – – – Yes Yes

FlexRMI (Taveira, de Oliveira Valente, da Silva Bigonha, & da Silva Bigonha, 2003) HPC – – – – X _– _– _– XXX _– _– _– _– _– _– _–

KaRMI (Philippsen, Haumacher, & Nester, 2000) HPC – – – – X – – – XXX – – – – – – Yes

(40)

Chapter 3 A middleware solution for integrating

and exploring IoT and HPC capabilities

3.1 Abstract

Existing middleware in IoT do not detail how they implement distributed processing and storage, and HPC solutions do not detail how they provide sensing, actuating and context awareness. Due to this gap, in this chapter we present an extension of JCL, used to help the implementation of sensing, actuating, processing, storage, context awareness and security services in distributed UAs classified as IoT/HPC. To allow this ubiquity, JCL incorporates the following characteristics: i. a single API to program different de-vice categories, specifically HPC, high-end (PCs and laptops), low-end (smart-phones and tablets), sink node (Raspberry Pi, and Galileo, for instance), and sensor node de-vices (Arduino); ii. support for different programming models, specifically event-based, Distributed Shared Memory (DSM) and task-oriented models; iii. support for Java and Android applications interoperability; iv. integration with MQTT technology; and v. se-curity, context awareness and actions services introduced programmatically via JCL API. The experimental evaluations demonstrated that JCL scales when doing the IoT/HPC services, which implies that it can manage smart buildings or HPC clusters with few components. Its super-peers introduced small overheads, interconnecting peers of dis-tinct networks, including those with invalid IP addresses. Java-Android and vice-versa code conversion overheads are sometimes high; therefore, customized JCL deployments become an alternative. These results make the JCL a feasible middleware alternative to implement integrated UAs.

(41)

A middleware solution for integrating and exploring IoT and HPC

capabilities 25

3.2 Introduction

Big data (Brynjolfsson, 2012), IoT (Perera, Liu, et al., 2014) and elastic cloud ser-vices (Zhang et al., 2010) are technologies that provide this new decentralized, dynamic and communication-intensive society. In (El Baz, 2014), it is highlighted the demand of an integration of IoT and HPC in the near future, since applications like smart buildings and smart logistics are requiring both alternatives in a single middleware solution. The integration imposes new challenges related with heterogeneity since both technologies must communicate and operate together. Other challenges related with fundamental IoT and HPC requirements, like deployment, code refactoring, performance, schedul-ing, fault tolerance and many more are also important and hard to be solved when an integration is mandatory.

Middleware are everywhere and most likely will remain everywhere for a long time to help reduce the complexity of application development (Al-Jaroodi & Mohamed, 2012b). The challenging issue is how to provide sufficient support and general high-level mechanisms using middleware for rapid development of distributed and parallel applications.

In general, existing IoT middleware do not detail how they implement distributed processing and storage, and HPC solutions do not detail how they provide sensing, actuating and context awareness, for instance. Some IoT solutions, like (Calbimonte et al., 2014), mentioned their distributed sensing storage in cloud, but the HPC general-purpose computing storage is not only sensing storage. It is, for instance, the support of global variables or data structures of every-day code distributed over clusters. HPC processing is, for instance, the scheduling and the invocation of methods asynchronously and transparently. None of the middleware alternatives used to develop our solution put these services together in a single Application Programming Interface (API).

The main problem stated in this chapter is:

How to combine IoT capabilities, e.g., sensing, actuating, security, sensing data storage and context awareness services, with HPC ones, e.g., distributed general-purpose storage and processing, in a single middleware solution ca-pable of running over multiple clusters, some of which have invalid IP ad-dresses?

(42)

26

A middleware solution for integrating and exploring IoT and HPC capabilities

called Java Ca&La or just JCL 1 with an API capable of programming different device categories and supporting three programming models.

The device categories supported by JCL were defined in Perera et al. (Perera, Ja-yaraman, et al., 2014): i. High performance computing (HPC) devices, e.g., huge servers and workstations and cloud computing solutions; ii. High-end devices, composed of PCs and laptops; iii. Low-end computational devices, where smart-phones and tablets are included; iv. Sink node devices, i.e., devices with low or medium processing power and storage capacity, like Raspberry Pi, Cubieboard, and Onion single-board computers; v. Sensor node devices, i.e., devices with low processing power and storage capacity, like Arduino and PIC microcontrolled boards. Categories i. and ii. were available and eval-uated in the first JCL contribution (Almeida et al., 2016). Therefore, in the current chapter we improve JCL HPC version by integrating the other three categories, allow-ing the implementation of IoT/HPC applications. Additionally, Perera et al. (Perera, Jayaraman, et al., 2014) define the miniaturized devices category, not considered here, composed of ultra-low processing and storage capabilities devices.

The JCL supports three programming models to control devices and sensors that can be combined to produce very interesting applications. The first one is the event-based programming model, following the publish-subscribe pattern (Eugster, Felber, Guerraoui, & Kermarrec, 2003). Normally, external events, named contexts, start tasks, like sensing or actuating tasks, but also any general-purpose HPC tasks, so this pro-gramming model is the basis of the well-known sensing as a service (X. Sheng, Tang, Xiao, & Xue, 2013), where IoT applications are called publishers and subscribers of common brokers. The second one is based on a distributed and shared memory address space (DSM) (Protic et al., 1996), where global variables and distributed Java maps are stored over clusters, enabling JCL tasks concurrent and thread-safe accesses; The last one is the task-oriented programming model (Shahrivari & Sharifi, 2011), where ordinary Java classes members are invoked asynchronously and remotely, but also where context awareness, sensing, actuating and security services are supported, since they are modeled as tasks. Thus, JCL is the unique middleware solution modeling IoT services as ordinary HPC tasks started from a main code. The benefits include active sensing or actuating, and also a strategy to wait for contexts without requiring third-party IoT brokers. Precisely, a Future Java object to wait for asynchronous computations is suf-ficient to wait for contexts to be reached, therefore very familiar for multi-thread Java development.

1

(43)

capabilities 27

Based on these capabilities, JCL applications can be implemented in Android or Java, running over clusters of things composed of Java, Android and Arduino devices, including clusters with invalid IP addresses since in JCL these clusters are interconnected by super-peers (Lua, Crowcroft, Pias, Sharma, & Lim, 2005; Androutsellis-Theotokis & Spinellis, 2004). Additionally, the UAs can add actions to be started when a context is reached. In this case, an action can be a sensing, an actuator control or even a general-purpose computing task using, for instance, the JCL API for HPC. Finally, JCL integrates with MQTT brokers to publish sensing data on them, but also to consume data from them.

Previous JCL (Almeida et al., 2016) work described how to put three decades of HPC requirements in a single API using task-oriented together with DSM programming models. We evaluated the JCL capability to execute a task, i.e., to invoke any Java class method, with different numbers and types of arguments. Task scheduling strat-egy impacts, the map distributed data structure API access costs and the throughput for instantiating Java objects as global variables over a cluster were also evaluated in (Almeida et al., 2016). In this work, we complement the HPC evaluations by adding the IoT ones. Precisely, the sensing services and the presence of JCL-Super-Peer compo-nents were evaluated. Additionally, we discussed the results of JCL Android-Java and Java-Android code conversion costs.

The rest of the chapter is organized as follows: Section 3.3 revisits the main re-lated work presented in Chapter 2, introducing the new JCL IoT/HPC version and discussing the improvements and drawbacks of these solutions to attend several IoT and HPC requirements; Section 3.4 details JCL architecture and how it implements IoT and HPC fundamental requirements, including some experimental evaluations; and finally in Section 3.5 the chapter is concluded.

3.3 Related Work

(44)

2 8 A m iddl e w a r e so lut io n fo r in te g r a ti ng a nd e x pl o r ing Io T a nd H P C ca pa bi li ti e s

Table 3.1: Comparison of middleware solutions and the JCL IoT/HPC version

Solution Type SaP CA DPM DS H SA SD FT GPC LR TS SP CD PaS Active Free

JCL IoT-HPC XX XX XXX XXX X _– XX _– XXX XXX XXX XXX XXX XXX _Yes _Yes

X-GSN (Calbimonte et al., 2014) IoT XX X _– _– XX _– XX _– _– _– _– _– _– _– _Yes _Yes

C-MOSDEN (Perera et al., 2015) IoT – XXX _– _– X _– XX _– _– _– _– _– _– _– _Yes _Yes

FamiWare (G´amez & Fuentes, 2011) IoT X X _– _– X _– _– XX _– _– _– _– _– _– _– _–

SMEPP (Caro et al., 2009) IoT XXX X – – X – – – – – – – – – No –

SIXTH (O’Hare et al., 2012) IoT – – – – X – X X – – – – – – – –

Hydra (LinkSmart) (Sarnovsky et al., 2007) IoT XX XX – – XX – – – – – – – – – Yes Yes

VIRTUS (Bazzani et al., 2012) IoT X – – – XX – XX – – – – – – – – –

Sofia2 (Smart & Cloud Architectures and Platforms, 2017) IoT XX XX – XXX XX XX – – – – – – – XXX Yes Yes

Cayenne (myDevices, 2017) IoT XX XX – – XX XX – – – – – – – – Yes Yes

OpenIoT (Soldatos et al., 2014) CoT XX X – – XX XX XX – – – – – X – Yes Yes

Kaa (KaaIoT Technologies, 2017) CoT XX X _– XXX XXX XXX _– X _– _– _– _– X XXX _Yes _Yes

SensorCloud (LORD MicroStrain, 2017) CoT X X _– _– XX XX _– _– _– _– _– _– X XXX _Yes _No

Xively (LogMeIn, 2017) CoT XX _– _– _– XX XX _– _– _– _– _– _– X _– _Yes _No

CloudPlugs (CloudPlugs Inc., 2017) CoT X X _– _– XX XX X _– _- _– _– _– X _– _Yes _No

Nimbits (Nimbits Inc., 2017) CoT – – – – X XX _– _– _- _– _– _– X _– _Yes _Yes

ThingSpeak (The MathWorks Inc., 2017) CoT – X – – X XX – – - – – – X – Yes No

Mango (Infinite Automation Systems, 2017) CoT X – – – X XX X – - – – – X XXX Yes No

Infinispan (RedHat, 2017b) HPC XX – – XXX XX – – XX XXX XX – – XX XXX Yes Yes

JPPF (Cohen, 2017) HPC X – – – XX – XXX XXX XXX XXX XXX XXX – XXX Yes Yes

Hazelcast (Hazelcast Inc., 2017) HPC X – – XXX XX – – XX XXX XX – – XX XXX Yes Yes

Oracle Coherence (Oracle Corporation, 2017) HPC X – – XXX XX – XX XX XXX – – – XX XXX Yes No

Apache Ignite (The Apache Software Foundation, 2017a) HPC – – – XXX XX _– XXX XX XXX XX _– _– XX XXX _Yes _Yes

(45)

capabilities 29

A major review and a detailed discussion of the solutions were made in Chapter 2, but we can observe that IoT solutions in general do not address solutions to various HPC requirements. The main limitations of them in integrating IoT/HPC are as follows: i) few approaches deal with processing and storage services, where processing is normally only sensing analytics and data aggregation services, thus no general-purpose computing capabilities are supported; and ii) the contexts are normally restricted to few options, and there are few notification mechanisms for users or UAs. HPC solutions normally implement various requirements, but they still do not integrate with IoT. The main lim-itations of them in integrating IoT/HPC are as follows: i) none of the HPC middlewares provide context awareness, sensing or actuating services; ii) various solutions are not designed to run over small platforms like Android and Arduino; and iii) few alternatives support super-peers. As presented in Table 3.1, no other middleware solution puts most of the requirement implementations together as JCL IoT/HPC version does. In the next section, we explain how JCL implements most of the requirements illustrated in Table 3.1 and the experimental evaluations results obtained.

3.4 JCL middleware proposal

(46)

30

presented in Table 3.1.

Some requirements, like super-peer support, performance and scalability, required experimental evaluations, thus the cluster used to conduct these experiments is composed of the following devices:

• _{Intel Galileo Gen 2, processor Intel}®_QuarkTM_{400MHz, 256MB RAM, Yocto Poky}

OS equipped with a 8GB SD-card;

• _{Raspberry Pi 2 Model B, processor BCM2837 Arm7 Quad Core 900MHz, 1GB of}

RAM, Raspbian Jessie OS equipped with a 8GB SD-card;

• _{Beaglebone Black Rev B, processor Sitara}TM _{AM3358 1GHz, 512MB of RAM,}

Debian Jessie OS, equipped with a 8GB SD-Card;

• _{Smartphone Lenovo Vibe K5 Plus, processor Snapdragon}TM _{616 (Quad core 1.5}

GHz + Quad-core 1.0 GHz), 2GB of RAM, Android 6;

• _{Smartphone Moto X, processor Snapdragon}TM _{801 (Quad core 2.5GHz), 2GB of}

RAM, Android 6;

• _{Smartphone Moto Z Play, Snapdragon}TM _{625 (Octa core 2GHz), 3GB RAM,}

An-droid 7;

• _{Arduino Mega, micro-controller ATmega1280, clock 16MHz, 128KB of Flash}

mem-ory, 8KB SRAM equipped with Ethernet Shield W5100; and

• _{Notebook Dell Inspiron 3421, processor Intel Core}TM_{i3, 4GB of RAM, OS Ubuntu}

16.04.

3.4.1 Simple Deployment

The deployment process is a time consuming activity in most of the middleware systems. In some cases, its necessarily to reboot the system to make the deployment of a new application, so to reduce the time consuming, JCL adopts a simple deployment process based on Java reflective capability.

(47)

capabilities 31

Figure 3.1: JCL Services

Step 1

Switch

JCL Server

Switch

JCL Server

JCL Host JCL Host ...

(A)

(B)

Switch

Step 1

Step 2

Figure 3.2: JCL multi-computer deployment view

component must be deployment after the JCL-Server in order to guarantee correct reg-istrations, i.e., registrations in the same deployed JCL-Server network. JCL supports one or many JCL-Hosts per cluster (Figure 3.2-B).

(48)

32

Switch

JCL Server

JCL Host JCL Host_...

...

Router Router

JCL Host JCL Host

...

JCL Super Peer

...

JCL Super Peer

Step 1

S

te

p

2

Step 3

...

Step 4

...

JCL Super Peer

...

(49)

capabilities 33

In Figure 3.4, several JCL-User components are deployed on different machine types, precisely desktop and laptop ones, but JCL also supports Android tablets or smart-phones. We assume each machine with a different UA.

Switch

JCL Server

JCL Host JCL Host

...

Step 5 ...

JCL User Existing Code

Step 1

Step 2

Following these deployment steps, multiple JCL-Users can run UAs, sharing JCL abstractions (registered modules, maps and global variables) without reboots of the cluster. If it is necessary to update a previously registered module of an UA, JCL only requires a new registration API call to perform all new deploys in the cluster, so even in live update scenarios the middleware does not stop its execution. To avoid register modules in the entire cluster all the time, there is a selective registration approach where only JCL-Hosts that will execute an UA register it before their first executions.

3.4.2 Security and Privacy

JCL introduces security in API; therefore, the communications done to provide a service in JCL API occur safely in UA when it calls the setEncryption() method before any API call. The method is used to synchronously apply/suppress security policies of JCL, representing service 14 of JCL API illustrated in Figure 3.1.

(50)

34

1998) to assert all blocks with exactly the same number of bytes. In general, JCL encrypted messages are 48 bytes longer than insecure ones.

JCL is the only middleware solution that allows enabling/disabling data encryption through API, i.e., during the execution of a certain block of code. IoT is huge in many aspects (Perera, Jayaraman, et al., 2014), so security at the API level can be very useful for Intranet HPC clusters together with sensing things in the Internet, therefore imposing security restrictions. JCL can also apply security polices when the JCL-Host starts, so it works also without explicit API calls, similar to several solutions in the literature (Bazzani et al., 2012; O’Hare et al., 2012; Aberer, Hauswirth, & Salehi, 2006).

3.4.3 Heterogeneity

JCL-Host is implemented for different platforms such as Linux compatible boards, An-droid and Arduino. This way, JCL runs over three huge community platforms: Java, Android and Arduino. The JCL-Host for Linux boards uses MRAA library (Intel IoT DevKit, 2017) to access the pins of the board to guarantee portability and interoper-ability since MRAA can be executed on many boards and it enables transparent sensor or actuator accesses regardless their communication particularities. Besides using TCP communication to provide all IoT/HPC services and UDP for discovery and other inter-nal control services, JCL is integrated with MQTT protocol, enabling exterinter-nal entities to subscribe to sensing data provided by JCL-Hosts or a new scenario where JCL-Hosts subscribe to sensing data from external entities.

There are JCL-User components for Java and Android, enabling the development of both types of IoT/HPC applications and their integration in a single cluster trans-parently. In summary, the JCL-Host component can convert .class files into .dex files and vice-versa using Android SDK DX Tool (Google, 2017) and reverse engineering (Pan, 2017), respectively. We evaluated the cost of this conversion in both scenarios: i) when UA registered an Android compiled module in a Java JCL-Host; and ii) when UA registered a Java compiled module in an Android JCL-Host.

To do this experimental evaluation we registered 3 different UAs with different sizes to observe the impact of the application size on the conversion. The UAs used in this experiment were a Big Sorting application (10KB), a Dijkstra solver application (500KB) and an e-mail sender application (1MB).

(51)

A middleware solution for integrating and exploring IoT and HPC capabilities 35 0 2000 4000 6000 8000 10000 12000 14000 16000 18000

Sorting Dijkstra Mail

R u n ti m e ( m s ) Lenovo Moto X Moto Z

Figure 3.5: Runtime to register an application, requiring code conver-sions - Java to Android

0 20000 40000 60000 80000 100000 120000

Sorting Dijkstra Mail

R u n ti m e ( m s ) Beaglebone Galileo Notebook Raspberry

Figure 3.6: Runtime to register an application, requiring code conver-sions - Android to Java

Figure 3.5 illustrates the runtime values to convert .class files into .dex files. In general, the runtime deteriorates 2 times when Dijkstra is registered and near 10 times when Mail is registered, but the Mail application is twice the size of Dijkstra, so the conversion overheads is not proportional to the application size. The Moto Z phone increased its runtime only 3 times when the same applications are registered, what means that code conversion is feasible only in devices with more computational resources. The standard deviation values were less than 10% in the worst cases.

(52)

36

3.4.4 Context Awareness

IoT context awareness services are represented by services 12 and 13 in Figure 3.1. Three methods are necessary to provide context awareness: i. the registerContext() method to synchronously register a context in a device, so it is necessary to have the device, the sensor, an expression and a nickname for the context. The expression in JCL is defined per sensing value; e.g., a GPS sensor produces two double values after sensing, one for latitude and one for longitude, so users can easily define expressions like s₀ > lat; s₁ < lgt, where s₀ and s₁ represent the two GPS sensing data and ‘lat’

and ‘lgt’ represent users limits for an area. The registerContext() method guarantees that the sensing data are being stored during the period the context continues to be true; ii. the addContexAction() method to asynchronously add an action to a context, where an action means a sensing task, an actuating task or any HPC general-purpose task. To add an action, users must inform the context previously defined, a sensor to be accessed after a context is reached and the commands to operate such a sensor. There is a second type of action, where a class, its method, and arguments must be informed, enabling asynchronous task executions when contexts are reached. A Future object is returned when actions are configured, enabling local computations, JCL calls or any other business logic in UA before waiting for a context to occur. When a context is reached an action runs and only when a context is reached again it runs a second time and so on; and iii. the get() method to synchronize the UA to get the result of an asynchronous action. Note that, the UA waits until a context is reached, so it represents a JCL alternative to develop a publisher and a subscriber in the same Java class with few portable API calls. The Future object has a get(long timeout) method variant, so UA can wait a predefined time for a context, perform other commands/computations and repeat these steps many times while the context is unreached.

A Java middleware for High Performance Computing (HPC) and Internet of Things (IoT)

A Java middleware for High

Performance Computing (HPC) and

Internet of Things (IoT)

Leonardo de Souza Cimino

Universidade Federal de Ouro Preto

A Java middleware for High

Performance Computing (HPC) and

Internet of Things (IoT)

Leonardo de Souza Cimino

Universidade Federal de Ouro Preto

Um middleware Java para Computa¸c˜

ao de Alta

Performance (HPC) e Internet das Coisas (IoT)

Resumo

A Java middleware for High Performance Computing

(HPC) and Internet of Things (IoT)

Abstract

Declara¸c˜

ao

Agradecimentos

Contents

List of Figures

List of Tables

Chapter 1

Introduction

1.1

Goal

1.1.1

Specific Goals

1.2

Contributions and Results

1.3

Work organization

Chapter 2

IoT and HPC integration: revision and

perspectives

2.1

Abstract

2.2

Introduction

2.3

IoT/HPC middleware requirements

2.3.1

Security and Privacy

2.3.2

Context Awareness

2.3.3

Different Programming Models

2.3.4

Distributed Storage

2.3.5

Heterogeneity

2.3.6

Simple Deployment

2.3.7

Fault Tolerance

2.3.8

General-purpose Computing

2.3.9

Code Refactoring

2.3.10

Task Scheduler

2.3.11

Super-peer Support

2.3.12

Collaborative Development

2.3.13

Performance and Scalability

2.3.14

Sensing Analytics

2.4

IoT/HPC integration: discussion and perspectives

2.4.1

IoT Middlewares

2.4.2

CoT Middlewares

2.4.3

HPC Middlewares

2.4.4