Versions Compared

Key

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

...

The Adapter integration pattern enables existing metadata repositories and their 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 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 by an OMRS Repository Event Mapper.  The Repository Event Mapper published 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.

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.

 

Figure 2 shows a deeper level of detail on how these components interact for the fictitious product called XYZ.  The left hand side of the picture shows XYZ as the publisher of open metadata and on the right hand side it is a consumer. Components in purple are specific to XYZ and components in forest green are standard OMRS components provided by Apache Atlas.  The numbers on the diagram refer to the notes below the figure.

Image Removed

Figure 2: event notifications that enable XYZ to join 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 cohort that contains metadata repositories that natively support the OMRS interfaces is shown here for comparison.

 

...

  1. to the

...

  1. OMRS

...

  1. event notification messages

...

 

Image Removed

Figure 3: Typical deployment of the adapter integration pattern components

 

 

The deployment shown in figure 4 is only one of the options.  Figure 4 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 4: Different XYZ OMRS Connector deployment choices

...

  1. .

 

...

 

...