Grouper Developers Forum

[Chris Hyzer <>]

Scott, what if the messaging system were an easy to setup and very 
inexpensive SaaS product?  (e.g. AWS).  Would that be acceptable for smaller 
institutions who don’t want to run another component?

Thanks,
Chris

Ps. granted we need to address the ordering of messages in SQS which I think 
we can do

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Scott Koranda
Sent: Thursday, August 14, 2014 2:54 PM
To: Michael R. Gettes
Cc: Michael Hodges; 

Subject: Re: [grouper-dev] Draft Minutes: Grouper Call July 30, 2014

On Thu, Aug 14, 2014 at 1:35 PM, Michael R. Gettes 
<>
 wrote:
> We share the same vision Michael.  Our changelog consumer makes use of the
> AMQ library calls.  It shouldn’t be hard to substitute XYZ broker API to
> make it compatible with Rabbit and so on.

+1

I understand the value proposition for making AMQ the preferred
message broker, and a tight
integration with Grouper makes sense to me, but I would like to see
the changelog consumer
flexible enough so that one could "easily" use a different message system.

I would also appreciate an effort to standardize on the message format(s).

I disagree with Michael about a change log consumer that provisions
directly to LDAP. For smaller
campuses and virtual organizations a change log consumer that directly
provisions to LDAP (including
a bulk synchronization mode or cycle) is preferred even if a messaging
system like AMQ ends up being
well integrated with Grouper. Having the additional message broker
piece adds extra complexity
that smaller organizations simply do not want to deal with. The
Grouper team always has to make
tradeoffs and decisions about where to invest limited effort and IMHO
it is worth the effort to have
a simple LDAP provisioner not bound to a messaging system that is
known to support the major
LDAP implementations (OpenLDAP, 389, Sun/Oracle, MS AD).

Thanks,

Scott K