3d pan white

iPhone controlling a living room

Suppose you want a system set up in your living room so that when you get a phone call, your Tivo automatically pauses what you're watching.


In a request-response system the Tivo would have some kind of API and I'd configure my phone--probably by installing an app--so that when a phone call came in, it would send the "pause" command to the Tivo. No so bad. All we need is an API on the Tivo.


Now suppose I want more. I want my stereo to mute the sound when I get a phone call. Another API and another app. But I have a DVR from Comcast in the bedroom and I want that to pause too. Another API and another app.


You see what's going on? I'm creating a hierarchy with my phone at the center. Installing and configuring an app isn't so bad for the first, but do you really want to install and configure apps for every thing (device, appliance, car, and so on) you own? It doesn't scale and the complexity goes through the roof.


Now, imagine an evented system. The phone merely raises and event to an event bus that says "Phil's getting a phone call." The Tivo, listens for phone call events and knows that it pauses (that's the natural behavior for a Tivo when the viewer gets distracted by something else). The stereo knows to pause. And so on. The phone doesn't know they're there. The phone doesn't have to understand their APIs, what commands they understand, or be configured when they are added. If a new DVR shows up, everything else can ignore it. If the stereo component goes away, everything else goes on about there business.


Here's the magic. In a request-response system the requester is obligated to understand the semantics of the APIs it deals with. In event-driven system, the responsibility for semantics falls on the event processor--the receiver. Turning the responsibility around leads to looser coupling.


0 faves
Taken on September 16, 2011