Service providers

Service providers, attached dirs

SHV use concept of so called providers. Provider can provide values of shv node/device which are not known to node, but has strong relationship to it, for example: history, configuration, visualization, etc. Provider can attach dir to SHV node to provide extra functionality (nodes, methods) if they are not provided by SHV node itself.

Up-tree calls (towards the root)

Provider call with relative path

• foo@bar~:/path - foo provider on broker with ID bar call
• foo~:/path - anonymous first up-tree foo provider call, do not use in production environment, since first up-tree provider might change when some provider connectivity is lost

path is extended by caller node mount-path. Broker root node service is searched for path. If path is not found request is sent to parent broker then to its parent, etc. until it is found.

examples:

+- shv
|  +- my
|     +- device
+- config
|  +- my
|     +- device
|        +- gps
+- history
   ...

• config~:/device.conf my config, absolute path: config/my/device/device.conf
• config~:/gps/device.conf my config gps node, absolute path: config/my/device/gps/device.conf
• sites~:/_files/anca.conf

Access control

Each node has right to read/write it's attached nodes. Requests are forwarded to service provider with access role 'wr'. Note, that service provider path cannot be absolute, it is always relative to caller node mount point.

Provider call with absolute path

same as relative path, but path is not extended by prepending caller node mount path

Use-case: Reading attached nodes of other node

• service@broker123|:/path - provider at broker with ID == broker123 call
• service|:/path - anonymous first upstream provider call, do not use in production environment, since first up-tree provider might change when some provider connectivity is lost

Access control

If service provider path is absolute, then roles of calling sub-broker are used to resolve access rights.

Notes

1. Anonymous service providers calls (without broker-id specified) can be ambiguous in case that some service provider in hierarchy will disconnect from its broker.
   1. This can be solved if all the brokers on the way will resolve request regardless the service provider is connected or not. Each broker has mount table, so it knows if particular service should be present or not.
   2. Other solution is to have .broker@super-id|:/app/providedServices() implemented but this moves discovery logic to the client.
   3. There is one use-case for this. ServiceProviders replicate its sub-tree from master, so it does not matter which one will answer to the RPC request, since responses should be always the same. But I'm still not sure if this should be enough to introduce the feature. Rather not for now.
2. broker-id of first super-broker can be discovered by call: .broker/app/masterBrokerId() on current broker. Calling .broker@master-id|:/app/masterBrokerId() on discovered broker will return ID of the master-id broker master one.

Down-tree calls (experimental)

• foo@bar>:/path/to/the/node - foo provider will be called on first down-tree broker with id == bar
• Slave broker have to somehow translate path from request to it's address space.

examples

1. path: history@mpkbroker>:/shv/pol/ols/mpk/tram/sig/zoneA/anca1
   1. mpkbroker sub-broker is mounted at shv/pol/ols/mpk
   2. mpkbroker sub-broker exports shv/mpk
   3. resolved path on mpkbroker sub-broker: history/mpk/tram/sig/zoneA/anca1

Down-tree calls might be replaced by .local virtual directory in future