Towards Distributed Ecore Models Jesus´ M. Perera Aracil and Diego Sevilla Ruiz DITEC, University of Murcia, Campus Universitario de Espinardo, 30100, Espinardo, Murcia, Spain Keywords: MDE, REST, Cloud, Ecore. Abstract: Models are the cornerstone of Model-Driven Engineering (MDE). Their size is constantly growing, becoming one of the main problems when it comes to manipulating them, via model-to-model transformations, model- to-text transformations or simply parsing them. In this paper we propose a way of distributing Ecore models representing them as JSON and URLs as identifiers, since HTTP is one of the most successful distributed protocols ever created. An implementation of distributed Ecore models using a RESTful-like service is also presented and and is publicly available. 1 INTRODUCTION the standar serialization format for Ecore models, these are implemented fragment-like depending on Models are a digital representation of reality, and as the position of the target element in the graph (e.g., such they are used as a software artifact and manip- #//EClass refers to metaclass EClass from Ecore). ulated by transformations to generate other artifacts. Cross-references between elements from different Models are becoming more complicated and larger in models are prepended by the path to the XMI file of size, making it difficult for a single computer to parse, the other model. Thus, this strong connection hinders transform or handle them. the ability to split a model into smaller pieces for dis- Some new tools and mechanisms have been de- tribution or even changes in the location of files might signed and implemented, such as paralellization of break them. transformations (Tisi et al., 2013), which enables This paper is structured as follows. Section 2 the execution of rules in parallel by distributing introduces the concepts of distributed models which the load on different cores. The use of continu- are used in our proposal. Section 3 introduces and ations (Cuadrado and Aracil, 2014) has also been describes our approach of distributing Ecore mod- implemented. This continuations enable the auto- els using URLs and JSON representation. Section matic scheduling of transformation rules by suspend- 4 presents our implementation of distributed Ecore ing transformation rules whenever a needed element models. Section 5 discusses related work and Section is not yet transformed or available. 6 summarizes conclusions and future work. There has been advances in data storage facili- ties (Benelallam et al., 2014) (Espinazo-Pagan´ et al., 2015), using databases in a way that queries for mod- 2 BACKGROUND els can be performed in a faster way. Even apply- ing big data techniques on models (Scheidgen and Software industry, and more concretely, Model- Zubow, 2012) (Barmpis and Kolovos, 2014) have Driven Engineering (MDE), is constantly growing. been studied, such as using MapReduce algorithms. In the case of models, these are becoming more and Even though these have alliviated the problem, more complicated as well as bigger in size, up to a it is certain that an implementation which supports point in which using a single computer for handling natively a distribution framework must be designed. models is not viable. This implementation would allow transformations to It is clear that a step forward must be taken in scale transparently for both the user and programmer. order to cope with this increase to still be able to One of the main challenges comes from the rep- use MDE technologies as a valid option. Distribut- resentation of references between model elements. ing Ecore models would allow to better parallelize ac- In XML Metadata Interchange (XMI)(OMG, 2015), cesses to a model, since querying different pieces of 209 Aracil, J. and Ruiz, D. Towards Distributed Ecore Models. DOI: 10.5220/0005685002090216 In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 209-216 ISBN: 978-989-758-168-7 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development the model would be independent from others. In ad- JSON, on the contrary of XML, does not have a dition, it would enable collaboration on models, since mechanism to extend the language with more com- different groups could work on different pieces of the plex values or a description of its structure, such as same model. XMLSchema (W3C, 2001). This is overcome by the We are now going to explain the concepts on fact that the language is simple and structured without which this paper and our proposal of distributed Ecore ambiguity. models heavily rely on. 2.1 REST 3 DISTRIBUTED ECORE Representational State Transfer (REST) (Fielding, MODELS 2000) is an architecture for building web applications. It is based on the idea of offering collections of re- Ecore models are traditionally stored by means of sources through, mostly, HTTP. XMI(OMG, 2015), which is a file-based storage. Ref- RESTful web applications use HTTP methods as erences (and cross-references between different mod- a means of accessing, modifying or deleting resources els) are also file-based, which makes splitting a model uniquely identified by URLs. These methods operate difficult, since it would now need to handle more files in a different way if the URL to which it is applied is and keep them synchronized. a resource or a collection. A roadmap (Clasen et al., 2012) has been pro- posed for distributing models and performing trans- GET method: Retreives the resource or collection • formations in the cloud, but still no implementation as a response. has been designed to fulfill this challenge. POST method: Creates a new element in a collec- We propose to store Ecore models on the cloud as • tion. JSON objects, which would allow for a distributed ac- PUT method: Replaces a collection or resource cess using REST web applications. Model elements • with other. are transformed into a JSON representation of them- selves by a process which will be defined later de- DELETE method: Deletes the resource or collec- • pending on their metaclass. tion. Unique URLs are generated for all model ele- RESTful applications rely heavily on hypermedia, ments based on containment of instances. These in which resources are named and referenced by their URLs are created by the URL of its parent prepended respective URL. A resource is identified by its URL to the name of the containment EReference which and can link (and be linked) to other resources by holds the elements and, if it is the case, its nu- these URLs. meric position (i.e., if an element B is contained in a EReference named ref of A, with URL 2.2 JSON http://www.example.com/A, its URL would be http://www.example.com/A/ref). Root elements JavaScript Object Notation (JSON)(JSON, 2015) of models are given a “base URL” from which the rest is a lightweight data-interchange format based on of the URLs of that model are derived. JavaScript. It is a human readable format which For illustration purposes, we are going to explain makes it easy for humans to understand and write and this approach with 3 models: for computers to parse and serialize. Subset of Ecore meta-meta-model (shown in Fig- In recent years, with the blooming interest in web • ure 1) applications, JSON has seen a rise in popularity at the Bag meta-model (shown in Figure 2). expense of the other big serialization format, XML. • Bag model (shown in Figure 3). JSON has a small but rich data values: • EPackage Strings: a sequence of characters. The base URL for Ecore will be • http://www.example.com/repo/0, that for the Bag Number: integers, floats, scientific notation. • metamodel will be http://www.other.com/repo/1 Booleans. and finally, that for the Bag model will be • Null: no value. http://www.example.com/repo/2. • We are now going to explain in detail the pro- Array: a collection of values. • cess of generating both JSON and URLs for some Object: a collection of key-value pairs, in which metaclasses of Ecore, EClassifier, EPackage and • the keys are Strings naming the value it binds to. EStructuralFeature. 210 Towards Distributed Ecore Models // EClassifier // URL: http://www.example.com/repo/0/ // eClassifiers/0 { "name":"http://www.example.com/repo/0/ eClassifiers/0/name", "abstract":"http://www.example.com/repo/0/ eClassifiers/0/abstract", Figure 1: Ecore subset. "eClass":"http://www.example.com/repo/0/ eClassifiers/0/eClass", ... } // EClass // URL: http://www.example.com/repo/0/ Figure 2: Bag metamodel. // eClassifiers/1 { "eClass":"http://www.example.com/repo/0/ eClassifiers/1/eClass", ... } Figure 3: A simple Bag model. Code Example 1: Ecore subset as JSON. // BagModel 3.1 EClassifiers // URL: http://www.other.com/repo/1/ // eClassifiers/0 Instances of EClassifiers will be transformed by { collecting all their EStructuralFeatures and cre- "name":"http://www.other.com/repo/1/ ating a JSON object which binds the names of eClassifiers/0/name", these EStructuralFeatures to their correspond- "abstract":"http://www.other.com/repo/1/ ing URLs. These new URLs will be the con- eClassifiers/0/abstract", "eClass":"http://www.other.com/repo/1/ catenation of the URL for the EClassifier be- eClassifiers/0/eClass", ing transformed concatenating the name of their ... EStructuralFeatures. } Code Example 1 shows a snippet of how both EClassifier and EClass are transformed into // Element JSON. We assume that their relative positions in their // URL: http://www.other.com/repo/1/ // eClassifiers/1 containment reference are 0 and 1, respectively. It { should be noted that an EClassifier is an EClass "name":"http://www.other.com/repo/1/ instance due to Ecore being its own metamodel. eClassifiers/1/name", EStructuralFeatures conversion to JSON will be "abstract":"http://www.other.com/repo/1/ explained in Subsection 3.3.