Use cases for Registry Notification - With modeling scenarios

[Len Gallagher <LGallagher@nist.gov>]

Registry Notification sublist,

I support a very limited facility for notifying users of Registry events. I 
believe the facility must be limited, almost pre-defined to a select number 
of events, because arbitrary user-defined events could be a severe drain on 
system resources.

My experience with notifications is based on "SQL Triggers" as specified in 
the Database Language SQL standard (ISO/IEC 9075:1999). SQL Triggers are at 
too low a level to be the model for notifications, since they are specified 
over UPDATE, INSERT, and DELETE actions on individual tables. However, what 
I suggest below is strongly influenced by that model.

Use Case #1: There must be a way for "notification users" to declare 
themselves to the Registry.

Discussion #1

The term "notification user" here is not the same as the User class in our 
model. Those User instances are folks or roles who act on behalf of some 
submitting organization (SO). They are authenticated by the Registry and 
are then allowed to act as an alias for the SO to take whatever actions 
that SO is allowed to take.

The term "notification user" is also not the same as the Contact class that 
existed in an earlier version of our model. Those Contact instances were 
also acting on behalf of an SO to answer questions about repository items 
submitted by that SO.

The term "notification user" as far as Registry notification is concerned 
is just some member of the public, possibly not related to any organization 
known to the Registry, who wants to be sent an email message (or other 
notification!) when some specific "event" happens. There is no reason that 
the email recipient can't be a piece of software that takes certain 
action's at the recipient's site based on the content of the email message. 
Those user actions are outside of the scope of the Registry model. However, 
the content of the message is not outside our scope and should be specified 
by Registry Services.

I believe we need a new class in our model, call it NotificationTarget, 
that captures the name and email address of people (or processes) who want 
to be notified when something happens. We need additional Registry Services 
for members of the public to declare themselves as notification targets, to 
identify new events that they want to be notified about, and to delete 
previous notification requests. I believe that NotificationTarget instances 
can be represented by an email address and a name string, e.g. Len 
Gallagher <LGallagher@nist.gov>. The email address can serve as a unique 
identifier for the name, so there is no need to require an additional 128 
bit GUID, although an implementation could assign one if they want to. 
There is no reason to require that Registry Services depend on a 128 bit 
GUID for NotificationTarget instances; if a user wishes to modify its 
notifications it need only supply the email address (and possibly a PIN!) 
in order to make the modifications. The PIN could be an additional 
attribute (optional?) of the NotificationTarget class.

Use Case #2: A minimum number of pre-defined events must be offered by the 
Registry so that public users can request that they be notified when such 
an event happens.

Discussion #2

I think that at least the following events should be supported as 
"notifiable events" by all Registries:

1) A specific repository item being "superceded" by some other repository item.

2) A specific repository item being "replaced" by some other repository item.

3) Registration of a new repository item of a specific objectType, e.g. 
ServiceInterface, cf RIM Section 7.3.2, that satisfies a specific 
classification.

4) The owner of a specific repository item being notified (if they request 
such notification) whenever any other SO creates an Association instance 
that references it as a targetObject. Or creates an Association instance to 
it of a specific associationType, e.g. "Uses" cf. RIM Section 10.1.1.

NOTE 1: Since we don't necessarily have ID's for repository items, the 
above events will have to be expressed in terms of actions on RegistryEntry 
instances.

I think it is possible that all of the notifiable events listed above can 
be represented by a new class in our Model, call it NotificationEvent! All 
4 of the above events are special cases of actions either on the 
Classification class or the Association class, sometimes combined with an 
attribute of the RegistryEntry class, e.g. objectType in 3. Thus the 
NotificationClass may have subtypes as follows: AssociationNotification and 
ClassificationNotification.

An AssociationNotification instance could be represented by the following 
attributes: sourceId, targetId, associationType. For example, the events 
1,2,4 above could be represented as follows:

    1)  (GUID, null, SupercededBy)  -- triggered by new Association 
instance fitting the template
    2)  (GUID, null, ReplacedBy)
    4)  (null, GUID, Uses)

A ClassificationNotification instance could be represented by the following 
attributes: objectType, classificationschemeId, path. Then event 3 above 
could be represented as follows:

    3)  (ServiceInterface, GUIDtoUNSPSC, pathValue)


Use Case #3: A user (i.e. a NotificationTarget instance) must be able to 
modify (i.e. Add and Delete) their notification events.

Discussion #3

All notification requests could be modeled in UML as a new many-to-many 
association between NotificationEvent and NotificationTarget. A user could 
give their email address and PIN and be accepted as a NotificationTarget 
instance. Then they'd be allowed to add or delete instances of this new 
association that link a NotificationEvent instance with a 
NotificationTarget instance.


IMPLEMENTATION SCENARIO

Assuming that instances of the Association and Classification classes are 
treated as rows in SQL tables, say ASSOCIATION_TBL and CLASSIFICATION_TBL, 
then all of the above could be implemented by defining an SQL AFTER INSERT 
trigger on each of these tables.

The Association AFTER INSERT trigger would look at each new creation of an 
Association instance, match it against one or more of the template 
instances of AssociationNotification, and then send a message to the set of 
NotificationTarget instances associated with any one of the selected 
templates. The content of the message would be the set of selected templates.

Similarly, the Classification AFTER INSERT trigger would look at each new 
creation of a Classification instance, get the objectType attribute from 
its parent RegistryEntry instance, then match that information against one 
or more of the template instances of ClassificationNotification, and then 
send a message to the set of NotificationTarget instances associated with 
any one of the selected templates. The content of the message would be the 
set of selected templates.

CONCLUSION

I see implementation of the above scenario being a relatively 
straight-forward process that could be implemented by most Registry 
implementations with little additional effort. Even this limited 
notification facility would be very valuable to Registry users.



**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************