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


I have a question though: do you consider using the Dispatch Router a good idea for our purposes? In particular this also implies: is the Dispatch Router ready for production from your point of view?


-----Original Message-----
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] On Behalf Of Gordon Sim
Sent: Tuesday, March 01, 2016 11:39 AM
To: hono-dev@xxxxxxxxxxx
Subject: Re: [hono-dev] Topology options for client connectivity

On 01/03/16 09:27, Hudalla Kai (INST/ESY1) wrote:
> Hi,
> I have created a Wiki page providing an overview of three options for connecting clients to Hono [1]. My understanding is that we have already started to "implicitly" discuss these options as part of previous threads on the mailing list.
> Personally, my original idea was to take the "Direct Connection" 
> approach. I was therefore looking for ways how to easily implement an AMQP 1.0 server. However, after following the discussion on the mailing list and this GitHub issue [2] I realized that there are other options as well :-) I now find the "Dedicated Router" approach most appealing. This way we could leverage an existing component for managing client connections (which might become a tedious task) while still having maximum flexibility regarding the MOM infrastructure to use for telemetry and command & control channels.
> What do you guys think?
> [1]
> [2]

That is a very helpful page! If you draw the 2 and 3 diagrams slightly differently, the differences between them are not so great. Forgive the crude ascii diagram, hopefully it conveys the point:

  ---------      ---------------------      ---------
|    A    |__f_|   B                 |__g_| C       |
|         |    |                     |    |         |
  ---------      ---------------------      ---------
                    |   -----------
                   h|  | E         |
                    |   -----------
               | D          |
               |            |

A - protocol adapter
B - infrastructure 1
C - solution
D - Hono
E - infrastructure 2

So here if E is RabbitMQ and B is an AMQP router, you have option 2 on your wiki page. If E and B are both ActiveMQ (even the same instance) then you have option 3.

The point I'm making is that the key is to define the interfaces to the infrastructure, i.e. f, g, h and i above, and then providing the interface is adhered to, different topologies can be deployed that all offer Hono's capabilities and the protocol adapters to services.

So Hono has two interfaces, h and i above, and it needn't care what is behind them providing whatever it is adheres to the protocol/interface as defined. I think defining these interfaces in more detail will be a useful activity early on.
hono-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top