Difference between revisions of "Ecosystem Approach Community of Practice: VME iMarine"
(→Open Issues) |
(→Stateful or Stateless?) |
||
Line 8: | Line 8: | ||
=Stateful or Stateless?= | =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. | + | 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. | ||
=UML= | =UML= |
Revision as of 08:28, 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
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.
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.