Grouper Developers Forum

[Chris Hyzer <>]

I could picture a java interface that writes and reads messages from 
messaging systems.  Standard message formats are key.  Inbound and outbound 
messages could be based on implementations for each messaging vendor.  
Obviously we would have one for activemq.  Hopefully based on the interface 
requirements we could make an implementation for AWS and using SQL based on 
or similar the change log consumers (if not too much effort).  If ActiveMQ 
has UIs and has better performance over the SQL option that is a motivator to 
use it, but institutions don't have to...  Not saying we need to reinvent the 
wheel, we already have change log consumers, maybe we can make that work 
without too many changes.

Thanks,
Chris

-----Original Message-----
From: Bryan Wooten 
[mailto:]
 
Sent: Thursday, August 14, 2014 4:32 PM
To: Michael R. Gettes; Scott Koranda
Cc: Chris Hyzer; Michael Hodges; 

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

Thanks all for the entertaining thread.

I have to agree with Scott on this one. Just think about the hassle of 
bringing up Grouper for a POC (ie quickstart).

Just my 2 cents.

-Bryan

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

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

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

And if a small site can't run this, then maybe they should be hiring a firm 
to do it for them.

Can we think of any?  hmmm

/mrg

On Aug 14, 2014, at 4:06 PM, Scott Koranda 
<>
 wrote:

> On Thu, Aug 14, 2014 at 2:22 PM, Chris Hyzer 
> <>
>  wrote:
>> 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?
> 
> In my opinion, no. You are asking the organization to set up and pay 
> for a SaaS product when they might not have any such existing service 
> contracts and no easy way to procure one (I put LIGO in this 
> category--we have to approach funding agencies to ask for permission 
> to spend grant money on such things).
> 
> The thinking will go something like "I have my groups in Grouper and I 
> just need them put into LDAP. I did that before with ldappc, then 
> ldappc-ng, and then (with a bit more pain) the PSP. Now you tell me 
> there is this embedded messaging service, that I will not have to 
> bother with, until something doesn't work and a message is lost and I 
> have to track it down at which point I need to learn a bunch of stuff 
> about AMQ that I have no other use for".
> 
> I *do* get the (architectural) attraction of using a messaging service 
> with a bunch of consumers/provisioners and fully support the idea.
> Most campuses I believe should be taking just such an approach. I just 
> think it should not be necessary for smaller organizations that want 
> to deploy Grouper, LDAP, and not much else.
> 
> Thanks,
> 
> Scott
> 
>> 
>> 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