AONS

From APSRWiki

Contents 1 Automatic Obsolescence Notification System (AONS) 1.1 Terms 1.2 Project Team 1.3 Project Plan 1.4 Related Projects 1.5 Workshops 1.6 Documentation 1.6.1 Why Are We Building AONS II? 1.6.2 What Is AONS II? 1.6.2.1 Deployment Modes 1.6.2.2 Adapter Pattern Usage 1.6.3 How Are We Building AONS II? 1.7 Tasks Remaining

[edit] Automatic Obsolescence Notification System (AONS)

The National Library of Australian (NLA) and Australian Partnership for Sustainable Repositories (APSR) are working on a software development called the Automatic Obsolescence Notification System (AONS). This work is refining the first AONS version, a prototype developed in an earlier stage of APSR in 2006, to a platform-independent downloadable tool that automatically provides information from authoritative international registries to support decisions on preservation action required to retain access to information resources stored in a range of repository types. AONS version two is designed to enable users to be informed when file formats that exist in their repositories are obsolete or at risk of becoming obsolete.

[edit] Terms

• AONS: This refers to the Automatic Obsolescence Notification System (AONS) project as a whole, including past, present and future versions.
• AONS II: This is shorthand for AONS Version 2.X, which is the current target build
• AONS I and AONS v1: This is shorthand for AONS Version 1.X

[edit] Project Team

• David Pearson, project manager: dapearso@nla.gov.au
• Matthew Walker, technical lead: mwalker@nla.gov.au
• David Levy, project developer: dlevy@nla.gov.au (also maintains a developer blog here)

[edit] Project Plan

Download AONS II Project Plan

[edit] Related Projects

The following projects have common applications and we shall seek to learn from all of them:

• PANIC
• CRIB

[edit] Workshops

• AONS II Workshop Outcomes

[edit] Documentation

AONS II was created with the intention of building an "as built" specification. Since then we have recognised the need to have the viewpoints and expectations of different stakeholders clearly established in order to create something useful. In doing so, we have expanded the original Technical Architecture document, breaking it down into the following three questions:

1. Why Are We Building AONS II?
2. What Are We Building AONS II To Be?
3. How Are We Building AONS II?

In addition to the above mentioned documentation, we also have the

[edit] Why Are We Building AONS II?

So far we have the following document detailing "why" we are building AONS II:

• AONS II - Motivations

[edit] What Is AONS II?

This question describes the characteristics in increasing levels of detail. First we have written a deliverables document which details what we are intending to deliver as a final product which will satisfy the stakeholders of the project. Next we go over the use cases for the system, based on our functionality breakdown.

• AONS II Deliverables
• AONS II Functionality Breakdown

[edit] Deployment Modes

AONS II will have two main target deployment modes. A federated deployment with REST interfaces, which will target the deployment within a SOA based environment and a local/enterprise deployment which will be a more traditional application with the presentation tier a part of the application. These two modes of deployment are demonstrated below:

[edit] Adapter Pattern Usage

Since AONS will be working with many different types of Registries and Repositories, we will be using an adapter pattern so the business logic inside the AONS II core can remain independent from the logic of a particular Registry/Repository implementation. As long as an external Registry or Repository type implements the contract for a Registry/Repository then we will be able to work with it.

In theory, this will mean that should someone have a repository or registry which they want to integrate with AONS, they can write adapters which conform to the interface. So in this way the application can plug in to potentially any Registry or Repository. Still, not to raise expectations too high, this does not mean the application is pluggable: that implies that new functionality can be added at run time. This is not the case, to integrate a true Java adapter would require a rebuild/repackage of the application - though we hope to make this process as simple as possible. Making AONS II truly pluggable would be a nice to have, but would require a fair extra chunk of complexity which we probably couldn't implement at this stage. Still, it's always worth remembering this for the next AONS version.

One big risk with this adapter pattern is that the offerings between different types of Registries and Repositories are so vastly different, that the adapter contract for each becomes almost meaningless in it's generality. If this were to happen, the code inside the AONS II core would still remain independent towards the underlying adapter, but the benefits of working with them would be greatly reduced. We shall strive to look out for this scenario, and if it does, maybe sacrifice the independence of business logic for simplicity. Still, this hasn't been the case so far, and everything is indicating that the adapter pattern will succeed - but it's still nice to keep in the back of our minds.

[edit] How Are We Building AONS II?

This section details how we are building AONS II, through release cycles, algorithms and design. We also include technological decisions chosen of significance (how we are doing scheduling, our persistence technology etc).

• Release Cycles
• General Design Documents
  • Temporal Domain Objects
  • Flexible Module Dependencies
  • Flexible Authorisation and Authentication
  • Repository and Registry Abstraction Layer
  • Internal/External Data Workflows
  • External Facade per Deliverable
• Technological Choices and Requirements
  • Java
  • Ant and Maven
  • Spring, J2EE or JEE
  • GUI Webflow Technology
  • GUI View Technology
  • REST Binding Technology
  • Persistence Technology (Hibernate vs JDBC vs ???)
• Open Source License and Open Source Repository

[edit] Tasks Remaining

This section describes the tasks to be completed before the project can be designated complete.

• Definition of REST interfaces (DL, DB)
• REST services accessible via COSI framework (DB)
• List of remaining features to complete (DL), and prioritise (NLA, DL, SY)
• Publish format summary XML (schema not necessary at this stage) (DL)
• Documentation (DL, DB)
• Installation of COSI, AONS on APSR server (DB)
• Sourceforge project establishment and support mailing list (DL)
• APSR Demonstration instance (DL, DB, SY + partner repository managers)
  • develop format summary service for DSpace and Fedora (SY to follow up responsibilities and whether service or crawl will be demonstrated on the various repositories)