Of course, that should always be possible. But isn’t that a given if we agree to expose Hono’s (messaging) interface using AMQP 1.0? I mean, an
AMQP 1.0 client can send any message it would send to Hono also to generic AMQP 1.0 message broker, can’t it? The result of sending that message might be different though, depending on what the consumer of that message does with it, right?
Regards,
Kai
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx]
On Behalf Of Henryk Konsek
Sent: Thursday, February 25, 2016 11:59 AM
To: hono developer discussions
Subject: Re: [hono-dev] Let's get started
I would just be careful with assumptions that we should always connect to EvenDispatcher. I can imagine situations when for example Red Hat customers would like to use protocol adapters and let's say our device
management capabilities, but at the same time they would like to use broker-native features for managing ACLs. I think we should be careful with this kind of commitments.
I think it should be possible to treat EventDispatcher as an optional component. Which can give you for example ACL features out of the box, without relying on the messaging/broker features to achieve it. However
for some scenarios people would like to rely on their broker-specific features for this and we should also respect that IMHO.
Thanks Kai, that makes total sense. I overlooked that part of the story for a moment.
On Tue, Feb 23, 2016 at 12:13 PM, Kai <sophokles.kh@xxxxxxxxx> wrote:
Glad you're still motivated and on board ;-)
I guess for the AMQP 1.0 infrastructure the clients can connect directly. For others (Rabbit, Kafka, Reddis, …) we can create a server (based on Vertx for example) that can convert messages to the appropriate
format.
From my point of view Hono adds more value than just an AMQP 1.0 interface facade. Instead, it should also be able to authenticate and authorize clients to connect and send messages to devies and/or receive data
pushed upstream from Protocol Adapters. My idea is that Hono is not a _generic_ message broker but instead provides messaging capabilities targeted at the specific requirements when connecting millions of devices to cloud applications. For that, Hono also
needs to be aware of device identities and ownership information about the devices in order to enforce privacy etc. I therefore think that clients will _always_ connect to Hono even if the underlying messaging infrastructure also speaks AMQP 1.0. That will
only make it easier for us to implement the facade :-)
_______________________________________________
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
|