ServicePath support in queryContext/updateContext NGSI10

[fgalan]

ContextBroker should process the ServicePath header in NGSI10 requests in the way described in this issue The ServicePath header refers to a specific domain to which entities may belong.

E.g: Madrid/BarrioDelPilar/ParqueNorte/Parterre34 could be a specific domain to which some entities (e.g. Tree21, Flower43, Bush28) may belong. Domains are hierarchical (the "/" characters is used for that), thus if Tree21 belong to Parterre34 domain it also belongs to BarrioDelPilar.

An entiy can belong to one and no more than one domain within the domain tree. E.g. if we have Madrid/BarrioDelPilar/ParqueNorte/Parterre34 and Madrid/Moncloa/ParqueOeste/Parterre27 domain hierarchies, Tree21 cannot belong at the same time to Parterre27 and Parterre34.

Entities without domain are also supported (thus backward compability with simple scenarios not needing this schema is assured).

At entity creation time (i.e. updateContext with APPEND on a non existing entity) the NGSI10 request could include a ServicePath header. In that case, the service path is stored in the entiy document at the entities collection, either as subfield in the _id field that stores entity ID and type (if we want to support the same ID/type can repeat in different domains) or as a new field in the document (if ID/type are unique cross-domain).

When querying for entities in the collection (e.g. queryContext or updateContext with UPDATE), if the NGSI request included the ServicePath, it has to be taken into account to select only entities in the right domain. Two comments on this:

• The hierarchy has to be taken into account. E.g. a queryContext with ServicePath: Madrid/BarrioElPilar must cover entities in the Madrid/BarrioElPilar itself and all its subdomains. This could be done taking advantage of regex search in MongoDB.
• Specifiying a list of comma separated domains in the ServicePath must be supported, e.g: queryContext on ServicePath: Madrid/BarrioElPilar, Barcelona/LesCorts should return the entities in both domains.

The requeriments on subscribeContext NGSI10 are described in https://github.com/telefonicaid/fiware-orion/issues/393

Edit: once created, the entity remains all the time in the same domain. Changing the domain of a given entity is not within the scope of this issue (it would be taken into account in a different future issue).

[kzangeli]

Entities without domain are also supported ... I imagine these entities without domain are treated as OK to read/write for ALL (777) ?

[fgalan]

@kzangeli Other option (probably better to simplify things in deployments not using ServicePath at all, e.g. FI-LAB) is to consider a special "null" domain (without hierarchy) for these updateContext/queryContext operations without ServicePath header.

[fgalan]

In order to avoid the length issues we have been discussing in PR #403, maybe we should set some functional limits. E.g.:

• maximum sub-domain (i.e. token between slashes) length: 20
• maximum hierarchy deep (i.e. number of sub-domains): 10
• the same character restrictions used for tenant/services apply

[kzangeli]

Yeah, I've been thinking about the same. However, 20 as max length 'inter-slash-token' I believe is far too much. I know 10 is not much but I would still vote for 10 as maximum. People will just have to abbreviate. The longer the name, the slower the broker ...

[fgalan]

Another constraint: maximun number of ServicePath for the same header in queries: 10

[fgalan]

Implemented in https://github.com/telefonicaid/fiware-orion/pull/422. However, we can not close the issue yet, as documentation in User Manual is pending.

[fgalan]

Documentation in User Manual section: https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide#Entity_service_paths