Pawn:Receiving Server

THIS IS OUTDATED DUE TO METS DEPRICATION

Overview

The receiving servers are simple servers that contain storage resources, validation resources, and drivers for publishing into an archive. Receiving servers will periodically update the PAWN scheduler with a information regarding it's current state and state of reservations on it. Data on receiving servers are organized into large storage pools. Within these storage pools, individual packages are organized into self-contained reservations.

Reservations and the objects within them also have a simple lifecycle that limits what actions may be performed on an item. items in a reservation transition from ingested to archived. When an item is in any of the states, certain actions may or may not be permitted.

Reservation Structure

PAWN attempts to keep reservations on disk in a form that is as simple as possible, ie human readable. Reservations are organized into a set of related obligations. Each obligation has a set of linked METS documents, metadata, and data objects.

Disk based reservation implementation. A reservation is stored in seperate pieces in a directory. The layout of the reservation follows:

 
   /                           - reservation directory, random name
   | reservation.properties    - global reservation properties
   | /[obligation1]            - files are grouped into self-contained obligations
   | |  obligation.properties  - 
   | |  /manifest              - manifest directory, name randomly generated
   | |  | urn                  - manifest files named by identifying urn
   | |
   | |  /data
   | |  |    /[manifesturn]    - directory named by manifest urn
   | |  |    |  file-id        - files named by ID in manifest document
   |
   | /[obligation2]

A sample reservation directory is shown below:

[toaster@naradev02 pool]$ find reservation-bkqqtloleg/
reservation-bkqqtloleg/
reservation-bkqqtloleg/reservation.properties
reservation-bkqqtloleg/yuyhmwlt
reservation-bkqqtloleg/yuyhmwlt/data
reservation-bkqqtloleg/yuyhmwlt/data/urn:pawn:mets-id.0000000001
reservation-bkqqtloleg/yuyhmwlt/data/urn:pawn:mets-id.0000000001/urn:pawn:file-id.xdb4034b8b6e470a047c587a6dde3e7d2
reservation-bkqqtloleg/yuyhmwlt/data/urn:pawn:mets-id.0000000001/urn:pawn:file-id.x8c0833b1bb88394dbe5976f748201622
reservation-bkqqtloleg/yuyhmwlt/manifest
reservation-bkqqtloleg/yuyhmwlt/manifest/urn:pawn:mets-id.0000000001
reservation-bkqqtloleg/yuyhmwlt/obligation.properties

The properties files are as follows:

• reservation.properties
• edu.umiacs.pawn.reservation.client : authorized client
• edu.umiacs.pawn.reservation.issuer : SAML issuer / manager owning this reservation
• edu.umiacs.pawn.reservation.domain : domain on owning managent server
• edu.umiacs.pawn.reservation.id : external ID of this reservation, used to retrieve reservation

Sample reservation properties file

[toaster@naradev02 pool]$ cat reservation-dgfqcdshge/reservation.properties 
#
#Thu Oct 27 17:13:23 EDT 2005
edu.umiacs.pawn.reservation.client=usgs\:rhextall
edu.umiacs.pawn.reservation.issuer=http\://umiacs.umd.edu
edu.umiacs.pawn.reservation.domain=Geological Survey, United States (USGS)
edu.umiacs.pawn.reservation.id=1130447603852

• Obligation properties
• edu.umiacs.pawn.reservation.obligation.id : management server id of obligation / record set
• edu.umiacs.pawn.reservation.obligation.desc : description of obligation
• edu.umiacs.pawn.reservation.obligation.root : root document for this obligation

sample obligation properties file

[toaster@naradev02 pool]$ cat reservation-dgfqcdshge/rmbycfct/obligation.properties 
#
#Thu Oct 27 17:13:24 EDT 2005
edu.umiacs.pawn.reservation.obligation.id=z14
edu.umiacs.pawn.reservation.obligation.desc=Vector Files
edu.umiacs.pawn.reservation.obligation.root=urn\:pawn\:mets-id.0000000050

Managing Reservations

The ArchiveContext contains a ReservationManager that is used to manage reservations and storage pools. It maintains a list of currently registered reservations and a list of what pool they are currently stored in. It will also take care of creating new reservations and removing reservations.

Lifecycle of Items

The following diagram shows the lifecycle for items in a reservation. This may be either metadata, data, or a manifest.

The following should be assumed. Once an item has been rejected, it may not be archived unless re-approved. If a single item has been rejected in a manifest and the manifest is to be archived. All items except for rejected will still be archived. Once an item is archived, it cannot be changed, however it can be archived multiple times if necessary.

The following web service calls are available depending on the state of the items. As item state is only based on manifest/item level details, operations at the obligation or manifest level aren't affected.

call	INGESTED	REJECTED	ARCHIVED
acceptManifest	-	Y	E
acceptObject	-	Y	E
archiveReservation	Y	E	Y
ingestManifests	Y	Y	E
ingestObjects	Y	Y	E
rejectObject	Y	-	E
rejectManifest	Y	-	E
removeManifest	Y	Y	E
removeObject	Y	Y	E
Y | Y | E

Y - call designed to be used in this state
E - call throws error when manifest or child is in this state
- - call does nothing, or is state agnostic