openMDM® 5: Fundamentals of Architecture (Part 1)

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

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.

  • Resilience

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.

Continue to Part 2 of this article…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s