[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Role of Hono Messaging
|
Hi,
I also like the idea. Reducing complexity where possible is always a good thing. However, I think it would still be useful to have an example “custom” protocol adapter to show people how to do things for custom protocol adapters.
Mit freundlichen Grüßen / Best regards
Daniel Maier
Cloud Services LWM2M (INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com
Tel. +49 711 811-58392 | Mobil +49 0173 6056415 | Fax +49 711 811-58200 | daniel.maier4@xxxxxxxxxxxx
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
Mit freundlichen Grüßen / Best regards
Daniel Maier
Cloud Services LWM2M (INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com
Tel. +49 711 811-58392 | Mobil +49 0173 6056415 | Fax +49 711 811-58200 | daniel.maier4@xxxxxxxxxxxx
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
-----Ursprüngliche Nachricht-----
Von: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] Im Auftrag von Frank Karsten (INST/ECS4)
Gesendet: Montag, 5. März 2018 09:57
An: hono developer discussions <hono-dev@xxxxxxxxxxx>
Betreff: Re: [hono-dev] Role of Hono Messaging
Hello all,
This makes much sense to me - and I think on our "journey" to a high-performance, massive scalable messaging architecture it will be important to reduce complexity.
FMPOV we do not need Hono Messaging for the Hono protocol adapters anymore, the only things we would loose seem to me:
- the central metrics about the messages that flow through the system (but this will be available per protocol on a more fine grained level anyway)
- a central point where plugin mechanisms in the future could be attached (but this would be better realized as north bound applications anyway)
So, I think this will definitely improve Hono.
The reduction of latency AND the reduction of network traffic AND the reduction of the number of JVMs running: worth the change!
Would we provide deployment configs for Hono in flavours then, like:
- "standard" (no HonoMessaging started)
- "custom PA ready": (HonoMessaging started and ready to bind custom PAs to) ?
Mit freundlichen Grüßen / Best regards
Karsten Frank
(INST/ECS4)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn
-----Original Message-----
From: hono-dev-bounces@xxxxxxxxxxx [mailto:hono-dev-bounces@xxxxxxxxxxx] On Behalf Of Hudalla Kai (INST/ECS4)
Sent: Montag, 5. März 2018 09:05
To: hono-dev@xxxxxxxxxxx
Subject: [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
_______________________________________________
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
