Event based, Implicit invocation & Map-Reduce

Map-Reduce

Interestingly enough the idea of the MapReduce pattern is based on the “map” and “reduce” combinators from a functional language like Lisp. In Lisp, a map takes as input a function and a sequence of values. It then applies the function to each value in the sequence. A reduce combines all the elements of a sequence using a binary operation. For example, it can use "+" to add up all the elements in the sequence. Inspired by this concepts the MapReduce algorithm developed within Google offers a mechanism for processing large amounts of raw data, for example, crawled documents or web request logs.

The pattern is mainly related to Master Worker pattern. The Master-Worker parallel structural pattern is well-known for its load balancing characteristics when there are a large number of (relatively) small requests. In the big picture the mapping phase is carried out by a structure very similar to the Master Worker. Additionally MapReduce exhibits the reduce step, which it is fundamentally a concurrent operation with communication costs that are difficult to hide. Scalable reduction algorithms as PLPP and Reduction are crucial to use in this phase. The key to the load balancing characteristics of the Master-Worker is the dynamic assignment of requests to idle workers. In this structure workers execute at their own speed, taking and processing requests when they need more work. In order to avoid the large scheduling overhead of workers, MapReduce however may employ a slightly different mapping strategy. For instance, if the cost of computing the tasks are similar across the full set of tasks, if they can be ordered from large time to small time, a static round-robin schedule may more adequate.

Event based, Implicit invocation

Implicit invocation architectures differ from explicit invocation systems in that implicit invocation system components use events to communicate with each other. Connectors in such architectures are bindings between events and component methods. Because these bindings are determined dynamically at runtime, components are loosely coupled; there is no compile time determination of which method calls will be made. Loose coupling offers software architects the great benefit of increased flexibility and maintainability: new components can be added by simply registering them as event listeners.

Loosely coupled components work together, but do not rely on each other to do their own job. The interaction policy is separate from the interacting components, providing flexibility. Components can be introduced into a system simply by registering them for events of the system, aiding greatly in reusability. Introduction of new components does not require change in other component interfaces, providing scalability as new features are added. Overall, implicit invocation eases system evolution.

Event-based, implicit invocation is an example of a well-crafted architectural style with high cohesion and loose coupling. As such, it is one of the more broadly accepted architectural styles in software engineering. Examples of implicit invocation systems abound, including virtually all modern operating systems, integrated development environments, and database management systems.