Major changes to the PAWN architecture

Producer Role

The producer manager is changing roles to be tied closer to an archive. A producer manager is now viewed as a tracking server for packages and is responsible for their well-being until they are converted/accessioned into a persistant form. In the case of NARA, packages may stay on a producer for months or years after a client initially pushes. In the old model, the producer manager merely tracked metadata for packages and provided oversight prior to delivery to an archive.

A producer only becomes aware of a package after a client starts pushing it into a receiving server. In testing w/ NARA, the old oversight role tended to get in the way more than help organize transfers. The only job a producer has prior to clients pushing data to an archive is to provide authentication for clients, and supply a list of allowed packages/record sets that a client can fill out.

After a package arrives, any editing or changes that need done, will be managed by the management server.

Record Set

Instead of creating packages that are attached to points in a hierarchy, clients will instead fill out predefined package or Record Set. Record Sets will be composed of broad obligations that a client will load data into. From a client, this will feel like the old setup except attachment points will have minimal predefined structure, and related data will all be in one package/attachment point.

Clients

Clients will still be issued from a producer, but will be limited to submitting data and appending to pre-existing submissions if allowed. They will be able to build pre-defined packages.

Receiver Server

As a result of the changing role of producer managers, receiving servers will be slightly more coupled with the manager. Receiving servers will update managers with what has been uploaded, and how it can be accessed for validation and accessioning. The receiving server will be moved into a role that servers as a gateway to accessioning processes with the producer tracking these processes.

Accounts/users

Accounts within a domain are organized into Roles or groups of accounts with the same function. An account can belong to multiple Roles. Any context related to the organization is stored at the role level rather than account level. Similiarly all allowed Record Sets are attached to roles and not individual accounts. An account must belong to a Role to perform any operation.

An example of a Role could be an office in an organization. IE, the IT department of an Agency, another could be a personal office. In lab environments, roles may be related to types of jobs, lab rats may all be grouped together.

-- MikeSmorul - 08 Jun 2005
to top