Revision as of 06:32, 22 August 2013

Introduction

The VME project has started to investigate how the iMarine infrastructure could work in combination with the VME-DB on FAO side. This page tries to make all assumptions explicit and therefore will probably be heavily used for discussion!

The Reports function of iMarine was initially thought of in the context of the FIMES XML Schema for generating factsheets. This page instead explains how it could work, while trying to target an objects graph like the VME DB.

You can find the object graph for the VME-DB here, in order to have an idea of the VME domain model (ask Erik or Anton for the name/password).

This page talks about key-values as the solution to transfer data from iMarine into the VME-DB. The naked truth is that it is composite-key-value solution. The composite key is composed of the type of:

• the object (KeyType)
• the id of the object(id)
• the name of the attribute that is to be manipulated.

A composite-key-value solution makes it easier on both sides to manage the data and works particularly well to manipulate an object graph like the VME-DB.

The big picture

UML

TemplateEditor

The VME-DB is an object graph. Every object in the VME-DB is represented in iMarine through a KeyType. Of course an object has attributes, therefore also a KeyType has attributes.

Examples of KeyTypes are Vme, Rfmo, GeneralMeasures, SpecificMeasures, etc.

• Template: Holds a collection of KeyTypes. A Template defines the form in order to manipulate the objects in the VME-DB.
• KeyType: This is the name of the object in the VME-DB
• Attribute: is the name of the attribute of a certain object

• TODO: Engineer and explain better the concept of Parent and Child. The more I think about it, the more I believe that such a concept is not needed. See also the example in Multilingual

Report, Delta and KeyValue

This diagram describes conceptually the model of a Report and the the format of a Delta message.

A Report is a collection of KeyValue(s). The Delta is a collection of KeyValue(s), representing a change of content.

KeyValue has the following attributes:

• KeyType: see above TemplateEditor
• id: is the id of the object in the in the VME-DB of a certain type(keyType).
• attribute: see above TemplateEditor
• value: the value for that attribute

Target

The target (VME-DB) is from a iMarine point of view a collection of KeyValue(s)

Webservice

Id management

When creating a new object on the side of iMarine, a reference or id for this object is needed. The responsibility of Id generation is primarily on the target side(VME-DB). What can be done is to generate an ID on iMarine side, according this convention:

ID = LOCAL_{localID}

Example of such an id would be: VmeId = LOCAL_452.

A delta can define a number of new objects with all local ids. Within the delta, the local ids have a meaning. When the ingestion webservice will create the new object in the target, a new object will be created and the local id will be replaced with the new ID. The local ids will be destroyed after the delta has been ingested.

Multilingual

The assumption is that multiLingual aspects can be covered also by only key values.

This implies that the Reports do not have to implement multilingual aspects. If the target (VME-DB) is multilingual, then Reports can handle that through key values.

Please verify this example:

Note: the above example describes also well in general how the key-value solution is envisaged.

Open Issues

• How to handle reference data, lookup tables (integration with the Cotrix Master Data Manager through a Master Data Client)
• How to handle validation rules
• The names of this iMarine function can be confusing: Reports. A report reports generally about 'something'. This function does not report but generates 'something', e.g. content. This function is all about editing content, to be send to another entity. Alternatives names could be UniversalEditor, InfiniteEditor, ContentCreator, etc.
• What to do if a delta corrupts the VME-DB? A solution could be to 'version' the VME-DB, so a previous version can be used in order to restore the website.
• How to implement the preview function of draft content? Also here versioning of the VME-DB could be a solution.

Stateful or Stateless?

The above picture assumes that the iMarine infrastructure will not hold state regarding the VME-DB. Content will flow from the VME-DB into iMarine, will be subject to manipulation and a stream of deltas will flow from iMarine into the VME-DB trough the webservice. In this scenario, iMarine is stateless.

The Stateful scenario would imply that the starting point of the lifecycle of the content is only within iMarine. The VME-DB is just an endpoint where the data is send to. The VME-DB will not hold primarily responsibility of holding the data in a meaningful and consistent way together.

Both scenarios have their pros and cons and FAO needs to speak with the iMarine experts which scenario fits best.