...
- The EdgeX configuration today is flat - meaning a single layer of key/value pairs with no groups or other structure. Configuration should, in the future, be categorized and grouped under a sub-structure to simplify the exploration and updating the config. For example, all properies related to MongoDB connection (host, username, password, etc) would be grouped under a MongoDB configuration structure.
- Downsampling: It is mentioned that the device service may receive from the device new unattended readings (e.g. in a pub/sub type of scenario). In this case, there should be a setting to specify whether we accept all readings or we decide to downsample because the source is pumping data too fast. This is actually a very common scenario when you deal with high frequency sensor packages.
Command: in order to protect the device from harmful commands, there should be the possibility to set a Min and Max limit for the value that is accepted on every single command. in fact the command service today is rather a hollow simple proxy, but in the future we very much envisioned adding additional security, caching to avoid having to hit the DS when unnecessary, and even grouping command requests for better resource conservation (especially for devices like BLE that get woken up when you hit them).
Data Transformation: This is something we have always considered as a potential in EdgeX – that of a filter, even a small transformation engine between device services and core data. Not a full blown export, but something that serves in a similar fashion and was common across services. We even thought about making it some type of quick CEP/rules engine feeder for those decisions that can’t wait to go through the rest of the layers.
- Revisited and improved security threat model.
- Implementation of message bus alternative for intercommunication between microservices as an alternative to REST.
While REST will not go away (a REST API will still exist around each micro service), there may be a need to implement point-to-point messaging between select services or to adopt some type of message bus unilaterally across all of EdgeX to support messaging among services.
Messaging provides for more asynchronous communications, typically lower latency communications, and better (or more finely tuned) communication quality of service (QoS). Are there places where messaging might be more appropriate (like between core data and export distro today). Would a use case dictate the use of an alternate messaging infrastructure be used among all services with an underlying message bus to support it? Would alternate protocols (SNMP, WebSockets, etc.) be desired in some use cases? For the Delhi release, some alternate communication requirements, design and early message implementation experimentation is likely to occur.
Should we allow configuration properties be overriden by command line provided properties (like Java allows/provides) for our Go services?