Delivery: ~ October 2018
The Delhi release is slated to provide the first system management capabilities while also implementing additional features in the security. Delhi will continue to show improvements in performance by offering Device Service SDKs in Go and C. Improved testing at all levels (unit, blackbox, performance, etc.) to ensure the quality of the system going forward while also providing a means to check backward compatibility. Finally, this release will include design and implementation plans (scheduled for Edinburgh release and beyond) for the replacement of MongoDB as the reference implementation database, and a replacement to the export services to allow for better scale and flexibility at the northbound layer. the scope of this release is smaller given the development cycle for the prior California release was made longer to accommodate all the Go Lang refactoring.
Implement a performance test harness
To establish a baseline of performance characteristics that can be used to understand EdgeX resource utilization, data throughput, etc.
Support binary data
Allow the EdgeX system (from device services through export services) to support binary data such as images, chunks of video or audio. This will require device services, core data, and the export distribution to appropriately handle this type of data. Local edge analytics may be fed binary data and create intelligence from it to allow for actuation at the edge based on the binary data (example: examine an image an detect the presence of a person of interest).
Replace any Java microserices that still exist.
Improve the configuration of EdgeX
Refactor the core and supporting services (inclusive of export services as necessary)
Refactor the services to implement data drive design, improves structure and organization of the code, improves ability to abstract infrastructure needs (database, messaging, etc.) to allow for replacements later, and allow services to bootstrap without artificial sleep mechanisms. Separates the domain model from the contract model.
Implement security & system management API hooks
Depending on the implementation needs of security and system management, there may be a need to make changes to the micro service code in support of these facets. It is likely that each micro service will implement some sort of base service to provide data and system management functionality to the system management agent. Access control to the service APIs will also be managed by the security services and code added to the service to require authentication before accessing the services will be needed.
Implement security & system management API hooks
Depending on the implementation needs of security and system management, there may be a need to make changes to the micro service code in support of these facets. It is likely that each micro service will implement some sort of base service to provide data and system management functionality to the system management agent. Access control to the service APIs will also be managed by the security services and code added to the service to require authentication before accessing the services will be needed.
Implement device service SDKs in Go Lang and C.
The device service SDKs and resulting device services will allow the EdgeX community to retire the last of the Java micro services and complete the dramatic performance improvement of EdgeX.
A stretch goal includes providing the existing device services in Modbus, BACNet, BLE, etc. in either Go or C.
Many of the original device services where created with driver stacks that are suit for purpose on all platforms, are no longer supported, are not homogeneous in their make up (i.e. having some parts Java while other elements in Python), or are using stacks that are not consider the best option for the protocol today. The BLE and BACnet device services fall under this categorization.
Several of the device services were created to prove, conceptually, how to connect to a device using that protocol, but it may not be a full implementation of the protocol API. For example, the SNMP device service implements enough to drive a Patlite and a few other devices, but does not understand all of SNMP.
Implement security & system management API hooks
Depending on the implementation needs of security and system management, there may be a need to make changes to the SDKs and existing micro service code in support of these facets. It is likely that each micro service will implement some sort of base service to provide data and system management functionality to the system management agent. As device services are typically created from an SDK, the same boilerplate code for the base service needs to be added to the SDK(s). Access control to the service APIs will also be managed by the security services and code added to the service to require authentication before accessing the services will be needed.
System management API (action, alerts, metric) as discussed and outlined here
System management Agent (see same document above outlining the agent functionality and duties)
As a stretch goal, the functionality added with this system management capability would facilitate systemd like bootstrapping.
· Use of JWT for authentication/access token