Code generation is an important tool in model-driven engineering. It eases the transition between designing models and implementing systems in code. This project aims to make code generation a web service, adding a layer of abstraction between the user's models and the generator used to produce their code.
The goal of this project is to develop a web service that allows users to publish code generators and execute them online. Generators are publicly available so anyone can use them on their own models. A user uploads their models to be processed and receives the output les produced by their chosen generator.
The motivation for this project is having the ability to generate code from models without the need for locally-available software. This removes the e ort of learning and maintaining the software from the user. It bene ts the situation where the individual writing the code generator is di erent to the one designing the models, like a team or client. The model designer does not need to know how the generator works but can bene t from the output it creates using their own models. The same abstraction can be placed on the service itself. While the internal system may change - to be optimised or made faster for example - the API stays the same.
Code generation as a service also bene ts situations where text is generated from very large models depicting a complex system. Computing in the cloud can have increased processing power and resources over a local machine, so code generation could take a shorter amount of time to complete, aiding the productivity of the user. An investigation of previous work in this area has been carried out and will be presented in this section. This process helps determine whether the project is novel enough to pursue, and the potential bene ts of the nished system.
Recently, there has been an interest for model-driven engineering solutions in the cloud. Other elds of technology have, in recent years, adopted web-based services successfully. For example, cloud storage of les and document editing, integrated development environments (IDEs) accessed through the web, and cloud computation.
As people that make use of MDE are also software engineers, it is interesting
to take a look at what side of software engineering the current services focus
on. There are currently many services that provide standard IDE facilities like
a code editor with syntax highlighting and error detection (such as Koding [
While there has been lots of progress made with online code compilation, code
generation has been less prevalent. APIMATIC [
One of the most fully-featured services available online is GenMyModel [
This project aims to have some novel di erences in its implementation.
Because it will primarily use Epsilon [
This section will describe how the service is used by a client as a step-by-step process, and detail how the service works internally. The service was written in Java, chosen because of its portability and maturity of support.
Representational State Transfer (REST) was chosen as the web service architecture because of the ease in which a client can be implemented to interface with a RESTful service. It was desirable to allow anyone to write a client for the service. Requests made to the service also work well with the RESTful style. For example, getting a list of generators with a GET request, or publishing a new one with a POST request. 3.1
Publishing a Generator One of the main aims of the project is allowing users to execute generators that others have made, and reuse generators without having to upload them to the service again. To this end, generators are `published' to the service and available for anyone to use on their own models. A system consists of an input, a process, and an output. Generators act as the processing stage of the system, with a model as the input and text as output. Because generators should be reusable, they have to be independent from the models they can parse.
Apache Ant [
<model ref="M"/> </epsilon.egl> </target> </project>
Figure 1 is an example of how an Ant build le might be constructed for a generator. XML nodes starting with \epsilon" are tasks for generating the output text. The Ant build lists \test.ecore" as the metamodel in which all models need to conform to. \Test.egl" is also listed as the EGL le that will be executed against the model. Both these les need to be included in upload sent to the service.
While planning the service, a decision needed to be made about how
generators would be stored/accessed on the service. The straightforward approach
would be to directly upload the les to the service. Instead, it was decided that
generators would be retrieved from GitHub [
POST /service/generators?owner=robcrocombe&repo=emf-gen In this project, a job refers to the single process of creating a request for text to be generated from a model, executing that request, and returning the output to the client. A job request should select which generator to use and contain the necessary metadata required for the generator to run.
An important design decision made was how the client would wait for a job to be completed. The amount of time it takes for code generation to run depends on the size of the model and complexity of the generator. Jobs normally take longer than the usual HTTP request so there needed to be a suitable system for dealing with this. The solution was that a job POST request would initialise a separate thread for the job and return a unique ID. The client then uses the ID to poll the service for the status of the job, ideally at regular intervals. When the job is complete a status request will instead return a zip le containing the generated output.
When a client wishes to create a job, a POST request is sent to the /job endpoint in the service. The request body has a `multipart/form-data' content type. This allows les to be attached as elds in the form. Every request must contain a JSON le containing the metadata needed by the service.
Figure 3 is an example of the JSON le. Here, the client speci es which generator to use with the \githubOwner" and \repoName" elds. Any string properties can be given as an array here. The properties and les are both inserted into the build.xml le before Apache Ant executes it. { } githubOwner: "robcrocombe", repoName: "emf-gen", properties: [ { name: "debug", value: "true" } ], files: [ { } ] fieldName: "file1", propertyName: "model", filePath: "test.model"
For example, the le with \model" as the \propertyName" will be put into the \model" property in gure 1.
Each item in the \ les" array contains three elds. \ eldName" links the item where the le has been attached in the form. These two elds must have the same name. \propertyName" is the name of property in the Ant build this le is for. \ lePath" is the path of the le including the extension. This eld must be a relative path. This means, for example, if the eld contains \directory/subdirectory/test.model" the le will be put into that folder structure relative to the job folder on the server.
This upload method also supports folders. To do this, each le must be included as an item in the \ les" array, with their le path including the folder they belong to. The property name is not included, as the le on its own is not a property value. Instead, the folder is added to the \properties" array, the name eld being the name of the property in the Ant build.xml, and the value being the name of the folder. This works because les are still Ant properties, they just have to be declared separately so they can be uploaded to the service.
Figure 4 is a sequence diagram summarising how a job is created, how its status is polled, and the output received by the client. The advantage of this solution is that it scales well. If the processing time is short, the rst poll would return the output. If it is long, there is little overhead to requesting the status regularly. An alternative solution was to open a small server on the client program and when the job is complete it will send the output to the client like red event. This was not as preferable because it was desired that the client would be lightweight and simple to implement. The service should also stay RESTful so the client should be the only entity making requests.
This paper has covered reasons for pursuing this project, its development progress, and how the service can be consumed. If this project was to be made available for public use some features would have to be developed further. For example, currently only public GitHub repositories can be published to the service, as private repositories would need authentication. Private repositories would be important for users if they wish to work on closed-source projects.
Fleshing out generator publishing would also be desirable. For example adding user accounts to keep track of generators and allow them to be updated by their owners.