From discussions with a couple of potential Apache Edgent users some themes are emerging.
- Multiple applications may need to run on a device within the same provider (container)
- Applications may be added or removed as time goes on
- Applications within the same provider need to exchange data, say in a publish-subscribe model.
- This is also required when a single connection is used to communicate with the IoT scale message hub, so multiple applications need to send data to the message hub without having an individual connection. So almost a Edgent system application that is responsible for publishing to and subscribing from the IoT message hub, and then Edgent apps can publish to a topic that is subscribed to by the ioTDevice app for subsequent sending up to the message hub.
- Applications need to be controlled from the back-end, e.g. started stopped etc.
- Applications need to restart on failure.
- Application status (e.g. running paused etc.) needs to be reported back through the message hub to interested consumers.
- Application metrics need to be be reported back through the message hub to interested consumers.
All of the above are in the general vision for Edgent, but not all are implemented.
- DirectProvider supports multiple running independent applications.
- Applications can be added or removed at any time.
- The ControlService is a work-in-progress to allowing arbitrary control objects to be registered by Edgent (e.g. job control), applications or application services, and then updated through the message hub.
Features in general should be optional rather than mandatory, implemented though:
- Additional application services
- "system" applications - thus extend the complete Edgent system itself by using Edgent, not hard-coding features into runtimes.
DirectProvider may remain as the most basic provider, while a new provider might be added that extends DirectProvider but adds in more functionality by addition of services and/or system applications.
Here is a potential example deployment (showing only a single device) with:
- two analytic Edgent applications communicating with each other and the system IoTDevice application
- System IoTDevice application responsible for communicating with the IoT scale message hub
- System monitoring application looking at the running applications and sending monitoring information back to the IoT scale message hub.
- Have a core function be the provider generate a stream of job status events (start, stop, add, pause etc.).
- This can then have any local analytics performed on it as well as a system app to send the events back to the message hub.
- Similarly, have a function which reads registered metrics and generates a stream of metric values. A system app can have a PeriodicSource running this function to send metrics back to the hub.