Chapter 32. Engineering Database - EDB

The EDB is a core component of the semantic part of the OpenEngSB. It's purpose is the persisting and versioning of domain models (so called OpenEngSBModel objects).

32.1. Motivation

The EDB concept was introduced with the idea to build a central persisting unit for the domain models of all domains. This central approach offers some interesting advantages, like for example:

  • easy to change
  • easy data maintainence
  • single point of versioning configuration
  • central instance where model transformations can take place

Model transformation is the out of the scope of the EDB and will be covered by the EKB.

Another important feature of the EDB are build-in conflict checkers. Until now, there is only one implementation which is based on version numbers. Whenever someone tries to save something into the EDB with the wrong version, the conflict checker tells the user that a conflict has been found and that he has to checkout the newest version of the model before he can save the model.

32.2. Structure

The EDB is a JPA based implementation of a central database supplier in service orientated architectures, which also have the additional functionality to version data. Currently we are using OpenJPA as JPA implementation.

Since the EDB simulates the functionality of a scm system, the structures of the tables in the EDB are no big surprise. They consist of objects which have a list of key/value pairs bound to them. Also there exist a commit table, with which the EDB is able to keep track of all meta-data of changes.

32.3. Usage

Until now, the saving/updating of models into/in the EDB is done through specific events which every connector which implements the interface "OpenEngSBConnectorService" can throw. This events hide many details of the saving procedure like the automatically load from where the event is coming and with this, an automatic event enhancement. Also the conflict check is started through such an event. In future the EDB has to be used directly without events to easier enable the possibility to use the EDB functionality in workflows(Jira-ISSUE).

The loading of models from the EDB is in conceptionally possible, but should always be done through the QueryService of the EKB bundle, since this service does the automatic transformation work of elements from the EDB to an OpenEngSBModel. See the detailed explanation of the EKB for more informations.

32.4. Conflict Detection

The conflict detection, as it is implemented now, is a very simple implementation of a conflict checker. The checker is based on simple version numbers. If the version number of the model which has to be saved doesn't fit to the actual version number, the conflict detection throws an error.

In the future there should be more possibilities for conflict detections been found. But for the start, this conflict detection is enough(Jira-ISSUE).