| Re: [hono-dev] Topology options for client connectivity |
Hi,
my initial image of the Hono topology was the "Direct Connection" approach but after following the discussion and thinking about it I tend to prefer the "Dedicated Router" option. I like the idea of not caring about connection handling/security etc. which should get us going more quickly as Kai said, given that we find an appropriate existing router. In fact we are doing something similar here to provide a WebSocket endpoint to our messaging system. Of course this approach adds an extra network hop or even two for messages flowing from solutions to the adapters or vice versa. But I think the advantages outweigh this, if not we should probably go for option 3, "Connection via Message Broker".
Regards,
Dominik
-----Ursprüngliche Nachricht-----
Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Dienstag, 1. März 2016 17:51
An: hono developer discussions
Betreff: Re: [hono-dev] Topology options for client connectivity
That's what I see as the benefit of this approach as well. It also seems easier to implement Hono as an AMQP 1.0 client connecting to the Dispatch Router than implementing it as a server which is responsible for managing the connections securely. If we can offload that responsibility to e.g. the Dispatch Router we might be able to create a first version of Hono a little quicker ...
-----Original Message-----
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] On Behalf Of Gordon Sim
Sent: Tuesday, March 01, 2016 4:47 PM
To: hono developer discussions
Subject: Re: [hono-dev] Topology options for client connectivity
On 01/03/16 15:41, Gordon Sim wrote:
> On 01/03/16 14:24, Hudalla Kai (INST/ESY1) wrote:
>> 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?
>
> From my point of view, yes it is. It is still a relatively young
> project with lots of work ahead. It is already used in production as
> part of Red Hat Satellite.
More generally, if the interface to Hono from the solutions and protocol adapters is AMQP 1.0, then most of the core code implementing that will be the same whether those connect directly to Hono or go via a router.
The benefit of the latter is that Hono doesn't need to focus on the security aspects of having clients connecting to it directly. By using a standard protocol you leave the door open for alternate solutions, and as I say, even having Hono accepting direct connections should still be easy to achieve. So you have lots of flexibility.
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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