Use Case 01 - Get Object Identified by PID

Goal

Retrieve an object identified by PID.

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.

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

1. 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.

2. Data sent to watchers might include: timestamp, object identifier, user id, IP of client.