Versions Compared

Old Version 5

changes.mady.by.user Mandy Chessell

Saved on

compared with

New Version 6

changes.mady.by.user Mandy Chessell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The Adapter integration pattern enables existing metadata repositories and tool sets to integrate into the open metadata ecosystem.  It requires the development of simple components that map between the proprietary metadata formats and the open metadata formats plus manage notifications around the activity occurring with the metadata repository.

A metadata repository needs the following capabilities to support the adapter pattern:

  • A remotely callable interface (API) that allows metadata to be queried, created, updated and deleted.
  • The generation of event notifications whenever metadata changes in the metadata repository.

The API is wrapped in an OMRS Connector implementation that maps open metadata repository service calls to the API of the metadata repository.   The event notifications are captured and mapped into the OMRS Events by an Event Mapper.  The Event Mapper published the resulting OMRS Events to the other metadata repositories in the clustercohort.

 

 

Figure 1 shows the adapter pattern in operation for a fictitious metadata product called XYZ.  Its OMRS Connector and Event Mapper are running in a Repository Proxy.  The repository proxy manages the OMRS Connector and Event Mapper and ensures they are called at appropriate times.

Figure 1: High level operation of the adapter pattern

...

  1. Determine the mapping between your metadata repository and the open metadata types.
  2. Create a connector that implements the OMRS Repository Connector API and maps calls to its API to calls to your repository's API.
  3. Create an event mapper that maps your repository's event notification to the OMRS event notification messages.

...

The equivalent flow for a metadata repository cluster cohort that contains metadata repositories that natively support the OMRS interfaces is shown here for comparison.

...

Figure 3 shows the deployment of the adapter integration pattern components for a metadata repository and toolkit called XYZ.  It assumes the Enterprise OMRS Repository Connector is configured to access metadata from multiple open metadata repositories, and one of these repositories is XYZ.  The XYZ OMRS Connector has been contributed to Apache Atlas so it can be called directly from the Enterprise OMRS Connector.  When calls are made to the Open Metadata Access Services (OMASs) the Enterprise OMRS Connector passes the request onto each of its configured OMRS connectors.  When it is the turn of the XYZ OMRS Connector, it translates the OMRS call into an XYZ REST Call and maps the response back to OMRS format and returns it to the Enterprise OMRS Connector.  The Enterprise OMRS Connector aggregates the responses from each of the OMRS Connectors and returns them to its caller.  

...

Figure 3: Different XYZ OMRS Connector deployment choices

  • A - The OMASs are configured to talk directly to the XYZ OMRS Connector.  This means all of the metadata requests flow to XYZ.
  • B - This is the same pattern shown in figure 2.
  • C - In this option, the XYZ OMRS Connector has not been contributed to Apache Atlas and so it needs to run in an OMAG Repository Proxy that the XYZ team has constructed and deployed.  This option leaves the XYZ repository and toolkit deployment unchanged but requires two network hops to get from an OMAS API to the XYZ metadata.
  • D - In this option OMRS components have been built into the XYZ product and so the XYZ metadata can be reached through the standard OMRS REST Connector.  This is the pattern that the Apache Atlas metadata repository implements - see Local Atlas OMRS Repository Connector for more details.

 

 

...