Versions Compared

Old Version 1

changes.mady.by.user Mandy Chessell

Saved on

compared with

New Version Current

changes.mady.by.user Mandy Chessell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Removed obsolete material

...

 

Image Modified

The Adapter integration pattern enables an existing metadata repository repositories and their tool set 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 Repository 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 which are then published to the other metadata repositories in the cluster.

 

The development steps to implement the Adapter integration pattern are:

  1. Determine the mapping between your metadata repository and the open metadata types.
  2. Create a connector that implements the OMRS 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.

 

...

by

...

an OMRS Repository Event Mapper.  The Repository Event Mapper publishes the resulting OMRS Events to the other metadata repositories in the cohort.

 

 

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.

Image Added

Figure 1: High level operation of the adapter pattern

 

The development steps to implement the Adapter integration pattern are:

  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

Image Removed

Figure 1: event notifications that enable XYZ to joint the open metadata ecosystem

  1. New metadata is created through the XYZ API
  2. The XYZ metadata repository generates an event to describe the changed metadata. 
  3. The XYZ Event Mapper converts that event into an OMRS Event.   
  4. The XYZ Event Mapper logs the OMRS Event in its OMRS Audit Log.
  5. The XYZ Event Mapper posts the OMRS Event to the OMRS Topic.
  6. The OMRS Event Listener for each consuming metadata repository receives the OMRS Event.
  7. The OMRS Event Listener, if configured to do so, passes the OMRS Event to its OMRS Connector (the XYZ OMRS Connector in this case).
  8. The OMRS XYZ Connector calls the XYZ REST API to store the metadata.
  9. The OMRS Event Listener then sends an acknowledgement event to the OMRS Topic.
  10. The OMRS Event Listener for the originating metadata repository receives the acknowledgement
  11. The OMRS Event Listener then logs the acknowledgement in its OMRS Audit Log.

 

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

 

Figure 2 shows the deployment of the adapter integration pattern components for a metadata repository and toolkit called XYZ.  It assumes the Enterprise OMRS 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.   New metadata is also being created through the XYZ toolkit user interfaces (see bottom left of figure 2).  These updates result in notifications that are processed by the XYZ Event Mapper and converted into OMRS event notification messages and posted on the OMRS Topic where they are picked up both by other metadata repositories through OMRS and other tools through the OMASs.

 

Image Removed

Figure 2: Typical deployment of the adapter integration pattern components

 

 

The deployment shown in figure 2 is not the only option.  Figure 3 shows different configurations of the OMRS Connectors to support different choices of where the XYZ OMRS connector runs and the number of network hops that are tolerable.   The options labelled A, B, C, D are described in the notes below the figure.

 

...

Image Removed

Figure 3: Different XYZ OMRS Connector deployment choices

...

  1. .

 

...

 

...