You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

 

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 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

 

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.

 

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.

Figure 2: 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 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.  

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.

 

Figure 3: Typical deployment of the adapter integration pattern components

 

 

The deployment shown in figure 2 is only one of the options.  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.

 

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 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.

 

 

 

  • No labels