1.0.0
This release concludes Hono's incubation phase regarding both, development of a consistent feature set as well as learning the Eclipse development process and build-up of a community around Hono.
We have created several 1.0.0 milestones since version 0.9 which mainly focused on
- improving functionality for sending commands to devices connected via (potentially changing) gateways
- finalizing Hono's public APIs, in particular we added an HTTP based standard API for managing the content of the device registry
- removing deprecated functionality like support for the legacy, Graphite based metrics back end
- adding and improving Helm based deployment to Kubernetes as the only supported way of deploying Hono
- support for limiting protocol adapters' resource usage by means of setting limits for the number of connected devices and message data volume at the tenant level
The project leadership certifies that the APIs in this release are "Eclipse Quality".
A security issue in Netty's implementation of the HTTP/2 protocol has been fixed by means of upgrading to Netty 4.1.39.
A lot of work has gone into Hono's documentation. In particular
- We have added support for hosting documentation for multiple (supported) versions of Hono on the project website.
- We have re-written the Getting Started guide to make use of Hono's Sandbox installation instead of a locally deployed Hono instance. This should make the getting started guide much easier to go through for most users.
- We have improved documentation of how to deploy Hono to Kubernetes based on the greatly improved Helm chart that we provide.
Deployment of Hono has been made much simpler by employing the Helm tool. The Helm chart that comes with Hono can be customized by means of setting variables in order to support deployment environments that are more geared towards production scenarios. In particular, the Helm chart can be configured to make use of an existing AMQP Messaging Network instead of deploying and using the example AMQP Network. The chart can also be configured to use an existing (production grade) device registry istead of deploying and using the example registry that comes with Hono.
Support for the Graphite based metrics back end has been removed.
The example Device Registry that comes with Hono now only supports the newly added HTTP based API for managing its content. Support for the original, proprietary API has been removed.
Hono's APIs are based on the AMQP 1.0 protocol which is a released OASIS standard. Authentication of clients is done based on SASL PLAIN as defined in RFC 4616.
Hono comes with protocol adapters which implement the server side aspects of MQTT 3.1.1, HTTP 1.0 and AMQP 1.0 that are relevant for receiving data from clients (devices) using these protocols. Authentication of devices is done based on username/password credentials conveyed by the device as part of the MQTT CONNECT packet or the HTTP Basic Authentication header as defined by RFC 7617.
Internally, Hono's micro-services use JSON Web Tokens as specified by RFC 7519 for authorizing requests from each other.
Hono also provides an HTTP based API for managing the contents of the device registry. The API is defined using the Open API standard which allows for easy creation of clients and skeleton implementations using existing tooling.
The Hono team has been working hard to attract users, adopters and contributors using arbitrary channels.
- On the mailing list (hono-dev@eclipse.org) the committers and contributors discuss fundamental ideas for features and/or implementation alternatives
- On GitHub (https://github.com/eclipse/hono) users can create issues for questions, bugs and enhancements and provide pull requests for improving Hono.
- Some of the committers are speaking at conferences, publishing blog entries and/or articles on the Eclipse IoT Newsletter. We also have done a screencast on the Eclipse IoT Meetup group. Links to these artifactes are available on the project web site
- We have also established a channel on Gitter which is used by the community to discuss issues around Hono. Using a browser based chat system seems to attract users more easily than the mailing list, which requires registration prior to being able to post messages.
Some of Hono's committers are also involved as committers on other open source projects that Hono relies upon, e.g. Apache ActiveMQ Artemis, Eclipse Kura, Eclipse Kapua, Apache Camel, Eclipse Vertx. Due to this fact, we are in close collaboration with these projects, trying to align the overall direction of Hono and particular implementation approaches with these projects.
During the past years we have set up and evolved quite an elaborate continuous integration environment based on the Eclipse and Travis CI infrastructure. We are able to do release builds by means of starting a build pipeline which prevents errors by reducing the required manual effort to a minimum.
Adoption
Hono has been selected by the Eclipse Kuksa project for implementing the cloud connectivity layer for the in-car software framework they are developing. We hope to receive valuable input from the Kuksa community as an outcome of their usage scenarios.
Aloxy, a start-up from Belgium, uses Hono in their customer projects for integrating LoRa based sensors.
Bosch Software Innovations GmbH employs Eclipse Hono as the technical foundation for their commercial Bosch IoT Suite offering.
Red Hat provides IoT features to EnMasse.io, its open source cloud messaging platform, by integrating Eclipse Hono components. The package is also offered commercially as AMQ Online.
Contributors
Over time we have been able to attract some additional contributors from outside of the organizations of the original project committers. In particular we have successfully onboarded a Ph.D. student via Google Summer of Code who implemented the inital AMQP protocol adapter, we receive contributions around support for LoRa WAN from employees of Aloxy and, last but not least, additional documentation has been contributed by Microsoft for setting up a managed Kubernetes cluster on Azure and depoying Hono to it.
Based on the usage of Hono in their commercial offerings, the Bosch product team regularly reports issues and contributes fixes and improvements.
We will also start to contribute to the newly created Eclipse Packages project whose purpose it is to create and host Helm charts for deploying multiple Eclipse IoT components together in order to provide a better Getting Started user experience and to improve re-use of projects. In particular, we will work on a pre-integration of Hono, Ditto and Hawkbit in order provide a full IoT stack, ready to deploy to Kubernetes.