Grouper Developers Forum

[Rob Hebron <>]

As announced, I'm just starting out on connecting Grouper to an ESB, and I
thought it would be useful to outline my direction. This is mainly driven
by a real requirement at Cardiff University.

What we already do at Cardiff

We have an instance of an ESB+extras (basically Mule + Drools + some custom
connectors for LDAP and DSML, called the DRRE) which we use to manage data
flows and out of Grouper.

The DRRE is notified of changes which occur in our Identity Management
system (itself a combination of the DRRE and Novell DirXML) and it
generates group membership requirements using Drools rulesets. These are
transformed into operations which are applied to Grouper using the Grouper
API (which is instantiated within the Identity Management system). We have
event hooks registered with the API which means that changes made within
Grouper are notified to the DRRE. It transforms these events into a simple
XML format and sends them on to another instance of the DRRE, which applies
the group membership to user objects in the Identity Management eDirectory
tree.

As we expand the use of Grouper, the limitations of our current methods are
becoming obvious. I need to address these, and would like to do so in a way
that makes is potentially useful to the Grouper community.

What needs to be done

At the moment what we have a Cardiff is very domain specific and has a
dependency on Mule, which is use at both the client and server and of every
connection, only covers a limited number of events and (as it uses hooks)
is limited to working within the API, and so instance of the API in use
needs to include the hooks. Therefore the following needs to be done:

1. Remove the dependency on Mule (not required at Cardiff, but would make
it much more useful)
2. Convert to using notifications, processed by the Grouper Daemon
3. Develop a generic way of packaging events and sending them to an ESB for
processing
4. If possible, develop a generic way of receiving events from an ESB and
processing them in Grouper (this is way more challenging than 3, and some
functionality would inevitably be duplicated with the WS)
5. Simplify as much as possible, off loading complexity onto the ESB where
appropriate.

The initial implementation will be for Cardiff University, and target Mule
as the ESB. There's no reason why other ESBs shouldn't be supported as
well. Any use cases that people can offer will be very useful, but I can't
promise that functionality will be included to specifically address them.
In my experience ESBs can be configured to do a range of things, so one
scenario may see grouper notifying the ESB of a subject being added as a
member of a group, the ESB notifying the person by Email, tweeting that it
has done so, and updating an LDAP directory. Most of the workflow would
therefore be handled by the (properly configured!) ESB.

I'll continue to post to the list as I move forward, and hope to get wiki
pages up soon.

Comments, suggestions etc welcome.

Regards,

Rob

-----Tom Barton 
<>
 wrote: -----

To: Grouper Dev 
<>
From: Tom Barton 
<>
Date: 02/17/2010 06:57PM
Subject: [grouper-dev] ESB connector

People may recall that since Fall 2009 we've been looking for a partner
to help us develop a notification connector to send group-related info
into an asynchronous messaging environment (ESB usually, these days).
This is an element in our roadmap:
<https://spaces.internet2.edu/display/GrouperWG/Grouper+Product+Roadmap>.

Rob Hebron, a developer under contract with Cardiff University, has
expressed interest in working with us on that. It'll be intended for
actual use at Cardiff to integrate their grouper implementation with
their Mule ESB, so we'll use the particulars of their circumstances to
help us constrain the abstract problem of sending info into messaging
systems.

Thanks Rob, and welcome!

Tom