In this paper, we present a solution to the TTC'20 offline case Round-trip migration of object-oriented data model instances [1]. This case involves the application of maintenance tasks to web APIs that are associated with domain models so that updates are backward compatible. The solution presented in this article features the EMF-Syncer [2], a synchronization tool for bridging MDE-agnostic programs and MDE-aware programs, which may have some similarities in their object-oriented data models at run time. EMF-Syncer provides a generic synchronization strategy that exploits such similarities automatically and is, therefore, a suitable candidate for solving the proposed problems, since each problem relies on a small change and there is a large overlap between two versions of the same data model. In the paper, we used the case benchmark framework to justify that our solution exhibits a good balance between specification conciseness and performance.
The Round-trip migration of object-oriented data model instances case [1] for the TTC'20 exposes an evolution problem in the context of web API development, where different APIs work on top of a common data model. To accommodate new or changing requirements in the system, API designers need to ensure backward-compatible changes in the underlying data model. Assuming an agile software development environment where data models may evolve rapidly, the case proposes the use of roundtrip migration services, relying on Model-Driven Engineering (MDE) technology, for enabling the co-existence of different versions of the data model at run time. In particular, the Eclipse Modeling Framework (EMF) [3] is used to encode data models with the EMF meta-modeling language, namely Ecore, so that tools built atop EMF can be used to implement data migration services.
The solution presented in this article features the EMF-Syncer [2], a synchronization tool for bridging MDEagnostic programs and MDE-aware programs, which may have some similarities in their object-oriented data models 1 , at run time. EMF-Syncer provides a generic synchronization strategy that exploits such similarities automatically and is, therefore, a suitable candidate for solving the proposed problems, since each problem relies on a small change and there is a large overlap between two versions of the same data model. The EMF-Syncer assumes that MDE-agnostic programs are implemented in a JVM language and that MDE-aware programs represent their data model using EMF-generated code.
Given a source data model (represented in a package of classes in the MDE-agnostic program), a target data model (represented as an Ecore model in an EMF-based program), and a collection of objects representing the source program state, EMF-Syncer translates the MDEagnostic objects as an EMF model instance in the target EMF-based program, synchronizing the state of both programs at run time. EMF-Syncer automatically infers structural similarities between object-oriented data models by mapping object structural features by name, when found, translating both attribute and reference values. This translation can be performed using a push-based model, where the entire source program state is migrated, or using a pull-based model, where only those feature values accessed in the target program are migrated. Once synchronization is established, changes that have been applied to target EMF model instances can be incrementally back-propagated to the source MDE-agnostic counterpart. Incrementality of back-migration entails that only changes in target model instances are propagated back and merged within the source instance.
The aforementioned generic mapping strategy that is built in EMF-Syncer can be customized in order to allow for more complex data transformations between the data models involved. A domain-specific mapping strategy is declared with a mapping specification that maps a source feature type to a target feature type, possibly including feature value transformations, either from source to target, or from target to source, or both. Two main custom mapping strategies can be declared: For the TTC 2020 case, we are relying on the observation that an EMF-based program can be regarded as a plain Java program. Hence, the given Java program will refer to the source data model and the EMF-based program will refer to the target data model. In the following sections, we discuss the solution to the case in ยง2, and the evaluation of the solution in ยง3 using the evaluation criteria proposed in the case, wrapping up with some conclusions in ยง4.
The solutions to the different tasks of the case are explained below and are available at https://github.com/emf-syncer/ttc20-roundtrip.
The solution has been implemented using the language Xtend [4].
In this task, a new feature age is added to the class Person in the modified data model ๐2 and when a Person instance is migrated, its feature value is set to -1. When the instance is migrated back, this information is lost.
The solution Task1_M1_M2_M1, shown in the listing below, illustrates the pattern used in all of the solutions. The EMF-Syncer is used by instantiating the class EMFSyncer between a source Java package name list #['scenario1_v1'] and a target Ecore model in the constructor. All of the solutions use the push-based model in syncForward, which is specified by indicating syncer.syncingStrategy = SyncingStrategy.EAGER, forcing the migration of the entire source instance.
In the method migrate, the statement syncer.syncForward(person_v1) migrates the source Person instance obtaining the target instance with the age feature, which is not initialized until the statement person_v2.age = -1 is evaluated. In the method migrateBack, the statement syncer.syncBack(person_v2) migrates the instance back to the source Java program.
The method modify is used to implement changes to target model instances that need to be propagated back. This logic is hardcoded in test cases in the benchmark framework. EMF-Syncer needs to track which changes are performed in the target model instance in order to enable incremental back migration. Therefore, this logic has been moved from test cases to task classes. It is important to note that the bidirectional transformation between both data models is completely inferred by the EMF-Syncer automatically in this task. In the back migration, as the age feature does not exist in the source program, it is not propagated.
The solution to the symmetric problem Task1_M2_M1_M2 is achieved by inverting the direction in which the EMF-Syncer is applied to the data models, as seen in the listing below. In this case, the data model M2 is regarded as the Java program and the data model M1 as the EMF program. In this case, the value of the age feature of a Person class is preserved on the back migration because this feature does not exist in M1 and, therefore, no changes can be applied to the feature age. In the following subsections, solutions to symmetric problems are achieved by flipping, as for this task, the direction in which the EMF-Syncer is applied and are not included in the paper.
In this task, the feature age of the class Person is renamed to ybirth, and its semantics is changed by representing the age and the year of birth, respectively. This renaming involves domain-specific semantics that is not present in the Ecore model, requiring a mapping specification so that the EMF-Syncer can perform the data transformation correctly.
A mapping specification consists of a collection of mappings between feature types by name, 'Person', 'age', /* <-> */ 'Person', 'ybirth', by adding optional feature value transformations as lambda expressions. For example, in the solution, the lambda expression gets a Person instance from the source data model and returns the ybirth value. When the EMF-Syncer applies the transformation syncForward, the feature value for Person::ybirth will be obtained by applying this expression. The rest of the solution follows the same structure as the solution explained in ยง2.1. This solution also contains an example of how to track changes performed in the target instance, in the modify method, that need to be migrated back. This change is encoded in the corresponding test case in the original test framework.
This task combines Task_1 and Task_2 with the aim of analysing reuse mechanisms that can be employed. The solution below reuses the transformation logic of Task_1, as it is handled by the EMF-Syncer automatically, and it reuses the mapping specification of Task_2, which is defined as a static field. The rest of the solution is as in ยง2.1, after renaming the corresponding namespaces.
In this section, we provide an evaluation of the solution according to the evaluation criteria proposed in [1].
Two test cases are provided for checking the correctness of each task. A test case provides the input for a round-trip migration and the expected output. The test framework has been adapted in order to work with code generated from Ecore models via EMF, which is required by EMF-Syncer . The main properties (namely, name, nsPrefix and nsUri) of the EPackage in each Ecore model were updated in order to generate disjoint namespaces. In test cases, loading resources for each Ecore model was modified in order to use the corresponding generated factory for each model instance. Model instances, used as input/output data, were modified to refer to the corresponding nsUri. In some cases, the test case also performs a change in the target instance, as in Task_3, that needs to be propagated back to the source instance. Such modifications have been encoded in the task itself, in the method modify, as the EMF-Syncer needs to track those changes. Such changes refer to implementation details and do not alter the correctness properties checked2 by the test suite.
Solutions for all of the tasks have been implemented and all of them pass the correctness check.
Task solutions have been implemented using Xtend. However, the EMF-Syncer can be used from Java programs as well. Given that the transformation in most of the solutions is inferred automatically and that solutions use generated code, instead of using the EMF reflection API for accessing/mutating values, we argue that solutions are likely to be more comprehensible than the reference ones.
When custom mappings are required, e.g. in Task_2 and in Task_4, these are defined by instantiating the class EMFSyncerMapping, where feature value transformations are defined as Xtend lambda expressions. Such mapping expressions could have been defined similarly in Java as well.
In the solution for most of the tasks, the EMF-Syncer infers both transformations to be applied, syncForward and syncBack, automatically. In such cases, the programmer does not need to provide a transformation specification and a bidirectional data transformation is being used internally so that Java instances can be migrated to an EMF program, and back again, at run time. A custom mapping specification containing only feature type renamings is fully bidirectional. Feature value transformation expressions are unidirectional though.
Therefore, the EMF-Syncer provides support for bidirectional transformations by default for all of the solutions and accommodates special cases with unidirectional feature value transformations, which correspond to a fraction of the data migration to be performed.
Re-usability is internalized in the EMF-Syncer by inferring transformations automatically. That is, when a user does not need to provide a mapping specification, the transformation logic in the EMF-Syncer is reused for any data model change. For example, reuse of the logic transformation in Task_1 falls under this category.
On the other hand, as EMF-Syncer is a JVM library, a programmer can rely on reuse mechanisms provided by the JVM language of choice. For example, reuse of the transformation logic in Task_2 falls under this category. The mapping specification defined for Task_2 is reused by calling a static field and by using a common interface for the class Person, which has been implemented using inheritance in Task_4.
We have run the performance tests both for the reference solution and for the EMF-Syncer solution on a MacBookPro11,5 Core i7 2.5 GHz, with four cores and 16 GB of RAM. The runtime results (in ms.) obtained are displayed in Fig. 1. The EMF-Syncer solution exhibits a linear growth with respect to the number of iterations, as instructed in the case benchmark. However, the EMF-Syncer solution is more efficient than the reference one thanks to its support for incremental migration of changes. While the reference solution takes about 31 s. for 2 million iterations, the EMF-Syncer solution takes about 9 s, with an improvement factor of 70%. The incremental propagation relies on a traceability model that caches relevant data at run time. An analysis of memory consumption is left for future work as it was not part of the case benchmark.
Following from the justification of the evaluation criteria in the section above, the results are summarized in Table 1, where the score ๐ out of ๐ is expressed as ๐(๐ ).
Overall, this solution shows that the EMF-Syncer helps in achieving a competitive trade-off between data migration specification and performance. On the one hand, the automatic inference of data transformations between different object-oriented data models reduces the need for specifying data transformations. When these have to be specified, a programmer can rely on their programming skills, using a JVM programming language, for reusing transformation logic. On the other hand, EMF-Syncer can be used as an efficient data migration service at run time. For example, the EMF-Syncer solution is faster than the reference solution developed in raw Java. EMF-Syncer can be used for building more scalable solutions, involving very large models, by using the pull-based model for propagating changes in syncForward only when they are required in the target program.