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

On 04/03/16 15:26, Hudalla Kai (INST/ESY1) wrote:

I have been thinking about the topology options some more and I would like to share my concerns and open questions with you. I have added another "Connect via embedded Router" option to the wiki page [1] and pointed out some pros and cons for most of the options.

I currently think that the "Connect via embedded Router" would be most suitable because it has both most of the advantages of the "Direct Connection" as well as those of the "Dedicated Router" option.

While doing my homework regarding the implementation options for such an approach I stumbled across the following three message brokers from the Apache universe:
- ActiveMQ
- ActiveMQ Artemis
- Qpid Java

Maybe somebody from RedHat (Dejan, Gordon, Henryk?) can point out some of the important differences between them? I would also be interested in your opinion regarding which of them would be most appropriate for usage as an "embedded router" within Hono. Or do you think that an embedded approach doesn't make sense at all?

All of those can be used as embedded *brokers*. I am not an expert on any of them, but I don't believe they can at this point in time be used as embedded AMQP 'routers'.

The issue really is how message acknowledgement works. Having a broker between two communicating entities usually implies a store-and-forward semantic. I.e. the publisher of the message gets an acknowledgement when the broker accepts (and has persisted or replicated) the message, not when the consumer of the message has acknowledged it. When using an embedded broker, one of the communicating entities has the broekr in-process, but would still typically be communicating with via a store-and-froward semantic. (The 'protocol' used by the embedded client just doesn't involve any network communication, it is all in memory).

In the diagram for 'Connection via embedded Router' this would mean that there are two stages for store-and-forward. Once in the process containing Hono and the embedded 'router' (aka broker), and once in RabbitMQ. It also means that the scalability, availability and fault-tolerance of the system is dependent on that of that embedded broker+hono process.

By contrast, a 'router' would not introduce an extra store-and-forward step. Specifically considering the Apache Qpid Dispatch Router, you would probably want to use it in link routed mode. This means that when the solution or protocol adapter establishes an AMQP link (i.e. a sender or a recover) to the system, that link establishment would be propagated through to the Hono process. In effect a virtual link would then be established between the solution/protocol adapter and the Hono process. Message and their acknowledgements would then be passed over this virtual link. If the solution/protocol adapter sends a message, they will not get an acknowledgement of that until the Hono process accepts the message (which can be tied to receiving an acknowledgement from RabbitMQ). Likewise in the other direction, when Hono sends out a message, it will not get an acknowledgement until the solution/protocol adapter receiving it confirms receipt. If either side fails, the other side is notified of this as their link is detached. (Store-and-forward is designed specifically to shield the end points from knowing about each others availability).

You can have multiple routers arranged in a network for scale and resilience, and they do not require strongly consistent state.

Back to the top