Unable to render Jira issues macro, execution error.

 

The Open Metadata and Governance (OMAG) Server Package provides a server runtime for the Open Metadata and Governance components. This includes:

Through the OMAG server configuration, the OMAG Server is able to perform combinations of the following roles in the metadata highway.

The OMAG Server has a REST API and UI for administering the OMAG Server.  This includes setting up the OMAG server roles it is supporting and managing its connectivity on to the metadata highway.  It is also able to dynamically load OCF connectors and their configuration (connections).  Through this service, the OMAG Server supports the Plug-in Integration Pattern for OCF Connectors.

The section below describes the operation of the OMAG Server in each of its roles and how it supports metadata tools and repositories connecting onto the metadata highway.

 

OMAG Server Roles

 

When the OMAG Server is configured to provide an Access Layer it means it is hosting the Open Metadata Access Services (OMASs) APIs and Topics for external tools and applications.  In the example shown in figure 1, there is a tool called ABC that is using the Caller Integration Pattern to access open metadata and related services. 

 


Since the OMAG Server does not have a metadata repository, all metadata is managed in other repositories and retrieved as required by OMRS:

  • The OMRS does not register with the metadata repository cohort because it does not have a local repository and so there is no OMRS message exchange with other repositories.    However, the OMASs will receive events from the OMRS Topic to service their own In and Out Topics.
  • OMRS Connector calls are made from the OMAG Server to other repositories in the cluster in support of calls from the OMASs.
Figure 1: ABC tools deployed with the Access Layer of the OMAG Server

 

Figure 2 shows the OMAG Server with both the Access Layer and a local metadata repository enabled.  Now metadata from ABC is stored in its local OMAG Server's repository.  This is blended with metadata from other repositories by OMRS. With a metadata repository in play, ABC can operate independently and connect into the open metadata repository cohort and is therefore now a open metadata Native.

 

 

Figure 2: ABC tools deployed with the the Access Layer and local metadata repository of the OMAG Server

 

Figure 3 shows a tool and repository product called XYZ connected to the Open Metadata and Governance Ecosystem through an OMAG Server configured as a Repository Proxy. 

 

 

The role of the repository proxy is to connect a proprietary metadata repository to the metadata highway and translate calls and messages between the XYZ proprietary formats and the open metadata formats.

Although the OMAG Server does not have its own repository enabled in this case, it is acting as a proxy for XYZ and so registers with the open metadata cohort registry.  Hence you see the OMRS message exchange between the Repository Proxy and other repositories in the cohort.

Figure 3: XYZ tools and repository using the OMAG Server as a Repository Proxy

 

In figure 4, the repository proxy has a local metadata repository.  The repository is being used to store metadata that augments the metadata in the XYZ repository.  This is used when the XYZ metadata model does not support all of the metadata types it needs, or there is a mismatch between the XYZ metadata metamodel and the open metadata types, requiring metadata to be cached locally in order to build up metadata content that can be stored in the XYZ repository.

 

Figure 4: XYZ tools and repository using the OMAG Server as a Repository Proxy with a local repository acting as a extension store for metadata

 

Figure 5 shows a further development where the users of XYZ are given access to the OMAS functions, both through the OMAS UIs and the XYZ UIs.  Thus, this is an example of the Access Layer and the Repository Proxy in action together.

 

Figure 5: XYZ tools and repository extending their Repository Proxy to support the OMAS APIs and UIs.  XYZ tools have also extended their UI to use the OMAS APIs.

 

Finally figure 6 adds the metadata repository so the repository proxy has a local store as well as the XYZ store.  Thus all 3 roles are enabled.

 

Figure 6: XYZ tools and repository extending their Repository Proxy to support the OMAS APIs and UIs and a local store of metadata



The OMAG Server, with its frameworks, and the fact that it is available as open source, can be extended with more advanced function through well defined plug-points.  The Apache Atlas Server is an example of the Native Integration Pattern built on top of the OMAG server to give it native support for the open metadata and governance APIs.   The Apache Atlas server then provides value-add services or managing metadata and governing data, such as the Hooks and Bridges for Hadoop technology.

 

 

 

  • No labels

1 Comment

  1. Yao Li

    1. in the Figure 2: "Figure 2: ABC tools deployed with the the Access Layer and local metadata repository of the OMAG Server"
    2. in the description of Figure 4, "here is a mismatch between the XYZ metadata metamodel and the open metadata types"
    3.  "Figure 4 : XYZ tools and repository using the OMAG Server as a Repository Proxy with a local repository acting as a an extension store for metadata"
    4. From figure 3 to figure 6, all the purple oval for XYZ OMRS Connector, the spelling was "XYZ ORMS Connector"