Designing Persistency

1. Designing Persistency Delos NoE , Preservation Cluster Workshop: Persistency in Digital Libraries 14. February 2006, Oxford Internet Institute

2. Digital Objects 1 • Digital objects are the core elements a digital library deals with. • For long-term preservation they have to be kept persistent. • Therefore we need DL systems that have the ability to keep digital objects persistent.

3. Digital Objects: Structure 2 • Digital objects are composed entities with a logical structure. Example:

4. Life-cycle of Entities 3 • Persistency appears in the life-cycle of any entity within a digital library.

5. Life-cycle of Entities 4 • The nature of instability of entities appears in the life-cycle of any entity within a digital library.

6. Requirements for the Design of a Persistent DL System 5 • The system should be able to react according to the transient and composite nature of digital library‘s entities. • Entities in digital libraries can be of different nature. E.g., the system should also be able to keep the structure of a collection as well as of a digital object persistent.

7. Requirements for the Design of a Persistent DL System 6 • It also should be able to react as to the common failures which can occur in a complex system. • It should cope with different preservation strategies. • Implementation: The design should be expressed in way that makes implementation of the system and maintenance of it as easy as possible.

8. 7 • This includes for example: • We need a flexibel system that is able to deal with digital objects of any structure. • The overall processing of the changes to the digital object needs to be strictly controlled. • The individual processing steps need to be bundled in line with their functional similarity.

9. 8 • All events that may have an impact on the longevity of digital objects need to be recorded. • Modifying access on digital objects (external or internal) need to be „announced“ to the preservation system. • The design of the system need to be expressed in a flexible, extensible, standardised and widely accepted language.

10. Prerequisites for this Approach 9 • We decided to use the UML for modelling persistent digital library systems. Therefore, the systems which adopt the Preservation Module, must be expressed in UML notation. • The approach suggested here is focused on the implementation of the system, that is a digital library as a software system.

11. Preservation Module 10

12. Preservation Module 11

13. Preservation Module 12

14. Preservation Module 13

15. Preservation Module 14

16. Preservation Module 15

17. Registering Interface 16 • Core tasks: Receiving and forwarding messages that represent a potentially persistency-sensitive scenario.

18. Preservation Module 17

19. Persistency Agent 18 • Core tasks: Interface between the processing units of the Preservation Module and the DL system (‚Gate‘); Delegation of messages; Controlling the message flow to the surrounding system components. • Additional tasks could be: Producing logfiles on activation of the Preservation Module, statistical issues

20. Processing Controller 19 • Heart of the core unit. Unit at the top level of control. • Coordination of the particular over-all processing steps. • Connected to the other functional units of the Preservation Module.

21. Persistency Memory 20 • Unit that encapsulates all preservation-sensitive parameters. • Keeps and administrates a machine-readable list of preservation-sensitive parameters. • Could be realised as a database.

22. Persistency Guard 21 • Unit that controls the execution of basic preservation actions (internal ones, ‚routines‘), like checking if a digital object is physically in good order. • Initiation and controlling of modifications to the Persistency Memory.

23. Object Handler 22 • Interface between the core unit of the Preservation Module and the system unit that is responsible for the storage of the digital objects (repository). • Controls all processing steps which are related to the repository.

24. 23 Core Unitwith exemplary functionality

25. MHU 24

26. Message Handling Unit 25 • Message Handler: • Pre-processing of the message: Obtaining its semantic content. • Deciding whether or not a message is preservation-sensitive. • External Message Handler: Exact semantic interpretation of messages which are forwarded from external units. • Internal Message Handler: Exact semantic interpretation of messages that are forwarded from the inside.

27. Message Handling Unit 26 Message Handling Unit with exemplary functionality

28. PWPU 27

29. Persistency Workflow Processing Unit 28 • Unit of the Preservation Module that controls all actions which concern the modification of the object (workflow). • A workflow is composed of a sequence of smaller workflow units that are encapsulated in the Persistency Workflow class.

30. Persistency Workflow Processing Unit 29 • The Persistency Workflow Handler initiates the workflow process. It also composes the over-all workflow that has to be carried out, according to the messages previously interpreted and forwarded to it. • The Persistency Workflow Controller is responsible for the control of the particular workflow steps.

31. Persistency Workflow Processing Unit 30 PWPU with exemplary functionality

32. Integration of the PM into Existing Systems 31 • The PM is conceived as a software module that has only two interfaces which have to be connected to the DL system. • The first interface, linking the PM via PA to the DL system is called Message Gate, the second, linking the PM to a repository is called Object Gate.

33. 32

34. Integration of the PM into Existing Systems 33 • Step 1: Specification of the interfaces

35. 34 Depending on the analysis of the existing model, there are various possibilities :

36. 35 Step 2: Adding the core unit

37. 36 Step 3: Adding the Message Handling Unit

38. 37 Step 4: Modelling the PWPU

39. 38 Integration of the PM into the conceptual models: EF

40. 39 Integration of the PM into the conceptual models: 5S