System Architecture

EasyDeposit is based on the CodeIgniter MVC PHP framework. EasyDeposit makes use of the separation of Views (look and feel) and Controllers (business logic). It does not use the Model functionality as the long term storage of the data is delegated to the repository that accepts the deposit.

The system is made up of a number of steps. These steps can be configured into different orders, with steps added or removed depending upon your requirements. A typical set of steps might be:

  • ldaplogin (allow users to login using LDAP)
  • depositcredentials (an invisible step that sets the username and password for the repository deposit)
  • metadata (collect metadata from the user)
  • uploadfiles (lets the user upload one or more files to deposit)
  • verify (verify the data with the user)
  • deposit (an invisible step that deposits the item)
  • email (an invisible step that sends an email to the user)
  • thankyou (thanks the user for their deposit)

Some steps can be invisible. These might be used to set up other parts of the system, or to carry out actions (such as the actual deposit, or sending an email) that do not require the user to see anything. These steps do some processing, and rather than displaying anything, they call the gotonextstep() method which moves the user to the next step automatically.

A complete list of the out-the-box steps can be seen at EasyDeposit steps

The Anatomy of an EasyDeposit step

EasyDeposit is made up of a series of steps. These are typically made up of three types:

  1. Login steps
    • Every instance of EasyDeposit must have a login step. A login step is like any other step, except that it must be the first step in the series, and it can tell any other step what the ‘user id’ is. This is used for creating a naming a temporary directory for each deposit where the fiels are collected and the package is created. If you are using an interactive login steps (e.g. authenticating against an LDAP directory) then the user id is the identifier of the user. If you do not want a user to have to log in, you could use an invisible login step such as ‘nologin’ which sets a random identifier and moves on the to the next step. Every time a user requests a page within EasyDeposit, the login class is asked if the user is logged in or not before processing the step. This stops users from entering part the system unauthenticated part way through a submission.
  2. Collection steps
    • These steps are used to collect input from the user. They could be steps related to the target repository (e.g. retrieve the service document, and present to the user a list of collections into which they can deposit), or related to metadata (e.g. asking for title, authors, abstract etc), or related to files to deposit (e.g. allow the user to upload one or more files).
  3. Processing steps
    • Processing steps take the data collected from the user, create a deposit package (in OAIS parlance aSIP), preform the deposit of the package and report the result back to the user. Optionally you can include processing steps that perform tasks such as sending confirmation emails. There could optionally be multiple deposit steps that deposit the item into more than one repository.

A guide to writing your own step can be seen at Creating a new step.