THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Figure 1 shows the different options for integrating an existing (or new) metadata tool/engine/repository into the open metadata and governance ecosystem. There are three standard patterns:
Figure 1: Open Metadata and Governance Integration Patterns
| ||
| (1) Caller - in the Caller pattern, a tool, engine or data management platform integrates with the open metadata and governance ecosystem through the Open Metadata Access Services (OMASs). These APIs and notification services are each specialized for a particular type of consumers. The integration team selects the appropriate OMAS to use and builds calls to it. The metadata it creates, stores and consumes are provided by another "product" through the Open Metadata Repository Services (OMRS) "metadata highway". | (2) Native - in the Native pattern, the tool, engine or data management platform embraces the full Apache Atlas stack. Its user interfaces (UIs) integrate with the OMAS APIs, its metadata is stored in its own Apache Atlas metadata repository and, as a result, all of its APIs and integration points use the native open metadata and governance interfaces. | (3) Adapter - in the Adapter pattern the tool, engine or data management platform already has its own proprietary metadata repository and APIs. The investment level and adoption is high enough to make replacing them undesirable, so instead, adapter logic is created to map between the proprietary formats and interfaces and the open metadata and governance formats and interfaces. The componentization of the OMRS is designed to minimize the adapter code that is necessary. |
