Hi Kai,
in my view, the most valuable thing Hono can provide would be a protocol-level API that is used by devices (protocol adapters) and services. For example, that API would define the structure of the AMQP message for the telemetry use case. Than devices and services can produce/consume those messages no matter of the which infrastructure is used (beyond the original AMQP connection). That would allow multiple implementations, based on the end-user preferences. For example, it can be a single AMPQ broker, a complex scalable AMQP infrastructure based on network of routers and brokers or a combination of the router as an AMQP endpoint and other MOM (Kafka) using an appropriate protocol conversion.
If we define things like this, then there’s no need for a single “Hono process”, but we can see if there is a need for Hono “system services” based on the supported use cases. We can provide an implementation for these services, but they need to communicate with the MOM using the well defined AMQP API, just like the end user services.
We can also provide the “reference implementation” that will include working out of the box deployment for people to work with.
So just to summarize, in this case MOM is responsible for connection handling, connection level security, routing and all the things that MOMs are doing normally. The Hono compatible solution will additionally need to “implement” Hono AMQP API, that allows connecting devices and services to the MOM.
To answer your questions for the preferred brokers, from our side Dispatch Router and ActiveMQ Artemis are technologies that we’re interested in implementing Hono API with.
I hope this makes some sense and I’m looking forward to hear your thoughts.
