Event-Based and Map Reduce Patterns

The event-based, implicit invocation, pattern implements a central event medium (i.e. manager) for handling the registration of and dispatching notification to listeners of events posted by the announcer. This concept seems logical so each announcer does not have duplicate similar code for handling registrations from listeners. By utilizing a central multi-threaded medium, many announcers of various events can take advantage of load balancing the notifications to the listeners.

It seems the event-based pattern use of the medium allows greater decoupling over the observer pattern. The announcer is not responsible for knowing which listeners are subscribed to the events as this is handled by the "third-party" medium. I think it actually simplifies the interface and modularizes the processes more. For greater number of listeners and guarantee of message delivery, systems may utilize middleware API like the Java Messaging Service (JMS) or commercialized products like JBoss or SonicMQ.

The map reduce pattern resembles the divide-and-conquer or fork/join framework. The idea is to split up the computations or various data retrieval tasks into smaller pieces and allow multiple threads or processor cores to independently obtain a result and then aggregate the results into a single response.

Errors in the map reduce pattern should be handled by the application developer as different errors require different actions. Depending on the data, an error may not be critical enough to cause the whole computation to be null and void.