Grouper Developers Forum

[Bert Bee-Lindgren <>]

Thanks Mike & Chris,

I just get the feeling that pre-hooks and same-transaction semantics (especially across data sources) are solving problems I don't see: I see huge near-term values of pre-hooks as filters. I don't see how these need coordinated commit/rollback with the GrouperDB transaction.

From reviewing Grouper/Signet roadmap issues, I see the following most affected by Hooks & Plugins. 

  -Notification of changes - email/grouper-to-signet/triggered provisioning

  -History & audit

  -Rule-based action (not sure if this uses plugins, but some rules could be considered augmentation)

Maybe my ACID religion will take a hit from this, but I'm not sure I see the harm in Auditing and (membership and attribute) Augmentation happening based on reliable notifications after the group's transaction commits. Further, when the group is changed via Post-Hook augmentation, it's possible that other pre-hooks should be triggered (Orig action, pre-hook, hib flush, post-hook that augments, pre-hook because request changed, hib flush, post-hook, commit.... ugh... double-ugh if it loops further or if a pre-hook later disagrees)

Generally, I see the following levels of increasing functionality and complexity. And I see current plans for #4 while #1 or 2 seem (to me) to be so much easier and offer so much value.I see 80% of vision I've heard being done with #1 and 90+% with #2. 

1) Pre-hooks as filters, reliable post-action notifications [I'd call this the minimum]

2) #1 with pre-hooks also as augmenters

3) #2 with all pre-hooks seeing the final (augmented) group

4) #3 with post-hooks and same-transaction semantics 

Am I missing Use Cases, or not considering ACID-lite problems, or am I seeing difficulty where there is none?

Put differently, if this is all truly necessary, great. Or if this is easier than it seems, even better.

Thanks, yet again, for you patience,

  Bert

On May 21, 2008, at 11:03 AM, Mike Olive wrote:

Bert,

 

Pre-hooks is certainly the more complicated aspect of this design with the implementation

most likely requiring the use of a transaction manager so that the pre-hook plug-ins may

participate in the final commit or rollback of the actual transaction.

 

On post-hooks persistence, the current design is agnostic of any messaging solution or

transportation mechanism of the change notification. The design is extensible such that

the developer could incorporate a guaranteed messaging solution (client) such as JMS.

--
Michael Olive

 

---

From: Bert Bee-Lindgren []
Sent: Wednesday, May 14, 2008 12:05 PM
To: Chris Hyzer
Cc: Grouper Dev;
Subject: Re: [grouper-dev] notifications vs hooks

Combining our approach to similar problems with UPenn's plans... I think we should consider very different mechanisms for pre-hooks and post-hooks.

Pre-hooks:

Normal, synchronous method calls

Pre-hook plugin developers should expect the event to possibly not occur even if they approve it. They should not notify, log, etc anything that might indicate to a user/auditor/sysadmin that an event happened... because they won't know about downstream rejections.

On the post-hooks, I think we should consider a persistent post-hook:

  a) A plugin would have two inbound methods

a1) "This event happened, do you care?"  [Boolean return, no external processing allowed, must be "fast"]

a2) "Process this event, let us know when you've succeeded in handling it" [Boolean return, TRUE means this plugin succeeded]

  b) Create plugin-specific/event-specific database rows in an event table based on the TRUE returns of a1's

  c) Immediately after all the plugins have had a chance to answer a1, hand the event to all the interested plugins a2's.

  d) Delete the plugin-specific/event-specific row when that plugin's a2 returns true

  e) Retry the failed a2's for a plugin before any new a2

  f) Possibly retry the failed a2's every couple minutes or with some backoff approach (or, disappointingly, wait for the next event)

Yes, this is basically a message queue, but simple to implement (we use a python-based version of this for several event queues in our system). I've looked for a JMS library as simple to use as this two-method approach and haven't found one.

On May 14, 2008, at 2:27 PM, Chris Hyzer wrote:

Gary put comments on my hooks page about transactions and notifications.

https://wiki.internet2.edu/confluence/display/GrouperWG/Hooks+simple

It makes this whole thing very complicated… if the actions happens in a long running transaction, and you want to be notified at the end, there are a few issues:

1.       It is a different architecture than we had been discussing since we need to know about the action at the time of the (successful) commit.  Perhaps using Hibernate’s events could do the trick, but you don’t have any object model anymore, you just have a list of column data for one table

2.       Like Gary points out, if the thing you are updating external to grouper fails, how do you log that and catch up later (e.g. if you are calling a web service, and there is a network issue)

3.       There are lots of different producers of events (UI, WS, extensions e.g. gsh, and direct db edits [granted they shouldn’t]).  Must make sure the notification hooks are registered everywhere, and test them to make sure they are firing everywhere (seems tedious / risky)

Lets take the use case of writing your own ldappc via notifications (something we will start out with at penn).  We want to know about new members, memberships, and groups.  We will just make 3 tables with the id’s and timestamps of when these change:

select * from ldap_change_memberships lcm where rownum < 4 order by lcm.LAST_UPDATED desc

MEMBERSHIP_UUID      LAST_UPDATED

cd5f23d2-a8c8-44c0-a8b1-a3c3210da3c5                5/8/2008 1:21:37.569272 PM

74710fee-40b2-48e4-a8dd-b750876bc4ea             5/8/2008 1:21:37.462896 PM

f2cf6b80-377c-41c3-981d-0eb9274dc74a                5/8/2008 1:21:36.076199 PM

On the grouper tables I have some simple triggers that check for diffs and insert to the change tables (and delete old records since all the daemon cares about is the most recently changed record).

Then we also have friendly views for the daemon to use to query the data:

select gmv.GROUP_NAME, gmv.SUBJECT_ID, gmv.SUBJECT_SOURCE, gmv.MSHIP_TYPE from grouper_memberships_v gmv where rownum <4

GROUP_NAME                                 SUBJECT_ID                        SUBJECT_SOURCE           MSHIP_TYPE

Centers:ISC:PennAccess -ext     GrouperSystem                g:isa                                       immediate

Centers:ISC:PennAccess -ext     GrouperSystem                g:isa                                       immediate

Centers:ISC:PennAccess -ext     GrouperSystem                g:isa                                       immediate

Then a daemon will run every 5 minutes to push the new data to ldap, and delete the record from the change table when done.

So this is all transactional, nothing can slip by (since trigger), and nothing can happen wrong if ldap update fails.

Triggers are DB specific, and it requires different tables for each notification type.

For notifications, grouper could provide:

1.       If you have certain table structures for last_updated dates (perhaps with name prefixes to support multiple)

2.       We could populate with Java hooks (perhaps not reliable per discussion above), or you could do triggers (we could provide examples for certain DB’s) which would be more reliable and probably more performant

3.       We could provide a daemon (e.g. runs every 5 minutes) with callbacks that would process the change tables (based on name prefix), and gives you a callback to take the data and put it somewhere

4.       We could provide a scheduled way to get all data not just the diffs (e.g. daily or weekly or monthly to ensure things are in sync)

Just brainstorming here…

Thanks,

Chris