Ever heard of Cloudfier? Cloudfier is a tool for developing business applications based on executable models. But why would you want to do that?, you may be asking. After all, you have been happily building business applications using Java EE, .Net, Ruby on Rails, Node.js or something similar. What is the problem with developing business applications with those tools?, you wonder, as you feel quite productive with your language and frameworks of choice.
Let me try to describe what I believe is the problem:
Information management applications are all about understanding the business domain and providing domain-centric features that serve the needs of the various business stakeholders. Technology is just a means to an end, and the way it is traditionally applied, where business knowledge becomes tightly coupled to the implementation stack, it also becomes an inherent threat to the longevity of the application.
(from a presentation submitted to the Industry Track at CBSoft, the Brazilian Conference on Software, last year)
Cloudfier is an attempt at avoiding the threat of tying your business application irreversibly to a concrete implementation technology by promoting a complete separation between business domain and technological concerns. The way it does that is by offering a high-level modeling/programming language for developing the business application at a more conceptual level, and then providing ways for turning the conceptual solution into a running application, either by executing the conceptual solution natively (model interpretation) or generating code into a concrete implementation technology of your choosing.
Cloudfier programs are UML models
Cloudfier programs are actually UML 2.5 models. Since version 1.5 of the spec, UML has been capable of describing behavior, via the formalism dubbed action semantics.
Besides being compatible with an industry standard, one key benefit of being based on UML is that the UML language provides many high-level concepts that are very important for building business applications and yet are lacking in typical programming languages. Examples are associations, constraints, and state machines.
There is a catch though…
Cloudfier uses TextUML, a textual notation for UML
Modeling behavior with a general purpose language using diagrams is just not practical, so instead of the traditional graphical notation, Cloudfier uses TextUML, an alternative textual notation for creating UML models, which covers features that usually appear in class, state and activity diagrams (Jordi and I talked about TextUML a while ago on modeling-languages.com). But in the end, the language is the same (you can grab the UML files used natively by Cloudfier and import in several UML-compliant tools in the market).
Cloudfier programs are business-centric and technology-free
Cloudfier programs are devoid of any technological choices. At the same time, they are 100% complete from the point of view of addressing business-related functional requirements (and that is all they are about). This opens some very interesting opportunities, as we will see below.
Instant prototyping for early validation
A Cloudfier program can be validated by the business stakeholders from day one. No need to build a database schema, an API, and a user interface just so your users can confirm you got their requirements right. Cloudfier can turn your business-centric conceptual solution into a running application by executing the UML model natively, backed by a relational database, and exposed via a REST API and a dynamically generated web-based user interface that you can provide anyone a link with for early feedback.
Model your tests, test your models
Another nice thing about having models that are executable is that you can write test models for your solution models. What do test models look like? Not much different than tests in 3GL programming languages, except for being at a higher level of abstraction and technology independent.
Gapless code generation
Code generation from models is actually quite popular, however, the most common approach is to generate partial programs: source code that is complete from a structural point of view, but completely lacking of any interesting behavior, which is left for the programmer to fill in by hand. That partial code generation approach defeats most of the benefits of model-driven development.
Cloudfier, being based on executable models, promotes gapless code generation: because the model has everything there is to know about the solution from a conceptual point of view, the code that is generated is complete and ready for use as is.
Supported target platforms
What platforms can Cloudfier generate for?, you ask. We are working on a JavaEE generator (using the great Xtend language), and at this point it can generate a REST back-end using JAX-RS and JPA (accessible via a mobile-friendly generic UI thanks to Kirra, a related project), but that is not production-level yet. A proof-of-concept MEAN (Node.js) generator also exists, but it has been shelved for the time being. But the idea is that the more the merrier, so if you would like to write your own generator for your platform of choice, contributions are welcome, which takes us to the next point…
Cloudfier is open source!
A little known fact is that since early this year Cloudfier was published as open-source on Github, with public builds on Cloudbees. There are two licenses being used for different parts of the code: EPL and AGPL. There is not much of a community yet (that takes time and hard work), and more must be done to make the project more inviting to contributors.
Cloudfier is an online development environment
Cloudfier builds on Eclipse Orion to deliver a complete development environment inside the web browser, including an editor, a compiler, git-based source control, an interpreter, a test runner, and code generators. Feel free to try by visiting develop.cloudfier.com.
Build locally
Cloudfier provides a Maven plug-in so you can compile and test your models using Maven. Check out the cloudfier-maven-plugin on GitHub. The Maven plug-in basically allows publishing your project to Cloudfier, validating it, running model tests and generating code, which is then downloaded into the computer running the build.
Want to know more?
There is quite a bit of documentation. Also, ask away, in the comment section right below, or as a “question” issue on GitHub or on twitter. And last but not least, this is just an introductory post; I will be writing more posts on Cloudfier in the future here on modeling-languages.com, where I will be focusing on specific aspects of Cloudfier, and will be including technical details and examples.
Founder at Abstratt Technologies, where he builds Eclipse-based tools (such as Cloudfier and the TextUML Toolkit) for model-driven development based on executable models, and consults on MDD, application modernization and software architecture. Rafael has BS/MSc degrees in Computer Science at UFSC (Brazil), and has developed software professionally for more than 15 years, in Brazil and in Canada, where he was once a committer in the Eclipse Platform Core team at the IBM/OTI Ottawa Lab.
Hi Ravael,
Could the generated code of be for OpenXJava. If yes, it would offer an industrial strength generated “backend”.
I believe that if you can write some code by hand, it can be generated as well (provided the model or architecture provide the supporting information for that), so it would be a matter of writing a generator that “spoke” OpenXava. Right now, I am working on a pure-JavaEE generator, initially using JPA and JAX-RS, without relying on 3rd-party APIs, so OpenXava support would be more as an idea for others to try. But it seems OpenXava works well with JPA-based domain models, so creating a generator for OpenXava starting from the existing JavaEE generator would make sense.
The goal is indeed that eventually others start writing their own code generators for Cloudfier-based programs (which are just UML models), either selling or publishing them as open-source.