Technical Overview

Summary

The DISSCO system is a flexible electronic records management system (ERMS) developed in java and mainly based on the Jakarta Slide project.

The DISSCO system ensures compliance with archival standards, uses WebDAV, provides workflow functionalities and allows export the archival fonds to other ERMS and archives management system.

The DISSCO system is independent from:

Core System

We may summarize the requirements relating to core system creation as follows:

  • the system must be compatible with MoReq and ISO 15489 recommendations;
  • the system must be extendable, so as to be able to take collaborative work functionalities on board;
  • the system must have a hierarchical access management system enabling every element of the classification scheme to be defined in terms of rights of access (or authorized actions) for a given community of people. In particular it must integrate the concept of user groups and roles, as well as permitting a definition of types of action corresponding to the requirements of an ERMS system;
  • the system must permit the specialization of an object entity in order to enable definition of different levels (or types of object) which constitute the classification scheme, as well as the rules which bind them (types of entity that they may contain, obligatory or optional metadata aggregates with which they are associated).
In order to meet this last requirement, it was found possible to define a generic type of entity describing the set of rules and properties to be applied to every type of specific entity in order that it complies with the requirements defined by the different standards studied. These common rules, which every entity of the system should meet (example given for an entity of a particular class as defined by MoReq), are:
  • the name of the entity type or aggregation level(e.g. class)
  • the list of obligatory metadata (e.g.: owner, creation date ... cf MoReq part 12)
  • the list of optional metadata (e.g.: comment, descriptive keywords ... cf MoReq part 12)
  • a flag indicating whether the users are authorized or not to create their own metadata (e.g.: true)
  • the list of entity types authorized as (type of element) children (e.g.: class, file, record)
  • a flag indicating whether the set of children has to be of the same type (e.g.: true)
On the basis of these requirements and tasks, the class diagram presented below was drawn up:

Core System Class Diagram

Notes related to the Core Class Diagram:

  • Within the diagram the archival concept of an entity is associated with the name Node.
  • Node designates the element accessed by the user for a given reference (structural element), it is defined by a type with which it is associated and contains one or more revisions.
  • The generic type of node is specified in order to enable the creation of various types of Node while implementing the solution within different institutions. This Node creation takes place via successive specialization beginning with the NodeTypeAbstract.
  • Each revision of a Node is associated to a version number; the inverse association of a version indicator linked to a revision makes no sense.
  • RevisionTreeDescriptor represents the version tree (revisions) for a particular node.
  • Assuming that the revisions for the same entity may have divergent metadata values, the metadata are attached at the revision level (Node is merely a structural concept). The aggregate of metadata associated with a revision is defined by the type of Node with which that revision is linked.
  • In case of a Node of the ElectronicRecord type, one or more binary contents will be associated with each revision.
  • Security is only represented in a summary manner and is based on the ACL standard, which implies a hierarchical structure of information, types of rights, roles and groups.

Architecture Overview

Software Layers

Storage

Data Stores

The solution is independent from physical data storage. Currently, the solution allows the storage of data in SQL 2 compatible databases via JDBC/ODBC, in a file system (in this case descriptive information relative to the information objects are stocked in XML files), in J2EE stores or in a LDAP repository for user-related information. This independence with regard to physical data storage also allows us to quickly adapt the solution to data storage types other than those mentioned, in particular for the use of XML or object databases.

^ To diagram

Data Stores Connectors

Data stores connectors are classes responsible for the store and retrieve functionalities on information objects towards the different types of data store previously mentioned. With regard to the data structure for relational databases, this is also independent of the solution and can be defined according to the needs (mainly according to the standard chosen for the entities description and the types of metadata objects). As an example, note that it is mainly at this level that modifications have been made in order to allow the support of the multiple parents structure, as described in the Assessment Report (Section 3.2.6.5).

^ To diagram

Core System

Data Stores Interface

The data stores interface defines the method to which the whole set of data stores connectors must conform.

^ To diagram

Data Manager

Data manager or core of the document manager, based on Jakarta Slide. The data manager defines the information objects of the system, their relationships as well as the connectors which allow the personalization of the system and the addition of plug-ins. As described in the DISSCO Core System Class Diagram (Assessment Report, Attachment I), the data manager is also responsible for security management (access rights). Concerning the information objects, see the DISSCO Core System Class Diagram and its explanation . Concerning the personalization of the system, see Connectors and Main Functionalities.

^ To diagram

API/Helper

Slide API or WVCM (JSR-147) as it is. This layer defines the actions that can be carried out on the information objects within the system. These actions are accessible through six 'helpers', respectively structure, content, security, lock, search and macro. For more information concerning these 'helpers', see the Jakarta Slide documentation. Following the example of the Slide WebDav servlet and the web application, this API will be used, if necessary, with regard to the WebDav functionalities, for the development of import/export systems in order to exchange information objects with other ERMS or EDMS.

^ To diagram

Web Application

The prototype has a predefined set of tag library, forms and actions based on Struts in order to allow a fast development of new web applications according to the MVC model. Web application examples, based on the DISSCO tag library, exist at present as a prototype.

^ To diagram

Webdav Servlet

Slide WebDav Servlet as it is. The WebDav servlet analyzes the incomming WebDav requests, sends the corresponding instructions to the core system via the API, and returns the result of these requests, according to the WebDav standard, to the distant application.

^ To diagram

Connectors

In order to keep a coherent and comprehensible solution structure, the core system must not include the customization of the solution. Since the solution must be flexible with regard to the chosen archival standard(s), role definition and the addition of modules for specific data processing, the solution defines four connectors: metadata, structure, roles and content interceptor (roles and content interceptor being defined by Slide). The following parts are dedicated to the description of these connectors.

^ To diagram

Metadata Set

The metadata set connector allows the definition of diverse metadata sets and their association with a specific namespace. This functionality must primarily ensure compliance with various archival standards and recommendations, in particular ISO 15489, MoReq and ISAD(G).

^ To diagram

Structure

The structure connector allows the definition of the information object types that must be supported by the system.

The structure connector also allows the definition of the structural rules that manage relations between the different types of information objects within the fonds, in order to assure compliance with various archival standards and recommendations, in particular ISO 15489, MoReq and ISAD(G) (ex.: a file can only contain either records or volumes).

For more information adout the information structure see structure functionalities

^ To diagram

Roles (Security)

Preliminary notes concerning security: Users and groups are considered as information objects that only have some descriptive metadata. Therefore, they can be subject to revisions (versions). The types of access rights that are applicable are defined in an XML configuration file.

These types of access rights are:

  • read-object, create-object, remove-object, grant-permission, revoke-permission, read-permissions, read-ownpermissions, lock-object, kill-lock, read-locks, read-revision relates, create-revision relates, modify-revision relates, remove-revision relates, bind-member, unbind-member, read-revision-metadata, create-revision-metadata, modify-revision-metadata, remove-revision-metadata.
Concerning the last four, the system also allows the placing of certain access rights on a particular metadata.

For more information adout the security see security functionalities

^ To diagram

Content Interceptors (Pre/Post Store Methods)

The content interceptor connector allows the creation of plug-ins in order to analyze and perform specific actions on information objects before and after their consultation, creation or modification. These plug-ins are java modules. They can be configured by means of an XML configuration file. Currently available plugins are:

^ To diagram