Looking for Archivematica the software project? see: archivematica.org

archivemati.ca

archivemati.ca header image 1

ICA-AtoM Physical Architecture

May 28th, 2007 · 1 Comment · ICA-AtoM, System Architecture

Since I first posted about my ideal information model several months ago, I’ve been wanting to add an update about the logical data model that I eventually implemented in the ICA-AtoM application but, before I can do that, I should briefly explain the physical architecture on which ICA-AtoM is built so it is easier to understand how the data object model fits into that. I’ll follow-up about the logical data object model in a later post.

First of all, for the uninitiated, ICA-AtoM is a open-source, archival description application that is currently in development. It is being built using the MySQL database engine, PHP5 object-oriented programming language and the Symfony web-application framework. Symfony incorporates a number of web development best practices and design patterns into a single framework making it easier to develop, maintain and contribute to applications that implement this common framework structure.

The Model-View-Controller (MVC) Design Pattern

At its highest-level, a Symfony application such as ICA-AtoM follows the Model-View-Controller (MVC) design pattern.

Views are the templates or webpages that the users see and interact with. The controllers consist of a front controller and related action code to route, filter and process the user input and to trigger application logic. The model layer reads and writes content to the database and converts it into programmable objects that are processed by the controller layer to carry out the application functionality and to pass on for display in the view layer.

The model, view and controller are conceptual layers which consist of actual .php files that are stored on a webserver and organized into a standardized directory structure or ‘scaffolding’. The data that is used by the application is stored in a database server that is accessible from the webserver. Users interact with the application by posting request and receiving responses via their web-browser software. The entire physical architecture (webbrowser, webserver, php5 files, database server) can be distributed over multiple clients and servers or it can be run on a single, stand-alone PC.

The model-view-controller design pattern is a web-based version of the classic n-tier architecture that seperates business logic, data persistence and presentation resulting in improved maintability and scalability. The Symfony framework provides the tools, interfaces and design rules to make the model, view and controller layers work together. Symfony is fully open-source (MIT license) and fully-configurable.

Any part of the framework can be enhanced or by-passed but, of course, there is tremendous value in sticking to the framework rules such as: development efficiency through the re-use of existing components, shared documentation, bug fixes, new feature plugins, readability of code for other developers, implementing best practices. These are some of the main reasons why Symfony was chosen as the development platform for ICA-AtoM, rather than simply building an application from scratch.

The View Layer

The Symfony view layer implements the Decorator design pattern which progressively adds layers of user interface output starting with a site-wide layout template. This global template is populated with the context specific templates and slots which are generated in response to the actions triggered by the user (i.e. clicking a link, pressing a button, moving the mouse). The templates are populated with data retrieved via the model layer.The resulting view is styled and themed using Cascading Style Sheets. Here is part of the view template that is generated by the ‘show’ action for the ‘archival_material’ object.

The Controller Layer

All web requests made to a Symfony application are handled by a single front controller (i.e. http://myWebsite/index.php) which routes the request and associated parameters to the appropriate action code. The controller layer also handles the user session, security and filtering output response. The core of the controller layer is the action code which is organized into modules that represent the core functions (e.g. search, browse) and data objects (e.g. archival material, repository) that are managed by the application. As show in the directory below, the modules that are implemented in ICA-AtoM vo.2 include actor, archival material, browse, menu, repository, search, staticpage, term and user.

The Model Layer

Like other MVC frameworks (such as RubyOnRails and Django), Symfony contains an Object-Relational-Mapping (ORM) component to help store and load the programmable objects that are used by the application to the tables and rows in a relational database (which is by far still the predominant way to persist data in software applications). Propel is the default ORM tool that is packaged with Symfony. It has a database connection interface that filters the generic SQL queries made in the Symfony application to work in a number of specific database engines.

MySQL is used as the default database engine in ICA-AtoM development because it is the most ubiquitous open-source database application, making it easier to deploy and support. However, using the Propel database connection, ICA-AtoM data can also be stored in MS-SQLServer, Oracle, Postgress, SQLite, or ODBC-compliant databases.

Propel uses the Row/Table Gateway design pattern to map the application objects to tables and rows in the database. This means that each class in the logical application model maps one-to-one to a table in the physical database model and each object, or instantiation of a class, maps to a row or record in the table.

In other words, the physical data model (shown in the MySQL table list above) is almost identical to the logical object model used at the controller layer. For example, I have an ArchivalMaterial table in my database that uses ISAD(G) fields as the fields or columns. Each row in this table gets loaded into the ICA-AtoM application as an ArchivalMaterial object which now has ISAD(G) fields as its active attributes and can take on behaviours through class methods such as exportToEadXML() or addToSearchIndex().

In a follow-up post, I’ll take a closer look at the logical object model that is implemented in ICA-AtoM.

1 response so far ↓

  • 1 sp.Blog » ICA-AtoM : un logiciel web pour la description de fonds d’archives // Nov 10, 2007 at 6:10 am

    [...] Sur le plan technique, cet outil s’appuie sur le framework Symfony (PHP5) et donc sur un modèle MVC ( Model-View-Controller) dont les auteurs détaillent le plan dans le blog de développement. Le conteneur de données semble être MySQL par défaut, mais les auteurs, qui ont utilisés le connecteur Propel, indiquent qu’il sera possible d’utiliser d’autres SGBDR. [...]