Topology Options

The following sections contain options for Hono's overall system topologies. The options mainly differ in the approach taken for connecting clients to Hono and how existing MOM infrastructure is used.

Direct Connection

In this option clients (Protocol Adapters and Solutions) connect directly to Hono (or any of its sub-components) using AMQP 1.0. Hono is responsible for managing the connections and implementing Hono's API. Hono employs dedicated messaging infrastructure for buffering the northbound telemetry data to be delivered to Solutions and for delivering southbound commands to devices connected via Protocol Adapters. It is important to note that one reason for using different messaging infrastructure for northbound and southbound traffic is that in IoT scenarios the telemetry data will most probably be orders of magnitude larger in volume and frequency than the command and control messages.

Main advantages of this approach:

• Full (programmatic) control over connection establishment (and in particular authorization). Hono can dynamically create AMQP sessions and links based on the client's identity and authorizations.
• No additional (remote) communication between Hono and an AMQP protocol router necessary.

Main drawbacks include:

• Requires implementation of AMQP connection management. While we can use existing frameworks for this (e.g. Apache Qpid Proton), there will probably some aspects not covered by the framework used and implementing a spec correctly (even if AMQP 1.0 seems to be written well) is not that easy.

Connection via embedded Router

This is just a variant of the previous option. In this case an embedded router component runs in the same process as Hono and is used for managing the AMQP 1.0 connections with clients.

Main advantages include:

• No need to implement connection management, depending on the router component's capabilities we might be able to leverage the router's Java API to control its behavior at runtime.

Main drawbacks include:

• Approach is limited to using a router component that can be run embedded in a Java process. Potential candidates include ActiveMQ, ActiveMQ Artemis, Qpid Java.

Connection via dedicated Router

In this option clients connect to a dedicated AMQP 1.0 router component which is responsible for managing the connections. Hono also connects to this router component as an AMQP client. The router component forwards API messages from clients to Hono which provides the implementation of the API. Hono leverages existing MOM infrastructure for implementing the northbound telemetry data channel and the southbound command & control endpoints representing the devices.

Main drawbacks include:

• Less control over connection establishment and authorization. This may require the usage of a separate AMQP session for exchanging flow control messages in order to explicitly trigger the dynamic creation of client specific resources.

Connection via Message Broker

This option is similar to the Connection via dedicated Router option with the main difference being that the routing of incoming messages from clients is not done by a dedicated (separate) router component but instead by the same (AMQP 1.0 based) MOM infrastructure that is used for implementing the northbound telemetry data channel and the southbound command & control endpoints representing the devices. Hono's main responsibility in this case is implementing the API.

Main drawbacks include:

• Requires usage of a MOM that supports AMQP 1.0 natively.

Hybrid Connection Model

This option is a hybrid between Connection via dedicated Router and Direct Connection and thus shares their respective advantages and drawbacks.

Telemetry Upload

The following sequence diagram illustrates the flow of messages involved in a Protocol Adapter sending a telemetry data message downstream to a Business Application.

1. Business Application connects to Dispatch Router with user BA and password psst. Dispatch Router successfully verifies credentials.
2. Protocol Adapter connects to Telemetry Endpoint with user PA and password secret.
3. Endpoint successfully verifies credentials using Auth Service.
4. Business Application establishes link with Dispatch Router for receiving telemetry data for tenant TENANT. Dispatch Router successfully verifies that client is allowed to receive data for tenant TENANT.
5. Protocol Adapter establishes link with Telemetry Endpoint for sending telemetry data for device 4711.
6. Endpoint successfully verifies that client is allowed to publish data for device 4711 using Auth Service.
7. Protocol Adapter sends temperature reading for device 4711.
8. Endpoint determines tenant that device 4711 belongs to using Device Registry.
9. Endpoint sends temperature reading to Dispatch Router indicating the tenant and the device the data belongs to.
10. Dispatch Router sends telemetry message to Business Application.

Command & Control

TBD