Review Meeting Information

Documents and Code Reviewed at this Meeting

• Architecture
• Components

Meeting Minutes

Objectives

Chris said that quality of the persistence layer was key for PIMS. For example one membrane protein project conducted 100,000 trials. PIMS has different needs than a desktop application for structure solution. He wants to reduce the risk to the PIMS project by establishing the possibility of plugging in a different persistence mechanism later, and in particular to decouple it from the code generation mechanism.

Rasmus said that CCPN want to have the API for SQL databases be the same as for XML storage, including when there are several XML files; build in constraint checking; and allow lossless transmission of data.

Architectural goals

The meeting reviewed the architectural goals. Local variation of the data model will make data exchange hard and lossless data exchange impossible. Anne pointed out that the new ExperimentMethod/Protocol class solves many of the problems. Chris reported that one of MPSI's goals is devising new methods. It was agreed that the cost/benefit tradeoff for making local changes was one for the customers to decide.

The meeting also recognised that implementing local variation, and providing a way to do it that is at all user friendly, is hard at least, perhaps impossible. It was resolved to change this goal from supporting local variation to determining how hard it is to support it.

Chris has reviewed EJB and does not think that it is helpful to PIMS. CCPN may want distributed applications, so remain interested in it.

The other goals were agreed.

Code generation

CCPN reported that the code generator imports the data model not as an XMI file, but as a .uml file from Object Domain. The first stage converts this to a Python data structure, which is then the input for generating Java, SQL, etc.

Database

Anne pointed out that backwards compatibility is needed. When the data model changes, existing sites will need to convert existing tables to the new structure.

Data Access layer

The meeting recognised that proposed architecture combined persistence (object-relational mapping), validation of constraints, and interface to metadata all in this layer. Rasmus proposed that the Data Model API should provide metadata (the Python one already does). This allows the generic UI to use the Data Model API, so simplifying the layer diagram significantly. The "Data Access layer" should then be renamed the "Persistence Layer".

Wayne reported that the current implementation fetches one attribute at a time, rather than caching rows. It was agree to look again at off-the shelf solutions including OJB.

Data Model API

The meeting decided that this should provide metadata queries, and provide methods:

    Object get(String attribute)
    void put(String attribute, Object value)

Rasmus reported that much of the code in this layer checks constraints. Some standard constraints could be represented by Constraint objects. Others are complex and have to be hand coded. Anne reported that this doesn't arise in the Protein Production packages, but does in the chemistry packages. Rasmus reported that in Python function calls are expensive, so this code is generated inline. Chris reported that method inlining and constant folding can be done by the JVM.

Wayne reported that Postgres checks foreign key constraints continually, instead of deferring the check to the end of a transaction. With other databases or by use of triggers, it may be possible to move the implementation of simple constraints to the database.

The meeting discussed design options for access rights. One proposal is to add an "Owner" type, with a link to an owner in each object, and for each Owner-PersonGroup to record read and write permissions. Object creation involves setting an owner: for each Type-Person there is a set of permitted owners for new objects created by that person. It was agreed that this model was simpler but more expressive that the Montreal one.

Lab API

The specific user interface will in part call Data Model API methods. The Lab API supplements these methods but does not replace them.

Generic Servlets

With the changes decided above, these will be able to use the Data Model API, so constraint checking will be available. However the meeting thought it possible if highly unlikely that types with complex constraints could still not be checked in a generic way. Chris said it would be acceptable to make it impossible to edit those types through the generic interface.

Action Items

• Propose revisions to Data Model API - Chris
• Propose Persistence Layer API - Wayne and Anne
• Evaluate OJB - Anne
• Propose revisions to Data Model for access control - Rasmus
• Meet again to review these proposals - all, 9th Sept.