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
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
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
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