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 
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?

Regards,
Kai

-----Original Message-----
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] On Behalf Of Guggemos Dominik (INST/ECS1)
Sent: Thursday, March 03, 2016 8:22 AM
To: hono developer discussions
Subject: 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

Back to the top