Skip to Content.
Sympa Menu

grouper-users - RE: [grouper-users] Grouper and Provisioning

Subject: Grouper Users - Open Discussion List

List archive

RE: [grouper-users] Grouper and Provisioning

Chronological Thread 
  • From: Chris Hyzer <>
  • To: "" <>, Gabby Capitanchik <>, "" <>, Tim gray <>
  • Subject: RE: [grouper-users] Grouper and Provisioning
  • Date: Mon, 2 Feb 2009 12:49:25 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

> Now that hooks are available, we'd be VERY interested in talking to
> sites that are looking to build on that interface to do real time
> provisioning into ldap, etc.

Hopefully in 1.5 we will have "Grouper Notifications", which will be a
reliable way to notify external systems about grouper registry changes,
incrementally, and in real time (well, you configure the interval, e.g. max 1
minute delay). The advantages to this over hooks would be:

1. Traffic to the external system would be more structured and less chaotic
since they would originate from one entity (e.g. the loader), instead of from
the loader, GSH, UI (could be load balanced array), WS (could be load
balanced array)

2. Any updates to the DB would take effect, e.g. if you have to run some SQL
against the DB to do a bulk update or something. Granted we don't want
people doing this, but if you had to... :)

3. Updates would be ordered by the order they occurred in the registry. E.g.
if the WS makes a change, and the UI makes a related change, then the order
of traffic from the UI and the WS to the external system might have a race
condition and be different than what actually occurred in the registry.

4. It would be fail safe. If the destination system is down for a little
while, and grouper hooks started failing, unless you built in your own
queueing mechanism, those changes might get lost. In grouper notifications,
the messages would just sit on the queue in the DB until the external system
is back online

5. It is transactional. If the change happens in grouper, the message will
be on the queue. This is not really case if you are using grouper hooks and
not keeping the data in the grouper database or doing some sort of
distributed transaction or something. E.g. if the change occurs, is
committed to grouper, then grouper gets turned off, before notifying the
external system, when it gets turned on, it will not know it needs to notify.

If we don't like the polling of the work queue table because it is too slow
or inefficient, TomB has also mentioned that the UI or WS could kick the
loader somehow to tell it to do some work...


Archive powered by MHonArc 2.6.16.

Top of Page