| Re: [iot-wg] IoT backend server platform proposal |
|
Hi Henryk, thanks for picking up the discussion of the IoT Server Platform again
J I have updated the content of our IoT Server Platform wiki [1] to reflect the results of our most recent discussions regarding this topic. In particular,
I have added the whiteboard diagram we have been discussing and have updated the black-box view of the components involved. This now reflects the state-of-affairs which I would like to also use for our discussion during the Unconference of the upcoming EclipseCon
2015 in Ludwigsburg. Regarding your points: I think we agree regarding the relevance and purpose of the “re-usable software services” . From my point of view, creating these will be the
main subject of the IoT Server Platform effort and I think it is these components that we should start to collaborate on. I also agree that Rhiot’s Device Management Cloudlet would be a good candidate for serving as the basis for the LWM2M Protocol Adapter
J So far I haven’t been aware of the importance of the “bootstrap API” as you called it. I would be interested to learn a little more about its relevance
for the overall effort. Could you maybe give an example where such a “bootstrap API” provides the “needed layer of abstraction” as you put it? Or, to put it the other way around, what should we try to avoid when implementing a “re-usable software service”
of the IoT Server Platform to make sure that we can deploy them to arbitrary execution environments? Are you thinking about something like the implementation guidelines described by “The Twelve-Factor App” [2]? From my point of view, the advice given there
could serve as our guiding principles for implementing our “re-usable software services”. [1] https://wiki.eclipse.org/IoT/IoTServerPlatform Regards, Kai From: Henryk Konsek [mailto:hekonsek@xxxxxxxxx]
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! [1] http://rhiot.io -- Henryk Konsek |