This page describes the high level components constituting an Eclipse Hono™ instance and their relations to each other.
The diagram below provides an overview of the top level logical components.
The MQTT and HTTP Adapters use the Device Registry to authenticate Devices connecting to the adapters and asserting their registration status. The adapters then forward the telemetry data and events received from the devices to the AMQP 1.0 Messaging Network for delivery to Business Applications. Business applications also use the messaging network to send commands to connected devices. Commands are first received by the Command Router and then forwarded to the protocol adapter that is connected to the respective devices.
The Device Registry and the Command Router use the Auth Server to authenticate the protocol adapters during connection establishment.
All interactions between the components are based on AMQP 1.0 message exchanges as defined by the
The diagram below provides an overview of the Mongo DB based Device Registry component’s internal structure.
The Mongo DB based Device Registry component implements the AMQP 1.0 based Credentials, Tenant and Device Registration APIs which are used by Hono’s protocol adapters to authenticate devices. It also implements the HTTP based Device Registry Management API which is used by administrators to provision and manage device data. Clients opening a connection to the Device Registry AMQP Server are authenticated by means of an external service accessed via the Authentication port.
Please refer to the Device Registry user guide for details.
The diagram below provides an overview of the Command Router component’s internal structure.
The Command Router component implements the Command Router API. Clients opening a connection to the CommandRouterServer are authenticated by means of an external service accessed via the Auth port.
The Command Router component uses the Device Registry via the Tenant API and the Device Registration API and is connected to the AMQP 1.0 Messaging Network to receive and forward Command & Control messages as defined by the Command & Control API.
The AMQP 1.0 Messaging Network is not per se a component being developed as part of Hono. Instead, Hono comes with a default implementation of the messaging network relying on artifacts provided by other open source projects. The default implementation currently consists of a single Apache Qpid Dispatch Router instance connected to a single Apache Artemis broker instance. Note that this setup is useful for development purposes but will probably not meet requirements regarding e.g. scalability of real world use cases.
The diagram below provides an overview of the default implementation of the Messaging Network component used with Hono.
Scaling out messaging infrastructure is a not a trivial task. Hono does not provide an out-of-the-box solution to this problem but instead integrates with the EnMasse project which aims at providing Messaging as a Service infrastructure.