Re: [hono-dev] Redundant(?) properties in API messages

["Hudalla Kai (INST/ESY1)" <Kai.Hudalla@xxxxxxxxxxxx>]

HI,

following up on the addressing scheme we started to discuss yesterday, we now seem to run into some (current) limitations of the Dispatch Router.

Assume a protocol adapter that sends a telemetry message to Hono using e.g. the following address for the message's "to" field: telemetry/myTenant/myDevice
Hono will extract the tenant and device from the address and add the "tenant-id" and "device-id" message annotations to the message and then forward the message to the Dispatch Router.

An application that wants to receive all telemetry data for tenant "myTenant" would create a receiver link with the Dispatch Router using source address "telemetry/myTenant". It seems that the Dispatch Router (currently?) has no way of configuring it to route all messages having an address starting with "telemetry/myTenant" to a receiver with a matching link source address, or does it?.

@Gordon: Are we missing something here? Can the Dispatch Router be configured to support this (yet)?

On a sidenote: if we want to support assuming a DEFAULT_TENANT then we also need to make sure that the Dispatch Router understands this semantics as well, i.e. if an application creates a receiver with source address "telemetry/" then it must make sure that the application gets all messages having an address starting with "telemetry/DEFAULT_TENANT". Again, I have no clue if and how the Dispatch Router can support this ...

Kai
________________________________________
Von: hono-dev-bounces@xxxxxxxxxxx [hono-dev-bounces@xxxxxxxxxxx]" im Auftrag von "Gordon Sim [gsim@xxxxxxxxxx]
Gesendet: Dienstag, 26. April 2016 16:29
An: hono developer discussions
Betreff: Re: [hono-dev] Redundant(?) properties in API messages

On 26/04/16 12:45, Guggemos Dominik (INST/ECS1) wrote:
> Hi all,
>
> Kai and I are having a Hono “hackathon” this week and we were just
> reflecting on how we transport information required for routing and
> authorization decisions. This is currently the name of the endpoint
> (e.g. telemetry, control, registration, …), the /tenant-id/ and the
> /device-id/. Now this data is scattered across several fields in a
> message (link’s source/target address, the /to/ property, /tenant-id/
> header, /device-id/ header) which is redundant and might be confusing to
> a user. So one suggestion would be to have this information in a single
> field and extract relevant data from there and add headers for routing
> in the backend where required.
>
> Example: For telemetry upload, the single source of information would be
> the /to/ property of a message: //telemetry/${tenant-id}/${device-id}.
> /There would be no more tenant-id or device-id header in the message
> received from clients, but if we need the information in a separate
> header e.g. for routing, we can add this in our Hono service.
>
> This way we would have less redundancy and less confusion. This would
> also play nicely with an authorization based on these resources e.g. to
> allow upload of telemetry data for /${device-id} /which belongs to
> /${tenant-id}/, you would give permission WRITE on resource
> //telemetry/${tenant-id}/${device-id}/. Same would apply for telemetry
> consumption (READ on resource //telemetry/${tenant-id}) etc./
>
> What do you think?

Sounds reasonable to me.

_______________________________________________
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