Hi,
I'd like to return to the topic of the server platform that has been initially raised by the Bosch team. I've been thinking about the proposal, about the things we already got in Rhiot, and about the things we would like to have in Rhiot in the future.
At this point we would be most interested in the codebase that could be used on the "right" side of the architecture diagram presented by the Bosch team. In particular in:
a) reusable software services
b) custom solution services
By a) I understand reusable software services that can be easily deployed into the PaaS of choice. Runnable out-of-the-box without need for extra code. The example of such service could be a device management service based on Leshan (which is something [2] we are already working on in Rhiot). The other example could be software provisioning service based on Hawkbit (something I'd love to have). In my understanding these services should be designed with horizontal scalability in mind and PaaS- (and Docker-) friendliness. In general by a) I'm thinking about something I can take, deploy into the cloud of my choice, configure using some properties provider and run. Run without extra coding (until some more significant customizations are needed).
By b) I understand a service that will be deployed as the addition to the standard a) services. For us (Red Hat) what would usually be the custom services written by our customers, whom will be using standard a) services (like device management and software provisioning services), but the majority of their application will be custom. While standard a) services should be PaaS-friendly, these b) services can be really anything that uses our a) API.
I believe that the very first thing we need to create in order to start a foundation for our further development efforts, is the "bootstrap API" that would be responsible for the service life-cycle in general, and in particular responsible for:
A. providing configuration access abstraction
B. handling star/stop of the service (aka service life-cycle)
C. providing the "beans registry" i.e. way to access Java objects regardless of the dependency injection engine used by the service developer
Those ABC points are needed to provide the layer of abstraction that would decouple our further efforts from the IoC technology used. This way end-users could use OSGi, Spring Boot, JEE/JNDI, CDI or any other IoC technology of their choice when working with our services and API.
I believe that working together on such "bootstap API" would be the best first step towards the platform, as that would allow us to build the proper abstraction which could be used later for working together on reuseable services (like device management).
As the second step I would propose to discuss the "IoT connector". That should be the second step IMHO, because in the first place we need the proper abstraction (bootstrap API) that will be used to configure and access the IoT connector in the framework-agnostic manner.
What do you think about this approach? As a prototype is worth 1000 words, I will be happy to contribute the initial code for this kind of bootstrap API. Of course if you also believe that it is the right action for the first step.
Cheers!
