| Re: [hono-dev] Role of Hono Messaging |
On Mon, 2018-03-05 at 10:09 +0100, Jens Reimann wrote:
> I think keeping at least one example alive would make sense. Not only from a
> point of showing people how it works, but also from a testing perspective.
> Things not tested tend to break at some point ;-)
>
+1 We could set up our integration tests in a way that one protocol adapter
connects to Dispatch Router directly whereas the other connects via Hono
Messaging.
> On Mon, Mar 5, 2018 at 9:59 AM, Maier Daniel (INST/ECS4) <Daniel.Maier4@bosch-
> si.com> wrote:
> > 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 | dan
> > iel.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 | dan
> > iel.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@eclipse.org ] 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@eclipse.org ] 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
> > _______________________________________________
> > 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