MIR Notifications

Nadim wants to use his generic DataBase^? Notification Service to generate notifications of changes in the MIR.

Here are some thoughts on what these might be.

These assume that the triggers and Topics are established administratively in advance, and that (at least in the future) filtering by additional headers and/or content as well as Topic is possible (apologies for possible incorrect second-hand terminology).

DBNS requirements

I think this basically uses DB2's trigger facilities. As such, a condition (which is effectively an SQL 'WHERE' clause over the 'New' and 'Old' row values) is applied for one of 'INSERT', 'DELETE, or 'UPDATE' on a chosen table.

Suggested notifications

('SubjectID' replaces 'TopicID' for clarity, and some reorganisation into minimal/desired -- ChrisGreenhalgh - 14 May 2003)

WFInstance status change

I.e. Workflow status change or updating of provenance.

'UPDATE' on MIR3.WFInstance

Minimal outputs:

• Topic, say 'MIR3WFInstanceStatusChange'
• PK of updated WFInstance, i.e. WFInstance row ThingID^?

Desired outputs:

• SubjectID^?, WFInstance ExternalURI^? (i.e. "SELECT ExernalURI^? FROM MIR3.Thing WHERE ThingID^?=?", arg=PK of changed row - note not at all sure about trigger/SQL syntax...)
• New status (i.e. "SELECT status FROM MIR3.WFInstance WHERE thingID=?", arg=PK of changed row)

Addition of new DataThing^?, WFDefinition, WFInstance or WorkContext^? to a WorkContext^?

Note: this exploits the generation by the MIR3Service of 'wasCreatedIn' Associations when these things are added to the MIR.

'INSERT' on MetaData^? WHERE "New.predicate=(SELECT ThingID^? FROM MIR3.Thing WHERE ExternalURI^?='wasCreatedIn')"

Note: the thingID for the 'wasCreatedIn' predicate should be constant for any given MIR and might be provided explicitly in the condition to yield a simple (but MIR instance-specific condition) such as WHERE "New.predicate=X"

Minimal outputs:

• Topic, say 'MIR3WorkContextAddition'
• PK of new Association, i.e. MetaData row ThingID^?

Desired outputs:

• SubjectID^?, WorkContext^?'s ExternalURI^? (i.e. "SELECT externalURI FROM MIR3.Thing WHERE thingID=(SELECT object FROM MetaData^? WHERE thingID=?)", arg=inserted MetaData row PK value)
• ObjectID^?, added thing's ExternalURI^? (i.e. "SELECT externalURI FROM MIR3.Thing WHERE thingID=(SELECT subject FROM MetaData^? WHERE thingID=?)", arg=inserted MetaData row PK value)

Annotation of one of my things by someone else

You probably don't need to be notificied of your own Annotations of your own things!

'INSERT' on MetaData^? WHERE "(SELECT Thing.createdBy FROM MIR3.Thing WHERE ThingID^?=New.subject)!=(SELECT Thing.createdBy FROM MIR3.Thing WHERE ThingID^?=New.ThingID)"

i.e. An Annotation/Association created by someone other than the creator of the Thing being annotated.

But in the worst case, with more client filtering, you could just notify all Annotations (which would also include Associations such as 'wasCreatedIn', used in the last example):

'INSERT' on MetaData^?

In this case, the client then has to perform the additional check equivalent to '(SELECT createdBy FROM MIR3.Thing WHERE ThingID^?=(SELECT subject FROM MetaData^? WHERE thingID=?))!=(SELECT createdBy FROM MIR3.Thing WHERE thingID=?)', args=PK of inserted MetaData row.

Minimal outputs:

• Topic, say 'ThirdPartyAnnotation' (or 'NewAnnotation')
• PK of new MetaData, i.e. MetaData row ThingID^?

Desired outputs:

• SubjectID^?, annotation/association's subject ExternalURI^? (i.e. "SELECT externalURI FROM MIR3.Thing WHERE thingID=(SELECT object FROM MetaData^? WHERE thingID=?)", arg=inserted MetaData row PK value)
• ObjectID^?, annotation/association's object ExternalURI^? (i.e. "SELECT externalURI FROM MIR3.Thing WHERE thingID=(SELECT subject FROM MetaData^? WHERE thingID=?)", arg=inserted MetaData row PK value)
• Predicate, annotation/association's predicate ExternalURI^? (i.e. "SELECT externalURI FROM MIR3.Thing WHERE thingID=(SELECT predicate FROM MetaData^? WHERE thingID=?)", arg=inserted MetaData row PK value)
• PredicateQualifier^?, annotation/association's predicate qualifier (i.e. "SELECT predicateQualifier FROM MetaData^? WHERE thingID=?", arg=inserted MetaData row PK value)

Notification service notes

Want to filter on Topic and SubjectID^?, but not (so far, anyway) on additional info beyond this.

If, in the short term, we cannot filter in the notification service on SubjectID^? then perhaps we can do this locally in the NetBeans client?!

Further clarifications (from an email)...

My current view of how this could work together is:

• The DBNS is configured in advance of normal use by an administrator to generate a small set of standard kinds of notifications, as per the examples on the Wiki, e.g. a DataThing^? added to a WorkContext^?. Each 'kind' of notification is realised using a particular trigger and condition.

• The information characterising such an event that is significant to the user is: the broad kind of event (e.g. 'AdditionToWorkContext'), the MIR changed, the LSID of the particular WorkContext^? added to, and the LSID of the thing added to that WorkContext^? (and possibly other information about the WorkContext^? or Thing, e.g. owner/creator, type).

• The User may explicitly or implicitly indicate a desire to receive such notifications in a range of ways. For example, they might configure their client to say that they wish to monitor all of the WorkContexts^? that they created (or 'used') by default, or they might choose an explicit action on a particular WorkContext^? requesting to be notified about additions to it. In the case of WFInstance status they are implicitly interested in it by creating it, but could also express explicit interest in someone else's WFInstance.

• In general the User might make quite complex filters, but as a base case they want to filter on one addition MIR ID, e.g. the WorkContext^? to which the thing was added, or the WFInstance that had its status updated.

• The user also wishes to receive additional specific information from the MIR related to the event, e.g. the ID of the Thing added to the WorkContext^? of interest.

If filtering in the notification service occurs ONLY on topic then there are two implementation/workaround options:

1. The topic is the broad 'kind', one per DBNS trigger/constraint, and the client performs any additional filtering required (e.g. discarding notifications relating to WorkContexts^? that the User does not have access to). Pro: works now. Con: poor performance and scalability for clients.
2. Topics are generated on the fly (by the DBNS, as events occur) from the general kind, concatenated with the particular ID to be used for filtering, in an agreed fashion. The client then manages corresponding subscriptions in parallel. Pro: correct level of filtering occurs in notification service. Con: requires extended functionality from the DBNS, how are these topics GC'd?.

I don't like the variant of 2 in which the client explicitly asks the DBNS to create a new trigger specific to a new topic+id since you will end up with loads of filters that all have to execute on each insert, and it's not clear that the client should (a) know about the DBNS as a distinct service or (b) be given the access required to install triggers in the DB dynamically.

The alternative - to implement additional filtering in the notification service - leaves the DBNS more or less like case 1, and the client more or less like case 2.

-- ChrisGreenhalgh - 12 May 2003 Some updates -- ChrisGreenhalgh - 14 May 2003