Difference between revisions of "Ecosystem Approach Community of Practice: VME iMarine"
(→Stateful or Stateless?) |
|||
| Line 6: | Line 6: | ||
=The big picture= | =The big picture= | ||
[[File:IMarineIngestion.png]] | [[File:IMarineIngestion.png]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=UML= | =UML= | ||
| Line 69: | Line 62: | ||
*How to handle validation rules | *How to handle validation rules | ||
*The names of this iMarine function can be confusing: Reports. This function is all about editing content, to be send to another entity. Alternatives could be UniversalEditor, InfiniteEditor, ContentCreator, etc. | *The names of this iMarine function can be confusing: Reports. This function is all about editing content, to be send to another entity. Alternatives could be UniversalEditor, InfiniteEditor, ContentCreator, etc. | ||
| + | |||
| + | ==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 responsibility of holding the data in semantic and consistent way together. | ||
| + | |||
| + | Both scenarios have their pros and cons. | ||
Revision as of 08:29, 21 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!
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).
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.
- 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.
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.
Open Issues
- How to handle reference data, lookup tables
- How to handle validation rules
- The names of this iMarine function can be confusing: Reports. This function is all about editing content, to be send to another entity. Alternatives could be UniversalEditor, InfiniteEditor, ContentCreator, etc.
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 responsibility of holding the data in semantic and consistent way together.
Both scenarios have their pros and cons.
