The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

JGF1 (322) [Avatar] Offline
#1
There are a couple of methods that return new instances
EventCorrelatorCallback()
MuleMessageInfoMapping()
They have nested methods within them.

Is this some sort of annoymous inner class?
Is this something to do with part of the the AbstractEventAggregator class that I'm not familiar with?

What's the whole deal with the correlationID and the hard coded 2 on the new EventGroup? Is this something to do with the fact there are only two prices to compare?

Finding it hard to understand this.
Could have done more in surrounding paragraphs to get reader up to speed here I think.

Was just looking here...
http://www.mulesource.org/docs/site/current2/apidocs/org/mule/routing/inbound/AbstractEventAggregator.html
tijs.rademakers (494) [Avatar] Offline
#2
Re: Can someone explain listing 4.15 in more detail.
Point taken, the explanation is a bit short.
Yes, the EventCorrelatorCallback and MuleMessageInfoMapping classes are anonymous inner classes. The same implementation could also be done with just plain sub classes, but we thought this was a bit more elegant. So it's not specific for the AbstractEventAggregator.

The EventGroup instance expects a correlation identifier, so the correlationID, and the expected number of messages arriving. And that's in this case always 2. But you can easily make this configurable by using Spring's dependency injection.

Hope this provides enough explanation.

Best regards,

Tijs
JGF1 (322) [Avatar] Offline
#3
Re: Can someone explain listing 4.15 in more detail.
Hi Tijs.
Is there a web reference that explains AbstractEventAggregator in more detail? ( A UML sequence diagram would help)
I say this because I'm assuming this Abstract class is some sort of template pattern that invokes these methods.
It's the not understanding how the pieces of the jigsaw fit together; the orchestration if you will, that's throwing me here more than anything.
Book failed to give me the grounding I needed to get the bigger picture.
Cheers.
Jeremy
JGF1 (322) [Avatar] Offline
#4
Re: Can someone explain listing 4.15 in more detail.
I think I may have worded this incorrectly in my confusion over the code.
Is the EventCorrelatorCallback some sort of template, rather than the AbstractEventAggregator?
When you return the newEventCorrelatorCallback, you then proceed to define multiple methods: aggregateEvents, createEventGroup and shouldAggregateEvents.

I'm thinking MuleMessageInfoMapping is doing something similar with the getCorrelationId

I've seen anonymous inner classes with things like Swing event listeners and callbacks in Spring, but I guess it's the seeing three methods for EventCorrelatorCallback thats baffling me the most.
I'm trying to understand how/why you need to implement these methods, how it all fits together.

I do have Enterprise Integration Patterns book on my bookshelf too. Is there something in there that may shed some light? (My assumption regarding correlation ids was confirmed. But here again can't recall reading much about this either). I've managed to read up to chapter 8 so far and no other part of the book baffles me so much as this section...
tijs.rademakers (494) [Avatar] Offline
#5
Re: Can someone explain listing 4.15 in more detail.
When you need some kind of aggregation functionality you can define your own implementation based on the AbstractEventAggregator, just like the standard Mule aggregators CorrelationAggregator and SimpleCollectionAggregator do. When you implement the AbstractEventAggregator, you'll need to implement the method getCorrelatorCallback which must return an implementation of the interface EventCorrelatorCallback. That's what we do in listing 4.15, implement the interface with an anonymous class. You could just as will implemented this with a normal class. This EventCorrelatorCallback and MessageInfoMapping instances are used in the process method of the AbstractEventAggregator implementation to do the correlation. I would advise you to look at the source code of all these classes to understand the full picture. You'll not find something about this use of patterns in the EIP book, this is more Gang of Four patterns material.

Best regards,

Tijs