Event Based Notification and Map Reduce

To begin, I felt that the Event Based Notification added very little to the generally known observer pattern. The only real differences I was able to spot was that there was a discussion of choosing the correct medium to transmit messages, such as a bus, and then briefly mentions that it may be necessary to consider notifying listeners on other threads. The specialization of this system seems to be in that all objects on the medium will receive and check the message sent to see if they are concerned about its content and act appropriately as opposed to a system where objects must register with some central authority about the type of event they wish to be notified of. The method outlined in the paper does have the advantage of not needing to maintain a listing of objects that must be broadcasted to which is nice when the system gains many objects that want notification. However, if there are a large number of objects then this tactic looses some of its luster, as many messages must be sent to objects that have no interest in the contents and time must be spent checking which state this object falls in. So, it is best to determine not only the projected growth of the system's objects but also how many objects are expected to actually need to listen for events. If there are many objects but only a few that need contacting then an explicit list will add overhead at creation but will reduce it during normal operation. As for error handling, a given component needs to know how critical the proper reception and execution of a message is. So, while it will probably fall to the medium to detect if all notifications have all occurred (and rectify any misses in the same way most internet packets do find their way) it should be up to the component to determine what it should do with faulty input. No blanket approach is going to satisfy all conditions but my intuition is that the central authority should only be contacted in cases of dire failures.

For the Map Reduce paper I was sad to see such little attention paid to the important steps of actually constructing the summary. Since the application of threads to collect data and use it to derive some basic further information should not be difficult at this stage the trick seems to be in constructing a way to intelligently combine the results in a way that does not sacrifice the efficiencies of the mapping. Unfortunately this paper seemed to be more focused on the general idea of Map-Reduce rather than on the actual application of it, seeming to leave the majority of the work to those Parallel Computing Gurus mentioned in the paper. Nor is there much discussion of creating a way for domain specialists to interact with a system that could ease their use of a Map-Reduce framework. The idea of an extendable framework that allows for both the easy identification of data sets, the mathematical analyses that wish to be performed and the expected output format would be an intriguing system to help construct.