The purpose of this document is to define the structure of OpenMDM™ 5 components and their relationship with the OpenMDM™ 5 Business Model.
1. Introduction
TBD
2. Driving Forces
Members of the OpenMDM™ Working Group have identified the following driving forces that heavily influence the architecture goals and its design:
ASAM ODS is the selected technology for persistent storage and retrieval of testing data; it’s the key concern for OpenMDM™ members as it enables them to share data using a standard format that’s not specific to a single member or vendor.
CORBA has proved to be a problem in previous iterations of the OpenMDM™ API, most notably perhaps the fact that setting a CORBA broker is troublesome and error prone. Also, the CORBA API has leaked to the front all the way from the bottom layers.
It should be possible to read and write data from and to different proprietary formats and feed it into the OpenMDM™ Business Model.
Members of the OpenMDM™ Working Group already posses large amounts of data stored in the OpenMDM™ 4 format. This data should be able to be consumed in read-only mode. Any changes made to data in this format should be written back in the OpenMDM™ 5 format.
There are many existing components OpenMDM™ 4 already but none of them must be used as a basis for design and implementation. In other words, the OpenMDM™ 5 components should be designed from scratch.
3. Goals
TBD
3.1. Modularity
TBD
-
Ability to replace any component with another one that performs similar behavior.
-
Should be able to distribute work to different providers and independently from each other.
-
Strict separation of interfaces vs. implementation.
-
Each component has a defined place in the architecture layers. Must not access upper layers.
-
Only dependencies on interfaces.
-
UI layer should allow modularity.
3.2. Assembly
OpenMDM™ 5 applications should be built as a composition of OpenMDM™ 5 components. It’s desired by some OpenMDM™ Working Group members that this composition happens using a declarative approach, using only configuration and no additional code involved.
-
Capability to aggregate components by configuration.
-
Components expose metadata about their compatibility and UI capabilities.
3.3. UI Independence
OpenMDM™ 5 components should be able to 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 stacks for example.
-
Components should provide hooks for different UI technologies to be used.
-
Don’t force a single UI technology unless that’s what the component’s behavior demands.
3.4. Conformance to Specification
OpenMDM™ 5 components should define their inputs/outputs and operations using a well known definition language. This is will be known as the OpenMDM™ 5 Component Specification.
-
Components must be certified through an OpenMDM™ TCK.
-
Components must comply with a CTCK that arises from the component’s specification.
OpenMDM™ 5 Component Specifications will be validated and tested using a particular OpenMDM™ 5 CTCK.
3.5. Resilience
Components can be exchanged while the system (not an application) is running. This accommodates for fail overs, 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.
4. Overview
The following figure shows a basic view of two OpenMDM™ 5 applications connected to the OpenMDM™ Business Model. The OpenMDM™ Business Model is responsible for transforming data from and to ASAM ODS, as well as executing specific MDM operations on said data. The components are responsible for building new behavior on top of the OpenMDM™ Business Model, such as custom searches, archiving, security. Notice that both applications share a common component (the blue one).
Interestingly these two applications use different UI technologies however they are able to share some components. This is possible because components can be designed in such a way that their core behavior and inputs/outputs can be designed independently of a specific UI technology. We propose the usage of the Remote Presentation Model pattern to fulfil this design goal.
The Presentation Model pattern as explained by Martin Fowler can be further extended to work under networking conditions, such that there are two halves of a Model: one at the client side, the other at the server side. Setting a value on one side transfer it to the other and vice versa. Value transfer can happen synchronously (set and wait) or asynchronously (set and continue). We prefer the latter mode as synchronization points (if needed) can be built on top of an asynchronous system, whereas the reverse is much more difficult to achieve.
Once a Remote Presentation Model is in place it enables developers to push the logic to the server side. This frees developers from reimplementing application login for each different UI stack that’s chosen. Building a new client using a different UI technology results in more reusability as it’s only the new visuals that must be created, as the logic and data interactions remains the same. The Presentation Model pattern also fosters code reusability and increased decoupling of View components from Controllers (or Logic) components.
4.1. Anatomy of an OpenMDM™ Component
There are two types of OpenMDM™ 5 components: Rich and Headless. This distinction is made solely on the terms of UI capabilities that the component may expose. Rich components deliver at least one UI part. These are the type of components that require the usage of the Remote Presentation Model pattern. On the other hand, Headless components do not expose an UI part and therefore do not require a Remote Presentation Model. The following figures depict both types of components
OpenMDM™ components can expose their input/outputs and operations using the following channels:
Used exclusively by UI clients that support the Remote Presentation Model pattern. This channel will be used to build up Rich and Web clients. The Component Specification must include the following:
-
Attributes
-
name
-
type
-
description
-
constraints (such as number range size, validation masks, etc)
-
-
Models
-
id
-
description
-
attributes collection
-
-
Actions
-
id
-
description
-
The language used to describe these elements must be Java, making use of interfaces, annotations and enums only. Constraints should be specified using JSR-303 (Bean Validation) annotations.
Used by clients that require offline capabilities and/or those that do not support the Remote Presentation Model pattern. The Component Specification must include the following:
-
A set of URLs that can be used with the HTTP verbs: GET, POST, PUT and DELETE.
-
Each URL must define its inputs
-
Each URL must define the format of its outputs
Good examples of well behaving and documented REST APIs are
Used by OpenMDM™ components co-located within the same JVM process; think of instances accessed via dependency injection. The Component Specification for this channel should be written using Java interfaces, enums and annotations only. Concrete and abstract classes are to be included on rare occasion, validated by the OpenMDM™ Architecture Committee.
Used by OpenMDM™ components that are located in different JVM processes. This channel is the preferred way of communicating two components over a well-known business (e.g, behavior) interface. The Component Specification for this channel includes Java interfaces, enums and annotations only. The chosen RPC technology may impose additional restrictions to the Component Specification.
Used by any OpenMDM™ component, whether local or remote; his enables low coupling of components and broadcasting of data. This channel enables one component to communicate with multiple components without any single component having a direct reference to the others. It also allows components to receive notifications coming from anywhere else in the system. The Component Specification should include the following:
-
Events
-
name
-
description
-
data payload
-
The Component Specification should be in terms of the chosen technology for implementing an Event Bus. In the case of the technology being JMS it should conform to JSR-343 (JMS 2.0).
It may seem redundant or overkill to propose 5 different communication channels for a single component, the following aspects were taken into consideration for proposing all these channels:
-
Components hosted at the same JVM container can reference one another. It’s recommended to use dependency injection as prescribed by JSR-330 (Dependency Injection) and/or JSR-346 (CDI 1.1).
-
RPC is the preferred choice for communicating components hosted at different containers given that this technology provides remoting capabilities to interaction through a well known API interface. RPC fosters one-to-one communication and both synchronous and asynchronous communication.
-
The Event Bus is needed for a component that can requires broadcasting data to multiple components. It also enables a component to be notified of incoming data without having a direct reference to the source or sources of said data. The communication in this channel should be asynchronous.
-
The Remote Presentation Model channel is used solely for UI facing components. Their logic and behavior reside solely at the server side, simplifying the construction of new UIs without altering standard component behavior.
-
Finally the RESt channel is used as the last alternative for components to expose data and behavior to clients that do not support eh Presentation Model, or are implemented using a programming platform other than the JVM (such as mobile devices like iOS or Android).
The following picture shows the interaction of 3 different OpenMDM™ components, two of which are located within the same JVM process.
Please note that the OpenMDM™ 5 Business Model can be accessed by components using an OpenMDM™ Connector. This allows the OpenMDM™ Business Model to be hosted at a different place, enabling replication and fail over. The communication protocol is still to be decided, most likely candidates are RPC and Messaging Queue.
4.2. OpenMDM™ Component Specification
-
spec defines the API.
-
component defines which channels must be used (PM, REST, RPC, EB).
-
UI delivers mockups and usability guidelines.
4.3. The OpenMDM™ Business Model
The OpenMDM™ 5 Business Model is comprised of 3 layers:
-
The API or core. This is the layer that defines MDM entities, their relationships and interactions.
-
The Connector. This layer is responsible for exposing the core layer to the outside world, that is, the OpenMDM™ components.
-
Persistence. This layer is responsible for storing and retrieving data to and from a specific persistence solution. The ODS Adapter is an specialized solution that can handle ASAM ODS. Other persistence solutions can be hooked on too, for example simple text files, very useful for automated testing when an ODS server is not available.
5. Summary
TBD
6. Glossary
Test Compatibility Kit. This is a set of rules and guidelines that must be validated in order to assert that a particular component specification is conformant to the OpenMDM™ Component Specification.
Component Test Compatibility Kit. This is a programmatic test harness that ensures a component is conformant to an specific component specification. In other words.