Difference between revisions of "Resource Registry Service - Instances Sharing Management"
Luca.frosini (Talk | contribs) (Created page with "TO BE CREATED") |
Luca.frosini (Talk | contribs) |
||
Line 1: | Line 1: | ||
− | + | [[Category: Developer's Guide]] | |
+ | [[Category: Information System]] | ||
+ | {| align="right" | ||
+ | ||__TOC__ | ||
+ | |} | ||
+ | |||
+ | These sections provide information regarding how to interact with [[Resource_Registry Service | Resource Registry Service]] for Entities and Relations instances sharing between Contexts. | ||
+ | REST and JAVA API are presented for each functionality. | ||
+ | |||
+ | Please note that the provided examples can intentionally hide some details in the response to avoid unneeded complexity. | ||
+ | |||
+ | == Instances Sharing Management == | ||
+ | |||
+ | Instances Sharing Management is responsible for sharing between Contexts. It offers the following APIs: | ||
+ | * Add To Context: it allows add an instance to a context; | ||
+ | * Remove From Context: it allows to remove an instance from a context (the Resource Registry deletes the instance when it is available only in the removing context). | ||
+ | |||
+ | |||
+ | The Instances Sharing Management implements the following policies: | ||
+ | |||
+ | * it manages the Header automatically; | ||
+ | * it validates the instance against the schema of the defined type; | ||
+ | * it guarantees propagation constraints. | ||
+ | |||
+ | When the resource registry receives a request to add a resource instance to a context (or remove from a context), it applies the propagation constraints defined in the outcoming relations. | ||
+ | This behaviour can have a "cascade impact" because also the target resource will be added (removed) and so forth. | ||
+ | |||
+ | Any request to add an instance to context has a source context which means that the resource registry analysed only the propagation constraint of the relations belonging to the source contexts. | ||
+ | Hence, sharing an instance from context C1 to context C3 can have a different result than sharing the same instance from the context C2 to the context C3. | ||
+ | |||
+ | |||
+ | == Instances Sharing Collection == | ||
+ | |||
+ | The following table shows the exposed APIs as REST Collection | ||
+ | |||
+ | {| class="wikitable" | ||
+ | ! Operation || HTTP Method || URL | ||
+ | |- | ||
+ | | Add Instance To Context || POST || <code>/sharing/contexts/{CONTEXT_UUID}/{TYPE_NAME}/{INSTANCE_UUID}?operation=ADD[&dryRun=false]</code> | ||
+ | |- | ||
+ | | Remove Instance From Context || POST || <code>/sharing/contexts/{CONTEXT_UUID}/{TYPE_NAME}/{INSTANCE_UUID}?operation=REMOVE[&dryRun=false]</code> | ||
+ | |} | ||
+ | |||
+ | Each operation returns the list of affected instances (both entities and relations) | ||
+ | |||
+ | The service offers the capability of simulating the operation specifying true to '''dryRun''' query parameter. | ||
+ | This is possible thanks to the returned list of affected instances even in dryRun mode. | ||
+ | |||
+ | Security configuration based on [[Authorization Framework]] make this port type accessible only from [[Information System Resource Manager|Resource Manager]]. | ||
+ | In other words, no others client is allowed to manage types rather than [[Information System Resource Manager|Resource Manager]]. |
Revision as of 07:23, 6 July 2021
These sections provide information regarding how to interact with Resource Registry Service for Entities and Relations instances sharing between Contexts. REST and JAVA API are presented for each functionality.
Please note that the provided examples can intentionally hide some details in the response to avoid unneeded complexity.
Instances Sharing Management
Instances Sharing Management is responsible for sharing between Contexts. It offers the following APIs:
- Add To Context: it allows add an instance to a context;
- Remove From Context: it allows to remove an instance from a context (the Resource Registry deletes the instance when it is available only in the removing context).
The Instances Sharing Management implements the following policies:
- it manages the Header automatically;
- it validates the instance against the schema of the defined type;
- it guarantees propagation constraints.
When the resource registry receives a request to add a resource instance to a context (or remove from a context), it applies the propagation constraints defined in the outcoming relations. This behaviour can have a "cascade impact" because also the target resource will be added (removed) and so forth.
Any request to add an instance to context has a source context which means that the resource registry analysed only the propagation constraint of the relations belonging to the source contexts. Hence, sharing an instance from context C1 to context C3 can have a different result than sharing the same instance from the context C2 to the context C3.
Instances Sharing Collection
The following table shows the exposed APIs as REST Collection
Operation | HTTP Method | URL |
---|---|---|
Add Instance To Context | POST | /sharing/contexts/{CONTEXT_UUID}/{TYPE_NAME}/{INSTANCE_UUID}?operation=ADD[&dryRun=false]
|
Remove Instance From Context | POST | /sharing/contexts/{CONTEXT_UUID}/{TYPE_NAME}/{INSTANCE_UUID}?operation=REMOVE[&dryRun=false]
|
Each operation returns the list of affected instances (both entities and relations)
The service offers the capability of simulating the operation specifying true to dryRun query parameter. This is possible thanks to the returned list of affected instances even in dryRun mode.
Security configuration based on Authorization Framework make this port type accessible only from Resource Manager. In other words, no others client is allowed to manage types rather than Resource Manager.