In July 2015 the openMDM® Eclipse Working Group (EWG) was founded by AUDI AG, BMW Group and Daimler AG. Further founding members were the software companies GIGATRONIK GmbH, science + computing AG, Canoo Engineering AG, HighQSoft GmbH and Peak Solution GmbH.
The openMDM® EWG helps to channel the diverse requirements for openMDM® 5 better, making it possible to initiate, plan and jointly fund Eclipse open source projects for new developments and improvements, as well as to maintain the openMDM® 5 software components.
The first concrete outcome of the work of openMDM® EWG was the new architectural concept of openMDM® 5, which was published in autumn 2015.
The openMDM® 5 Architecture describes the composition of the openMDM® platform in terms of core services and components. Core services deliver the runtime facilities required by components to be instantiated, queried and managed. Components define their behavior by specification. This allows vendors to provide different implementations as needed while making sure their implementations are conform to a common set of APIs.
The following driving forces have heavily influenced the architecture of openMDM® 5:
- Assembly of applications
openMDM® is intended to be a kit of components and concepts, which can be used to compose specific applications for test data management without programming, only by combining components and configuring them.
- Compatibility with ASAM ODS
ASAM ODS is the selected standard for the persistent storage and retrieval of test data. It is the key concern for openMDM® users as it enables them to share data using a standard format that is not specific to a single system vendor.
- Shielding the ODS interface through the openMDM® API
Because the ODS interface is very generic and technically difficult to implement, it is encapsulated for the development of application components through the openMDM® API. The API is responsible for storing and retrieving data to and from a specific persistence solution and defines openMDM® entities (business object model) as well as their relationships and interactions.
Modularity facilitates the ability to interchange component implementations while keeping a base level of behavior. This allows the replacement of any component with another one that performs similar behavior. Prerequisite is a strict separation of interfaces vs. implementation and that each module has a defined place in the architecture layers.
Components can be exchanged while the system (not an application) is running. This accommodates for fail-over, load balancing and scalability. Connections between components and their communication protocols should be elastic and flexible, that is, if a component is taken offline and replaced immediately other parts of the system may work without having to take them down, too.
- UI Independence
OpenMDM® 5 components can be assembled into applications that have different UI technology stacks from one another. This enables a component to be reused on a Rich Client and Web stack for example.
- Compatibility with the openMDM® 4 data model
Users of openMDM® already have large amounts of test data stored in the openMDM® 4 application model of ODS. It is possible to consume this data with openMDM® 5 in read-only mode. Any changes made to the data are written back in the openMDM® 5 format.