Use Case 01 - Get Object Identified by PID¶

Revisions: View document revision history.
Goal: Retrieve an object identified by PID (authenticated or not, notify subscriber of access).
Summary: A client has an identifier for some object within the DataONE system and is attempting to retrieve the referenced object from a node (Member Node or Coordinating Node). If the object exists on the node and the user has READ permission on the object, then the bytes of that object are returned, otherwise an error condition occurs.

A client has an identifier for some object within the DataONE system and is attempting to retrieve the referenced object from a node (Member Node or Coordinating Node). If the object exists on the node and the user has READ permission on the object, then the bytes of that object are returned, otherwise an error condition occurs.

This low level operation assumes that the client knows that the desired object is available on the target node. The normal process for retrieving an object given only the identifier is to first resolve the object, then retrieve the object from one of the identified nodes. Resolution is described in UC36.

Actors

Client requesting object
Coordinating Node
Member Node

Preconditions

Client has authenticated to the desired level (e.g. client may not have authenticated, so access might be anonymous).

Triggers

An object is requested from the DataONE system.

Post Conditions

The client has a copy of the object bytes (or an error message in the case of failure)

The node event log is updated with the results of the operation

Watchers are notified of the event.

Figure 1. Use case 01 diagram showing actors and components involved in this action.

Figure 2. Sequence diagram for Use Case 01 illustrating the sequence for retrieving an object identified by a PID from the DataONE system. No distinction is made between Member Node and Coordinating Node implementation as they are identical at this level of detail.

Notes

For the GET operation, should isAuth() be performed only by CNs? Relying on the MN system metadata requires trusted implementation of the MN system and consistency of system metadata across all MNs (which will be the case, though with uncertain latency). Requiring all isAuth() operations to be performed by CNs will increase trust in the operation (assuming the operation is not spoofed by a MN) though will increase load on CNs. This should be specified in the Authorization use case.
Data sent to watchers might include: timestamp, object identifier, user id, IP of client.