Revision as of 03:48, 19 May 2015

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

TBD

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.

top level overview (TBD)

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.