“Data Incoming!” Event-Based Systems and Self-Determination

A while ago, Steve was helpfully giving me information related to my driving from the passenger seat. I jokingly told him it would be helpful to me if he’d tag his utterances so I’d know what they were. So he started prepending “data incoming!” to the start of his driving tips. So, he’ll say something like “Data incoming! There’s a car on your left!”

Wednesday were driving around Mountain View and he said “Data Incoming! Turn left!” I said “That’s not data, it’s a command.” This is a vital distinction and captures perfectly the difference between request-based system and event-based systems. “Car on your left!” is an event. “Turn left!” is a command.

The Web is a request-based system. The client (browser) sends a command to the server “GET this for me!” and the server is obligated to execute the command or say why it can’t. The client determines what it wants done and then makes whatever commands are necessary to do it. In an event-drive system, the sender merely says that something happened.

The following table shows this pattern of opposites that makes request-based and event-based system the duals of each other:

The first different is in the type of signal. Where the receipt of a request triggers a request-response system, the receipt of an event triggers event-driven systems. An event is a notification of a state change. Thus the nature of an event is different than that of a request. Whereas a request says “do this for me” an event says, “this happened.” In a request-driven system the sender chooses what action to take. In an event-drive system, the receiver interprets the event and determines what action to take.

Event processor has no obligation to the endpoint. Endpoint is obligated to report events and respond to directives. Conversely, a client in a request-drive system has no obligation to the server. It can make a request or not. Servers are expected to fulfill requests.

As we’ve discussed, the interpretation of what an event means is made by the server. A request, on the other hand, implies that the interpretation—what should happen—has already been made.

This last point is critical. Request-based systems are sender deterministic. Event-based system are receiver determinisitc. The receiver determines what happens. The receiver may choose to ignore the sender or to take action. The sender might not even know that action has been taken.

Because of these differences, the flow control of event processing systems is very different than that of request-response systems. Consequently, applications are constructed differently in event-driven systems.

This has significant implications for programmers of event-based systems. They can be harder to program because the fundamental model is so different than that traditional imperative programming model we’re familiar with. We like command-style systems.

On the other hand, the benefits of receiver-deterministic systems–event-based systems–are huge. They largely stem from event-based systems being more loosely coupled than request-based systems. Loose coupling results in systems that are more flexible and less prone to small failures causing large disruptions.

One of my favorite examples is from a May 2001 Scientific American article by Tim Berners-Lee (et.al.) on the Semantic Web. It starts:

“The entertainment system was belting out the Beatles’ “We Can Work It Out” when the phone rang. When Pete answered, his phone turned the sound down by sending a message to all the other local devices that had a volume control. His sister, Lucy, was on the line from the doctor’s office: …”

Do you see the problem with this scenario? While the whole goal of the Semantic Web is to reduce coupling by allowing for dynamic data interpretation, the scenario presents a request-based model of interaction. When the phone sends a “turn sound down” command to local devices with volume controls, it has to know which devices are in the vicinity that have volume controls and explicitly script them. Discovery of this kind of information is difficult and computationally expensive (hence the need for the Semantic Web). Knowing what commands to send to which device entails significant complexity.

Imagine a slightly different scenario:

“The entertainment system was belting out the Beatles’ “We Can Work It Out” when the phone rang. When Pete answered, his phone broadcasts a message to all local devices indicating it has received a call. His stereo responded by turning down the volume. His DVR responded by pausing the program he was watching. His sister, Lucy, …”

In the second scenario, the phone doesn’t have to know anything about other local devices. The phone need only indicate that it has received a call. Each device can interpret that message however it sees fit or ignore it altogether. This significantly reduces the complexity of the overall system because individual devices are loosely coupled. The phone software is much simpler and the infrastructure to pass messages between devices it much less complex than an infrastructure that supports semantic discovery of capabilities and commands. What’s more adding another actor in the system–say a lighting system that raises the lights when there’s a phone call–doesn’t require that every other device be reprogrammed to know it’s there. It simply starts listening for relevant events, interpreting them within it’s own domain, and responding as appropriate.

Events, the messages about things that have happened are the key to this simple, loosely coupled scenario.

Event-based systems are much closer to how most people interact with each other. We all know that our friends and family respond better when we give them data and let them determine how they should act instead of trying to direct their lives for them. Our servers don’t have feelings or an entitlement to self-determination (yet) but even so we can create more compelling and flexible systems if we pretend that they did. “Data incoming!”

Tags:

events

kynetx

event+programming

krl