Issue 10748
Design and integrate the event broadcasting mechanism for registry operations
10748
Reporter: trobertson
Assignee: kbraak
Type: Epic
Summary: Design and integrate the event broadcasting mechanism for registry operations
Priority: Major
Resolution: WontFix
Status: Closed
Created: 2012-02-02 16:06:21.04
Updated: 2017-10-06 15:25:13.756
Resolved: 2017-10-06 15:25:13.74
Description: Many people, modules and components wish to monitor the registry and be notified of changes. This task involves thinking through this process and designing, and then implementing an event publishing mechanism.
Events might include:
- organization created
- data provider endorsed
- new dataset discovered
- dataset renamed
etc.
The events should be well documented, so others (e.g. Tim Hirsch) might read it and understand what events they could potentially subscribe to (with subsequent implementation).
It is possible in thinking through the endorsement procedure that there needs to be some subscription activities as well. ]]>
Author: ahahn@gbif.org
Comment: Only applies in part, as far as notification subscription option is requested. Mostly, this will rather be handled in another work line concerning statistics/tracking (activity, validation, dynamics over time etc)
Created: 2012-02-02 16:44:09.15
Updated: 2012-02-02 16:44:09.15
Author: kbraak@gbif.org
Comment: I have added a new wiki page detailing the various events here: http://dev.gbif.org/wiki/display/POR/Registry+Broadcasting+Mechanism
Created: 2012-02-09 20:02:07.103
Updated: 2012-02-09 20:02:07.103
Author: kbraak@gbif.org
Comment: I have updated the wiki page with a table for each set of events by Node, Organization, and Dataset. The table should be an easy reference for the list of events expected, and to understand what they mean and what their message payload will be.
Created: 2012-02-10 17:05:08.619
Updated: 2012-02-10 17:05:08.619
Author: kbraak@gbif.org
Comment: A 2nd draft of the document has been saved. Changes were made following discussion with Andrea this afternoon.
Created: 2012-02-14 19:41:58.95
Updated: 2012-02-14 19:41:58.95
Author: mdoering@gbif.org
Comment: Do we need to add Network and TechnicalInstallation events to that list? Or should some events apple to several classes?
Created: 2012-02-14 21:40:06.644
Updated: 2012-02-14 21:40:06.644
Author: jcuadra@gbif.org
Created: 2012-02-15 10:24:29.581
Updated: 2012-02-15 10:26:35.44
(This is a bit technical, but don't know other place to discuss about it)
Yesterday, one concern surfaced about where are messages going to be sent from. As of now, messages are going to be triggered from these areas:
- the registry-synchronizer project (e.g. new DS discovered and added to the Registry DB)
- IPT (adding new DS)
- RegisterMe
- Admin console
- others...?
Yesterday having a quick chat with Fede, we talked about who should be the one sending this kind of messages. We kind of agreed that the registry-persistence project should be the one broadcasting these messages. the registry-service project can't be used as the reg-synchronizer will use the persistence layer directly. Would you agree that broadcasting these messages from reg-persistence is the best idea. Im eager to read any possible problems with this appraoch. With this approach, any creation/update/deletion will always emit a message.