[
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:
Guys,
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.
