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:
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:
- Determine the mapping between your metadata repository and the open metadata types.
- Create a connector that implements the OMRS Connector API and maps calls to its API to calls to your repository's API.
- 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
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 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