| Re: [hono-dev] Hono specifications and standards |
Aaron,
even though Henryk has already given you some feedback on your questions, I would also like to share my opinion on some of your points. See below ...
1. Is Hono focused on
- building an IoT server that securely flows messages and execute workload
the former: yes, the latter: no, at least not in a way that Hono provides the execution environment for custom code to be deployed. Execution of workloads could (and should) be triggered by messages flowing through Hono but the workload itself is not supposed to be running "inside of Hono" but on separate systems (provided by others). >From my point of view this is explcitly addressed by what we call "Telemetry ingestion".
- or codifying client payload patterns that can be understood as generically actionable on north and southbound clients. IE – heres a payload that means we want to update our firmware with the attached binary
My take is that Hono should not know anything about the semantics of the message payload. Based on that I do not think that it would be wise to implement a "firmware update process" inside of Hono. If you are looking for an open source component that is able to do that you should take a look at Eclipse hawkBit :-) A system like hawkBit, however, should use Hono to communicate with the devices in order to abstract away communication protocols and location of the devices.2. Will Hono allow multiple applications to run at once in isolation(Co-tenanted, or like Tomcat hosting many Web Applications at once) - I think the answer is yes, and it looks like they are called “Solutions”?We definitely need to update the picture on the project web site :-) Hono only deals with the part on the picture that is labeled "IoT Connector". In fact, that was the "code name" before we decided to call it Hono. Having said that, the "Custom Solutions" you see on the picture are "third party", i.e. they are not part of Hono nor are they deployed to Hono in any way. They simply use Hono's remote API to interact with devices ni a uniform and transparent way. However, Hono itself will definitely be "multi tenant", i.e. it will be possible to associate sets of devices connected to Hono via Protocol Adapters with a "Tenant" and then route messages and authorize access to devices and their data based on that Tenant. In that way multiple solutions can use the same Hono installation/instance while still having their own private view on "their" devices only.3. What does the schema / meta-model of a “Solution” look like?I do not really understand the question but it looks like it is no longer relevant given the previous answer, rigth?
4. I see interesting thoughts about topic level ACL define applied to users and devices. Is the user/device registry intended to be extensible or injectable to third party solutions and auth strategies?We haven't really figured out yet what concepts the authorization model should be based on. From my point of view it should at least be based on device ID and Tenants. Whether this will be mapped to topics is a question of the particular underlying messaging infratructure used, e.g. if we use RabbitMQ or Kafka a "Tenant" might indeed be mapped to a "Topic". However, a clietn connecting to Hono should not bother with Topics but instead use the higher level abstractions provided by Hono, in this case a client should be authenticated as belonging to a particular Tenant and hence be authorized to access data from devices belonging to that Tenant.Whether the user/device registry will be extensible is a question of whether we see any use cases that would require it to be, I guess. So far, I have no such use case in mind but that's why we are interested in attracting more people to the project who can bring in new use cases and ideas :-)If by "injectable" you mean "can be integrated with" then I think the answer should be "yes". It would be nice if Hono could be integrated with e.g. OAuth or maybe SAML or any other token based auth system. Do you have experience in this area or anything particular in mind? We could sure need help in that area :-)5. Is there persistent or at-rest data storage in this design? Maybe something like a session or stateWe explicitly decided against keeping device state out of Hono, except of course the state we need in order to be able to communicate with the device. This includes mostly device meta data, e.g. device ID, model, make, owner etc.I know that many "IoT Platforms" provide such a central device management repository which may contain only the device's current property values (like sensor readings, configuration etc) or even the whole history of data. However, my personal opinion (backed by practical experience) is that most applciations/solutions prefer to include the devices in their domain model which also means having relations with other (non-device) objects. Using an external API for managing the device data makes this hard to implement and also reduces performance accessing data and traversing relations radically.
These questions felt more like belonged on the developer discussion, but I’m happy to do issues in github and remove the noise.I think you have raised some excellent questions and we would be wise to address them on our project web site as well in order to better inform potential users and collaborators from the beginning. Thanks for helping us figuring this out :-)
Full disclosure – ClearBlade is a company that offers a commercial IoT Platform. Any opportunity to contribute ideas and code to the Hono project that helps us all standardize and interoperate would be great for the IoT developer community.That's exactly the reason why we think we should build Hono :-)_______________________________________________From: <hono-dev-bounces@xxxxxxxxxxx> on behalf of Kai <sophokles.kh@xxxxxxxxx>
Reply-To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Date: Sunday, February 28, 2016 at 9:55 AM
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] Hono specifications and standards
_______________________________________________
Hi Aaron,
thanks a lot for your interest! There definitely is opportunity to contribute ideas (and code :-)). All of the ideas we have for the project so far are described on the project home page at Eclipse [1], the GitHub repo issues [2] and the mailing list (which you already seem to have found :-)). Feel free to share your thoughts and/or create issues on GitHub and the mailing list.
We are at a very early stage regarding architecture discussions but it seems settled that we will provide an AMQP 1.0 based API for clients to connect and interact with Hono. It also seems to be agreed upon that we will support multiple "messaging engines" under the hood, in particular I see RabbitMQ and Kafka in that area. Since we also have people from RedHat involved we will probably also support Active MQ (but you should ask for confirmation on the mailing list). We also strive for supporting deployment to runtime environments based on Docker as well as Cloud Foundry.
Cheers,Kai
On Sun, Feb 28, 2016 at 3:58 PM Aaron Allsbrook <aallsbrook@xxxxxxxxxxxxxx> wrote:
_______________________________________________I am very interested in the Hono project and the potential capabilities it offers. I believe there is opportunity for Hono to provide open functionality, and also lead the IoT community in some core application standards.
Specifically things like API specification, securing of messages and application schema export between server instances. Is there any documentation on whats being planned in this space? Is there an opportunity to contribute ideas?
Aaron Allsbrook | CTO | ClearBlade103 E. 5th Street | Austin, TX 78701
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev