Event-Driven Architecture: Event Web Building Block
One can think of responders in two ways: either as a software module that receives an event stream and controls a device based on the events it receives, or as the device itself. For instance, a responder could be a software module that gets event information about patients in a hospital and pages doctors, or it could be the pager itself. These articles consider responders software modules and completely encapsulate the actual devices (for example, the aileron or the pager) within these modules. Although the software module issues commands to the device, these commands are not part of the design.
An EPA receives and generates message streams, sometimes multiple streams. EPAs do not interact directly with the environment as sensors and responders do; they process the message streams that sensors, responders, and other EPAs generate.
Figure 4: Responder Example: Alert Responder
An S&R system consists of a network of agents where the agents are connected to one another through message streams. An S&R system can be represented as a labeled directed graph whose nodes represent agents and the labeled directed edges represent streams from one agent to another. As a first approximation, one can think of these graphs as acyclic with events flowing from sensors through EPAs to responders, and control signals flowing in the reverse direction.
Figure 5: Sensor, EPA, and Responder in Action
The S&R system may change with time, adding and deleting agents and streams. Since its structure changes much slower than the rates at which messages are generated, thinking of an S&R system in terms of a sequence of versions where agents and streams are fixed in each version makes sense.
Now that you have an understanding of the components of EDA, the next section discusses contracts to illustrate how absence of messages conveys information in EDA.
Consider a simple example: a (sophisticated) temperature sensor that monitors temperature in Pasadena, California and the EPA that receives the event stream that the sensor generates. They share a model of how temperature varies with time, day by day and month by month. For example, the model may predict that the temperature tomorrow will vary from a low of 10 degrees centigrade at 2AM to a high of 20 at 2PM, and then decrease to 10 at 2AM the following day (see Figure 6). A contract between the sensor and the EPA could stipulate that the sensor will send a message to the EPA if the temperature the sensor measured deviates by more than three degrees from the temperature the model predicted. The sensor sends no messages while the measured temperature is within the specified band. Assume that the underlying architecture has a service-level agreement (SLA) to deliver messages from the sensor to the EPA quickly (say, in a couple of seconds) and that temperature changes insignificantly while a message is in transit.
Figure 6: Event Generation: Weather
A key point in such an event-driven system is the absence of messages conveys information. Suppose the EPA receives no messages for a day. You can conclude that the measured temperature was within the predicted band for the entire day. (Of course, this conclusion is predicated on the sensor and message communication network satisfying their contracts.)
Four aspects of EDA allow the receiver of an event stream to make deductions about the system state without receiving messages:
- The contract between producer and consumer of information specifies that a message will be sent when a model prediction is violated. Note that the contract makes the producer responsible for sending the message. The consumer's only responsibility, once the contract is established, is to accept the producer's messages.
- The message generated by a producer contains information, such as a timestamp, that helps the consumer make deductions from the model. For example, if the consumer gets a message timestamped 8:00AM and the next message it receives is timestamped 11:52AM, then the consumer deduces that measurements matched the model in the interval [8:00 AM, 11:52AM] between the two timestamps as measured by the producer's clock.
- SLAs ensure that the consumer can use shared variables such as timestamps in making deductions. For instance, a consumer cannot make deductions if the clocks between the producer and consumer drift apart arbitrarily, and message delays are unbounded so that the producer's timestamps are meaningless. Of course, in practice, clocks do drift, and messages are delayed in transit, but the SLAs about drift and delays help consumers make deductions.
- Control messages from the consumer to the producer of the event stream can tell the producer to change the model used to generate events. For instance, an EPA may change its predictive model of temperature based on information from satellite weather feeds and send a command message containing the new predictive model to the temperature sensor, which then generates events based on the new model.
These aspects fall within a single category: powerful contracts, which require producers to adapt their models (even when sophisticated) to commands from consumers. Compared with SOA, EDA can achieve more with less communication and (often) less computation, but at the cost of more sophisticated contracts.
The next article discusses EDA contracts in more detail and presents design tradeoffs between complexity of contracts, volumes of communication, and number of computational steps. Understanding these issues will help you build effective S&R applications.
About the Authors
K. Mani Chandy is the Simon Ramo Professor of Computer Science at the California Institute of Technology, where he has been a professor since 1989, twice holding the office of Executive Officer of the Computer Science Department. Dr. Chandy does research in distributed computing. He has published three books and over a hundred papers on distributed computing, verification of concurrent programs, parallel programming languages, and performance models of computing and communication systems.
Jonathan Lurie is a newly minted doctoral student at the California Institute of Technology, prior to which he toiled as a "professional software professional" whilst acquiring a bad case of acronym certification measles: MCT, MCSD, MCSE, MCDBA, MCAD.NET, MCSD.NET, MSF, Java Certified Developer, and IBM XML Certified Developer. He currently researches an area of Computer Science known as Sense & Respond at the Infospheres Research Group.
Robert Alexander is a dedicated and creative designer who delivers quality high-end modern designs. Robert can be reached at firstname.lastname@example.org.
Page 2 of 2