The metadata repository that is used to create a metadata entity or a relationship is called the home metadata repository for the entity/relationship.   This means it has the master copy of that metadata and all updates to it should be done through this repository.  So part of the responsibility of the OMRS is to ensure updates happen in the home metadata repository.   However, whenever this metadata repository changes its home metadata, it also sends an OMRS event to the OMRS Topic describing the change.  All other open metadata repositories in the open metadata repository cohort are subscribed to the OMRS Topic and are notified when an OMRS event is posted.   The other repositories can use the event to maintain a reference copy of this metadata entity/relationship in their repository.  When they receive the event about the metadata change - whether they are maintaining a reference copy of not, they send a confirming event on the OMRS Topic.

 


Notification Patterns

Figure 1 shows how events flow between metadata repositories within an open metadata repository cohort.  The components on the left of the OMRS Topic show the behaviour of an open metadata repository sending notifications and receiving acknowledgements, and the components on the right show the behaviour of an open metadata repository receiving notifications about another repository's metadata.   The numbers on the diagram refer to the notes below Figure 1.

Figure 1: standard OMRS notification sequence

  1. New metadata is received through an OMRS Connector, typically from an Open Metadata Access Service (OMAS).
  2. The OMRS Connector stores the new metadata locally in its repository.
  3. The OMRS Connector calls the OMRS Event Publisher to send out a notification about this new metadata.
  4. The OMRS Event Publisher formats the notification message and logs it to its OMRS Audit Log. The notification message includes the metadata repository identifier for the source repository as well as the details of the metadata change.
  5. The OMRS Event Publisher posts the notification message on the OMRS Topic.  All metadata repositories in the metadata repository cohort subscribe to this topic and are notified of this new message.
  6. The OMRS Event Listener is the component that receives the notification message for a repository in the metadata repository cohort.  It unpacks the notification message and ignores it if it contains the metadata repository id for its local metadata repository. 
  7. The OMRS Event Listener has configuration that determines which types of metadata entities and relationships it should pass onto its local metadata repository through the OMRS Connector.  If the notification message contains metadata of the right type, the OMRS Event Listener calls the OMRS Connector for its local metadata repository.
  8. The OMRS Connector saves the metadata as a reference copy in the metadata repository.
  9. The OMRS Event Listener logs the notification message in its OMRS Audit Log and posts an acknowledgement notification on the OMRS Topic to say that the notification has been processed and the action taken.  This acknowledgement notification has the metadata repository id of both the originating (home) metadata repository and the one sending the acknowledgement.
  10. The OMRS Event Listener of the originating (home) metadata repository picks up the acknowledgement.  The OMRS Event Listener for the other repositories ignore acknowledgement notification not for notifications that they have sent.
  11. The OMRS Event Listener logs the acknowledgement in its OMRS Audit Log.
 
  • No labels

2 Comments

  1.  

    in this design, the OMRS Event Publisher will talk with OMRS Topic Connector and the OMRS Topic Connector will infrom OMRS Event Listener. Both the listener and publisher are not directly interacted with OMRS Topic. should the Notifications Patters in Figure 1 also change?

    1. The OMRSTopicConnector is an implementation detail of how the Event Publisher and Event Listener interact with the OMRS Topic.  The diagram you have pasted is part of the internal component design and is at a finer grain of detail than the flows above.  Adding the Topic connector to the Figure 1 above would make it more complex and not help anyone understand the flows better.