The Storage Commitment Service enables a user agent to request the safekeeping of Instances on an origin server. It corresponds to the DIMSE Storage Commitment Service Class as defined in Section J “Storage Commitment Service Class (Normative)” in PS3.4 and has the same semantics.
As committing to storage of Instances is often a long-running operation on the origin server, the use of this service may be split into two transactions, at the discretion of the origin server: 1) requesting the commitment, and - when the origin server cannot give the result yet - 2) checking for the result, in line with the Asynchronous Request-Reply (ARR) pattern [Ekuan].
Note
A PACS may wait with a response to the storage commitment request it receives, for instance until the VNA that it uses for long term storage has given commitment for the referenced Instances.
Figure 13.1-1 shows the possible scenarios of requesting storage commitment.
This starts when the user agent sends a Request to the origin server. This requests the origin server's commitment to safekeep a set of SOP Instances, specified by their respective UIDs.
In case the origin server responds to the Request with Done, it behaves synchronously and returns, for each Instance, whether it commits to safekeeping that Instance or not. The user agent can handle this result appropriately, for example by deleting the local copies of the Instances that now are safely kept by the origin server.
In case the origin server responds to the Request with Working, it behaves asynchronously, and is working on the request. In this case, the user agent needs to perform a Result Check after some time. When this check is performed, the origin server may respond with Done, and will provide the same kind of result as in the synchronous case, which can be handled in the same way by the user agent. The origin server may also respond to the Result Check with Working, which will trigger the user agent to perform a Result Check again. This process continues until the origin server responds with Done, finalizing the process.
For both the Request and the Result Check it is also possible that the origin server returns an error, and this also needs to be handled appropriately by the user agent; see Table 13.4.3-1 and Table 13.5.3-1 for more details.
There is one resource defined by this service:
The origin server shall support Query Parameters as required in Table 13.1.2-1.
The user agent shall supply in the request Query Parameters as required in Table 13.1.2-1.
See also Section 8.4.
The origin server shall support the media types specified as Default or Required in Table 13.1.3-1.