Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

openMDM5: From a fat client to a scalable, omni-channel architecture

537 visualizaciones

Publicado el

The handling of measured data goes way beyond simple data storage and retrieval. A measured data management system must provide reliable long-term archival, including provenance, and efficient search mechanisms while ensuring proper access restriction across different teams, departments, and even companies. However, the required functionality widely differs between these parties. Instead of implementing a single full-featured rich-client, the openMDM WG has been working to create a toolbox which allows to create individual measurement data management solutions tailored to the particular use case. The underlying software architecture will be presented in this talk.

Publicado en: Software
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

openMDM5: From a fat client to a scalable, omni-channel architecture

  1. 1. openMDM5: From a fat client to a scalable, omni-channel architecture EclipseCon Europe 2015 November 4, 2015, Ludwigsburg
  2. 2. Sibylle Peter Canoo Engineering AG @persillie Andreas Benzing ICS AG @andreasbenzing
  3. 3. openMDM IWG „The open MDM Working group […] wants to foster and support an open and innovative eco-system providing tools and systems, qualification kits and adapters for standardized and vendor independent management of measurement data in accordance with the ASAM ODS standard.“ openMDM charter
  4. 4. Measurement Process
  5. 5. History 1999: Start of openMDM @ AUDI AG 2008: openMDM becomes open source - community gains new members - more functions, components - codebase grows 2014: Transition to Eclipse IWG
  6. 6. First Idea
  7. 7. (Very) Rich-Client
  8. 8. Abstractions/Interfaces • CORBA and ODS sprawled everywhere – Once CORBA is in place, why not use it again?  Separate data access and logic! • Transparent data access masks bottlenecks – Getters can trigger query to ODS server  Data retrieval must be done explicitly!
  9. 9. Separation of Concerns • Monolithic API hinders maintainability – Extension changes entire API, all modules affected  Modularize API! • Dependencies result in tight coupling – Home-grown solution difficult to handle  Establish solid dependency management!
  10. 10. Let’s build openMDM5! • Be compatible with ASAM ODS • Shield CORBA interfaces from applications • Provide method for integrating external data • Break compatibility with MDM4 • Work split between driving members
  11. 11. The Goal Design a flexible, configurable, pluggable, adaptable, resilient System
  12. 12. (flickr: juanaidrao) BigDesignUpFront?
  13. 13. “The best architectures, requirements, and designs emerge from self-organizing teams.” 11th Principle of the agile manifesto.
  14. 14. Open Source Open-source software may be developed in a collaborative public manner. (Source: Wikipedia)
  15. 15. elastic/elasticsearch
  16. 16. Just enough to guide emergent architecture
  17. 17. UI ODS MDM API Business Logic Data Access MDM API Business Logic Data Access MDM API Business Logic Data Access
  18. 18. Step 1 Layers
  19. 19. Data Access ODS Business Logic UI MDM APIBOM
  20. 20. Step 2 Modularization
  21. 21. Data Access ODS UI MDM APIBOM Business Logic
  22. 22. MDM Component Ports Adapters
  23. 23. Ports & Adapter (Patrick van Bergen)
  24. 24. MDM Component
  25. 25. And the Data???
  26. 26. MDM Data Access Module BOM
  27. 27. Bringing it all together
  28. 28. Explorer Component
  29. 29. OpenMDM API DataProvider ComponentExplorer Component Client Rich PresentationModel Server PresentationModel Logic Component API Server Logic Component API Server Logic ModelLibraries de.rechner.openatfx ATFX-Datei DataAccessMock available at: (read the readme files!)
  30. 30. Data Access ODS UI MDM API Platform Business Logic BOM
  31. 31. MDM Components managed
  32. 32. MDM Platform
  33. 33. Guiding Emergence • Design for testability • Design for learning • Return to design fundamentals • Make technical decisions at the last responsible moment • Use standards instead of concrete implementations
  34. 34. THANK YOU! Questions?