Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Topology options for client connectivity

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. 

On Mon, Mar 7, 2016 at 4:50 PM, Hudalla Kai (INST/ESY1) <Kai.Hudalla@xxxxxxxxxxxx> wrote:
> You would also need some way to have Hono be able to indicate to the
> 'clients' (i.e. protocol adapters and solutions) if authorisation fails
> (i.e. you need to be able to signal to some extent in both directions).

Exactly, we would basically re-implement the link establishment process on top of established links using AMQP 1.0 messages ... feels kinda strange to me.

> > It seems to me that this approach would not require a dedicated
> "signaling queue/resource" as described above but would enable Hono to
> dynamically react to a client's Link establishment request, right?
> That is correct, yes. From Hono's perspective, the link establishment
> in this approach would be the same as if the client had connected
> directly to Hono.

This looks more appealing to me at least.

> > However, this might also be possible by plugging in to a broker to
> achieve the same thing but I am not an expert with the brokers under
> discussion (e.g. ActiveMQ, RabbitMQ).
> I am not an expert either, but for those two brokers at least I very
> much doubt it.

And even if this were possible it would basically mean that we need to deploy a broker specific version of Hono to a broker which doesn't feel right to me.

So, to me the main question is whether we want to "afford the luxury" of using a dedicated signaling resource/queue or instead want to be able to control link establishment and thus directly leverage the information exchanged as part of the link establishment process.

Personally, I am much in favor of the latter because it seems to have the potential of providing a cleaner API that doesn't rely on separate sequential message exchanges to get data flowing.

hono-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Dejan Bosanac

Back to the top