This document discusses code generation as a service, where a client can submit modeling artifacts like UML models to a server which will generate code. The server schedules generation jobs, allows clients to check status, and retrieve results. This simplifies generator deployment by eliminating installation on the client side. Potential downsides include network latency, the server becoming a bottleneck, and confidentiality issues. Future work ideas involve supporting other backends, private repositories, synchronous execution, sandboxing, improved job management, and a public deployment.

1. 1
Code Generation as a Service
Robert Crocombe, Dimitris Kolovos
Department of Computer Science
University of York

2. 2Motivation
• Model-Driven Engineering
– Steep learning curve
– Non-trivial tools with lots of dependencies
• Lowering the entry barrier for developers
– Allow developers to model with spreadsheets,
annotated drawings, XML etc.
• Lowering the entry barrier for users
– Simplify distribution and use

3. 3Scenario
• Team of (non-MDE) developers
• Company/client has a bespoke data
persistence architecture
– e.g. system maintains multiple versions of the
data / authorisation through an external system
• Large legacy code-base
– Rewriting all of it using a new framework not an
option
• New code amenable to generation

4. 4
$ orm –model m.uml –lang java –o /temp

6. 6Objectives
• Simplify distribution of code generators
– Minimise effort for generator developers and
users
• Ensure that all members of the team are
always working with the latest version of
the generator

7. 7
$ xgen orm –model m.uml –lang java –o /temp

8. 8
=

9. 9
<project>
...
<property name="model" description="A valid UML model"/>
<property name="lang"
description="Output language: java or python"/>
<epsilon.emf.loadModel name="UML" file="${model}" ... />
<epsilon.evl src="orm.evl"> <!-- validation -->
<model ref="UML"/>
</epsilon.evl>
<epsilon.egl src="orm-${lang}.egx"> <!-- generation -->
<model ref="UML"/>
</epsilon.egl>
...
</project>
build.xml

10. 10
<project>
<!-- #file -->
<property name="model" description="A valid UML model"/>
<!-- #string -->
<property name="lang"
description="Output language: java or python"/>
<epsilon.emf.loadModel name="UML" file="${model}" ... />
<epsilon.evl src="orm.evl"> <!-- validation -->
<model ref="UML"/>
</epsilon.evl>
<epsilon.egl src="orm-${lang}.egx"> <!-- generation -->
<model ref="UML"/>
</epsilon.egl>
...
</project>
build.xml

11. 11
$ xgen orm –model m.uml –lang java –o /temp

12. 12Asynchronous Execution
• When xgen is executed:
– the server schedules a new generation job;
– returns the scheduled job's id
• xgen can then query the server for the status of
that job
– Waiting
– Running
– Compressing
– Success (separate call to retrieve output)
– Error (+log)
– Cancel
• Jobs can be cancelled

13. 13
$ xgen orm –model m.uml –lang java –o /temp

14. 14
$ xgen dk/orm –model m.uml –lang java –o /temp

15. 15Pros/Cons
• Pros
– Simplifies generator deployment
– Users only need to install a thin client
– Don't have to reveal the generation logic
• Cons
– Network latency
– Generation server can become a bottleneck
– Confidentiality

16. 16Future Work
• Support other back-ends (e.g. GitLab)
• Private generator repositories
• Synchronous execution (for small jobs)
• Sandboxing
• Job management
– e.g. kill long-running jobs
• Deploy a publicly-accessible version of the
generation server
– e.g. on Google AppEngine