Re: [hono-dev] Topology options for client connectivity

[Gordon Sim <gsim@xxxxxxxxxx>]

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] https://github.com/eclipse/hono/wiki/Topology-Options
> [2] https://github.com/eclipse/hono/issues/4

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         |
                   |   -----------
               ____|____|i_
              | 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.