This glossary contains a list of terms commonly used to describe topics related to openMDM.
openMDM Specific Terms
This section describes terms specific to openMDM.
The openMDM(R) Toolkit is the central work item of the openMDM(R) Eclipse working group. It materializes the goals of the openMDM(R) EWG. It consists in
- openMDM(R) components which can be combined and configured (without programming) within openMDM(R) applications to deliver an openMDM(R) system to the end users
- documentation of best practices os so called concepts (end user processes, end user use cases)
A system describes a productive openMDM(R) environment. This environment includes everything that is required to operate an openMDM instance including configuration and resources. A system consists of various deployment units and (possible external) services, for instance
- openMDM(R) applications to be rolled out on user devices
- connected commercial applications
- services (multiple instances possible, possibly interdependent)
- ASAM ODS service running an instance of an openMDM(R) application model
- openMDM(R) business layer service running an openMDM(R) application
- openMDM(R) web service running an openMDM(R) application
- openMDM(R) import service running an openMDM(R) application
- openMDM(R) processing service running an openMDM(R) application
- storage services
- database services
System development - as it is very specific to different companies - is not in the focus of the openMDM(R) Eclipse working group.
An application is a part of a system which serves a particular purpose, for example
- rich client application
- web application
- mobile app
- headless server application
openMDM(R) components are composed using openMDM(R) components
It is specific to platforms (like application servers, operating systems etc.).
Components are the central work item of the Eclipse projects managed by the openMDM(R) Eclipse working group. A component implements certain functionality. Components can be used for the composition of multiple applications.
For every component it has to be determinable,
- if it complies to the openMDM(R) architecture definition
- if it complies to the openMDM(R) branding
- if it complies to the openMDM(R) quality kit
For every component must be documented and retrievable
- which requirements are met by the component (functionality definition, see above)
- which interfaces does the component implement
- which services does the component depend on
- which services does the component provide
- which further restrictions exist (instantiate)
Every component has to be testible. There shall be an integration environment published by the communitie's quality committee, which consists of a well- defined set of components, to which the component under concern can be integrated and tested.
This section describes terms which originate from an openMDM related domain and have a special interpretation in the context of openMDM.
The exact role of a product owner in the context of openMDM is not yet defined.