Grouper Developers Forum

[Chris Hyzer <>]

I think the API should send a list of objects, but yours will only have one 
inside.  If we add bulk processing later, it will be an option so that you 
will only have one in ours, but others could have multiple.

> As a side question, shouldn't ChangeLogConsumerBase be an interface as 
> opposed to an abstract class?

Well, maybe an interface with a default implementation that is recommended to 
extend like the Subject API.  I like abstract classes so that you can add 
optional methods without everyone needing to change/recompile their code.  I 
think I am probably in the minority here... but when comparing the pros and 
cons I just don't see it in some cases...

Thanks,
Chris


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

 
[mailto:]
 On Behalf Of Nathan Kopp
Sent: Tuesday, May 10, 2011 11:25 AM
To: 

Subject: RE: [grouper-dev] RE: Recommendation for EsbConsumer

I've been thinking about this a bit.  I do agree regarding the desire for the 
potential of performance improvements based on batch event processing.

Here's the other side, though:

The reason I wanted to use EsbConsumer, as opposed to working straight from 
ChangeLogConsumerBase, is that the it provided a slightly easier-to-implement 
extension point, EsbListenerBase, compared to the ChangeLogConsumerBase 
extension point.
1) The data is passed as a POJO*.  ChangeLogEntry is very flexible, but that 
makes it more difficult to work with.
2) All of the looping and error handling logic was accounted for already.
3) It provided EL-based event filtering out of the box

*Required a modification to the publisher API.

#2 was one of the things that was appealing to me about this extension point. 
 This helps keep my custom code very simple and easy to maintain.  Adding the 
capability of bulk processing would re-introduce that complexity.  Maybe we 
need to provide two extension points: one that takes a list of events, and 
one that takes a single event.  The person writing the provisioning connector 
could then choose if they want simplicity at the cost of performance, or 
performance with increased code complexity.

What I hope to do is take the concepts from EsbConsumer to create an 
easier-to-use generic extension point for provisioning that is somewhat of a 
blend between ChangeLogConsumerBase and EsbListenerBase.  The easiest 
extension point I could imagine would accept individual events (delivered 
sequentially, though parallelism maybe could be introduced in some cases) as 
POJO objects.  Maybe some of this kind of work is already being done in the 
context of ldappc[ng] and real-time-provisioning.

As a side question, shouldn't ChangeLogConsumerBase be an interface as 
opposed to an abstract class?  ;-)

-Nathan


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

 
[mailto:]
 On Behalf Of Chris Hyzer
Sent: Tuesday, May 10, 2011 9:04 AM
To: Rob Hebron; 

Subject: RE: [grouper-dev] RE: Recommendation for EsbConsumer

I asked for this before and I will ask again... I think the API should send a 
List of EsbEvents, even if only one is sent right now.  Then if we want to 
add an option to send multiple at once, we wont have to change the API 
again...

Thanks,
Chris


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

 
[mailto:]
 On Behalf Of Rob Hebron
Sent: Tuesday, May 10, 2011 2:09 AM
To: 

Subject: Re: [grouper-dev] RE: Recommendation for EsbConsumer


>>  However, there's one major drawback: the EsbListenerBase abstract class
>
>>  defines the "dispatchEvent" event method as taking a JSON string
> parameter.
>
>>  I think it would be much more effective if the API instead accepted a
>
>>  single EsbEvent object as the parameter of the "dispatchEvent" method.
>
>>  This would then turn EsbConsumer into a generic provisioning connector
>
>>  (which would probably mean it could be renamed).
>
>>
>
>>  We actually have made these modifications for our implementation, and
>
>>  we'd love to share them with the community if you think they would be
> beneficial.
>
> Note you can convert back to JSON to the beans if you like J. Also note
> that you
>
> would get multiple EsbEvents, not just one. That said, I do think your
> idea is good,
>
> Rob owns this code, Rob, what do you think?
>

Thinking back, I believe that the original design allowed for single 
events only, then I made changes to allow for multiple events. I have 
never used multiple events in a live environment (for similar reasons to 
those Nathan outlines), so I'd be happy to make the change if no-one 
else is using it for multiple events.

We've been using the ESB consumer at Cardiff University to sync all 
group memberships from Grouper to LDAP for about 6 months now and it has 
proved very reliable, with no need for periodic bulk sync. This does 
rely on each part of the chain reporting errors correctly so that 
retries happen properly where appropriate. On a related point: I find 
that the latency in the ESBConsumer is insignificant in comparison with 
latency in other operations in the provisioning chain.

Rob