Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
0.5
This is the initial release of Eclipse Hono with a strict focus on providing functionality for devices to publish Telemetry data and Events for consumption by applications connected to Hono.
Devices can publish data to Hono using MQTT and/or HTTP. Eclipse Kura gateways can publish data to Hono using Kura's standard MqttDataTransport. The arbitrary transport protocols for interacting with devices are implemented by Protocol Adapters. Hono comes with an MQTT, a HTTP and a Kura Protocol Adapter out of the box. Users can extend the range of supported transport protocols by implementing a custom Protocol Adapter and integrating it with the Hono back end services.
When a device connects to a protocol adapter, Hono verifies the device's identity by means of username/password credentials thus establishing the source of the data being published. Consuming applications can then be sure that the data they receive really originates from the indicated device.
The APIs between the protocol adapters and Hono as well as the consuming solutions and Hono are defined in AMQP 1.0.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
From an architectural point of view, the focus of this release is to create the inital version of the external AMQP 1.0 based APIs for interacting with Hono and to establish the Docker container based micro-service architecture used to implement Hono's functionality.
Using this approach, each of Hono's (micro-)services can be scaled out horizontally independently from each other. There are, of course, certain restrictions regarding the capcity of individual services for processing requests. For example, a single instance of Hono Messaging can process only that many messages sent by protocol adapters which results in a certain overall ratio between protocol adapter instances and Hono Messaging instances.
Users can implement custom protocol adapters in order to support transport protocols that Hono does not support out-of-the-box. Integration with Hono is done based on the public (AMQP 1.0 based) APIs of Hono's micro-services. Over time, the number of protocol adapters included with Hono is expected to grow, based on user contributions and evolving trends in IoT device protocols being used.
Hono's APIs have been designed to support end-to-end flow control between devices producing data and the back end applications consuming the data. In particular, AMQP 1.0 has been chosen as the transport protocol because of its inherent support for explicit flow control and propagation of back pressure, making sure that the system never accepts data from devices that it cannot process or offload to a downstream consumer.
There are no security issues known at the time of this writing.
Hono comes with a set of documentation in the following areas:
- A Getting Started guide that is supposed to get users up and running with a simple (single instance) local deployment of Hono running on Docker Swarm.
- Guides for deploying Hono to Kubernetes and OpenShift
- Information regarding the usage and configuration of Hono's individual micro-services.
- Extensive documentation of Hono's AMQP 1.0 based APIs
- User guides illustrating the usage of Hono's public APIs.
- Descriptions of Hono's underlying architectural concepts.
Hono itself does not include any components that are intended to be used by interactive users via e.g. a web UI. Instead, Hono provides a set of APIs that are intended to be used by application developers for interacting with Hono's services. These services include the upload of Telemetry data from devices, consumption of data in back end applications and the registration and management of device identities and credentials used for authenticating devices.
Since this is the first release of Hono, there are no deprecated or removed features (yet).
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.
The protocol adapters that come with Hono implement the server side aspects relevant for receiving data from clients (devices) of MQTT 3.1.1 and HTTP 1.0 respectively. 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.
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.
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.
- Log in to post comments