Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Modeling the OSGi Way - S Chemouil

100 views

Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Modeling the OSGi Way - S Chemouil

  1. 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. 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. 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. 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. 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. 6. The Plan
  7. 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. 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. 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. 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. 11. The plan
  12. 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. 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. 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. 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. 16. A Tower of Models
  17. 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. 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. 19. The Big Picture
  20. 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. 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. 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. 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. 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. 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. 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. 27. Building a simple application
  28. 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. 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. 30. Quick Demo
  31. 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. 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. 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. 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

×