IoT/IoTServerPlatform

Introduction

At EclipseCon NA 2015 a number of IoT WG members meet to discuss the definition of an open source IoT Server Platform. The general view was that a lot of the open source technology has been focused on the devices and edge but not the server and enterprise middleware. The long-term goal of this discussion would be to determine what open source technology need to be created to support an open source IoT server platform.

Out of this meeting, the main feature/components of an IoT Server platform would include:

• Communication/Protocol adapters
• Device Management
• Data storage (in raw form)
• Event Management/Rules Engine/BPM
• User Management/Identity/Security
• API

The next steps for this discussion needs to be to

1. add detail to each feature/component,
2. map how this integrates and extends the existing open source middleware that exists in many server solutions, and
3. map this to cloud computing solutions.

Context

Following the Arc42 approach, we start with some simple context views to illustrate the surrounding actors and components an IoT server platform needs to deal with.

Business Context

The diagram shows how multiple (potentially millions) Devices are connected to the Iot Server Platform. The devices upload (sensor) data to the back end while the functions/services they expose can be invoked from the back end.

Business Applications use the Iot Sever Platform as a proxy for accessing the devices' data and functionality. Applications can subscribe to particular events like notifications about data changes or device life-cycle events. This way the applications do not need to deal with the technical and semantical specifics of the devices and their particular data models and communication protocols. Both of these aspects are abstracted away by the IoT Server Platform.

The data gathered from the devices can (optionally) be persisted in third party Data Stores. Arbitrary persistence strategies are possible, e.g. flat file, relational database, document store etc. The IoT Server Platform does not provide any means to store data out-of-the-box because it is expected that Business Applications will usually implement a their own, domain specific persistence layer anyways.

The IoT Server Platform uses an Identity Provider to authenticate incoming requests from Business Applications. (Note: The Identity Provider should probably also be used to get a user's authorities as well).

Technical Context

TBD

Building Blocks

The top level building block view provides a white box view of the overall IoT server platform. All of its components are shown as black boxes only, i.e. at this level their internal structure is not relevant (yet) but instead the focus lies on responsibilities and relationships. If necessary, the internal structure of each of the components (the white box view) can be documented in subsequent sections, thus forming an alternating row of black box/white box views providing a drill down into the inner workings of the system.

Communication/Protocol adapters

• Which protocols should be supported?
• Authentication? authorization?
• Encryption?

white box view (TBD)

Device Management

• Which protocols should be supported?
• Provisioning
• Bootstrapping

white box view (TBD)

Data storage (in raw form)

• Pure key-value store vs. time-series database?
• What querying capabilities are needed?

white box view (TBD)

Event Management/Rules Engine/BPM

• TBC

white box view (TBD)

User Management/Identity/Security

• TBC

white box view (TBD)

External Interfaces

• Existing (standard) APIs to leverage?

Meetings

The IoT Working Group members will be having regular meetings to discuss the requirements and action items to establish an open source IoT server platform. Participation to these meetings is for Working Group members only, but minutes are public.

Relevant Technology Components

• Communication, Device Management, API
  • ECF's implementation of OSGi Remote Services.
    • As demonstrated by commercial adoption/usage of Remote Services, by OSGi Alliance efforts in IoT, the Bosch acquisition, and by various presentations and tutorials, Open implementations of OSGi standards are already being heavily used in both server development and in IoT.
      • Communication - ECF's RS impl protocol-independence is ideal for dealing with a heterogeneous IoT networking/communication/integration environment. Further ECF's impl already has MQTT/Paho-based and websockets-based Remote Service providers and we or others can easily add others based upon other IoT protocols.
      • Device Management - Remote Services provides a standardized, open, elegant, and simple solution (persistence is another orthogonal aspect to device management).
      • API - The use of OSGi Services and Remote Services provides an open, elegant, time-and-use-tested, dynamic, version-enabled approach to IoT API definition.