| Re: [hono-dev] Role of Hono Messaging |
Hi,
during the last days I have given Hono Messaging and its role it plays within
Hono some thought. During Bosch Connected World I was talking to Dejan and he
mentioned that it might be a good idea to try to simplify Hono's system
architecture, making it easier to deploy and maintain. Given that there's always
room for improvement, Dejan proposed to co-locate an instance of Hono Messaging
with each instance of the protocol adapters so that we potentially could
eliminate the need of separately deploying Hono Messaging altogether and save one
network hop required for messages flowing downstream.
At first I was a little skeptical but after having given it some thought, I find
the idea very appealing and in the meantime I have made some experiments which
lead me to believe that we should be able to get rid of Hono Messaging in many
cases altogether.
After we had introduced separate service implementations for Device Registration
and Credentials, the main purpose of Hono Messaging had been to validate the
registration assertions issued by Device Registration in order to make sure that
a protocol adapter does not publish data for arbitrary devices that it is not
authorized for. This problem mainly exists for custom protocol adapters which
have been created by third parties. The Hono protocol adapters are built to
always check with Device Registration whether a device exists, is enabled etc.
This means that the Hono protocol adapters already perform all necessary checks
and validations and the additional step of routing the downstream messages
through Hono Messaging in order to validate the assertion does not add any value.
FMPOV in this case, the protocol adapter(s) could as well connect directly to the
downstream AMQP 1.0 Messaging Network (e.g. the Dispatch Router) without loosing
any functionality or security/privacy. The protocol adapters would still get a
registration assertion from Device Registration in order to check for the
device's existence and registration status. However, it would not include the
assertion in the downstream message to be forwarded to the AMQP 1.0 Messaging
Network.
In a system setup that contains custom protocol adapters provided by third
parties, though, those protocol adapters should still be required to always go
through Hono Messaging in order to make sure that the protocol adapter is
actually allowed to accept and forward data received from the devices that it
forwards data for.
Based on this, IMHO we can greatly simplify the overall system architecture,
reduce latency of individual messages traveling downstream and last but not least
also can increase throughput because we get rid of the (costly) validation of the
registration assertion if the message has been received via one of Hono's
original protocol adapters.
WDYT?
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Ullsteinstr. 128
12109 Berlin
GERMANY
www.bosch-si.com
Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB
148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors:
Dr. Stefan Ferber, Michael Hahn
_______________________________________________
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