Design and Implementation of Decoupled IoT Application Store: A Novel Prototype for Virtual Objects Sharing and Discovery

Abstract

The internet of things (IoT) has been growing towards the conception of a cyber-physical space in which physical things could be discovered, examined, activated, interlinked, and updated, for the realization of possible interactions in both virtual and physical space. The fundamental idea of IoT is the concept of a virtual object, which is regarded as the digital equivalent of a physical entity. Currently, in every IoT platform, the use of virtual objects has become a vital component. These virtual objects form building blocks of IoT applications, support the discovery of services, nurture the production of complex applications, foster the objects’ energy and power management efficiency, as well as address heterogeneity and scalability issues. Idea sharing and reusing are widesplread, and different solutions are built for this purpose to share applications or their components with similar domains to avoid duplication of efforts. In this paper, we design and implement a cloud-centric IoT application store that serves a purpose for hosting virtual objects of different IoT domains so that technology tinkerers can consume them and integrate them to build IoT applications. The proposed system is different than existing IoT marketplaces in the sense that they provide full-fledged IoT applications which include software and hardware that users can plug and play. The application store is aimed to be decoupled and can expose virtual objects of different IoT domains so that similar areas can use them with little or no modification. Moreover, it is also aimed to be modular, scalable, secure and support heterogeneity, which are considered vital attributes of IoT applications. An IoT testbed client application is developed to reuse some of the virtual objects from the proposed application store and to share specialized virtual objects to the proposed system for the use of other clients applications with similar goals. The performance and load of the platform are tested and found to be within an acceptable response time for up to 40 simultaneous users.

1. Introduction

The internet of things acronym as IoT is a revolutionary paradigm, shaping the development of technologies in the information and communication technology (ICT) arena [1,2,3]. The basic idea of this paradigm is the pervasive presence around us of a variety of things or objects such as sensors, actuator, RFID tags, and mobile phones. This massive number of heterogeneous and pervasive objects with different computing and connecting capabilities are integrated under a common umbrella term known as the IoT. The principal goal of IoT is to provide services to the users through the Internet, but with vital information and services linked strictly to the real world that has been provided through the physical objects [4]. IoT applications are typically composed of physical objects with limited capabilities that communicate using a variety of communication protocols. For this, the concept of a virtual object is introduced. A virtual object is the digital counterpart of the physical object, aims to provide technological solutions that augment the capabilities of the physical devices with additional functionalities, and allows all of them to talk to each other at the same level to make the realization of robust applications easier [4,5,6].

Virtual objects are considered as a central component of the recent IoT platforms. An IoT application is built by combining different virtual objects to form a service that can be consumed by end users. The latest advances in cyber-physical systems are redefining our way of life and have paved a way to encourage the idea of virtual objects and demand the representation of physical space into cyberspace where every physical thing can be interconnected and controlled through cyber world [7,8,9,10]. Technologies like Quick Response (QR) codes and RFID are already making way for digital representation of physical objects.

Historically, there has always been a group of the community who, despite their limited technical knowledge, tinker with the technology components and integrate them to make a product. These people are referred to as The Makers [11,12]. The major drivers for these groups are creativity and a sense of accomplishment. Many of the maker IoT projects are in fact complex systems integrating commercial IoT products as well as their hardware and software into complete systems. These makers are believed to be the real user-innovators in IoT, leading innovation in the form of new products and prototypes but at the same time encountering integration hurdles ahead of the rest of the users and developers [13]. A prevailing paradigm for facilitating makers is do-it-yourself (DIY) approach [14,15,16]. In the DIY paradigm, the principal focus is to provide visual code components and entities that can be dragged and dropped to form an IoT service. Some distinguished platforms employing DIY approach are Node-RED [17], SAM starter kit [18], Super stream collider [19], particle.io [20] and dweet.io [21]. The virtual objects in most of such platforms are dragged and connected to compose IoT services. However, most of these platforms are off-line, and the efforts put by one maker can’t be reused by other makers [22]. Consequently, there is a need for a common place where these building blocks of IoT platforms can be shared and discovered to reuse them in similar domains of IoT applications.

There are several advantages of this commonplace for makers and IoT application developers. First, it avoids duplication of efforts. For instance, a temperature sensor sensing data has common characteristics and behaviour. The fabrication companies might differ but the underlying behaviour is always similar, and thus a virtual object designed for a sensor can also be reused for other similar physical sensors. If this virtual object can be discovered in a centralized place, then there will be no need to make another virtual object for a similar goal that has already been implemented by application developers. Secondly, a client application can automatically fetch a virtual object based on the semantic information, and thus can be controlled autonomously without any additional modules. Nevertheless, there are also several challenges in which notably storing virtual objects in a uniform and standardized fashion so that it can easily be decoded and could easily communicate with other virtual objects [23].

Some efforts have already been made for standardising virtual objects across different IoT applications. The work in [23,24,25,26] are worth mentioning. As a common point, a virtual object must have a unique representation (ID), describe the data about the object (properties) and behaviour of the object (methods). In some cases, an object can have an executable file that is a skeleton code on how to simulate the behaviour of the virtual object using the object data. Keeping in mind the above-mentioned challenges and facilitating the open-source makers’ community, this paper presents the idea of a decoupled application store, which serves a cloud-centric central place for virtual objects. These virtual objects can be discovered from the application store and can be used in a variety of similar IoT applications. Moreover, different IoT domains can also share their virtual objects so that they can be discovered and consumed by other applications. The application store can be thought of loosely coupled components of IoT applications which can be combined to build an IoT application.

The proposed application store considers traditional software engineering quality measures for designing the proposed architecture as outlined in [27]. For instance, software should be modular in structure, the components within the same module have high relevancy, and the elements across different modules have little relevance. This is referred to as cohesion and coupling [28]. A sound software must have high cohesion and low coupling; i.e., the modules have high relevance, and there are the lowest possible dependencies on other modules. Our proposed design makes use of the architecture pattern and aims to be modular with high cohesion and low coupling.

We aim to design a novel architecture with the goal to support popular service-oriented engineering. The architecture of the application store is decoupled and headless. The term headless refers to the ability to act as a data source without a user-interface. The application programming interfaces are exposed for client applications which they can utilize to get these resources using a variety of client software, e.g., android application, web applications. The major contribution of this paper is as follows:

• Design and implement a decoupled IoT application store based on the cloud to provide a central point for discovering and sharing of virtual objects.
• Ensure headless behaviour by exposing data of the application store and API for heterogeneous clients to consume the data without the need to go to the application store.
• Assess the effectiveness of the proposed application store; an IoT testbed client is developed to consume the API in order to get and share virtual objects.

The rest of the paper is organised as follows. Section 2 covers the proposed work’s motivation and highlights the system core architecture and modules. Section 3 overviews some of the design considerations and key approaches followed in the design of the proposed system. Section 4 identifies key processes and workflows of the system to highlight the operations of the system better. Section 5 illustrates the design and implementation of the system and discusses the functional and non-functional requirements of the system. Moreover, it also highlights the tools and technologies used in implementing this work. Section 6 presents execution results and presents IoT testbed client to demonstrate the discovery and sharing of virtual objects from and to of the application store. Section 7 investigates the performance of the system concerning load, scalability and response time. Section 8 presents the related work, and finally, Section 9 concludes the paper and identifies future directions of this work.

2. Motivation and System Architecture

The recent breakthrough of industry 4.0 and 5G communication technologies have enabled technologists to produce a massive amount of smart objects interacting with each other in real time to form an IoT-empowered smart space [29,30]. Smart things are composed of hardware and software. Hardware is the actual physical thing, while software is the interface to control it. The use of virtualization technologies allows physical objects to be imitated in a cyber-world. These entities are referred to as virtual objects. The relationship between virtual objects and their corresponding physical objects faces several challenges in terms of realization [4,23]. For instance, a virtual object is encoded according to certain criteria and thus needs to be decoded. Another challenge is the standardization of virtual objects. For example, virtual objects of temperature sensor must have certain data attributes and methods for it to be treated as its digital counterpart. In this paper, the virtual representation of these objects is standardized, and the decoding information is exposed via its application programming interface.

Table 1. Relationship between virtual objects and physical objects.

Virtual Object’s Attributes	Physical Object Mapping	Relationship
Type	Sensors, Actuators, Hybrid	Type of virtual object limits it to be used in certain categories of devices for instance sensors.
Title	Name of Object	Title can help in correlating virtual object in similar things
Supported Protocol	Way of interacting physical objects	A sensor supporting only CoAP can’t work with HTTP
Data Attributes	Size, duty cycle, resistance are data attributes	These enables the correct use of these attributes; For instance, a thing Person could have an attribute age
Methods	Potential tasks/operations a physical object perform	Sensing data, controlling fans, etc. can be mapped into methods in virtual domain
URI	Location	URI is where the object is located. With URI
Tags	Properties	Tags help in categorising virtual objects and efficiently searching relevant search
Metadata	Information like last access time	Metadata represents information about the physical object

overviews the link of the virtual object with its corresponding physical object.

From Table 1, the intuition dictates that virtual objects are nothing but the in-system representation of physical objects and also dictates terms and interfaces to allow the operating of their corresponding physical things. In short, a virtual object is a contract of the operating mechanism of corresponding physical things. When it comes to IoT software, the same question arises on how to reuse code and functionality and to minimize human efforts. The motivation of this application store is to allow IoT domains to share virtual objects provided by applications. For instance, an IoT domain based on a smart home offers sensors, virtual objects for temperature, humidity, pressure, etc., and actuator virtual objects for controlling illumination and other environmental parameters. Another IoT application with a similar goal can consume these virtual objects from the proposed application store and plug it on their physical devices with a no or minimal effort on the software part. In a nutshell, the motivation of the system is to share and consume common virtual objects without the need to reinvent the wheel. The overview architecture of the system is shown in Figure 1.

It is apparent from Figure 1 that different IoT domains pull virtual objects from the proposed application store and reuse it in the testbed IoT application without the need to write software for virtualization of the physical IoT resources. Likewise, IoT domains can also share their virtual objects to the application store in the standards laid down by the application store, enabling sharing, and code reusing of virtual objects. When a user gets a virtual object from the application store, the need to write code for representing virtual objects and persisting it is alleviated, and thus considerable human efforts are saved. Furthermore, for makers, only marginal changes such as the URI (which is specific for every user) are made in the virtual objects’ configuration before deploying it. For example, in case a fan actuator virtual object is being received from the application store, the testbed platform represents virtual objects and their methods in the form of functional blocks and allows a drag-and-drop feature to operate it using the mapped operation. It is worth noting that the drag-and-drop facility is not provided by the proposed application store, but makers can integrate any popular platform such as node-RED to allow linking of virtual objects’ instances with a particular operation. In Section 7, a use case is exhibited to present the functional point of view of the proposed system in more detail. A sample scenario in which the application store can be utilized effectively is portrayed in Figure 2.

Two scenarios can be thought of for explaining the effectiveness of the proposed application store. First, an IoT technology tinkerer, who aims at integrating different objects to form an IoT service, will search the required virtual objects in the store. The application layer of the store will take a user query for the virtual object. The query contains the meta description of the virtual objects. The application layer passes the received information to the OWL handler module which in turn posts a SPARQL-based query to search the virtual objects against user-supplied metadata in the Semantic database. Once, the virtual object is found, the semantic database returns the reference of the virtual object which has been stored in the virtual object repository database. MySQL adapter module uses the reference to retrieve the virtual object and delivers it to the application layer or RestClient module in case the user requires a headless response. These operations are numbered as 1, 2, 3, 4 in Figure 2.

The second scenario is for sharing virtual objects. Different IoT domains share virtual objects in standards compliant with the application store. Virtual object buffer temporarily stores the virtual objects and then passes it to meta descriptor module. The module extracts meta-data information from the virtual objects and uses RestClient module to put the request. The request is parsed, and the equivalent SQL query is generated by MySQL adapter which persists the virtual object and returns the unique identification of the newly-added virtual object. The OWL Handler uses the identification reference along with the data to generate a SPARQL-based post operation to post the meta-data and the reference into the semantic database. The sequence of operations in the second scenario is labeled as A, B, C and D in Figure 2.

As part of the system architecture, an IoT Testbed Client is implemented for assessing the usefulness of the proposed system. The testbed is discovering virtual objects from the application store and sharing specialized virtual objects for open-source IoT makers. The testbed is communicating with the application store using RESTful web services. The architecture of the testbed is illustrated in Figure 3. The testbed is a layered architecture and has different layers for defined roles. The top layer is a service layer which deals with services offered by the platform so that end users can consume them. The following layer is the functional decomposition and microservice layer. This layer receives a virtual object, decomposes it into the form of functional blocks and maps them to form a microservice. In other research, it is also called composite virtual objects [31,32]. A layer underneath is virtual object discovery and sharing layer. This layer has two sublayers; both of which is communicating with API exposed by the application store. The virtual object discovery layer finds and discovers virtual objects according to application requirements and the sharing layer shares the customized virtual objects to the application store for the use of open-source makers community. Each virtual object is registered with a gateway which is the job of the gateway layer. Virtual objects are registered and mapped onto the actual physical hardware. The last layer is the physical layer which deals with the deployment of virtual objects on physical corresponding devices.

3. Application Store Design Considerations and Key Approaches

In this section, design considerations and principal approaches of the application store are brought into the discussion. Some of the key strategies are listed in the forthcoming subsections.

3.1. Decoupling

As described in earlier sections of the paper, one of the central motivations of the application store is the decoupled nature of modules. The decoupling in this context implies that the virtual objects of the application store have no dependencies on any IoT platform and services. These objects are independent and can be consumed by any application. It is the main motivation of this work and is considered one of the preliminary requirements of the system. There are various systems which provide full-fledge IoT solutions, including hardware, software and user guideline on how to operate the system. In contrast, the target audience of the proposed system is technology tinkerers and makers, who like to be involved in the technology and customize the application to adapt to the business requirement of the domain. The decoupling consideration allows IoT domains to use some of the virtual IoT resources as building blocks and work with those building blocks to develop a customized IoT service that fits well in the domain requirements.

3.2. Modularity

The crucial design challenge in software engineering is to have a modular system with high cohesion and low coupling. The proposed system is modular, and each module has its defined functionality, and the cohesion is high. For instance, hypertext application language (HAL) and RestClient modules are utilized for serialization and RESTful web services. Similarly, for authorization OAuth2 module has been utilized. The important modules of the system are summarized in

Table 2. Overview of different modules used in the proposed application store.

Module	Description
RestClient	The module deals with the Restful API. Valid commands are PUT, POST, DELETE, PATCH and GET
HAL	Hypertext Application Language (HAL) is a wrapper module which uses RestClient to support RESTful web services that contain hypermedia and embedded objects
OWL Handler	OWL handler utilizes semantic ontologies for supporting meta description of virtual objects in the form of vocabularies and ontologies.
MySQL Adapter	It is responsible for database operations like create, delete, edit and select.
Taxonomy	It is used for categorization of virtual objects
Views	This is a MySQL adapter wrapper module for efficient enabling of listing and searching virtual objects on the application store
Simple OAuth	This module provides authorization support by utilising OAuth2 server and tokens
Serialization	This is one of the preliminary modules for headless support of the framework and is used to serialize JSON or XML request payload
Varnish Cache	This module enables fast caching on the system for a performance boost and optimization
Secure Login	This module enables security on login forms by changing the URL pattern and prevent flood attacks
Captcha	It enables captcha system to prevent machine login

.

3.3. Headless Support

The term “headless” is often used when an application works even without a graphical user interface. The demand for the headless property of the system is growing due to the vast number of mobile devices and smart things. A software system is said to have headless support if it can act as a data center for a ubiquitous array of applications. These applications acting as consumers can be any of the mobile applications, web applications or any hybrid applications. The proposed system is headless in a sense that different IoT domains acting as consumers and providers can interact with the system without using a graphical user interface. The data is exposed using RESTful web services so that it can be consumed in a headless fashion. Similarly, an authorized user can also provide IoT objects by hitting certain endpoints exposed by the system.

3.4. Restful Web Services

As it is described in earlier sections that if the system has to be used without a graphical interface, the data have to be exposed for different software, therefore, the proposed system uses serialization restful web services to consume and provide the data. Given the popularity of RESTful services, it has been the de-facto standard for IoT applications. We support HAL, RESTful web services and serialization modules which provide secure and end-to-end data transport across different IoT domains via RESTful services. Serialization module is used to serialize JSON or XML payload of the request. Similarly, HAL module is employed for provisioning hypermedia objects such as external resources and links within JSON or XML payload.

3.5. Authentication and Role Management

The proposed system was equipped with role management feature which enables users to associate with certain roles. Moreover, for every role, a set of permissions has been specified. For instance, a role “Virtual Object (VO) consumer” has the permission of only read data and not write data but for the role “VO provider” write permission was also granted. Roles and permissions allow verification and validation of who and what a user can do. Similarly, every user had to be authenticated before using the system. The system allowed anonymous users to register. Once a user has an account on the system, he/she can be authenticated with the credential provided at the time of registration. Table 2 provides a small snapshot of some of the permission strings and the assigned roles on physical corresponding devices.

3.6. Authorization

Authentication is helpful in identifying a user or device whereas authorization is used to know whether an authenticated user has access to a certain resource or not. For instance, a user with role IoT consumer is not authorized to delete a virtual object on the system, but in contrast, a user associated with admin role is authorized to do so. In addition to the simple authorization system, we used an OAuth server which adds another layer of security and is helpful in device and machine authorization. The authorization is of paramount importance for headless systems in a sense that an external user or machine has to have a valid token for posting something to the system.

3.7. Security

The system security is considered a major design goal and, therefore, it has been deployed in the cloud to get benefited from the security features. Moreover, some specialized security modules have been used to prevent hackers from attacks. Modules like captcha, secure login have been employed to make the system even more secure.

3.8. Analytics Support

One of the fundamental considerations in any application design is to enable context-awareness and user preferences so that only relevant content is displayed to a specific set of users. For instance, a user belonging to a smart-home IoT domain is only interested in resources which can be integrated into a smart home scenario. Similarly, users with the smart farm case will want to have a list of those virtual objects which is relevant to the mentioned domain. Therefore, the proposed system was made intelligent with the passage of time to learn user preferences over time using an analytics module.

4. Key Processes and Workflows

In this section of the paper, we discuss the key processes and workflows for interacting and reusing the resources on the system effectively in a decoupled and headless fashion. The overall processes are based on scenarios which are described in the earlier part of the paper in Figure 2. Some of the key processes are mentioned in the forthcoming subsections.

4.1. User Registration

Registration is the main module through which application users can get access to the resources on the application store. Users can be registered with the role of consumer, provider or they can opt for both. At the time of registration information like IoT domain, time zone and email address are received. The administrator receives the registration request and approves it, and the new user is notified via email. A sample web form is shown in Figure 4.

4.2. Client Registration

As discussed in the design considerations that virtual objects in the application store must be protected from unauthorized access. For this, the OAuth2 module has been utilized which enables effective authorization. In the OAuth2 system, one requirement is to register all clients who tend to interact with the system. The client is the application that would like to access the user’s account on the system, and upon registration, the client will be associated with a role and user on the system. The difference between users and clients is that clients can be machine or IoT gateways or even smart things. Some clients don’t need users, and they autonomously post contents without user intervention. When a client is registered on the system, it has been assigned with client unique user id (UUID) and secret code which can be used as mandatory parameters in OAuth access token grant request.

4.3. Authorization Code Grant

The registered clients got the access code from the authorization server which grants access to protected resources on the application store. The client makes a request using OAuth2 protocol to the authorization server by providing parameters like client UUID, secret, authorization server URL, access token URL, and callback URL. Access token URL is where the token is posted, and the authorization server URL is the address of the authorization server which identifies clients and validates them using the provided UUID and secret. A sample postman-based test request is shown in Figure 5.

Once the form is submitted, and the access code has been granted, which can be supplied in the header of POST request of REST, the system validates the access token and authorizes the request to protected resources.

4.4. Posting Virtual Object

When the client is authorized, and the access token is granted, only then can it access protected resources and add new resources to the application store. The headless access support of the application store allows clients to share their virtual objects in the store without the need to visit the store. Clients can leverage RESTful API to post their virtual objects to the store in a store compliant format. The restful request should be wrapped in the HAL for allowing hypermedia and embedded objects. The standard payload for virtual objects is based on the parameter of the virtual object. The JSON format of the system compliant virtual object is shown below.

          {
          "type": [{
          "target_id": "virtual_object"
          }],
          "_links": {
          "type": {
          "href": "http://13.209.74.51/jnuappstore/rest/type/node/virtual_object"
          }
          },
          "title": [{
          "value": "LED from external app"
          }],
          "body": [{
          "value": "Test app?"
          }],
          "field_model": [{
          "value": "external-led-edited"
          }],
          "field_vo_type": [{
          "target_id": "actuator"
          }],
          "field_supported_protocol": [{
          "target_id": ["coap", "http"]
          }],
          "field_common_methods": [{
          "value": ["BlueOn", "RedOn", "GreenOn", "TurnOff"]
          }],
          "field_resource_uri": [{
          "value": ["coap://129.21.121.1", "http://129.21.121.1"]
          }]
          }
        

The payload will form the body of the POST request, and the access token is provided in header; otherwise the request will not be authorized.

4.5. Semantic Knowledge-Based Discovery

In this paper, a semantic approach has been used to store and conceptualize virtual objects’ descriptions and their relationship with other entities. The information model is based on OWL ontology, and the discovery is made possible using SPARQL, a standard query language for querying and traversing semantic graphs. It has been argued in many literature studies [33,34,35] that an IoT application should be semantically modeled in terms of ontologies which define common knowledge base of a particular IoT domain. IoT applications deal with physical devices of heterogeneous nature, so some of the preliminary requirements of IoT application mentioned in the early design of IoT systems are interoperability and support of diverse platforms [36,37]. Therefore, the semantic representation of information is of paramount importance in the IoT domain due to the inherent comfort of interoperability. Semantic representation also makes IoT applications easily discoverable due to the uniformity of the documents’ structure. We use Protégé editor [38] for visualising ontologies and Apache Jena API [39] for interacting with the application store. The ontology graph based on Protégé editor is depicted in Figure 6. As shown, OWL classes such as owl:VirtualObects, owl:Permission, owl:Platform and others are defined along with their relationship and domain of their attributes. For instance, it has been shown that for the operation sharing, the policy of authorization and authentication must be ensured. In semantic modeling of knowledge, certain known facts are manually created which are also known as asserted facts. On the other hand, some facts are inferred using the asserted facts. For instance, the following facts

• :Actuator rdf:type owl:Class .
• :VirtualObject rdf:type owl:Class .
• :Actuator rdfs:subClassOf :VirtualObject .
• :FanActuator rdf:type :Actuator .

will infer the below fact, and the process is called ontology reasoning.

• :FanActuator rdf:type :VirtualObject .

Ontology reasoning is performed by a reasoner. For this purpose, we have used Fact++, a Protégé built-in reasoner, to infer the knowledge based on asserted facts. Moreover, instances (also known as individuals) are created for each class which is shown in boxes having pink diamonds. Dotted arrows represent the relationships while solid arrows denote the sub-class (is-a) relationship. For instance, the yellow dotted line between owl:VirtualObject and owl:Operations represents the “performs” relationship. Every virtual object has a bunch of data attributes such as unique ID, location and timestamp on which it is created or updated. The unique ID is also stored in the MySQL database so that when it is received by SPARQL, the same is used to return the actual virtual objects from the database.

Figure 7 illustrates the flow of virtual objects from a functional point of view. The IoT testbed client connects with the application store and requests the virtual objects with a set of parameters provided in a query string. The GET request is parsed by the application store’s RestClient module and parses it in the SPARQL format. The SPARQL query is executed by a SPARQL engine, and if the information is matched with any virtual object, then its node id is returned. Afterwards, the RestClient formats the request based on the node id and redirects it to MySQL adapter which in turn returns the virtual object in JSON format as portrayed.

5. Design and Implementation

In this section of the paper, we describe the design and implementation technologies of the system. In computer engineering and sciences, an architectural design portrays the general organization of a system, abstracting from restraints such as implementation technology. The motivation is to understand and describe the system’s behaviour without going deep into the technical world. Based on the design considerations described in the earlier section, the design of the system is based on a set of functional and non-functional requirements described in the forthcoming subsections.

5.1. Functional Requirements

Functional requirements are the actual functionalities of the system that is expected by the end users and what a system should be qualified to perform. In some cases though, functional requirements also state what systems should not do. The functional requirements are not quantified, but the user analytics and certain tools which measure the effectiveness of the system indirectly link to the functional requirements. The functional requirements of the proposed application store are as follows.

• Virtual object discovery: if an individual does not know what are his capabilities he cannot advertise them to others. The same principle is applied in IoT, where it is crucial for things to be aware of their abilities and limitations, so they can announce to peers what services they offer. Virtual object discovery is the process used by a client or IoT device to search for the desired object on the application store.
• Role management: a role is a mechanism through which the client or user capabilities are restricted in the system. Roles have to be managed on the application store. A role can be added, edited and removed. Similarly, one or multiple roles can be associated with registered users and clients so that their interaction with the application store can be controlled.
• Permission handling: permissions and roles are correlated with each other. For every role, a set of permission strings is defined. If a user or client device with an associated role wants to perform some operations, they are checked with the permission string allowed to the associated role and the control granted if true and false otherwise.
• Virtual object management: like roles management, the administrator of the application store can manage virtual objects. A virtual object can be added, deleted and edited by the administrator users and each of them belongs to a specific category. These virtual objects are the building blocks of the store, so they also need to be protected from unauthorized access.
• Headless data center: if the application store is not accessed with a graphical user interface in the browser, it should act as a data center which provides different data like virtual objects, users, clients, roles, tags and categories in XML or JSON format so that it can be consumed by external mobile applications or 3rd party APIs.
• Client management: clients are IoT applications or machines interacting with the application store to share or discover virtual objects. The application store must have the ability to track client and the associated role and to authorise the access if certain criteria are satisfied.
• Heterogeneity: virtual objects are the virtual representation of physical things. These can be sensors, actuators or service objects which are a combination of sensors and actuators to form a composite virtual object. These objects can be operated using different protocols. Some of them are CoAP, MQTT, HTTP, and web sockets. The application store will uniformly treat these virtual objects hiding the underlying technical complexity from the end users.

5.2. Non-Functional Requirements

Non-Functional requirements do not directly influence the technical functionality of the system, but they must be achieved to ensure QoS. Some of the requirements of the application store are as follows.

• Security: security is considered vital for IoT applications. The application store must ensure the security of the system and protect flood attacks. The system is deployed on the cloud to have an extra layer of security provided by Amazon web services (AWS) cloud in the form of security groups.
• Privacy: privacy of the system is ensured by protecting all the resources and assigning roles and permissions for users and clients so that no unauthorized access is granted.
• Interoperability: the virtual objects provided by the application store is platform independent and can inter-operate in heterogeneous devices and platforms.
• Performance: the application store ensures high performance by enabling a fast cache system like varnish and APC.
• Scalability: the application store is enacted to be scalable for a massive number of virtual objects, and the performance must not degrade for a peak load.

5.3. Design

Based on the requirements mentioned in previous subsections, the architecture of the application store was accomplished. There were various entities, and the most important of them were virtual objects. The class diagram of the system is shown in Figure 8. The application store is used by broad categories of users and clients either of them are identified by their roles, e.g., admin role, consumer role, and producer role. A user can register with the application store against one or more roles, and each role has a set of permission assigned to it. For instance, one example of a permission is “delete virtual object” which is associated with the admin role so that non-admin users are not authorized to delete the virtual objects on the application store. Examples of permissions and roles are summarized in

Table 3. A small snapshot of permission and roles management of the proposed application store.

Permission String	VO Consumer	VO Provider	Anonymous	Admin
View VO	TRUE	TRUE	TRUE	TRUE
Create VO	FALSE	TRUE	FALSE	TRUE
Edit Any VO	FALSE	FALSE	FALSE	TRUE
Edit Own VO	TRUE	TRUE	FALSE	TRUE
Delete Any VO	FALSE	FALSE	FALSE	TRUE
Delete Own VO	TRUE	TRUE	FALSE	TRUE

. The virtual object which is the primary entity of the application store was further specialized into three categories namely sensors, actuators and service objects. Each virtual object had a unique id, name, model and also belonged to a specific category, e.g., sensors, and actuators. A virtual object can support one or more platforms and protocols. Platforms are based on general purpose machines like Raspberry PI, Intel Edison board, Arduino board, or more specialized devices. Similarly, protocols can be CoAP, HTTP, MQTT and web sockets.

The sequence of operations among different components of the application store and IoT testbed client is shown in Figure 9.

There are two scenarios in which the application store can be utilized. The first scenario is resource discovery and the second scenario is resource sharing as shown in Figure 9a,b. In both cases, the interaction is from IoT testbed client to the application store. In the first scenario, the client application which is an IoT testbed aims to discover virtual objects for IoT resources registered on the gateway. The metadata of the registered resource is parsed to form a discovery request. The request is made to the application layer in the form of RESTful web service. Afterwards, the request is laid as a GET request along with the metadata of the registered resource. The metadata can be the supported protocol, platform, type of resource, to name a few. The application layer, as part of the authorization and authentication, gets a CSRF token from the authorization server for avoiding cross-site request forgery attacks and appends it with the request to the repository. It also authorizes the request by appending an auth token which is a license to access the application store. The request has now CSRF and auth token in addition to the metadata. The OWL handler process the request and form a SPARQL query based on the metadata in the discovery request. If a virtual object matching with the request payload is found, it’s node id is returned in response to the MySQL adapter. The SQL query against the node id is made to the virtual repository, and the virtual object is returned all the way to the discovery manager. The discovery manager decomposes the virtual object into functional blocks which are used to model microservices. These microservices are deployed in the form of commands to the actual physical resources.

The second scenario which is for virtual object sharing is a little more intricate in a sense that it needs to acquire access token and also register the client machine on the application store before posting something on it. In this case, the client application control IoT resources with some virtual objects necessarily not in the application store compliant format. Before sharing the virtual object, the client needs to be registered on the application store. RestClient sends a request for it to the Client Manager which in turn registers the client by associating a UUID and a secret to it. The same information is also stored on the authorization server against the client id so that the application store recognizes the same client as an authorized client for future requests. The same credential is provided to the client application as well. The client now forms a POST request for the access token to authorization server by specifying its UUID and secret. The authorization server identifies and validates the client and returns the access code in response. Now, the client uses the access code in the header of the POST request and the virtual object’s JSON representation in the payload of the request. The request is validated, and once it is compliant with the HAL requirement of the application store, it is transformed as an SQL query by MySQL adapter and inserted as a node in virtual object repository. If the insert operation is successful, the node id of the newly-inserted node is returned to the RestClient which ships it along with the request to the OWL handler. The OWL handler makes a SPARQL query, and the semantic information is saved in semantic database (DB). The response code 200 indicating success is returned all the way the sharing manager indicating that the virtual object is successfully shared on the application store.

5.4. Implementation Tools and Technologies

In this section, we cover the technology stack used for implementing this work. As described earlier, the effectiveness of the application store needs to be assessed with a client application which can get some virtual objects from the application store, and likewise, can share some to the application store. The application store has been developed with Drupal 8, an open-source framework [40]. Drupal uses PHP as a core programming language. Drupal has a vast community and solid developers bench. The primary motivation behind using Drupal is the robustness and scalability of the framework. The security patches of the framework released every single month making it even more robust against newer cyber attacks. Moreover, Drupal is modular and supports headless behaviour making it an ideal candidate given the system requirements. The application store was deployed on AWS elastic compute (EC2) instance. For implementing modules and interaction between 3rd party tools, Sublime text and PHP storm have been utilized. Likewise, Protégé editor was used for ontology editing and visualization. Apache Jena was used as a 3rd party module which enables the interaction between the application store and semantic ontologies. For instance, when a virtual object discovery request is received, the OWL handler consumes API provided by Jena to format the query and send it to the ontology database. These tools and technologies have been summarized in

Table 4. Specification of implementation environment of application store.

System Parameter	Value
Operating System	Linux AWS EC2 Compute Node
CPU	Intel (R) Core(TM) i5-4570 CPU @ 3.20 GHz
Primary Memory	12 GB
IDE	Sublime Text 3, PHP Storm, Protégé Editor
Framework	Drupal 8
Core Programming Language	PHP
Libraries	HTTP foundation, ReactJS, HTTPKernal, Bootstrap 3, HTML 5/CSS3, TWIG, Apache Jena
Persistance	MySQL

.

As a client application, an IoT testbed was developed which has different gateways connecting different IoT resources. The IoT server was different for each gateway. There were five gateways used in which one is using flask server which listens to HTTP requests, one of them is listening to CoAP requests, another was based on publish-subscribe MQTT protocol. The specification of IoT testbed client is summarized in

Table 5. Specification of implementation environment of application Store.

System Parameter	Value
Number of Gateways	5
Supported IoT Protocols	CoAP, HTTP, MQTT, Web Sockets
Operating System	Raspbian OS based on Linux
Primary Memory	1 GB
IDE	Sublime Text 3, PyCharm
Framework	Flask
Core Programming Language	Python
Libraries	Jinja2, Bootstrap 3, HTML 5/CSS3, Javascript jsPlumb
Persistance	MySQL

. We instated different IoT servers to inter-operate virtual objects using different protocols and physical devices. The hardware specifications of the IoT testbed client will be described in the subsequent section. Apart from this, jsPlumb [41], a Javascript library, has been utilized to facilitate the drag and drop feature which helps in connecting the functional blocks of virtual objects to model microservices.

6. Execution Results

In this section of the paper, we present the execution results of our proposed application store. The application store was a repository of virtual objects shared by different IoT domains. The application store acted as a central point for technology tinkerers to share their virtual representation of their physical hardware and also to get some of them depends on the availability and satisfaction of the requirement. One advantage of the application store is that it provided building components of IoT applications in a decoupled fashion. Thus, avoiding the use of full-fledged IoT applications which results in over-utilization of the resources. In this work, we mainly focus on the functional requirements and design consideration we highlighted in earlier sections and present a snapshot of the systems accordingly. The first and foremost thing is the effective presentation of virtual objects so that they can be discovered easily. Virtual objects were listed categorically, and search filters are added at the top of the page to speed up the discovery process. Figure 10 shows the snapshot of the recent virtual objects page.

The listing page included recently added virtual objects from different IoT laboratory students of computer engineering. The attribute of a virtual object can be the title, model, type of virtual object, data, methods and supported protocols. These virtual objects can be exported and used in other IoT applications in JSON and XML format. In addition to virtual objects, an executable object is also attached as a guideline on how to deploy the virtual objects on actual physical hardware.

The client management page is exhibited in Figure 11. Each client had a specific UUID, label, scope and optionally, a callback URL. In addition to these attributes, the scope can be defined to associate the client with a specific role, for instance, in Figure 11, one client has $app\_consumer$ role, and three of them have $app\_provider$ role.

These clients were users or IoT gateways interacting with the application store to share and get virtual objects. Therefore, the identification is of paramount importance to avoid malicious attacks and unauthorized access. The roles and permissions for controlling unauthorized access to the application store’s protected resources are exhibited in Figure 12.

The role management module, as shown in Figure 12a lists down all roles added to the system and administrators can add, edit and delete roles. There are app provider and app consumer roles specific for virtual objects sharing and discovery respectively. A user or client can have multiple roles. For instance, application users might be interested in discovering some virtual objects from the application store but at the same time can share their customized virtual objects to the application store too. In this case, both app consumer and app provider roles are assigned. The permission strings for each role has been depicted in Figure 12b which shows the corresponding implementation of permissions and roles summarized in Table 3.

When a request was made to a virtual object, the nature of the request was first investigated by HTTP foundation module. If the request was in PUT, DELETE, and POST, then there was a chance of modification to the system. The client id was checked to find out associated roles. Associated roles help in finding the permission list for the user and thus the access was controlled against the request accordingly. For instance, if a DELETE request was made to a virtual object, and from the client id, it is affirmed that the associated role was app consumer who was not authorized to delete any virtual object, the request was denied consequently. This way the application store was made robust and secure from unauthorized access, which is a crucial design aspect of IoT applications. For decoupling and headless access to the application store, the RestClient module was implemented to enable the RESTful API call to the application store. Figure 13 exhibits the interface of RestClient module.

The entity on which the endpoints of an application is exposed is virtual objects, and the methods are GET, POST, DELETE and patch. The request formats can be one of hal_json, JSON and XML and the authorization is based on oAuth2 library.

A Use Case IoT Testbed Client for Sharing and Discovering Virtual Objects

As described in previous sections of the paper, the IoT testbed client was developed to elaborate the functional behaviour and the usefulness of the proposed application store in making IoT applications. The testbed client was dealing with discovering some virtual objects from the application store and sharing some of them on it. The testbed client comprised of different IoT devices and gateways which are summarized in

Table 6. Specification of implementation environment of application store.

IoT Gateway	IoT Server	Devices Connected	IoT Protocol
Raspberry PI	Flask	Fan Actuator, LED, Temperature Sensor	HTTP
Raspberry PI	CoAP	RGB LED, Humidity sensor	CoAP
Raspberry PI	Node.js	LED, Camera	MQTT
Raspberry PI	Flask	SenseHat	HTTP
Raspberry PI	Flask	Traffic Control Application, RGB Led, Gas Sensor, Camera	HTTP

.

The prime motivation of the testbed client was to use different IoT technologies, heterogeneous devices and IoT platforms to find the interoperability of the application store. CoAP, HTTP and MQTT are some of the commonly-used communication protocols in IoT applications. We have utilized these three protocols by installing the respective servers. For HTTP, we used a Python-based Flask server which listens to HTTP requests. Similarly, we use Node.js server to listen to MQTT requests and CoAP server for CoAP requests. The resources are connected to different IoT gateways sharing wireless internet access. A variety of small IoT applications were developed and deployed on the testbed client. These applications included the likes of temperature monitoring, fan control, remote traffic control, and remote light control. Virtual objects used in the application are shared in the application store. The IoT testbed Client’s experimental setup based on Table 6 is depicted in Figure 14.

There were several gateways and devices connected to form a mashup of IoT applications. For instance, a simple IoT application was implemented to detect the gas using a gas sensor which takes the snapshot if the gas is detected for surveillance of a room to prevent fire hazards. The MQTT has been used as a communication protocol and the virtual objects for the camera, and the gas sensor have been shared to the application store. A web-based application was developed to handle these virtual objects and to share them on the application store using RESTful API. Figure 15 shows the client application designed for IoT testbed client to manage the virtual objects and services used in the IoT testbed client. The implementation technology of the client application is summarized in Table 5.

The primary interface of the client application is shown in Figure 15. Virtual objects used in the applications were managed in the client application. For every virtual object, there were two action buttons; first of which was for sharing virtual objects to the application store whereas the second one was for decomposing the virtual object into functional blocks. If the share button was clicked, it triggers the API request, which first authorizes the client against the UUID and secret. Once the client was authorized, and the access token was granted, the subsequent request converted the virtual object to JSON and ships the access token in the header of the request and posts it to the application store. The RestClient receives the request and lays it down in the application store-compliant form if not already, and stores it in the repository.

In this paper, the detailed design of intelligent weather control in the smart home, a simple-as-possible case study is presented. The application utilizes the proposed application store to discover virtual objects of temperature sensors and humidity sensors. It also uses a fan motor as a controlling actuator. The flowchart representation of the application is exhibited in Figure 16. First, the device profile is investigated from the specification document and based on the desired features, the virtual object is discovered. Once the virtual object is found, it is received in IoT testbed client. The virtual object is then configured to reflect application specific changes, i.e., changing URI, and is saved in the database. The virtual object is decomposed into functional blocks afterwards. The blocks are then drag-and-dropped using any DIY technology to compose a microservice. In this paper, we have used jsPlumb, a Javascript library to enable the drag and drop behaviour in the browser. A microservice is an operation which is performed by a physical thing. In the virtual domain, a microservice is comprised of a virtual object and an operation or a task.

The user intending to discover virtual objects starts with the adding virtual object to the client system. In the virtual object discovery interface, there was an option to discover virtual objects on the application store considering the user is already connected and authorized. If the virtual object meets the device profile meta-information supplied by the user, the interface was pre-populated, and the virtual object was pulled using the RESTful GET method. The discovered virtual object was added after making some application-specific modifications. The virtual object listing interface listed down all the virtual objects added into the database as shown in Figure 15. For each virtual object, the action column provided a couple of buttons to decompose it into functional blocks and also to share application-specific ones on the application store. In Figure 17, we have considered a case where the user needs a virtual object for the fan controller. First, he connects with the application store and provides meta information. These include tags, data attributes, description, and operations or methods the object can potentially perform. In the second step, the virtual object was discovered and saved in the database which is shown on the virtual objects listing page. On the listing page, two actions can be performed on individual virtual objects; sharing to the application store and decomposing it into functional blocks. In the case, if the decompose action is triggered, the application comes up with an interface which provides a space to the makers, where the virtual objects are represented in functional blocks. The functional blocks are operations that a virtual object can potentially perform. For instance, in the case of fan control, operations like turnoff-fan, turn-clockwise, and turn-anticlock are listed. These operations are connected by dragging a line from the virtual object to the operation and dropping it on the operation block. Once the drag-and-drop is done, the configuration is persisted in the form of microservices. In the next screen, the microservices are listed with an action button to deploy them on their corresponding physical objects. Once the button is clicked, the fan control starts to perform the specified action. Consequently, the maker saves a lot of effort by otherwise writing code for virtual objects adding, configuration and connecting it. The same steps can be followed to discover sensors virtual objects and deploy them as a microservice on the specified temperature sensors. To make a simple weather control service, the microservice are deployed conditionally. For instance, the temperature sensor is deployed, and if the sensed value is greater than some threshold, only then the turnon-fan microservice is deployed.

7. Performance Evaluation

In this section of the paper, the performance of the system under peak load and the impact of data size in the RESTful communication has been investigated. For load testing, an open-source tool named Blazemeter [42] has been utilized while for the delay and response time analysis, the communication has been emulated on Mininet with open network operating system (ONOS) as a Graphical User Interface (GUI).

7.1. Load Testing of Application Store

A load testing experiment has been carried out against various key performance indicators (KPI) for assessing the performance and scalability of the system under different load conditions. The KPI we considered for the performance were average response time, error percentage and network bandwidth. We used Apache JMeter to develop a testing script and import it in Blazemeter to assess the load of different virtual users. The testing results are shown in Figure 18.

We have tested the load under different load conditions with different virtual users and have defined criteria for too slow response and too many errors. Figure 18a shows the simulation for 40 simultaneous users. The errors are very few, and the response code 500 indicates that it is not due to the peak load but is an internal server error. The green line shows hits per second, and although it fluctuates, still the errors remain steady. Figure 18b exhibits the response time behaviour of the application store for the same samples. The average response time was 421 ms which is less than half of a second for such a high number of simultaneous users. This proves that the system is robust against peak load condition and scalable if more simultaneous users and resources are added.

7.2. Performance Analysis of Application Store Access

In this section, we investigate the performance analysis in terms of response time for two scenarios which have been described earlier, i.e., VO discovery and VO sharing. For this, we use Mininet tool along with ONOS as a remote controller and GUI. The topology of the network is exhibited in Figure 19. Three IoT testbed clusters are communicating with each other by sharing and discovering different virtual objects. Hosts are acting as gateways to different IoT resources. In this experiment, Pulse Sensor, Oximeter Sensor, Humidity Sensor, ECG Sensor, Temperature Sensor, and Gas Sensor were taken as sensor devices whereas Fan actuator and LED actuator are considered as actuating devices.

The communication nhas bee performed in three ways for both cases; first, intra-cluster communication which shares and discover virtual objects in the same cluster. Second, the closest cluster for communication and finally, the remote cluster which was at the farthest location. The response time for 200 requests is recorded for a bandwidth of 476 Mb/s and with a network latency of 10 ms. The resultant graphs are shown in Figure 20. It has been evident that the response time of intra-cluster communication was the fastest in both cases and the response time of the farthest cluster in inter-cluster communication is the slowest in both cases. It is due to the additional hops and the distance between IoT domains and application store. Overall, the response time of VO sharing is slower than the response time of VO discovery because the uplink speed is in many cases slower than the downlink speed.

7.3. Subjective Testing

As part of the subjective testing, 20 students from the Department of Computer Engineering, Jeju National University, were given the application store source to get the necessary virtual objects for their IoT-based course projects and shared their distinct virtual objects to the application store after completing their projects. At the end of the course, a survey was conducted to find the opinion of students on various key factors of the application store. These include performance, code reusability, the usability of the application store, interoperability and many more. Their responses are recorded in either of poor, satisfactory and excellent. The result of the survey is shown in Figure 21. The green area shows the percentage of students who voted excellent for various attributes. The red area indicates a satisfactory response from students and the blue area represents a poor response.

It is evident that for each attribute, a majority of students voted for excellent and satisfactory. Overall the response area of “excellent” is more prominent than “satisfactory”. There is a slight existence of the poor response area. In learning curve, notably, the response indicating “poor” is 10% which means two out of 20 students think the usability of the system has some room for improvements. From the subjective testing, it is evident that the students can use the system effectively and find it excellent regarding the novelty and think of it as a great addition to the state-of-the-art.

8. Related Work

The related works of this paper are based on the motivation, architecture and the design of this work. The first notable thing which gives birth to this work is to have an application store in which IoT components are decoupled and can be used by makers to build applications. Virtual objects are considered as the building blocks of IoT application as pointed out in many research studies. Nitti et al. [4] indicates that virtual objects are the primary building blocks in their survey on the elements of IoT. The concept of virtual objects is also utilized by Ahmad et al. [22] in which IoT application is considered as the collection of virtual objects stored in the cloud to remotely configure IoT devices. The use of virtual objects enables heterogeneity, interoperability and uniform representation of diverse devices in the cyberspace [4,31]; however, it brings challenges in terms of standardized representation [23] and management of such a massive amount of diverse devices [25]. Espada et al. [23] highlighted two possible hurdles due to the lack of a standard template of virtual objects. The hurdles are difficulties on how to decode the virtual object back on the device and how to enable communication to automate IoT tasks. The authors also, for the first time, proposed certain features which are common among all the definitions of virtual objects. Israr et al. [25,26] proposed a prototype to manage virtual objects for effective organization of monitoring of a vast number of physical devices through virtual objects. All these studies agree on one thing that a virtual object is the building component of modern IoT applications, despite the fact that their end goal is different.

One of the enabling technologies of virtual objects is cloud computing [43,44]. IoT applications generally comprised of a vast number of objects which have constrained capabilities in terms of computation power and memory. Therefore, managing such a massive number of devices requires a central place to host the context data. It can only be possible if there is a virtual representation of devices in the cloud which is also backed by Hang et al. [45] recently. The application store thus utilizes the elastic computation feature of cloud and enables virtualization of objects on the cloud to make the component of IoT application available for makers. Another crucial aspect of the application store is that it’s target audience are makers, unlike other IoT marketplaces which are purely intended to be used by application end users. A vast number of efforts have been put forward on makers. The term “makers” was first coined by Anderson et al. [11]. The idea of “making” became so famous that a maker movement has been started which provides entrepreneurs with the ability to tinker with the technologies to form applications [46,47].

Another notable effort which also encourages the idea of making is the DIY approach. It was first proposed in 2011 Gartner Hype Cycle [48], that IoT is now no more imagination and has become a real work [49,50], so the end users should be a part of the building process while having the power to discover and control things [1,51] for effective utilization of applications in smart environment [52,53]. Toward the DIY approach, first distinguished work is DIY Smart Experience (DiYse) project which states a manifesto of 13 statements for designing and implementation of systems [16]. The manifesto also, for the first time, reveal the relationship of makers to the DIY paradigm. The open-source tools and products which address makers and DIY approach have since then become a norm. A wide class of products is launched aiming at the visual programming of IoT applications. The efforts in [17,18,19,54,55,56,57] are worth noting. All these applications are good attempts to involve the public in the creation process, but one thing is missing in all of them which is a common store for sharing the creativity of their work. There is no application store for IoT which is for open-source makers community and whose aim is to provide IoT components for makers to avoid code duplication and encourages code reuse. Some renowned application stores are IoT-based marketplaces [13,58,59,60]. BIG-IoT marketplace provides semantic queries for application developers, but the main problem in all of these platforms is that they are designed for IoT end-users, not makers, providing full-fledged IoT application which is not the goal of makers. Therefore, this project is the first idea to have a decoupled application store which provides IoT components mainly virtual objects so that DIY applications and makers can consume it to build their applications easily and this, to the best of authors knowledge, is the first attempt of its kind.

9. Conclusions

In this paper, a novel idea of a decoupled application store has been proposed for sharing and discovering virtual objects which are considered as building blocks of IoT applications. The significance and motivation of this work, with reference to the open-source makers’ community, have been highlighted. Some of the design considerations and key approaches have been described which are regarded as a crucial aspect of IoT platforms. The functional and non-functional requirements based on these considerations are described in great detail. The application store is implemented in the cloud to take further advantage of the extra layer of security that the cloud offers. Furthermore, the design of the application store is made modular and decoupled to meet the best practices of software engineering. An IoT testbed client has also been implemented in which different small IoT applications have been deployed, and the virtual objects discovery and sharing in such a heterogeneous context has been demonstrated. The performance of the system is investigated using Blazemeter, and it has been verified that the system degrades gracefully even in the highest possible load conditions. In the future, we aim to develop more IoT building blocks like service objects, composite virtual objects, and services.