Components

Design > Architecture > Components

Release Information

Project:	PIMS
Internal Release Number:	0.1
Related Documents:	Design > Security

Data Model

Description:	The Protein Production Data Model is a formal representation of the protein scientists' understanding of the physical world. It is an abstract description of the relevant data and their relationships. There are other stakeholders in it apart from the PIMS project, including BRI Montreal and the Weizmann Institute. The data model includes not only types and attributes, but also consistency rules called "constraints". In the protein production model these are mostly simple, but PIMS will also include the chemistry packages, which have some complex constraints. One of MPSI's aims is devising new methods. These may require changes to the data model.
Available Interfaces:	UML, for human reading and as input to the code generator. We may need a UI for making local changes to the data model. Alternatively we may decide this is infeasible.

Description:

The Protein Production Data Model is a formal representation of the protein scientists' understanding of the physical world. It is an abstract description of the relevant data and their relationships. There are other stakeholders in it apart from the PIMS project, including BRI Montreal and the Weizmann Institute.

The data model includes not only types and attributes, but also consistency rules called "constraints". In the protein production model these are mostly simple, but PIMS will also include the chemistry packages, which have some complex constraints.

One of MPSI's aims is devising new methods. These may require changes to the data model.

Available Interfaces:

UML, for human reading and as input to the code generator.
We may need a UI for making local changes to the data model. Alternatively we may decide this is infeasible.

Code Generator

Description:	This is supplied by CCPN, and is not part of the normal runtime operation of PIMS. It is used to create code from the data model, which becomes part of PIMS. We may decide to ship it with PIMS to enable users to make local changes to the data model.
Available Interfaces:	Its input is the UML files representing the data model. These are first converted to a Python data structure, which is saved in a file. Later it may also accept a hints file, e.g. listing denormalisations that are required to meet performance goals. Generates SQL Data Definition Language to set up the database. Generates Data Model API We may need a runtime representation of constraints. Later it may also generate test data to populate the database.

Description:

This is supplied by CCPN, and is not part of the normal runtime operation of PIMS. It is used to create code from the data model, which becomes part of PIMS. We may decide to ship it with PIMS to enable users to make local changes to the data model.

Available Interfaces:

Its input is the UML files representing the data model. These are first converted to a Python data structure, which is saved in a file.
Later it may also accept a hints file, e.g. listing denormalisations that are required to meet performance goals.
Generates SQL Data Definition Language to set up the database.
Generates Data Model API
We may need a runtime representation of constraints.
Later it may also generate test data to populate the database.

Database

Description:	RDBMS containing the laboratory information. Must (in general) have a table for each class in the data model, and a column for each attribute. It must suppport: inheritance, including subclasses of subclasses. access rights, so only specified users can view or update a record (later) version history (audit trail) (later) normalisation and denormalisation that is transparent to the application layers. Some customers will not accept Oracle. There may be others who insist on it. Backwards compatibility is needed. When the data model changes, existing sites will need to convert existing tables to the new structure.
Available Interfaces:	The database is accessed solely by the Persistence Layer. The DDL to create the tables is generated from the data model. To coordinate the code generation and Persistence layer, there must be a documented set of conventions for table and column names. Triggers or stored procedures in the database may be helpful, e.g. to implement data model constraints. Version 0.1. should be delivered before a final choice of RDBMS, so only a limited amount of time should be invested in creating stored procedures.

Description:

RDBMS containing the laboratory information. Must (in general) have a table for each class in the data model, and a column for each attribute. It must suppport:

inheritance, including subclasses of subclasses.
access rights, so only specified users can view or update a record
(later) version history (audit trail)
(later) normalisation and denormalisation that is transparent to the application layers.
Some customers will not accept Oracle. There may be others who insist on it.
Backwards compatibility is needed. When the data model changes, existing sites will need to convert existing tables to the new structure.

Available Interfaces:

The database is accessed solely by the Persistence Layer.
The DDL to create the tables is generated from the data model.

To coordinate the code generation and Persistence layer, there must be a documented set of conventions for table and column names. Triggers or stored procedures in the database may be helpful, e.g. to implement data model constraints. Version 0.1. should be delivered before a final choice of RDBMS, so only a limited amount of time should be invested in creating stored procedures.

Persistence (Data Acccess) Layer

Description:	Provides an API to read and update the data model as represented in the database and read metadata about it. Must support: Access control Create an audit trail of updates (later) facilities to report the audit trail Write transactions (update several records atomically) Read transactions, so all reads for one operation are from the same version of the database. Long read transactions, for use when preparing reports. These must not lock out other operations. The requirement for transactional correctness will be relaxed if necessary. Use a read-only connection when a read transaction is requested. This will make it easier to audit the security of the system. The design must not have excessive performance overheads, e.g. it should use lazy instantiation rather than performing fetches that may be unnecessary. It should fetch whole rows, not individual column entries. If it relies on an off-the-shelf object-relational mapping, we must be able to replace it later without changing other layers if it turns out to be unsatisfactory. For version 0.1, it is acceptable for transactional correctness to be acheived simply by completely serializing requests with a single lock.
Available Interfaces:	Uses JDBC to access the database, or may consist mainly of an off-the shelf object-relational mapping, e.g. OJB. Provides an API to the implementation of the Data Model API. Parts of the Persistence layer may be implemented as triggers or stored procedures in the database.

Description:

Provides an API to read and update the data model as represented in the database and read metadata about it. Must support:

Access control
Create an audit trail of updates
(later) facilities to report the audit trail
Write transactions (update several records atomically)
Read transactions, so all reads for one operation are from the same version of the database.
Long read transactions, for use when preparing reports. These must not lock out other operations. The requirement for transactional correctness will be relaxed if necessary.
Use a read-only connection when a read transaction is requested. This will make it easier to audit the security of the system.
The design must not have excessive performance overheads, e.g. it should use lazy instantiation rather than performing fetches that may be unnecessary. It should fetch whole rows, not individual column entries.
If it relies on an off-the-shelf object-relational mapping, we must be able to replace it later without changing other layers if it turns out to be unsatisfactory.

For version 0.1, it is acceptable for transactional correctness to be acheived simply by completely serializing requests with a single lock.

Available Interfaces:

Uses JDBC to access the database, or may consist mainly of an off-the shelf object-relational mapping, e.g. OJB.
Provides an API to the implementation of the Data Model API.

Parts of the Persistence layer may be implemented as triggers or stored procedures in the database.

Data Model API

Description:	The API is generated automatically from the data model, together with its implementation. Its responsibilities include checking constraints when objects are created or attributes are changed.
Available Interfaces:	Provides services to the Lab API. Lab API classes may extend model classes. Provides services to the Generic UI, including metadata queries. Calls the Persistence layer to provide the object-relational mapping. The existing Java API (version 0.9.5) is basically suitable, but it needs small enhancements to support access rights and transactions, and needs to support metadata queries like the python version. Some contraints may be implemented as triggers in the database.

Description:

The API is generated automatically from the data model, together with its implementation. Its responsibilities include checking constraints when objects are created or attributes are changed.

Available Interfaces:

Provides services to the Lab API. Lab API classes may extend model classes.
Provides services to the Generic UI, including metadata queries.
Calls the Persistence layer to provide the object-relational mapping.

The existing Java API (version 0.9.5) is basically suitable, but it needs small enhancements to support access rights and transactions, and needs to support metadata queries like the python version. Some contraints may be implemented as triggers in the database.

Laboratory API

Description:	Classes and methods to represent laboratory operations. Contains no presentation code, just scientific logic.
Available Interfaces:	Provides methods to be called by applets and specific servlets. These methods are specific to particular laboratory operations, so the list will grow continually during the project. Uses Data Model API, in some cases by extending the classes to add extra methods. Clients of the Lab API will also have access to Data Model API methods.

Generic Servlets

Description:	A few generic web pages to represent the data in the database and allow updates.
Available Interfaces:	Uses the Data Model API and is especially dependent on the availability at runtime of metadata from it. All objects in the model must be viewable. It would be acceptable if some types cannot be edited, if it is hard to implement complex constraints through a generic interface.

Specific Servlets

Description:	Custom pages for lab operations, supporting those activities where an HTML form is sufficient to give a good user interface.
Available Interfaces:	Developed hand in hand with the Laboratory API. Should have a consistent style, to be documented in a Web Interface Style Guide. This will include the convention that HTTP GET operations are used only for read transactions. Must be suitable for automated testing.

Applets

Description:	Custom interfaces for lab operations. An applet will be created when a web page cannot be sufficiently user friendly, e.g. because drag-and-drop is appropriate.
Available Interfaces:	TBD

Company Proprietary