Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Adapt Telemetry/Event API to reflect removal of Hono Messaging

Just thinking what’s their purpose now, if they are not checked anywhere in the system. Protocol adapters and device registry have established trust through authorization, so adapters can trust responses from the registry without a token. 

On Mon, Nov 5, 2018 at 5:12 PM Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx> wrote:
On Mon, 2018-11-05 at 16:56 +0100, Dejan Bosanac wrote:
>
> On Mon, Nov 5, 2018 at 4:20 PM Hudalla Kai (INST/ECS4) <
> kai.hudalla@xxxxxxxxxxxx> wrote:
> > On Mon, 2018-11-05 at 16:06 +0100, Dejan Bosanac wrote:
> > > I’m probably missing something, but I can’t find where we deprecated it.
> > The
> > > release notes states that adapters now “can” connect directly and that’s
> > about
> > > it. And the original discussion thread is left with the note that we should
> > > keep it for this use case.
> >
> > I agree that we could have made it more explicit, but the review information
> > for
> > 0.7 [1] actually states that we are deprecating it (End of LIfe section).
> >
> > [1] https://projects.eclipse.org/projects/iot.hono/releases/0.7/review
>
> As I said, I probably missed something :)
> Then I guess, with removing it from the docs (APIs) as you suggested is all
> that is left to be done.

> > >
> > > I’m not against deprecating it. We’re losing “external adapters” use case,
> > but
> > > no one is interested in that at the moment, so one less bit to maintain.
> >
> > I do not think that we are losing the "external adapters" use case. We are
> > only
> > relying on the AMQP Message Network's ability to properly authorize the
> > adapters.
> > instead.
>
> Sure, the only thing is that in this case protocol adapters are trusted to do
> all the work regarding authenticating and authorizing devices, right?
> Wonder if in this case device registration assertion tokens play any role in
> the system anymore?
>

You mean, in this case we could also stop issuing the (costly to create) JWT
tokens altogether, right?

> > > If there’s a consensus that we should do it, let’s make more explicit in
> > docs,
> > > release notes and code.
> > >
> > > On Mon, Nov 5, 2018 at 1:10 PM Hudalla Kai (INST/ECS4) <
> > > kai.hudalla@xxxxxxxxxxxx> wrote:
> > > > On Mon, 2018-11-05 at 12:20 +0100, Dejan Bosanac wrote:
> > > > > Hi,
> > > > >
> > > > > I agree that current definitions could be confusing for the people
> > coming
> > > > first
> > > > > time to the project and seeing components that are not used (much)
> > anymore.
> > > > > IIRC we agreed that we’ll keep Hono Messaging service for the cases of
> > > > > external/custom protocol adapters. Are we still planning to do so?
> > > >
> > > > Well, we have deprecated Hono Messaging with 0.7 and I would rather
> > remove it
> > > > from Hono <= 1.0 altogether ...
> > > >
> > > > >  If yes, then maybe we can:
> > > > >
> > > > > * change API definitions as Kai suggested, as from the APIs perspective
> > > > “Hono
> > > > > messaging” isn’t important anymore
> > > > > * document “Hono messaging” component as an optional part of protocol
> > > > adapters
> > > > > and how it can be used in a setup with external protocol adapters.
> > Maybe we
> > > > can
> > > > > have a separate page about protocol adapter basic architecture?
> > > > >
> > > > > On Mon, Nov 5, 2018 at 11:12 AM Hudalla Kai (INST/ECS4) <
> > > > > kai.hudalla@xxxxxxxxxxxx> wrote:
> > > > > > Hi list,
> > > > > >
> > > > > > when we originally created the Telemetry and Event APIs, we did not
> > (yet)
> > > > > > have
> > > > > > the clean separation between Hono and the AMQP Messaging Network.
> > This
> > > > was
> > > > > > also
> > > > > > reflected in the API definitions, e.g. the southbound operations
> > (used by
> > > > > > protocol adapters to send data downstream) referred to "Hono's
> > > > > > Telemetry/Event
> > > > > > endpoint" when if fact the protocol adapters connect to the AMQP
> > > > Messaging
> > > > > > Network (because there is no Hono Messaging anymore). The same
> > applies to
> > > > the
> > > > > > northbound operations. IMHO we should therefore adapt the APIs and
> > > > explicitly
> > > > > > mention the AMQP Messaging Network as the container that the adapters
> > and
> > > > > > downstream consumers need to connect to. In the end, all we are doing
> > is
> > > > > > defining
> > > > > > a set of addresses and properties for sending/receiving messages "the
> > > > Hono
> > > > > > style"
> > > > > > (which has a lot of value in my opinion) over the AMQP Messaging
> > Network.
> > > > > > However, I think it would help with making the responsibilities of
> > the
> > > > > > Protocol
> > > > > > Adapters vs. the AMQP Messaging Network more explicit.
> > > > > >
> > > > > > 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://www.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://www.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://www.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://www.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://www.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://www.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://www.eclipse.org/mailman/listinfo/hono-dev


--
Regards
--
Dejan Bosanac
http://sensatic.net/about

Back to the top