Grouper Developers Forum

[Chris Hyzer <>]

Thanks for the email

> 1. Notifications & PIT (point in time audit data). You posit a
> notification architecture that's centered around the database and its
> record of changes. An alternative is for each API instance producing a
> change to emit a notification of that change. That can work provided
> all
> API instances share a common serialization scheme, ie, a way so that
> recipients of their notifications can order them correctly. A way to do
> that is to grab a serial number from the DB, ie, reduce the
> architectural dependence on the DB to just that one function. Did you
> consider an approach along these lines and reject it? What are the pros
> and cons of the two approaches?

I think there should be one point of contact from grouper and the external 
system to reduce chaos, make things easier to deploy/test, and keep messages 
well ordered/reliable.  If the WS adds a group, and the notification to the 
external system fails.  Then in the UI a membership is added to that group, 
the notification will go, and presumably fail.  Then what will finish the job 
when the notifications can succeed again, if there is one daemon, with an 
ordered queue of work, then it will continue its work, or retry some, or 
however we get it to work.  Im not exactly sure what you are suggesting, that 
the WS would contact the external system directly, and that system would know 
to wait for another message from the UI based on a serial number?  An 
advantage of system directly contacting external systems is the message would 
be more timely.  Though as you have said before, the API systems could 
communicate with the daemon to tell it there is work to do...

>
> 2. Although doing PIT and User Auditing in the DB may be easy, I wonder
> about the difficulty of re-integrating a logical group management
> action
> from its DB-level effects. Could you (or someone) illustrate how this
> would proceed in a couple of particular cases? Eg, how would you tell
> that an indirect membership was removed due to an action taken by
> $Subject at $Time?

I think both types of auditing (PIT and user auditing) can be used for data 
investigations like your example.  I don't know the best way to do this, but 
in the data model we have some information linked to memberships (e.g. the 
parent or via membership), which could eventually give you direct membership 
change which caused the delete.  Once you have that, you could use that ID to 
go to the user auditing to see who or what did it and from what system (UI, 
WS, loader, etc).  We could try to automate this process (or whatever process 
we come up with) for users.  E.g. enter a user and a group and an action 
(membership delete), and it could give you a history of PIT and user audits 
that are related (including if it was an indirect or composite membership)

>
> 3. I completely understand the considerable value of using triggers
> from the perspective of performance. However, this raises the prospect of
> limiting the set of RDBMS products (and their revs) supported by
> Grouper. Quite aside from whether that's a good course to take from the
> Marketing perspective, what would implementing that type of support
> realistically mean to us as a development team? Eg, in January 2011
> would we find ourselves under pressure to continue grouper's support of
> older revs of Oracle and SQL Server, older than those running in
> production at each developer's campus? Would that mean that we must run
> a series of revs of each supported RDBMS to test against? Would there
> be licensing costs the Grouper Project would need to underwrite if we're
> not piggy-backing on the license held by some developer's campus? Any
> other operating costs (servers, space, sys admin time to keep the
> required suite of RDBMS-revs running)?

This piece could also be done in java hooks which might be less performant, 
but still work fine for DBs which have issues with triggers or our 
triggers...  the triggers I picture will not be complex so DB triggers 
hopefully will not be too hard to maintain.  Maybe that could be our fallback 
position if this situation occurs.

Thanks!
Chris