Building Modular Middlewares for the Internet of Things with OSGi

Abstract

The paper addresses an analysis of OSGi in the context of building modular middlewares for the Internet of Things. The Internet of Things (IoT) is an emerging approach to development of intelligent infrastructures combining various devices through the network. OSGi is a framework providing a number of specific mechanisms intended for building modular, fine-grained and looselycoupled Java applications. Although a number of works have been devoted to OSGi, and several OSGi-based middlewares have been designed for the IoT, they do not thoroughly utilize mechanisms of OSGi. In this paper rich OSGi functions are analysed in terms of development middlewares for the IoT. An example implementation of the system illustrates the presented considerations.

Temporally-relaxed conditions for activation of services in the web of things

“…For example, using OSGi, Java-based services exposing RESTful interfaces could be integrated, while providing software life-cycle management [2]. Another recent approach to centralized user-friendly programming of scalable applications on devices in the Web is based on a REST framework for JavaScript (JS) [7].…”

Generic Architecture for Edge Computing Based on SPF for Military HADR Operations

“…Finally, we believe in the adoption of the OSGi [17] [18] specification 1 to support the execution, the composition, and the management of bundles (Java based applications) at runtime. In particular, adopting OSGi enables the possibility to efficient manage applications through containerization techniques, which will let new bundles to be created, uploaded, and activated on request without performing any cold or warm restarts of the other applications running on the same remote gateway.…”

Comparison of architectures for service management in IoT and sensor networks by means of OSGi and REST services

“…If there is no service of specified interface or meeting the additional constraints, null value is returned and must be properly handled. If the caller tends to invoke only one service, but in the registry there are few possible services meeting the requirements, OSGi environment returns the service of the highest rank (specified during service registration) and the lowest identifier (i.e., the oldest one) [11] [12].…”

“…Since OSGi v.4, the mechanism of sending and handling the events defined by software developers has been introduced. The event-based communication allows the definition of events' topics and accompanied metadata, which are handled by dedicated EventHandler services [11][13] [14].…”