.. _UC21:

Use Case 21 - Owner Subscribe to CRUD Operations
------------------------------------------------

.. index:: Use Case 21, UC21, subscribe, owner subscribe, notify, watch

Revisions
  View document revision history_.

Goal
  Data owners can subscribe to notification service for object management
  (create, read, update, delete, replicate) operations for objects they own.

Summary 
  The system should support a mechanism for notifying a content owner of use
  of content they own. One approach may be to support a feed (e.g. RSS or
  Atom) whose entries indicate events related to an object or family of
  objects. Since object may be replicated to multiple nodes, an aggregator is
  necessary to provide a complete report to a user. The CNs keep aggregated
  logs of object access, so feeds may be generated by the CNs, however issues
  of scalability should be considered.

Actors
  - Subscriber
  - Coordinating Node

Preconditions 
  - Content has been added to system
  - Subscriber has access to content

Triggers
  - A new subscriber joins the system by creating a feed definition
 
Post Conditions
  - A new subscriber is recorded
  - A new feed is generated

.. 
   @startuml images/21_seq.png
   actor "User (Data Owner)" as user
   participant "Client" as app_client << Application >>
   user -> app_client
   note left
   Assume user authority
   for notification registration.
   end note
   participant "Register API" as c_reg << Coordinating Node >>
   app_client -> c_reg: registerForNotification (token, dataOwnerID)
   app_client <-- c_reg: ack or fail
   @enduml

.. image::  images/21_seq.png

*Figure 1.* Interactions for use case 21.


**Notes**

Although conceptually simple, implementing a subscriber broadcast service that scales to tens of thousands of users and potentially billions of objects is non-trivial. The process for generating a feed entails processing accumulated logs to extract the relevant events, creating the feed entries, and rendering the feed on demand.

Some observations:

- DataONE should be able to support at least one feed for each user, so say,
  about 100,000 feeds.

- Read operations should far exceed the number of other types of operations,
  thus supporting only non-read log events would significantly simplify
  reporting.

- Can we leverage an asynchronous messaging service such as XMPP or Twitter to
  hand off the logging / feed generation to other services?

.. _history: https://redmine.dataone.org/projects/d1/repository/changes/documents/Projects/cicore/architecture/api-documentation/source/design/UseCases/21_uc.txt