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

An important point to consider is, that the EDB isn't supposed to be used directly. Instead, the EKB (Engineering KnowledgeBase) component provides two interfaces which shall be used to access the EDB indirectly. The reason for that is, that the EKB handles the OpenEngSBModels, their transformations and everything related to them. The EDB on the other hand is only the persistence used by the EKB in the background.

The saving of models to the EDB directly is conceptionally possible, but should always be done through the PersistenceInterface provided by the EKB bundle, since this service does the automatic transformation work of elements from OpenEngSBModel to EDB savable objects. See the detailed explanation of the EKB for more informations. WARNING: There was another possibility, with which you could throw EDB*Events from connectors. This possibility is no deprecated and should not be used any more.

The loading of models from the EDB is conceptionally possible, but should always be done through the QueryInterface 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).