Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "IoT/IoTServerPlatform"

< IoT
(Defining an IoT Server Platform)
Line 1: Line 1:
== Defining an IoT Server Platform ==
+
= Defining an IoT Server Platform =
  
 
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.
 
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.
Line 16: Line 16:
 
# map this to cloud computing solutions.
 
# map this to cloud computing solutions.
  
== Relevant Technology Components ==
+
== Communication/Protocol adapters ==
 +
 
 +
* Which protocols should be supported?
 +
* Authentication? authorization?
 +
* Encryption?
 +
 
 +
== Device Management ==
 +
 
 +
* Which protocols should be supported?
 +
* Provisioning
 +
* Bootstrapping
 +
 
 +
== Data storage (in raw form) ==
 +
 
 +
* Pure key-value store vs. time-series database?
 +
* What querying capabilities are needed?
 +
 
 +
== Event Management/Rules Engine/BPM ==
 +
 
 +
*
 +
 
 +
== User Management/Identity/Security ==
 +
 
 +
*
 +
 
 +
== API ==
 +
 
 +
* Existing (standard) APIs to leverage?
 +
 
 +
 
 +
= Relevant Technology Components =
  
 
* '''Communication, Device Management, API'''  
 
* '''Communication, Device Management, API'''  

Revision as of 12:22, 17 April 2015

Defining an IoT Server Platform

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.

Communication/Protocol adapters

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

Device Management

  • Which protocols should be supported?
  • Provisioning
  • Bootstrapping

Data storage (in raw form)

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

Event Management/Rules Engine/BPM

User Management/Identity/Security

API

  • Existing (standard) APIs to leverage?


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.

Back to the top