The discipline of model engineering has matured considerably over the last years and is applied in a wide array of domains, ranging from embedded software development to IT landscape documentation. A variety of di erent model repositories attempt to meet the requirements that emerge when working on models, most notably e cient persistence, versioning and query capabilities. However, existing tools scale poorly when faced with large models used in practice, in particular in scenarios where (semi-)automated element generation pushes model sizes to hundred thousand individual elements and beyond. In this paper, we present our research agenda for Chronos1, an e ort which aims to provide a solution to this problem in the form of a novel model repository for EMF Ecore models.
In recent years, the importance and popularity of model engineering has
increased considerably, both in academic as well as in industrial
settings [
Model repositories in this category store serialized forms of models
in les (typically XML, or XMI [
MagicDraw Teamwork server are representatives of this category. { Relational / SQL-Based
Tools based on relational technology aim to perform a mapping from the object representation into an equivalent relational representation. This process is referred to as object-relational mapping, or O/R-mapping. The relational information is then stored in a traditional database system. Versioning introduces additional entries in the relational tables to store the state of an element at a given version. Eclipse CDO makes use of this approach.
Both techniques su er from severe drawbacks and are not optimal for storage of model data. XML-based systems struggle with per-element versioning and the absence of indexing structures for querying, as well as having di culties in providing lazy loading capabilities, because any given XML le must usually be processed in its entirety before individual elements can be extracted. Such processing (i.e. serialization or deserialization) is also very costly with respect to CPU power, RAM and runtime. Relational backends (e.g. SQL databases) provide indexing structures and per-element loading while also working on a user-de ned schema which allows for versioning, provided that the repository takes care of this aspect on its own. The major problem with relational backends is the expensive Object{Relational Mapping (O/R mapping) process that converts objects into table entries and vice versa. O/R mapping increases considerably in complexity when objects with many connections to other objects have to be processed, which is a very common use case for modeling. Typical O/R mapping algorithms are often implemented in a recursive fashion5 which can lead to call stack over ows on su ciently large models. Converting the relational representation back into model element objects requires at least one SQL JOIN operation per connection. These operations have inherent quadratic complexity and therefore scale poorly.
We aim to improve the situation by adressing the hot spots of resource consumption: object (de-)serialization, storage of versioned data and queries on the persisted information. We do so by applying concepts from the NoSQL area and combining them with suitable mapping strategies and a novel approach to storage of versioned data.
The remainder of this document is structured as follows. Section 2 provides an overview of the related work. In Section 3 we present an outline of our solution. We present the expected contributions of the thesis in Section 4 and outline a plan for evaluation and validation of our approach in Section 5. Finally, Section 6 provides details on the current state of the project and Section 7 concludes the paper with a summary. 5 As for example in Hibernate: http://hibernate.org/
Having realized the shortcomings of the existing storage solutions for
large models as described in Section 1, Gomez et al. proposed and
implemented alternatives for EMF based on NoSQL technology, using graphs [
In 2014, Felber et al. proposed a set of algorithms that enable versioning
on a key-value store [
As the resulting artifact of this PhD thesis is going to be a model
repository, all the tools listed by Pierantonio et al. [
We propose a model repository that is capable of handling tightly coupled, large-scale models with 100000 individual elements and beyond. The features will include a rich query API and full per-element versioning support, as well as important collaboration features such as lightweight branching and con ict detection.
s o n o r h C
EMF Ecore
Fig. 1. The Chronos Data Management Stack This project is named Chronos, and consists of three main parts (collectively called Chronos Components). These components build on top of each other: { ChronoDB is the storage backend, and the lowest layer in the Chronos project. It is a key-value store with built-in versioning capabilities, to which we refer to as a Temporal Key-Value Store. ChronoDB is intended primarily as a lightweight storage backend for embedding into an application that writes to the local hard drive. In the repository, it is responsible for storage, versioning and branching. We implement these features on the lowest level because the key-value format is conceptually simple compared to an object graph, which reduces the complexity of the versioning problem. { ChronoGraph is an implementation of the Apache Tinkerpop6 graph computing API, mapping graph structures onto the key-value schema provided by ChronoDB. Several other libraries, including Titan DB7, have demonstrated that it is possible and feasible to implement a graph database based on a key-value store. ChronoGraph provides the low-level query API and a standardized storage format to the repository. { ChronoSphere is an EMF Ecore model repository. Built on top of ChronoGraph, it maps incoming model data onto a standardized graph structure. By leveraging the capabilities of the TinkerPop graph query language Gremlin, it will provide expressive model-level queries to programmers, as well as the versioning and branching features provided by ChronoDB.
In combination, these three components form a new type of model repository that implements the full data management stack. Aside from this top-level goal, due to the modular design, these three components can also be used individually in other projects: ChronoDB is a generalpurpose key-value store with versioning support, and ChronoGraph implements the Apache TinkerPop API, the de-facto standard API for graph databases, enabling it to act as drop-in replacement for other implementations. 4
The thesis will provide the following contributions to the theory of temporal data stores and model repositories: 4.1
A formal model for a Temporal Key-Value Store: This formalization is based on an in nite two-dimensional matrix structure that de nes and exclusively relies on history{preserving append{only operations. It provides the formal semantics which guide the implementation of the 6 http://tinkerpop.incubator.apache.org/ 7 http://thinkaurelius.github.io/titan/
A novel query framework: By utilizing the features o ered by the
NoSQL graph database, ChronoSphere will provide an entirely new
approach to model queries. It will allow developers to write queries at model
level in an internal, Java-embedded domain-speci c language that can
be checked by the compiler, providing additional compile-time
recognition of e.g. type system errors or spelling mistakes in comparison to
string-based alternatives, such as OCL [
Alongside and based on the contributions to theory, the thesis is expected to make a number of contributions to practice. We categorize them by software artefact.
Graph Database and Key{Value store: To the best of our
knowledge, ChronoGraph will be the rst implementation of the Apache
Tinkerpop API that o ers full versioning support which is provided by the
temporal key{value store in ChronoDB. Lightweight branching, as seen
in popular version control systems such as Git or SVN, is also part of
the versioning engine. ChronoGraph will be the rst graph database
with full ACID transaction support with the highest possible isolation
level (\serializable" [
The research methodology applied for this thesis follows the principles
of Design Science as de ned by Pe ers [
CPU and RAM usage) of the prototype implementation and
comparing it to other model repositories will provide the necessary data
for a discussion on the factual scalability of the model repository.
{ Industrial Case Study: Several Chronos components are already
being used in an industrial setting as the primary storage backend for
the IT Landscape Documentation tool Txture8 [
As of July 2016, large parts of Chronos have already been implemented. The core of ChronoDB is complete9, and a paper titled Scalable Versioning for Key-Value Stores has been accepted by and will be published at the 5th International Conference on Data Management Technologies and Applications (DATA 2016). This paper covers the theoretical foundations and implementation aspects of ChronoDB. The evaluation of the core components of ChronoGraph as a backend for Txture is currently ongoing and shows very promising early results with respect to performance. A publication on this topic is the next step. The implementation of ChronoSphere is currently work-in-progress. We plan a publication on this topic at the MODELS Conference 2017. For the nal publication, we aim for a journal paper in 2018 that summarizes our ndings and combines them with the results of an industrial case study. We aim for the conclusion and publication of the PhD thesis by the end of 2018. 8 www.txture.tools 9 https://github.com/MartinHaeusler/chronos/tree/master/chronodb In this paper, we have provided an overview over the Chronos project that aims to provide a scalable solution for storing, versioning and querying model data, based on NoSQL graph and key-value techniques. In contrast to existing solutions, it will not rely upon XML serialization or object-relational mappings. Instead, the entire data management stack will be implemented from scratch, with the use case of storing large models in mind. The resulting artefact will serve as a proof{of{concept and will be tested against an automated test suite and in an industrial case study. Comparative benchmarks with existing repositories are also part of the evaluation. The planned end of the PhD thesis is in 2018, with a total of three conference publications and one journal paper.