Event-Driven Architecture: Event Web Building Block

This article is the third in a series about the Event Web (EW), a thin layer on top of the World Wide Web that continuously monitors information sources and responds appropriately as conditions change. The EW, based on service-oriented architecture (SOA) and event-driven architecture (EDA), can also serve as a platform for Sense and Respond (S&R) systems, a new type of application that continuously responds to critical conditions.

As described in the previous article, software architectures consist of components, compositional operators, and contracts. Compositional operators are used to plug components together with other components. The contract (or specification) of a component tells systems designers everything they need to know about the component. This series discusses SOA and EDA in the context of components, compositional operators, and contracts. The goal is two-fold:

1. Present the architectural components of EDA informally.
2. Explain the concept that in EDA the absence of messages conveys information.

EDA and S&R Systems

EDA is the software architecture for S&R systems, systems that monitor and respond to conditions in their environments. An S&R system is both a control system and a decision-support system, and contracts in EDA can be influenced by ideas from control and decision theory as well as biologically inspired cognitive information processing.

Click here for a larger image.

Figure 1: EDA in Control Systems

An S&R system operates within an environment; for instance, the environment of an airplane is the air through which it travels. The environment is given, because designers cannot pick the environment of their choice. An S&R system designer receives specifications that he or she must satisfy within the system's environment. A public health system is an example of an S&R system that senses and responds to conditions to protect and improve the health of the public. Other examples include living creatures, military command and control, supply and demand chains, and compliance management systems.

The next section introduces the components of EDA and then discusses how the absence of messages can convey information.

Components of EDA

EDA has two components: streams and agents (also called processes). A stream is a sequence of messages that have a common schema. Streams are either event streams or control streams. Messages in event streams contain information about the system state. For instance, a temperature sensor measures the temperature in the environment and generates an event stream in which each message contains a temperature reading. A temperature measurement is information about the system state. Messages in control streams contain control commands. For instance, control messages to a temperature sensor may specify the frequency with which the sensor should send event messages.

Click here for a larger image.

Figure 2: What Does an Event Stream Look Like?

There are three types of agents:

• Sensors
• Responders
• Processing agents (or EPAs for event processing agents)

Sensors monitor the environment and generate event messages that contain information about the attributes that they monitor. For instance, a sensor in an intrusion detection system monitors whether a door is open or closed and generates an event stream describing the status of the door. Sensors may receive control messages such as commands telling the sensors when to make measurements.

For the purposes of designing S&R applications, a sensor is a source of data. For instance, a sensor may poll a Web site and then send the information it extracts in an event message. This sensor would be a software module. The Web site itself is not a sensor but rather an attribute to be sensed.

A responder receives an event stream and modifies the state of the environment based on the stream. For instance, a device that calls people's telephones to give them alerts is a responder. The telephone is part of the environment and the call modifies the state of the environment. A software module that controls the ailerons of an airplane also is a responder.

Click here for a larger image.

Figure 3: Sensor Example: Temperature Sensor

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.

Click here for a larger image.

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.

Click here for a larger image.

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.

Powerful Contracts

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.

Click here for a larger image.

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:

1. 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.
2. 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.
3. 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.
4. 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 ralexander@codeconference.com.