| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| <html lang="en-us" xml:lang="en-us"> |
| <head> |
| <meta content="text/html; charset=utf-8" http-equiv="Content-Type" /> |
| <meta name="copyright" content="(C) Copyright 2005" /> |
| <meta name="DC.rights.owner" content="(C) Copyright 2005" /> |
| <meta content="topic" name="DC.Type" /> |
| <meta name="DC.Title" content="openMDM5 Business Layer Interface Model" /> |
| <meta name="abstract" content="This section presents how applications components can access the persisted data via the openMDM API." /> |
| <meta name="description" content="This section presents how applications components can access the persisted data via the openMDM API." /> |
| <meta content="XHTML" name="DC.Format" /> |
| <meta content="openMDM5.business_object_model" name="DC.Identifier" /> |
| <link href="commonltr.css" type="text/css" rel="stylesheet" /> |
| <title>openMDM5 Business Layer Interface Model</title> |
| </head> |
| <body id="openMDM5.business_object_model"><a name="openMDM5.business_object_model"><!-- --></a> |
| |
| |
| <h1 class="topictitle1">openMDM5 Business Layer Interface Model</h1> |
| |
| <p>This section presents how applications components can access the persisted data via the openMDM API.</p> |
| |
| <div class="nested1" id="openMDM5.business_layer_interface_model.motivation"><a name="openMDM5.business_layer_interface_model.motivation"><!-- --></a> |
| <h2 class="topictitle2">Motivation</h2> |
| |
| <div> |
| <p>The openMDM API is an intermediate layer between data processing components and the ODS layer. Basically it would be possible that those components work directly with the ODS interface. But the introduction of the Business Layer has several advantages. First of all the semantics of openMDM are represented as interface functionality and rules that openMDM define can be integrated in these functionality. Another benefit is given by a common data object model, that can be shared by all data processing components. In the other case every component must define its own model. </p> |
| |
| </div> |
| |
| </div> |
| |
| <div class="nested1" id="openMDM5.business_layer_interface_model.abstract"><a name="openMDM5.business_layer_interface_model.abstract"><!-- --></a> |
| <h2 class="topictitle2">Abstract</h2> |
| |
| <div> |
| <p>Concerning the flow of data the Business Layer is complete based on queries. As performance is a key issue, the communication should be economical as possible. Every data to process is the result of a query. The query language has to be complex enough, that in the majority of cases a single query should be enough. </p> |
| |
| <p>The process starts with a query, which is defined by the client component. The query can be defined, without having an interaction with the openMDM API. When the query is completed, it is passed to a specific openMDM API instance. The instance is realized by a specific implementation. The common examples are operating with an ODS server or an ATFX file. The result is passed as an interpretable object model, that can be processed within the openMDM application.</p> |
| |
| <p>If write access is needed, the openMDM API provide methods to handle ODS transactions. This include transaction executions functions (start, commit, abort) and monitoring functions (transaction state, callback features.</p> |
| |
| <div class="section"><h3 class="sectiontitle">Extensions </h3> |
| |
| <p>As mentioned in the Business Object Model the model is extensible by Modules. The "core" openMDM API interface and their implementations can handle all business objects, that are included in the Default Model. If functions are needed, that are related to business objects of a Module, specific interfaces are needed. These interfaces are called "openMDM API Extensions". They can refer to the openMDM API interface.</p> |
| |
| <p>Each Extension can have multiple implementations and is associated with specific Application Model. Extensions require their Application Model to be installed before the can be used. The implementation of the openMDM API and the Extension must operate on the same ODS instance. This has to be assured before providing the service to a client component.</p> |
| |
| <p>The transaction control is located centrally at the openMDM API, because there will be use cases, where business objects from the Default Model and the Module should be altered in one transaction.</p> |
| |
| </div> |
| |
| <div class="section"><h3 class="sectiontitle">Query Collection</h3> |
| |
| <p>Generally a client component can define every query by itself, without having an interaction with the openMDM API. There are no API entities anymore as they were in openMDM 4, which masked default queries. Due to this fact standard queries would probably be duplicated within components. To prevent this, there is a collection of queries, which can be used as base for custom queries. These queries are nothing more than predefined queries, behaving the same as if they were defined within a component. A "Collection Query" can be extended, adjusted and supplied with additional constraints. It can not be invoked directly to prevent just using a sequence of default queries, which would be similar to the way openMDM 4 worked.</p> |
| |
| </div> |
| |
| <p><img src="images/Business Layer Interface Model.png" /></p> |
| |
| </div> |
| |
| </div> |
| |
| <div class="nested1" id="openMDM5.business_layer_interface_model.interface_structure"><a name="openMDM5.business_layer_interface_model.interface_structure"><!-- --></a> |
| <h2 class="topictitle2">API Interface Structure</h2> |
| |
| <div> |
| <p>The openMDM API follows a service oriented architecture. The main task of this service is to handle openMDM queries. </p> |
| |
| <p>The query itself is defined by an set of business objects and the relation between them (e.g. Test, Step and TestEquipment). Every business object ca be supplied with attribute constraints (e.g. attribute "thrust_washer" is like "KL41%"). </p> |
| |
| <p>Then the query is passed to a specific Query Service, which interprets and validates the query and retrieves the expected data from its ODS service. This data is formed to a result, that is formed by POJOs. As per usual definition a POJO is an object, which has no connection to the persistence layer anymore. It contains all attributes of an ODS Instance Element and the relations to other POJOs, representing the associated ODS relations. For example there is an POJO Class for Test, which has relation to a StructureLevel POJO and a TestStep POJO. </p> |
| |
| <p>Due to the lack of ODS connection the result and POJOs generally should be considered as partial snapshot of openMDM data. By this detachment the POJOs are suitable for being a object model, which can be shared by client components. So they do not have to implement their own object model.</p> |
| |
| <p>If openMDM data should be modified, a set of POJOs is passed to the Query Service. These POJOs could derive from a previous query result and could be provided with additional information in form of attribute modifications or completely new POJOs. POJOs can even derive from an other ODS source. So when a transaction is active, the passed "update model" is validated and the result is persisted within the ODS layer.</p> |
| |
| <p><img src="images/API Interface Structure Model.png" /></p> |
| |
| </div> |
| |
| </div> |
| |
| |
| </body> |
| </html> |
