...
The Open Metadata Access Services provide the APIs and notifications that will be used by tools, application and engines to access and update metadata in the open metadata repositories. There are multiple, independent OMASs, each targeted at a particular type of tool, application or engine.
Inside an OMAS
...
Figure 1 shows the typical structure of an OMAS. Tools, applications and engines can connect to an OMAS through its API or use its topics to either post metadata to the open metadata repositories or receive notifications about metadata changes.
Figure 1: Anatomy of an Open Metadata Access Service (OMAS) | Every OMAS supports a Java client interface that runs locally in the metadata tool, engine, application. These client interfaces can be downloaded and used independently with the Open Metadata and Governance Client Package. For callers that do not use Java, there is an OMAS REST API and an event notification interface (typically supported by Apache Kafka) behind the Java client interfaces that can be called directly. The event notification interface for each OMAS has a topic to allow an external caller to post metadata updates to the open metadata repositories (OMAS In Topic) and another topic (OMAS Out Topic) to receive relevant updates that have come from other parts of the open metadata and governance ecosystem. |
...
Both the REST API and the topics interact with the OMRS to receive and sent metadata to the open metadata repositories, either by receiving messages on the OMRS Topic or by calling an OMRS Connector. The type and configuration of the OMRS Connector (and hence which metadata repositories it connects to) is set up when the OMAS APIs are deployed.
The OMAS APIs are deployed together in a single web application. This application can be co-located with a metadata repository, or can be deployed independently (see Open Metadata Packages to understand the options). The implementation of the OMRS Connector handles the communication between the OMAS application and the metadata repositories, whether this is through local or remote calls.
The implementation of a specific OMAS is independent of other OMASs to allow each OMAS to develop at the pace of its consuming community. However, the implementation of an OMAS follows a common design pattern and naming conventions which are described here: standards for OMAS interfaces.
...
OMAS Inventory
The OMASs that are either available or in development are shown in the table below.
| Name | Description | StatusJira/Module | ||||||
|---|---|---|---|---|---|---|---|---|
| Asset Catalog OMAS | Provides | access to metadata through an OCF connector. It is designedsearch and query capabilities for tools and applications | that are using OCF connectors to access data resources, IT infrastructure and/or software components. It provides the metadata about these resources at 3 different levels of detail plus the ability to provide feedback on these resources. This feedback is linked to the resource's metadata entry in the open metadata repositories.In development | |||||
| Connector Directory OMAS | Organizes and groups connection definitions into connector directories to make them easier to find. It is designed primarily for the Connector Broker from OCF but it can also be used by tools that need to manage collections of connectors. | In development | ||||||
| Glossary OMAS | Provides maintenance APIs and notifications to open metadata glossaries. It is designed for tools that are used to author and managed the glossary categories and terms. This includes taxonomy and ontology tools. | In development | ||||||
| to support a metadata catalog function. It supports search requests for metadata with specific characteristics and returns summaries of the matching metadata, plus methods to allow drill-down into the details of a specific metadata entity/relationship and navigation to related metadata. | In design | |||||||
| Asset Consumer OMAS | Provides services to applications using OCF Connectors to work with different types of assets such as data stores, APIs and analytical functions. It provides a factory for connectors that is able to look up connection metadata and call a Connector Broker to create the required connector. It also provides access to governance services such as Audit Logs. | In development | ||||||
| Asset Owner OMAS | Provides services for an information owner to curate metadata about their asset(s) and understand how these assets are being used and governed. | Concept | ||||||
| Community OMAS | Support the administration for a community and user profiles. | Concept | ||||||
| Support metadata lookup in the open metadata repositories to support the OCF connector getConnectedAssetProperties() method. | In development | Governance Engine OMAS | Provides information about the real-time governance requirements for a collection of assets. This OMAS is used by governance enforcement engines such as Apache Ranger. | In development | ||||
| Data Platform OMAS | Provides a standard hooks and bridges integration point to enable data platforms to publish metadata to the metadata repositories about the changing structures and content stored in the data platform. | Concept | ||||||
| Information View OMAS | Provides information on existing assets plus the ability to define views over these assets. This OMAS is used by BI reporting tools and virtualization/federation tools to configure their engines. | In development | ||||||
| Catalog OMAS | Provides search and query capabilities for tools and applications to support a metadata catalog function. It supports search requests for metadata with specific characteristics and returns summaries of the matching metadata, plus methods to allow drill-down into the details of a specific metadata entity/relationship and navigation to related metadata. | In design | ||||||
| Data Science OMAS | Provides access to metadata for data assets, connections and projects, plus the ability to maintain metadata about data science notebooks and models | Governance Definitions OMAS | Provides the ability to maintain a governance program in the open metadata repositories. It is designed for | governancedata science and | CDOanalytics management tools. | In design | Concept | |
| Developer | Information ProcessOMAS | Provides access to glossaries, schema definitions and code snippets for software developers as well as the ability to | manage process metadata that is used to provide design metadataquery and maintain API definitions. It is | used by data engineering tools such as ETL designdesigned for API management tools. | Concept | |||
| DevOps OMAS | Provides services for | an information owner to curate metadata about their asset(s) and understand how these assets are being used and governed.Concept | Stewardship OMAS | Provides services for managing exceptions discovered in the information landscape that need correcting. These exceptions may be quality errors, missing or outdated information, invalid licensing, job failures, and many more. The stewardship OMAS also enables the review and triage of the exceptions, simple remediation and status reporting. | a DevOps pipeline to query and maintain metadata about systems, processes and software components that are being deployed into the information landscape. | Concept | ||
| Discovery OMAS | Provides the services for discovery services plugged into the Open Discovery Framework (ODF) to manage their configuration and file reports of the annotations they have discovered when analyzing data assets. | In design | ||||||
| Community Governance Engine OMAS | Support the administration for a community and user profiles. | Concept | ||||||
| Project Management OMAS | Support the management of projects and campaigns. These projects and campaigns may be for governance projects, or generic data use projects. | Concept | ||||||
| Provides information about the real-time governance requirements for a collection of assets. This OMAS is used by governance enforcement engines such as Apache Ranger. | In development | |||||||
| Governance Program OMAS | Provides the ability to maintain a governance program in the open metadata repositories. It is designed for governance and CDO tools. | In design | ||||||
| Information Infrastructure OMAS | Provides support for the design and planning of the information infrastructure that supports the data assets. | Concept | ||||||
| Information Landscape Information Architecture OMAS | Provides the ability to define information standards, definitions, blueprints and models for an organization. It is designed for information architecture tools. | Concept | ||||||
| Information Process OMAS | Provides the ability to manage process metadata that is used to provide design metadata. It is used by data engineering tools such as ETL design tools. | Concept | ||||||
| Information Protection OMAS | Provides the services to support the definition of roles and rules for managing the protection of metadata and assets, plus work with the audit logs captured by the open metadata and governance tools. | Concept | ||||||
| Information Landscape View OMAS | Provides support for the design and planning of the information infrastructure that supports the data assets. | Concept | information on existing assets plus the ability to define views over these assets. This OMAS is used by BI reporting tools and virtualization/federation tools to configure their engines. | In development | ||||
| Project Management OMAS | Support the management of projects and campaigns. These projects and campaigns may be for governance projects, or generic data use projects. | Concept | ||||||
| Stewardship OMAS | Provides services for managing exceptions discovered in the information landscape that need correcting. These exceptions may be quality errors, missing or outdated information, invalid licensing, job failures, and many more. The stewardship OMAS also enables the review and triage of the exceptions, simple remediation and status reporting. | Concept | ||||||
| Subject Area Expert OMAS | Provides maintenance APIs and notifications to open metadata glossaries. Also provides | Reference Data and Mappings OMAS | Providesthe ability to manage reference data and mappings between different types of reference data and | schemasschema. This OMAS is designed to support tools that capture knowledge about data resources from their subject matter experts. This includes glossary, taxonomy and ontology tools. | In development | Concept
...
Inside an OMAS
Figure 1 shows the typical structure of an OMAS. Tools, applications and engines can connect to an OMAS through its API or use its topics to either post metadata to the open metadata repositories or receive notifications about metadata changes.
Figure 1: Anatomy of an Open Metadata Access Service (OMAS) | Every OMAS supports a Java client interface that runs locally in the metadata tool, engine, application. These client interfaces support calls to the REST API and provide message helpers for the OMAS Topics. They can be downloaded and used independently with the Open Metadata and Governance Client Package. For callers that do not use Java, there is an OMAS REST API and an event notification interface (typically supported by Apache Kafka) behind the Java client interfaces that can be called directly. The event notification interface for each OMAS has a topic to allow an external caller to post metadata updates to the open metadata repositories (OMAS In Topic) and another topic (OMAS Out Topic) to receive relevant updates that have come from other parts of the open metadata and governance ecosystem. These topics are handled by the OMAS Event Listener and OMAS Event Publisher respectively. Both the REST API and the topics interact with the OMRS to receive and sent metadata to the open metadata repositories, either by receiving messages on the OMRS Topic or by calling an OMRS Connector. The type and configuration of the OMRS Connector (and hence which metadata repositories it connects to) is set up when the OMAS APIs are deployed. The OMAS APIs are deployed together in a single web application. This application can be co-located with a metadata repository, or can be deployed independently (see Open Metadata Packages to understand the options). The implementation of the OMRS Connector handles the communication between the OMAS application and the metadata repositories, whether this is through local or remote calls. |
...
The implementation of a specific OMAS is independent of other OMASs to allow each OMAS to develop at the pace of its consuming community. However, the implementation of an OMAS follows a common design pattern and naming conventions which are described here: standards for OMAS interfaces.
Proposed standards for OMAS interfaces
...
...