The communication of web-based services is typically organized through public APIs which rely on a common data model shared among all system components. To accommodate new or changing requirements, a common approach is to plan data model changes in a backward compatible fashion. While this relieves developers from an instant migration of the system components including the data they are operating on, it causes serious maintenance problems and architectural erosion in the long term. We argue that an alternative solution to this problem is to use a translation layer serving as a round-trip migration service which is responsible for the forth-and-back translation of object-oriented data model instances of diferent versions. However, the development of such a round-trip migration service is not yet properly supported by existing technologies. In this challenge, we focus on the key task of developing the required migration functions, framing this as a model transformation problem.
1. Introduction migrate the existing data using tools such as Liquibase1.
Once the migration has been performed, components
Context: In web development, the communication of relying on version 1 of the data model are replaced by
web-based services is typically organized through pub- their updated successor versions.
lic APIs which rely on a common data model shared In practice, however, not all the afected components
among all system components. Over time, the shared can be migrated instantly and at the same time [
Figure 1 illustrates this problem by means of a typical flexible solution would be to operate components relying example of a distributed system exposing a three-tier on diferent data model versions at the same time and to architecture with a client, a service and a database layer. use a translation layer serving as round-trip migration The API and its underlying data model are evolved from service being responsible for the forth-and-back translaversion 1 (red, not striped) to version 2 (green, striped), tion of object-oriented data model instances of diferent which may lead to diferent architectural evolution sce- versions. The evolution scenarios ➋, ➌ and ➍ use such a narios, depending on the temporal order of updating the involved components. Ideally, all components are up- 1https://www.liquibase.org/ dated simultaneously (scenario ➊). When performed in an online fashion, we need a translation layer (TL) to 1 TL 1
V.1 V.2 API V.1
API V.2
API V.1
API V.1
TL 2 V.1 V.2 TL 3 V.1 V.2 TL 4
V.1 V.2
API V.2
Service V.2
round-trip migration service to migrate and migrate back changes in methods or endpoints in HTTP are out of
shared data model instances on demand. Architecturally, scope. Protocol changes (e.g., change of message format,
this allows for greater flexibility than the aforementioned authentication, rate limit) as mentioned in Wang et al.
solutions. It leaves open a wide variety of design deci- [
Research Gap: Although it seems to be an attractive a transformation problem that abstracts from technosolution to deal with data model evolution, the develop- logical details. While the shared data model is typically ment of a round-trip migration layer which is responsible defined through Web API specification languages, we for the the forth-and-back translation of object-oriented choose a more simple and explicit representation using data model instances of diferent versions is not yet prop- an object-oriented modeling approach. Conceptually, we erly supported by existing technologies. consider object-oriented data models and instances as
Frameworks such as Google’s Protocol Bufers 2, graphs, serving as basis for the problem definition which
Apache Thrift3 or Apache Avro4 support versioning of we present more formally in Section 2. Next, in Section 3,
the whole API and provide annotations in order to change we give a set of selected data model evolution scenarios
an API in a backwards compatible way. On a more fine- and the corresponding round-trip migration tasks which
grained level, UpgradeJ [
Traditional research on data model evolution and in- Relation to Previous TTC Cases: At the 2017
edistance migration has its roots in the database systems tion of the Transformation Tool Contest, the “Families
community. Here, schema evolution generally refers to to Persons Case” [
The same limitation applies to more recent work in of modern web-development languages (e.g., the use of
model-driven engineering. Here, multiple approaches optional fields in Section 3.3) as well as the development
have been proposed addressing the migration of instance process of web applications in general (e.g., our
evaluamodels in response to meta-model changes, referred to as tion criterion re-usability in Section 4.4).
meta-model evolution and model co-evolution [
Challenge in a Nutshell: In this challenge, we focus ideally expect from round-trip migrations. on the key task of developing migration functions which are needed by a round-trip migration service. We only 2.1. Data Models and Instances consider API changes afecting the shared data model, while other aspects of API evolution such as signature Graphs are a natural means to conceptually define objectoriented data models and instances. For the sake of being compatible with the majority of available model transformation technologies, our notion of a graph can be 2https://developers.google.com/protocol-bufers 3https://thrift.apache.org 4https://avro.apache.org transferred to model representations which are based on ent data models to communicate with each other, a the essential MOF (EMOF) standard being defined by the translation layer is responsible for migrating instances OMG5. Specifically, a graph = ( , , , ) forth and back. Formally, a translation layer is a tuple consists of two disjoint sets and containing = (1, 2, , ) where 1 and 2 denote the data the nodes and the edges of the graph, respectively. Ev- models the layer translates from and to via migration ery edge represents a directed connection between two functions : ℳ1 → ℳ2 and : ℳ2 → ℳ1, respecnodes, which are called the source and target nodes tively. Given an instance 1 ∈ ℳ1, we refer to the of the edge, formally represented by source and tar- consecutive application of and to 1, i.e., ( (1)), get functions , : → . Given two as the round-trip migration of 1 via 2. Likewise, since graphs and , a pair of functions ( , ) with translation layers are supposed to work symmetrically in : → and : → forms a graph either direction, given an instance 2 ∈ ℳ2, ((2)) morphism : → if it maps the nodes and edges of denotes the round-trip migration of 2 via 1. The to those of in a structure-preserving way, i.e., ∀ ∈ round-trip migration of an instance 1 via 2 (resp. : (()) = ( ()) ∧ (()) = 2 via 1) is called successful if ( (1)) = 1 (resp. ( ()). ((2)) = 2). A translation layer is considered
An object-oriented data model is conceptually con- successfully round-trip-migrating if the following
condisidered as a distinguished graph referred to as type tions hold:
graph , while an instance of this data model is formally
treated as an instance graph typed over . Formally, a ∀ 1 ∈ ℳ1 : ( (1)) = 1 (1)
type graph = ( , , , , , ) is a special ∀ 2 ∈ ℳ2 : ((2)) = 2 (2)
graph whose nodes and edges are representing types, and
which comprises the definition of a node type hierarchy
⊆ × , which must be an acyclic relation, and a
set ⊆ identifying abstract node types. The typing
relation between instances and data models may be
formalized by a special graph morphism : →
relating an instance graph with its associated type graph
[
In order to avoid going into any technical details of model transformation approaches yet, we will take an extensional view on data models. That is, speaking about a data model , then ℳ refers to the (infinite) set of data model instances which are properly typed over .
In practice, round-trip migrations as introduced above will barely happen since, more often than not, a component will not directly return an instance it just received but rather apply some modification to the instance before returning it. Given two data models 1 and 2, a round-trip migration with modification of an instance 1 ∈ ℳ1 via 2 is a consecutive application of functions ∘ 2 ∘ (1) = (2( (1))) where, like above, and are migration functions from 1 to 2 and 2 to 1, respectively, and 2 : ℳ2 → ℳ2 is an instance modification function performing the modification of the migrated instance (1) ∈ ℳ2. Due to the modification of (1), the original definition of a successful round-trip migration is not suitable anymore. The result of migrating back the modified instance 2( (1)) ∈ ℳ2 is not expected to be the original instance 1. Intuitively, the result is rather expected to be a modification 1(1) of instance 1 where 1 : ℳ1 → ℳ1 represents the corresponding comodification of 2 on data model 1. A translation layer 2.2. Round-Trip Migration Functions = (1, 2, , ) which handles round-trip migraWe diferentiate the migration and the modification of tions between data models 1 and 2 is called successinstances. Given two data models 1 and 2 with fully round-trip migrating with modification if there are 1 ̸= 2, a total function : ℳ1 → ℳ2 is con- co-modifications 1 : ℳ1 → ℳ1 and 2 : ℳ2 → ℳ2 sidered a migration function from 1 to 2. Given two such that the following conditions hold: imnisgtarantceedsto1∈2 iℳf1(an1d) =2∈2.ℳOn2,thweecsoanytrtahrayt, giv1eins ∀ 1 ∈ ℳ1 : (2( (1))) = 1(1) (3) a single data model , a total function : ℳ → ℳ ∀ 2 ∈ ℳ2 : (1((2))) = 2(2) (4) is considered an instance modification function . Given two instances and ′ typed over , we say that is 3. Selected Evolution Scenarios modified to become ′ if () = ′.
To allow two components which depend on difer5https://www.omg.org/spec/MOF
In the following sections 3.2 through 3.4, we introduce a selection of diferent cases of data model evolution and according round-trip migration scenarios. Data models :Person name = "Alice"
:Person name = "Alice" and instances are represented using UML class and object Person instance does not provide a concrete value for diagram notations, respectively. Each scenario comprises this field. The more complicated case, however, is the two versions of a data model that demonstrate the ap- 2 ↦→ 1 ↦→ 2 round-trip migration since it needs to plication of typical edit operations on object-oriented access a previous revision of the migrated object during a data models in a minimal context. Each scenario can later stage in the round-trip migration. Here, the value of be interpreted from two perspectives, i.e., from 1 to ifeld age should be recovered from the original Person 2, or vice versa. The respective edit operations which instance. In the context of traditional bidirectional transcan be observed in both cases are inverse to each other. formation, this can be considered as a standard scenario We discuss round-trip migrations in both directions, us- which we use as a warm-up task of our round-trip miing the shorthand notations 1 ↦→ 2 ↦→ 1 and gration case. 2 ↦→ 1 ↦→ 2 , respectively.
For each of these round-trip migration scenarios, the 3.2. Rename Field task is to specify the required migration functions, referred to as migrate and migrate back in the sequel. That In this evolution scenario, the name of a field is changed. is, each of the four data model evolution scenarios yields The most simple reason for this kind of change is to imtwo tasks which we ask to be solved by solution providers, prove the wording in the data model to better reflect the summing up to a total number of eight tasks for the entire terminology of a domain of interest. A more challenging case. Since all of these tasks are independent from each change is to slightly update the meaning of a field, as it is other, participants may address a subset of them. the case in our evolution scenario presented in Figure 2 (left). Here, the field age in 1 is changed to ybirth in 3.1. Create/Delete Field 2, now capturing a Person’s year of birth instead of its current age.
In this scenario, a new field is added to (removed from) The migration functions which are to be developed for a class of the data model, as illustrated in Figure 3 (left). this scenario should account for this semantic change We assume this field to be functionally independent from and convert between proper values of fields age and any other field of the same class. ybirth. As illustrated in Figure 2 (right), we assume the
As illustrated in Figure 3 (right), in a 1 ↦→ 2 ↦→ current date as a basis for the conversions in both direc1 round-trip migration, the new field age should be tions. In this case, the change in the semantics of age and set to some suitable default value since the original ybirth requires the integration of some user-defined
:Person age = 25 arithmetic operation during transformation. Purely struc- data model shown in Figure 4 (left). The latter case is tural approaches often lack this feature, even though in represented by the default notation used for all other our context of Web APIs this is an important requirement. fields, meaning that the field is a mandatory one. The key issue here is to deal with potential null3.3. Declare Field Optional/Mandatory values in 2 and their corresponding default values in 1. This is rather straightforward in a 1 ↦→ 2 ↦→ In this scenario, the multiplicity of a field is generalized 1 round-trip migration, as illustrated in Figure 4. Here, (specialized) from 1 to 0..1 (0..1 to 1). The former case null-values in 2 may occur due to a modification of means that the field is declared to be optional, as indicated the migrated instance, and they should be translated to a by the notation [?] attached to field name in 2 of the default value in 1. The 2 ↦→ 1 ↦→ 2 round-trip migration is more complicated. Here, we have to check according round-trip migration scenarios are supported, whether a default value has been synthesized during mi- the more expressive is the transformation approach. gration or through an explicit modification. In the former To turn this intuition into a measurable evaluation case, as illustrated by the upper right example shown in criterion, we assess the correctness of each task by proFigure 4, a synthesized default value is migrated back to viding sets of associated tests. A test case comprises pairs a null-value. In the latter case, illustrated by the lower of instances serving as input and as expected output of right example shown in Figure 4, the default value is the a round-trip migration. For each of the tasks presented result of an explicit modification in 1, which should be in Section 3, a first test case is derived from the example migrated back to a default value instead of a null-value presented in that section. A second test case is added in in 2. This evolution scenario is of special interest to order to prevent literal encodings of solutions (except for us, since optional fields are a common pattern used in the taks presented in Section 3.3, which already has two the design and evolution of Web APIs. associated test cases. A task is considered to be solved correctly if it passes all tests. 3.4. Multiple Edits All tasks are scored by means of the provided test cases. A point is given for each passing test case, and points In this evolution scenario, we combine two edit opera- are summarized over all test cases. This means that all tions which we have already considered before. As we tasks are scored evenly between zero and two points. can see in Figure 5 (left), from an 1 to 2 perspective, Zero means the task has not been tackled at all, one point the field age of class Dog has been deleted, which corre- indicates a partial solution, and two points mean that the sponds to the edit operation considered in the evolution task has been solved and the transformation has been scenario presented in Section 3.1. At the same time, the implemented correctly. name and semantics of field age of the referenced class Person has been changed to ybirth, as in the evolution 4.2. Comprehensibility scenario presented in Section 3.2.
The corresponding 1 ↦→ 2 ↦→ 1 and 2 ↦→ Specifications of migration functions should be compre1 ↦→ 2 round-trip migrations are illustrated in Fig- hensible in order to be maintainable and to allow for ure 5 (right). Their specification can be considered as better manual validation. Our idea of evaluating solua combination of the migration functions required for tions is to compare their comprehensibility with that of the evolution scenarios presented in Section 3.2 and Sec- the provided reference solution (see Section 5). For each tion 3.1. The main aim of this scenario is to call for task, the comprehensibility of the reference solution is solutions that support some form of re-usability (see Sec- scored by one point. Better, equal and worse comprehention 4). sibility of a submitted solution are acknowledged by two, one and zero points, respectively.
We acknowledge that such a classification is highly
bi4. Evaluation Criteria ased by subjective preferences. Developers being familiar
with model transformation languages such as Henshin
To evaluate the quality of the proposed solutions, we give or ATL most likely prefer a declarative or
declarativea set of quality characteristics which we consider to be rel- imperative style, while mainstream web developers will
evant for the specification of round-trip migrations. We most likely prefer a purely imperative style of writing
draw inspirations from previous work on defining qual- migrations. More objective measures such as code
metity attributes of model transformations [
Bidirectional transformations (BX) [
Within this challenge, we do not insist on any particu- time characteristics of the proposed solutions, we repeatlar mechanism for specifying bidirectional transforma- edly run the round-trip migrations required to support tions, and all mechanisms are ranked equally. All tasks the evaluation scenarios described in Section 3 for a large and extension tasks are scored evenly with zero (no bidi- number of iterations and measure their execution time. In rectionality) or one point (support for bidirectionality). general however, we consider runtime performance a secondary evaluation criterion. Hence, diferences among 4.4. Re-usability proposed solutions with regards to runtime performance shall only serve as a tie-breaker among solutions which score equally for the other four criteria.
As with any other kind of software, re-use mechanisms are an indispensable means to increase the productivity and quality of model transformations. To that end, numerous re-use mechanisms for model transformations 5. Reference Solution have been proposed in the literature, a survey may be found in [22]. We evaluate re-usability by means of To provide a reference solution for this case, we imthe “Multiple Edits” evolution scenario presented in Sec- plemented all the migration functions which are retion 3.4 since it subsumes the scenarios presented in quired to support the 8 round-trip migration tasks arissections 3.2 and 3.1. ing from our four data model evolution scenarios pre
One possible option is to achieve re-usability by means sented in Section 3 in Java. Its integration into the evaluof delegation. Specifically, when developing migration ation framework presented in Appendix A is illustrated functions supporting the round-trip migration of Dog in Figure 7 (bottom). Each task is realized by a coninstances, this could be achieved by, e.g., delegating the crete subclass of class AbstractTask, each of which migration of the referenced Person instances to migra- is being instantiated by the concrete task factory called tion functions which have been already defined. JavaTaskFactory. None of the migrations is delegated
Another possible re-use mechanism could be to ab- to a dedicated model transformation system, but the mistract from the concrete data models and to specify the re- gration functions migrate and migrateBack are diquired migration functions in a generic manner, focusing rectly implemented in Java. on the conceptual parts of the respective edit operations.
The generic migration functions would then be instan- Qualitative evaluation results Table 1 summarizes tiated for the concrete data model used in this scenario. the qualitative evaluation results for our Java-based refThis is similar to the extraction of core transformation erence solution, namely for the criteria expressiveness, concepts that generalize over several meta-models [23]. comprehensibility, bidirectionality and re-usability. On In the context of Web APIs, we see this as a core re- the one hand, it is not surprising that a general purpose quirement of a feasible transformation approach. In our programming language like Java is expressive enough to setting, the continuous evolution of a data model also implies the continuous development of a corresponding migration layer. From a software engineering point of 40000 Total Transformation Runtime view, a transformation approach should therefore pro- 35000 vide support for re-usability. More specifically, s single 30000 change to the data model should require only one corre- )(sm25000 sponding change to the migration layer, which implies item20000 that existing migration code can be re-used. unR1105000000
We do not insist on any particular re-use mechanism, 5000 and all re-use mechanisms are ranked equally. Support 0 for re-usability is acknowledged by four points, while no 0 250000 500000 75000N0o. o1f0R0e0p0e0t0itio1n2s50000 1500000 1750000 2000000 points are given if the specification has been developed Figure 6: Performance results of our provided reference sofrom scratch. lution.
Evolution Scenario / Task Create/Delete Field
Task_1_M1_M2_M1
Task_1_M2_M1_M2 Rename Field
Task_2_M1_M2_M1
Task_2_M2_M1_M2 Declare Field Optional/Mandatory
Task_3_M1_M2_M1
Task_3_M2_M1_M2 Multiple Edits
Task_4_M1_M2_M1 Task_4_M2_M1_M2 correctly solve all the tasks provided with this case. Thus, One of the next steps to further extend this challenge the reference solution achieves the maximum score in could be to study more evolution scenarios than the four this category, i.e., two points per task summarizing to 16 considered in this paper. Moreover, we could think of points in total. On the other hand, bidirectionality and a (semi-)automated specification of the required roundre-usability are not supported at all. trip migration functions. Again, we are convinced that technologies from the field of model-driven engineerPerformance results Figure 6 illustrates the runtime ing, notably techniques for model matching [31, 32] and characteristics of our reference solution in terms of the diferencing [ 33], can serve as starting point for such performance test of our evaluation framework (see Ap- automation. pendix A). These results were obtained on a Mid-2014 MacBook Pro with an Intel Core i5 processor running at References 2,6 GHz and 8 gigabytes of main memory. As expected, the time consumed to perform the round-trip migrations grows linearly with the number of iterations. It takes about 40 seconds to perform all the 2 million iterations of our performance test.
In this paper, we outlined our vision of a so-called translation layer which supports the communication of webbased services in diferent, incompatible versions. One of the key tasks of implementing such a translation layer is to support the round-trip migration of instances of objectoriented data models in diferent versions. In this challenge description, we phrased this as a model transformation problem which, in contrast to previous TTC cases on the same topic, is driven by the needs and specifics of our application context. We are convinced that modern model transformation technologies such as Henshin [24], VIATRA [25] or ATL [26] are capable of solving the challenge in an elegant way. In particular, solutions to the TTC 2017 “Families to Persons Case” [27, 28, 29, 30] may be adapted to our case with moderate efort. «enumeration»
TaskInfo TASK_1_M1_M2_M1 TASK_1_M2_M1_M2 ...
TASK_4_M2_M1_M2
AllFunctionalTests task_1_M1_M2_M1() task_1_M2_M1_M2() ... task_4_M2_M1_M2()
PerformanceTests testPerformance() «abstract» AbstractBenchmarkTests init() «use» «use» «abstract»
AbstractTaskFactory createTask(TaskInfo info, EPackage M1, EPackage M2) «instantiate» «abstract»
AbstractTask AbstractTask(EPackage M1, EPackage M2) migrate(EObject instance) : EObject migrateBack(EObject instance) : EObject JavaTaskFactory
Task_1_M1_M2_M1 Task_1_M2_M1_M2 Task_4_M2_M1_M2 Task_4_M2_M1_M2
the model comparison tool EMF Compare [34].
A performance test is provided by the class General architecture Tests in our evaluation frame- PerformanceTests. There is only one test method, work may be run as JUnit tests. The abstract class called testPerformance(), which proceeds as follows: AbstractBenchmarkTests serves as a base class for Similarly, to the functional test cases, the test relies on the all concrete tests (see below), doing some basic initializa- correct implementation of the AbstractTaskFactory tion. As illustrated by the architectural overview shown and AbstractTask. During performance testing, all in Figure 7, the class AbstractBenchmarkTests takes test cases provided for the four evaluation scenarios are the client role of an implementation of the Abstract Fac- executed repeatedly. That is, a full round-trip migration, tory design pattern, the classes AbstractTaskFactory involving calls to migrate and migrateBack is perand AbstractTask are supposed to encapsulate con- formed. After a certain number of warm-up iterations, crete solutions. That is, for each of the eight tasks pre- this test loop is repeated for a total of 2 million repetitions. sented in Section 3, solution providers who want to use The test method measures execution with the increasing our evaluation framework are asked to provide a con- number of repetitions and stores the results into the file crete subclass of AbstractTask which is to be instanti- results.csv at the root of the solution’s bundle. See ated by a concrete subclass of AbstractTaskFactory. the provided code repository of the evaluation frameThe class AbstractTask defines the signatures of the work regarding plotting scripts for the resulting data. two central migration functions called migrate and migrateBack, respectively. The idea is that migrate and migrateBack then delegate the actual transforma- Registration of a concrete task factory In order to tion task to the model transformation system used in a register a concrete subclass of AbstractTaskFactory, concrete solution. solution providers may use the Eclipse extension point mechanism. Concrete task factories can be registered Functional tests vs. performance tests All test through a dedicated extension point6. Please note cases for assessing the correctness of each of the that, in this case, the classes AllFunctionalTests eight tasks presented in Section 3 may be run as and PerformanceTests need to be run as JUnit PlugJUnit tests which are collected in the Java class In Test. Alternatively, solution providers may subcalled AllFunctionalTests. Each test method, i.e., class AllFunctionalTests and PerformanceTests task_1_M1_M2_M1() through task_4_M2_M1_M2(), which can be then run as a normal JUnit test. In this case, executes a particular task and checks whether for a given the init method of these concrete subclasses must take input models the obtained output model looks as ex- care of instantiating the concrete task factory. Our refpected. Checking the equivalence of an actual and expected round-trip migration result is performed using erence solution (see Section 5) implements both options for the sake of illustration.
Test data Finally, since many model transformation tools available in the model transformation research community are based on the Eclipse Modeling technology stack, we provide implementations of the data models used in the evolution scenarios presented in Section 3 in EMF Ecore. Consequently, instances serving as test data for assessing the correctness of transformation tasks are represented as EMF instances (often referred to as instance models in the EMF community).