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

["Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>]

Gordon,

Thanks for the reply, I agree 100% with your conclusions :-)

The only reason I drew them as two options was to make sure that we do not a priori _assume_ (or even _require_) B and E (as used in your ASCII art ;-)) to be the same thing. They might be, as you pointed out, and this case is explicitly supported by the fact that we define h and i based on AMQP 1.0.
So, the _role_ of B is always that of a router for messages Hono is supposed to exchange via its interface h while the _role_ of E is always providing infrastructure required by Hono by means of interface i.

I would also like to hear some more feedback from Henryk et al. (Dominik?, Dejan?) before we settle for this as our "guiding" picture for our further work, ok? 

Regards,
Kai

-----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] 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.
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/hono-dev