Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Grouper Messaging connector question

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Grouper Messaging connector question

Chronological Thread 
  • From: "Michael R. Gettes" <>
  • To: "Waldbieser, Carl" <>
  • Cc: David Langenberg <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] Grouper Messaging connector question
  • Date: Tue, 27 Jan 2015 15:55:45 +0000
  • Accept-language: en-US

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.


> 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]
>> [2]
>> [3]
> --
> David Langenberg
> Identity & Access Management
> The University of Chicago

Archive powered by MHonArc 2.6.16.

Top of Page