You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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 Apache Atlas Server is an example of the Native Integration Pattern built on the OMAG server that provides value-add services for managing metadata and governance.

The OMAG Server has a REST API and UI for administering the OMAG Server.  This includes enabling the different roles and managing the OMRS connectors and their configuration (connections).  Through this service, the OMAG Server supports the Plug-in Integration Pattern for OCF Connectors.

 

OMAG Server Roles

 

Figure 1 shows the OMAG Server configured as an Access Layer.  This is providing Open Metadata Access Services (OMASs) APIs and Topics to tools and application.  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 cluster (because it does not have a local repository) and so there is no OMRS exchange with other repositories.  The OMASs will receive events from the OMRS Topic to service their own In and Out Topics.

Figure 1: ABC tools deployed with the Access Layer of the OMAG Server

 

Figure 2 shows the OMAG Server with 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 cluster 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 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, it is acting as a proxy for XYZ and so registers with the open metadata cluster registry.

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 augment the metadata in the XYZ repository.  This is used when the XYZ metadata model does not support all of the metadata type, 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.

 

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.

 

Figure 6 adds the metadata repository so the repository proxy has a local store as well as the XYZ store.

 

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

 

 

 

 

 

  • No labels