Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fixed figure numbering and references as per Yao's comments

...

Figure 2: event notifications that enable XYZ to joint 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.

...

New metadata is also being created through the XYZ toolkit user interfaces (see bottom left of figure 23).  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.

...

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

 

Figure 34: 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 23.
  • 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.

...