OSGi Community Event 2017 Presentation by Simon Chemouil [Lambdacube] In an ideal world, business code would be decoupled from implementation details. It would be domain driven and self-contained; it would live in a single location, and that would make it easier to maintain. In practice, things get messy. Business code gets scattered in a Java/OSGi back-end – potentially distributed –, in a Web front-end written in TypeScript and in a native app for a phone or a tablet. In each of these platforms, these domain objects and behaviours are bound to libraries and frameworks, be it for UI databinding, REST access, database mapping, or bridging a fancy new Big data system. Let it simmer for a while, then end up with a number of domain mismatches and idiosyncrasies. Can we do better? Model-driven engineering aims to help developers deal with implementation details by letting us focus on higher-level domain models. In its lighter form, it is a common approach: a number of popular projects have domain-specific languages to generate bindings (e.g Protocol buffers), technical/optimised code (e.g Antlr) or scaffold applications (e.g Rails). This approach is particularly popular in the Eclipse community, where it was taken a step further. The Eclipse Modeling Framework (EMF) is at the core of a rich ecosystem that consider models first-class constructs. It makes the creation of custom models easy, and projects gravitating around it provide out-of-the-box – yet customizable – diagrammatic views, database mapping, UI databinding, and much more. Still, EMF has not been adopted in the Java community at large, probably in part because benefitting from the full experience provided by extensions makes EMF leak in your APIs' design and dependencies. In this talk, we will see how OSGi and modeling complement each other in a modular, OSGi-powered EMF-like framework, and how models can help developing OSGi applications.

1. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling The OSGi Way
(Modest Modular Models)
Simon Chemouil
@simach
Lambdacube
OSGi Community Event, 2017
1 / 45 Simon Chemouil @simach Modeling The OSGi Way

2. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Outline
1 Modeling 101
A Tale of Divergence
What’s a model?
Model-Driven Development
2 A Modern Take On Modeling
Modeling Fundamentals
A Modeling Framework
3 Modeling Applications
The Service Component Model
Building upon abstractions
4 Conclusion
2 / 45 Simon Chemouil @simach Modeling The OSGi Way

3. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
Once upon a time, in a shiny software project
Java/OSGi back-end, distributed in “micro-services”
Clear API/implementation separation, transparent remoting
through (reactive) service interfaces
TypeScript/AngularJS front-end
Communicates with back-end using REST endpoints and JSON
5 / 45 Simon Chemouil @simach Modeling The OSGi Way

4. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
Not everything was that shiny
Different schedules between back-end and front-end, hard to
synchronize API needs
When we were developing X, they were busy with W, with they
asked about X, we had moved on to Y
Time passes and we end-up with slightly different abstractions
and idiosyncrasies
Often different data structures for the same abstractions - and
sometimes different names: which one is right?
Hard to change without breaking one side
Duplicated effort!
6 / 45 Simon Chemouil @simach Modeling The OSGi Way

5. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
Slaying the beast
While it was happening, human time and energy could have
improved things
What about tools and methods instead ?
What if we had a repository where we described our types and
services APIs
Not just for documentation, but as the Source Of Truth!
7 / 45 Simon Chemouil @simach Modeling The OSGi Way

6. The Plan

7. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
Evaluating the plan
That’s what JHipster does...
Scaffolds Spring Boot + AngularJS application
That’s just an instance of a greater problem: modeling
Addressed by Eclipse Modeling Framework - aka EMF!
Approaching the problem with modularity and modern
practices in mind
9 / 45 Simon Chemouil @simach Modeling The OSGi Way

8. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
What’s a model?
Model (16th century)
From old french «modelle», itself from latin «modulus», itself
short for «modus»: way, mode, measure, rule
More recently: replica, representation, description
Module (20th century), as a self-contained component of a
system
Related:
mold, modulo, moderation, modest, modal, ...!
A Model is...
a definition, a representation, an abstraction
11 / 45 Simon Chemouil @simach Modeling The OSGi Way

9. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
Models are everywherething
Examples of models:
APIs
Database Schemas
Programming Languages
Machine Learning
OSGi!
We all do modeling!
Often informally, just in our mind, without tooling support
12 / 45 Simon Chemouil @simach Modeling The OSGi Way

10. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
Model-Driven Development, or Modeling
Making Models first-class citizens
At build time, and potentially at runtime
Just like Types - they allow us to reason
Thinking about models and their relationships
Abstracting on abstraction is hard to discuss, let’s go back to
our example
14 / 45 Simon Chemouil @simach Modeling The OSGi Way

11. The plan

12. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
A separate model repository?
Modeling is about abstract data, not about parsing
It can be custom languages, Java annotations or XML or JSON
A separate repository would allow us to describe our types and
services in (a) neutral language(s)!
tailored to express exactly what we need
even enforce good practices through grammar and tooling
Something we can potentially show to someone not knowing
Java
16 / 45 Simon Chemouil @simach Modeling The OSGi Way

13. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
Domain-Specificity: modularity for models
Domain-Specific Models (DSMs) represent one domain, and
do it well
Domain-Specific Languages (DSLs) are possible textual or
graphical representations with a DSM
One DSM may have several DSLs; several DSMs may be
isomorphic
The opposite of General Purpose Models and Languages,
such as UML and Java
What if we could modularize the language itself?
17 / 45 Simon Chemouil @simach Modeling The OSGi Way

14. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
A Tale of Divergence
What’s a model?
Model-Driven Development
General Purpose vs Domain Specific
Complex vs Simple
Fewer constructs mean instances (“programs”?) can be easily
analyzed by tools
e.g model evolution → instance update, less worrying about
backwards compatibility
Monolith vs Modular
Small modules are easier to reason about, but harder to
assemble!
DSMs and general purpose languages can cohesist happily!
18 / 45 Simon Chemouil @simach Modeling The OSGi Way

15. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
Models and Meta-Models
Modeling deals with models
For instance, describing my services in a service model
To express the what the service model is, we use another model!
We call the model that is used to express another model its
meta-model
There may be several ways to express the same thing...
21 / 45 Simon Chemouil @simach Modeling The OSGi Way

16. A Tower of Models

17. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
The Datatype Definition Model
The core building block
Called Meta-Object Facility (MoF) in OMG/MDA, ECore in
EMF
It can be used to define all other model structures
Semantics must be expressed in a different place
23 / 45 Simon Chemouil @simach Modeling The OSGi Way

18. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
Model Transformations
Definition
A model transformation is a function (α1 : A1, . . . , αn : An) → B
that takes one or more input models (α1, . . . , αn) with meta-models
A1, . . . , An, and returns a model β with meta-model B.
Example: transforming service definitions (meta-model:
Service) to Java interfaces (meta-model: JavaModel)
24 / 45 Simon Chemouil @simach Modeling The OSGi Way

19. The Big Picture

20. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
The case for a framework
Middleware to define models, provide transforms, hook
serializers in a consistent way
At build time, and potentially at run time (e.g: live transforms,
bytecode generation)
Network effect
Meta-reflection: A way for the original, transformed, model to
be kept at runtime ?
Keeping the original intent and making it available to tools
27 / 45 Simon Chemouil @simach Modeling The OSGi Way

21. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
The Eclipse Modeling Framework
The major F/OSS modeling framework
de-facto standard, huge ecosystem, still going
A lot resolves around ECore generated Java models, “Java
beans on steroids”
Databinding, Persistence, Transactions, and more ...
out-of-the-box using plugins
28 / 45 Simon Chemouil @simach Modeling The OSGi Way

22. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
Why EMF?
Fast application scaffolding
Rich ecosystem
Integrates well with Eclipse IDE
Solutions ready for common problems:
big models that don’t fit memory (e.g: database!)
comparing models
diagram editors
parsing and textual languages
29 / 45 Simon Chemouil @simach Modeling The OSGi Way

23. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
Why not EMF?
Java Beans on steroids
Beans are built on mutability, concurrency unfriendly, remoting
unfriendly, mixing state and identity (address)
To benefit from the ecosystem, one must implement EObject
EMF and its extensions are built around Eclipse’s extension
registry
No handling of dynamics
EMF is 15+ years old and won’t be moving significantly
Any significant design change would break the ecosystem
30 / 45 Simon Chemouil @simach Modeling The OSGi Way

24. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
Praxis: a modular modeling framework experiment
A modular modeling framework for build and run time, built
“The OSGi Way” - while making OSGi optional
Modular: do as little as possible, co-operate with other
frameworks (who may provide models)
Component-based design to hook extensions such as
transformations and parsers
Meta-circular: built with itself
Draws ideas from EMF, Clojure, Haskell, NoSQL, Reactive,
DDD, Event-Sourcing, ...
31 / 45 Simon Chemouil @simach Modeling The OSGi Way

25. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
Modeling Fundamentals
A Modeling Framework
Plato/Data: a persistent data model
The Data Model is at the core of Modeling
Focus on immutable, persistent data models, separate state
from identity (à la Clojure)
Regular, consistent data shape: ADTs in Java with builders and
visitors for pattern matching, non-nullable fields
Magic happens when all data objects share the same
superstructure and properties
Concurrency and remoting friendly
Planned custom serialization/deserialization support
No framework dependencies (extra-features must be optional,
e.g using OSGi services)
32 / 45 Simon Chemouil @simach Modeling The OSGi Way

26. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
The Service Component Model
Building upon abstractions
The OSGi Way
OSGi brings Service Component Architecture to JVM
applications
We can design typed service contracts as Java Interfaces
Have components provide and reference services
Bundles provide a way to package code for deployment
We have the Plato/Data model...
Introducing Plato/Service and Plato/Component
Can we support that methodology through models?
35 / 45 Simon Chemouil @simach Modeling The OSGi Way

27. Building a simple application

28. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
The Service Component Model
Building upon abstractions
Todo Data Model
Example
model io.primeval.praxis.demo.todo
import java:java.time#LocalDate as Date
type Todo {
val title: String
val author: String
val contents: TodoContents
val color: TodoColor
val date: Date
}
type TodoColor = Green | Red | Blue | Orange
type TodoContents = SimpleTodoContents | CompositeTodoContents
type CompositeTodoContents { val elements: List[ TodoContents ] }
type SimpleTodoContents = TextTodoContents | IncludedTodoContents
type TextTodoContents { val text: String }
type IncludedTodoContents { val todo: Todo }
37 / 45 Simon Chemouil @simach Modeling The OSGi Way

29. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
The Service Component Model
Building upon abstractions
Todo Service Model
Example
model io.primeval.praxis.demo.todo
import data:io.primeval.praxis.demo.todo as todo
import java:org.osgi.util.promise#Promise
import java:org. reactivestreams #Publisher
service TodoManager {
def addTodo(todo: todo#Todo ): Promise[Void]
def removeTodo(todo: todo#Todo ): Promise[Void]
def listTodos (): Publisher[todo#Todo]
}
38 / 45 Simon Chemouil @simach Modeling The OSGi Way

30. Quick Demo

31. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
The Service Component Model
Building upon abstractions
Reactive Data Models
What if our data model does not fit in memory?
We can’t have it entirely as a persistent tree
We need to be able to distinguish model instances, reference
certains paths, return certain elements matching certain
predicates
A query language?
Generate service and component models for data models to
provide well-typed, reactive DB access?
41 / 45 Simon Chemouil @simach Modeling The OSGi Way

32. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
The Service Component Model
Building upon abstractions
Layered models
Once we can reference certain paths...
Add another model on top of an existing one
e.g: a commenting model that can annotate any model element
from any model
Could be used to keep meta-data about transforms (e.g link
data element to Java class)
or keep parsing information (line/file) associated to model
elements
Enrich models without making the base model more complex
e.g: REST Endpoint model on top of service model, serialization
customisation over data model
42 / 45 Simon Chemouil @simach Modeling The OSGi Way

33. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
The Praxis+Plato Experiment
Everything is about data: the data model is central
Persistent data types help think: no cycles, no questions :-)
A reactive data model instead of an ORM
Static vs Dynamic
Modeling can help bridge the two worlds
Methods and Tools
Languages can be guides to a way of thinking
Can we get a real yet human-friendly system overview with
static and runtime visualization?
44 / 45 Simon Chemouil @simach Modeling The OSGi Way

34. Modeling 101
A Modern Take On Modeling
Modeling Applications
Conclusion
The Praxis+Plato Experiment
Questions?
http: // github. com/ primeval-io/ praxis
Twitter:
@simach
simon.chemouil@lambdacube.fr
45 / 45 Simon Chemouil @simach Modeling The OSGi Way