Grouper Developers Forum

["Michael R. Gettes" <>]

FWIW, we use STOMP for the reasons you mention.  It is also our impression 
there are many other apps using STOMP.  The messaging community won’t be the 
ones to decide - it will be the apps who decide what protocol lives.  Kinda 
like with SCIM - SCIM is definitely a good idea and the way to go but the 
number of apps employing it are very few and I have had little luck (no luck) 
convincing vendors to use it.

I think Chris’ answer is most appropriate.

/mrg

> On Jan 27, 2015, at 10:50 AM, Waldbieser, Carl 
> <>
>  wrote:
> 
> Dave,
> 
> To be honest, I have only recently started experimenting with messaging, 
> and I was looking at ActiveMQ and RabbitMQ.  Both seemed to support AQMP 
> and STOMP as well as some other protocols.  There are plenty of client 
> implementations for either around.
> 
> Just browsing around, I seem to get the impression that AQMP is the more 
> complex but feature complete protocol.  It seems like it is easier to write 
> clients for STOMP (text based, simpler protocol).  However, STOMP seems to 
> have a very loosely described PUB/SUB model that may have varying behavior 
> depending on the middleware you use.  AQMP seems to deal more concretely 
> with queues and topics in this regard.
> 
> STOMP has appeal to me in that it seems simple to understand and 
> troubleshoot the actual protocol.  There are 10 commands whose semantics 
> are not terribly complex.
> 
> However, depending on what features Grouper is going to need to leverage, 
> AQMP may be the better choice.  It also seems to have a lot more formal 
> standardization and is used by a lot of big names.
> 
> As far as the actual message payloads go, I would think the format is 
> easily parseable by a wide array client tools, and the mapping to Grouper 
> events ought to be fairly obvious.  I think JSON is fine for a message 
> format.  Lots of modern tools can parse it.  The simpler the messages, the 
> better.
> 
> Thanks,
> Carl
> 
> ----- Original Message -----
> From: "David Langenberg" 
> <>
> To: "Carl Waldbieser" 
> <>
> Cc: "Grouper Dev" 
> <>
> Sent: Tuesday, January 27, 2015 10:08:03 AM
> Subject: Re: [grouper-dev] Grouper Messaging connector question
> 
> Hi Carl,
> 
> We're still working out those details.  The present ideas all center around
> a standard body semantic for the wire protocol based on JSON with Java
> interfaces on either end to handle the idiosyncrasies of various messaging
> platforms.  We hadn't considered either AQMP or STOMP, but since we're
> looking at message formats now, those are certainly things we can
> consider.  Do you have any preference or see the overall message community
> coalescing around one of those?
> 
> Dave
> 
> 
> On Tue, Jan 27, 2015 at 8:02 AM, Waldbieser, Carl 
> <>
> wrote:
> 
>> 
>> On the "Post PSP Provisioning" page [1] it looks like the current thinking
>> is that Grouper will be able to target messaging middleware that can then
>> forward the events on to software that does the actual provisioning.  In
>> the last minutes email that went out I noticed this:
>> 
>>  "Grouper will ship with provisioning connectors to internal, AWS and
>> ActiveMQ".
>> 
>> For the ActiveMQ item-- is Grouper going to be targetting a protocol like
>> AMQP[2] or STOMP[3]?  I realize it may be too early for a definitive
>> answer, but I am curious as to whether support for ActiveMQ is going to
>> translate into support for any messaging system that supports a given
>> protocol (e.g. similar to how LDAP and HTTP servers are fairly
>> interchangable) or if there are idiosyncrasies particular to each messaging
>> platform that need to be addressed by Grouper (closer to how the RDBMS
>> landscape looks today).
>> 
>> Thanks,
>> Carl Waldbieser
>> ITS System Programmer
>> Lafayette College
>> 
>> 
>> [1] https://spaces.internet2.edu/display/Grouper/Grouper+Messaging+System
>> [2] http://www.amqp.org/
>> [3] http://stomp.github.io/
>> 
> 
> 
> 
> -- 
> David Langenberg
> Identity & Access Management
> The University of Chicago