Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] auditing for 1.5

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] auditing for 1.5

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>
  • Subject: RE: [grouper-dev] auditing for 1.5
  • Date: Mon, 5 Jan 2009 14:58:12 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

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.


Archive powered by MHonArc 2.6.16.

Top of Page