2
Event-Processing Patterns in Business

This chapter describes different types of interactions among people and among software components. The chapter analyzes use of these different interaction types at different times in the evolution of information technology, and shows why event-driven interactions are becoming more common today. The differences between different types of interactions are highlighted by studying contracts or expectations between people executing each type of interaction; contracts between people are extended to software contracts between components. The chapter explains why hybrid systems—systems that use different types of interactions for different functionalities—are becoming increasingly common. Understanding the basic types of interactions described in this chapter will help lay the foundation for more detailed analyses in later chapters.

Categories of Business Drivers for Event Processing

Chapter 1 discussed the business drivers for event processing and summarized them in Figure 1-1. Understanding those business drivers is also helpful to understanding trends in the use of information processing patterns in business and IT, as discussed in this chapter, so Figure 1-1 is presented again here as Figure 2-1 for your reference.

The business drivers shown in the first three columns of Figure 2-1 can be aggregated into three basic categories:

Celerity —The pace of business keeps increasing. Celerity—swiftness of action—is an increasingly important competitive advantage.

Connectedness —The world is increasingly interconnected. Events in Guangzhou impact prices in Peoria. Bands in Dublin impact music listening in Los Angeles.

Complexity —The intricacy of business regulations in multiple jurisdictions, convoluted healthcare insurance, and labyrinthine financial instruments (such as credit default swaps and collateralized debt obligations) provide ample evidence of the increasing complexity of business and, indeed, daily life.

Celerity is fundamental to several of the components listed in Figure 2-1, including timeliness, the faster pace of business, time-based competition, and the predictive enterprise. Since more timely service to customers is also better service, celerity is also important in better customer service. The relationship between celerity and these components of Figure 2-1 is shown in Figure 2-2.

Figure 2-1: Escalating business pressures motivate the use of event processing.

Figure 2-2: Celerity and business trends driving event processing.

Connectedness between enterprises and the outside world is a feature that appears in many of the components of Figure 2-1. Globalization requires interactions between components distributed across countries. Market consolidation requires connections between enterprises that are merged or acquired. Different countries and even different states within the same country have regulations dealing with the same issues, and so more complex regulation is also a demand for greater connectivity. Governments are issuing more regulations on the financial sector and other areas of business. Better customer service through the Web requires more attention to connectivity. People and components in different places and time zones help agile enterprises adapt to changing conditions. The relationship between connectedness and these components of Figure 2-1 is shown in Figure 2-3.

The business world is getting increasingly complex. Regulations are getting ever more detailed and regulators require businesses to detect and report noncompliance ever more quickly. Rules and processes become more complicated as markets and businesses are consolidated. Enterprises compete for each individual customer; for example, advertisements associated with keywords on web searches are targeted to satisfy the interests of smaller and smaller groups of customers as they treat each customer as a “market of one.” The adaptive enterprise responds quickly to changes in the economic climate and government actions. People in enterprises are kept aware of situations and key performance indicators across multiple divisions. A few of the roles that complexity plays in business trends driving event processing are shown in Figure 2-4.

Celerity, connectedness, and complexity are characteristics of business trends that result in increasing use of event-driven patterns of interactions. These categories are examples of “consumer pull”—demand by consumers for more support for eventdriven interactions.

Figure 2-3: Connectedness and business trends driving event processing.

Figure 2-4: Complexity and business trends driving event processing.

Trends in technology also increase use of event-driven interactions. These trends are examples of “producer push” that increase usage of event-driven interactions by providing less expensive and more powerful technology. These trends include (see Figure 2-5):

Price —Costs of most items, such as a year of college education, a car, and a kilowatt-hour, have gone up at least tenfold in the last 50 years. In the same period, the dollar cost of an information processing operation, such as the cost of searching a database, has gone down by many orders of magnitude. The cost of information processing operations has changed even more dramatically in the last 50 years when measured not in dollars but in units such as the number of database searches that cost the same as one day of college education. There are many reasons for the decreasing cost of IT, such as Moore’s Law, more powerful software, open source software for event processing, and global competition in the IT space; see Figure 2-5.

Pervasiveness —IT components are increasingly pervasive in all aspects of our lives, including our safety, health, food, water, and energy needs. The densities of transistors on chips and data on storage devices, such as disks, have increased exponentially over the last 50 years. Partly as a consequence, form factors and power consumption ratings of devices have dropped dramatically, and this in turn is leading to increasing use of IT devices in cars, hospitals, and the smart electric power grid. Billions of people are familiar with IT tools, such as the Internet and mobile phones, and this level of education about IT tools makes IT even more pervasive.

Figure 2-5: Technology push for event-driven interactions.

Performance —The ease of access to immense computing power offered by cloud computing, such as Amazon’s EC2, wasn’t imagined even as recently as 10 years ago. The performance of information systems has grown dramatically over the last half century, and even small companies can get access to substantial computing power.

The combination of technology push—price, pervasiveness, and performance— and consumer pull—celerity, connectedness, and complexity—is making changing components of IT systems and enterprises interact in a more event-driven manner. We refer to this collection of trends as PC-cubed, after p roducer push and consumer pull, and after the components of producer push and consumer pull—price, pervasiveness, and performance, and celerity, connectedness and complexity (Figure 2-6). Let’s begin our study of how event-processing interactions are impacted by the PC-cubed trends by looking at basic human activity.

Figure 2-6: The PC-cubed trends driving demand for event-driven interactions.

The Basic Action: An Interaction

A simplistic description of human activity is that humans observe the world around them; learn from the past; communicate with others; decide what to do; and act (see Figure 2-7). When a group of prehistoric men hunted, they used their five senses to observe their environment; they learned that certain spoors indicated deer while others indicated tigers; they communicated with others in their hunting party; they decided what each of them would do; and they acted. The activities we carry out today and those that our ancestors carried out millennia ago have points in common. There are, however, profound changes in speed, scale, and complexity.

Our ancestors looked for threats and opportunities as far as the eye could see; today we use sensor networks to scan the planet. Our forefathers deciphered patterns of paw prints in the ground; today we use sophisticated business intelligence programs to identify subtle patterns. Our ancestors communicated with members of their hunting party by using sounds and signs; today we use the Internet to communicate to all points on the globe. Our forebears processed information in their brains; today we amplify our intelligence by using powerful algorithms, processors, and storage. Though the differences in scale are indeed profound, you can understand the continuing evolution of IT by focusing on how IT supports activities that humans have carried out from the beginning of history.

Let’s begin by studying a basic unit of human activity: the interaction. How do people interact with each other and what do they gain from interactions? Many types of interaction occur among people and components in IT systems. Chapter 1 introduced the basic types of interaction—time-driven, request-driven, and event-driven interactions. People exchange information and decide what to do in these interactions. Each type of interaction offers some advantages over the others in terms of celerity, agility, and information availability, so most IT systems employ combinations of the basic types. This chapter discusses different types of interaction in detail.

Figure 2-7: Stages in human activity.

A study of types of interaction helps in identifying the fundamental concepts essential for designing in the event-driven architecture (EDA) style. A review of the historical contexts in which these interactions flourished helps us understand how different software styles developed in the past and where they are going in the future. Arguments about software architectures can get heated—discussions about whether a product is in the EDA style or whether service-oriented architecture (SOA) can be event-driven can get contentious. We can get to the heart of these issues by asking questions about the most elementary operations: How do people interact with each other? How do we expect software components to interact? Elucidating the differences between basic types of interaction gets to core issues without using terms that may be considered either pejorative or complimentary.

People with expertise in different areas of IT have different views of event processing. An expert concerned with only one stage of activity—such as an expert in sensor networks for observation, business intelligence for learning, message oriented middleware (MOM) for communicating, real-time pattern detection for deciding, or actuator design for executing actions—brings a valuable, but different, perspective to event processing. This discussion integrates different perspectives to help you understand how event processing helps across all stages of activity.

People and organizations have processed events since the beginning of history. IT has always supported event processing, though IT approaches have been problemspecific and ad hoc. A discipline of event processing that spans all branches of IT is only just emerging. This discipline will have a profound impact on the evolution of IT over the next few decades. A foundation for such a cross-discipline must start with the basics, and there is nothing more basic than an interaction. Let’s identify features common to event processing in human organizations and IT by studying interactions among people in enterprises and among IT components. Indeed, most features of IT event-processing systems are mirrored in human organizations. The term agent is used to indicate both a person and a component of an IT system. A study of interactions among agents is thus a study of how people and IT components interact.

Note: A discipline of event processing that spans all branches of IT is emerging. A foundation for such a discipline must start with the basics, and there is nothing more basic than an interaction.

People in an enterprise have expectations—formal or informal—of each other. An enterprise functions because people live up to shared expectations. We have expectations of one another at all stages of activity as we observe, learn, communicate, decide, and act. For example, we expect to be kept informed about important events. A parent on a business trip expects to be informed if an emergency occurs at home; the president of a country expects to be informed if the country is attacked; a CEO expects to be notified if a factory burns down. An example of shared expectations between a mother and her support system, while the mother is traveling, is shown in Figure 2-8. People interact partly to meet shared expectations, and components of IT systems interact to meet designers’ expectations about component behavior. In software engineering, an expectation of a component is manifested as a formal contract specifying how that component must behave. Expectations and contracts provide a systematic framework for analyzing interactions.

Note: An enterprise functions because people live up to shared expectations. Shared expectations of people in organizations and formal contracts for components in IT systems provide a systematic framework for analyzing interactions.

The next section analyzes basic types of interaction using the framework of shared expectations and contracts in the context of the PC-cubed trends.

Time-, Request-, and Event-Driven Interactions

Chapter 1 introduced the three basic types of interaction, time-driven, request-driven, and event-driven. This chapter explores the nature of these interaction patterns in more detail. The types of interaction are differentiated by what initiates the interaction and the set of participants in the interaction. The goal here is to identify the unique features of event-driven interactions as they occur in the context of human activity (refer to Figure 2-7) and as they occur between IT components.

Time-driven —In a time-driven interaction, an agent, or a group of agents, initiates an interaction at a specified time. An example of such an interaction is a regular meeting of an executive committee that meets every Monday at 8 A.M. The interaction is initiated when a specific time (Monday at 8 A.M.) is reached. The participants in the interaction (the executive committee) are specified by the invite list.

Figure 2-8: Shared expectations in event-driven interactions.

Request-driven —In a request-driven interaction, a client requests a service from a server and waits to receive a reply from that server. The interaction is initiated by the client and completes when the server replies. The participants in the interaction are the client and the server.

Event-driven —In an event-driven interaction, an agent initiates an interaction by creating an object describing an event. Here’s an example of an event: Lehman Brothers declared bankruptcy on September 15, 2008. Lehman started an event-driven interaction by creating an event object—the bankruptcy filing. The event object describes a state change: Lehman was not bankrupt on September 14 and became bankrupt on September 15. The bankruptcy filing does not specify which agents—organizations, individuals, and software—should read the filing and what they should do upon receiving the information. Hedge funds may act upon the information by short-selling bank stocks; employees in the financial industry may respond by updating their resumes; and government agencies may act upon the same information by preparing contingency plans. In general, an event object does not specify which agents should read the object, when it should be read, or what agents should do upon reading it. The set of participants in the interaction is open-ended, the time at which the interaction terminates is open-ended, and what agents do upon reading the event object is open-ended as well.

The major differences between the different types of interaction are summarized in Table 2-1.

Table 2-1: Basic Types of Interaction

In technical terms, an event is a change in the state of a component of an enterprise or its environment. All interactions deal with state changes so all interactions can be treated as special cases of event processing. If you ask somebody their name and they reply “John Smith,” then your state of knowledge changes; and when the clock ticks forward, the state of the world changes. Time-driven interactions are triggered by time moving forward to a predetermined interaction point, and this movement of time is an event. Request-driven interactions are initiated by a client making a request, which is also an event. When you carry out a request-driven interaction, such as buying an airline ticket, you do so because something happened—an event occurred— to make you start the interaction. Though time-driven and request-driven interactions can be thought of as special cases of event-driven interactions, the ways in which events are processed by each of these interactions are different.

The basic types of interaction can be illustrated by considering three simple commands from an investor to a commodities broker:

Time-driven example —Buy 10 ounces of gold every morning at 8 A.M. provided the price is less than $800 until my funds are exhausted (see Figure 2-9).

Request-driven example —Buy 10 ounces of gold right now provided the price is less than $800 per ounce (see Figure 2-10).

Event-driven example —Until I tell you to stop buying, or my funds are exhausted, keep buying and selling gold according to a specified strategy. An example of a strategy is this: Exchange cash for gold when the 13-week moving-point average price drops below the 52-week moving-point average (see Figure 2-11).

Figure 2-9: Time-driven interactions.

Figure 2-10: Request-driven interactions.

Figure 2-11: Event-driven interactions.

The following sections examine each of these types of interaction in more detail using the examples just described and shown in the figures. After that, each of these types of interaction is evaluated in turn. The examples are used to show the differences between the participants in different types of interaction, the start and end times of the interactions, and the business situations in which each type of interaction is used.

Time-Driven Interactions

In the time-driven interaction of the example (see Figure 2-9), the broker continues to perform tasks for the client, but does so at specified times. The broker’s actions are triggered by time. Some time-driven interactions are executed once and some are executed repeatedly. Time-driven interactions are appropriate when tasks can be scheduled and rapid responses to unanticipated events are not critical. The benefits of time-driven interactions are evident from their ubiquity: for example, a CEO meets with the executive team every Monday at 8 A.M., or a batch computer job runs every night at 11 P.M. Organizations use time-driven interactions in combination with other interaction patterns. For instance, if a factory burns down on Tuesday, the factory manager doesn’t wait till the following Monday to inform the CEO. Information about the event—factory burns down—is communicated to the CEO as soon as possible using event-driven interactions.

Request-Driven Interactions

In a request-driven interaction, such as depicted in the example in Figure 2-10, a server executes a service for a client and then does nothing on behalf of the client until the client makes another explicit request. Request-driven software interactions are better suited than time-driven interactions for meeting urgent needs. For example, a CEO may call a CFO to ask about the status of a line of credit rather than wait to find out the status at the next scheduled weekly meeting. The thread of interaction begins with the CEO making a request to the CFO and ends with the CFO responding to the request. In that context, the CEO is the client and the CFO is the server. A common example of a request-driven activity is a consumer looking up a bank balance at a website.

Advantages of request-driven interactions are that the interactions have clear initiation points (client makes a request), clear termination points (client receives a reply), and well-defined participants (the client and the server). These advantages are manifested in both human and software interactions. In some cases, the request and reply can be treated logically as a transaction—a single indivisible atomic operation: a transaction is either completed successfully or aborted. For example, when a bank is transferring funds to another bank, you want either the transaction to succeed and funds debited from the first bank and added to the second, or the transaction to be aborted and the amounts in both banks to remain unchanged. You would be perturbed if a transaction you initiated to move funds from one bank to another either lost your money or never terminated. Though transactions can be implemented as sequences of event-driven interactions, they are more commonly treated as requestreply interactions.

The request-driven interaction pattern has been used in IT since the dawn of computing with good reason. Programming languages, since the 1960s, have used procedure calls in which a program calls a procedure and waits for a response. Remote procedure calls, remote method invocations, client-server interactions, and most web service interactions are request-driven. The long history and current ubiquity of request-driven interactions provide evidence of their value.

Event-Driven Interactions

In the event-driven interaction example shown in Figure 2-11, the commodity broker continues to do tasks for the investor; however, the actions of the broker are triggered by events and not by the clock or by requests. The event of the 13-week moving-point average dropping below the 52-week moving-point average is a complex event; this event is detected by carrying out computations on a set of simple event objects such as an object that contains a price and a timestamp.

The event-driven interaction example, though very simple, has features that merit discussion. The investor and broker have long-term expectations of their interaction: the broker continues to carry out responses on behalf of the investor until told to stop. By contrast, a request-driven interaction terminates with the reply from the server. Indeed, the requester may not want the server to keep data about the request after the interaction is over. In an EDA application, the user expects the application to maintain information about the user so that the application can continue to execute tasks on the user’s behalf. For example, you expect your doctor to remember your medical information so that the doctor can send you an alert when an event— such as the recall of a drug that you are taking—occurs. The differences in expectations impact designs of systems based on time-, request-, and event-driven interactions.

Note: Users expect event-driven applications to maintain information about them so that the applications continue to work on their behalf. A user of a request-driven application may prefer that the application delete information about the user after the application has replied to the user’s request.

The following sections evaluate how the PC-cubed trends impact the usage of different types of interaction. Later in this chapter, we compare expectations of components—or, in software engineering terms, formal contracts for components—that participate in each type of interaction.

Evaluation of Time-Driven Interactions

IT relied mostly on time-driven interactions in the 1960s. Computing jobs in that period required long execution times, so job schedules optimized use of the scarcest resource: the computer. Such schedules were largely time-driven. Since the 1960s the costs of non-IT tools and services have increased tenfold while costs of IT have dropped by many orders of magnitude. So, optimum scheduling to maximize effective usage of computers has given way to patterns of interaction that optimize performance of people and their non-IT tools and services. This has resulted in more usage of event- and request-driven interactions that serve people’s needs with greater celerity.

All-hands company meetings can be efficient at small startups but are inefficient for companies with hundreds of thousands of employees. Many IT systems have thousands of sensors, responders, and processors, and synchronized operations of large numbers of devices are inefficient. Even within a single microchip, synchronized scheduling of operations across a billion or more transistors is less efficient than executing multiple local asynchronous operations. Time-driven interactions won’t disappear, because they are very useful, but system-wide centralized interactions are being replaced by multiple local interactions among fewer agents.

Certain activities—such as the government’s reports on unemployment, or company quarterly reports—are time-driven, and the IT operations that monitor these activities are, perforce, time-driven too. Likewise, markets open and close at fixed times and so analyses of complex financial instruments are often carried out in a timedriven fashion: after the market closes each day and before the market reopens the next day. But 24/7 trading venues and the competitive advantages of celerity are incentives for event-driven computations. For instance, instead of running a batch application to check for medical insurance fraud once a day, an EDA application can detect anomalous behavior as possibly fraudulent claims are submitted, and the application can immediately schedule execution of more compute-intensive tasks to investigate anomalous claims and determine whether they are truly instances of fraud.

There are many advantages to time-driven interactions, including the following:

Scheduled interactions among groups of agents allow a piece of information to be shared efficiently among all participants.

Scheduled interactions serve as a “heartbeat” mechanism. If an agent who is expected to participate in a scheduled interaction does not appear at the expected time, then the other participants infer that there is something wrong with the missing agent. For example, heartbeat mechanisms are used in sensor networks to monitor sensor health.

Measurements made at regular intervals produce time series that are readily analyzed. Most digital control systems use periodic signals.

Listening intently requires energy both for people and wireless devices. The time-driven pattern saves energy by enabling groups of agents to listen and interact at specified intervals. Agents become dormant or carry out other activities between scheduled interactions.

These and other benefits ensure that time-driven interactions, supplemented with request- and event-driven interactions, will continue to be used in human organizations and IT systems, but will be used at multiple local levels rather than at systemwide levels. You will see later in this chapter that the PC-cubed trends are engendering hybrid systems that combine time-, request-, and event-driven interactions with predictive and proactive computational patterns.

Evaluation of Request-Driven Interactions

This section looks at how the PC-cubed trends impact usage of request-driven interactions. Consider, for example, the ratio of the cost of having a baby in a hospital to the cost of a standard IT operation, such as searching a repository of text documents, in 2010 and in 1960. The value of an hour of an obstetrician’s time, measured in terms of number of IT operations that can be executed for the same price, has increased by many orders of magnitude in 50 years. Economics tells us that we should be as profligate in using IT to improve the performance and efficiency of obstetricians (and indeed of all people) today as we were cautious 50 years ago.

A critical and increasingly scarce resource is uninterrupted time. Request-driven interactions can help to husband this precious resource because agents choose the times of interactions and the services with which they interact. On the other hand, the demand for celerity requires people to respond to events rapidly; celerity argues for people to be interrupted when important events occur. You will see later in this chapter that the tension between having to respond rapidly to events and needing uninterrupted time can be managed by combining request- and event-driven interactions into proactive computations.

Evaluation of Event-Driven Interactions

This section looks at how the PC-cubed trends drive demand for event-driven interactions. Celerity requires rapid response to events and therefore favors eventor time-driven interactions. Increasing connectivity also favors event-driven interactions. It is more efficient for information about the outbreak of a factory fire to be proactively pushed across management layers to the CEO than for the CEO to request each person in the organization to report whether anything important has occurred. Task complexity can also be managed by event-driven interactions by sensing when results from complex tasks are required and responding by executing those tasks proactively. Trends in pricing, pervasiveness, and performance, likewise, drive demand for event-processing interactions as IT becomes the central nervous system that enables the enterprise to sense and respond to the business environment.

Contracts: Formalization of Shared Expectations

This section analyzes different types of interaction in the context of the PC-cubed trends and the expectations people have about components in different interactions. The expectations are manifested as contracts, so contracts for components in different types of interaction are the focus.

Contracts for Event-Driven Interactions

A parent on a business trip expects to receive a message if an emergency occurs at home. If the parent hasn’t received such a message, he or she assumes that no emergency has occurred. This commonplace situation illustrates a characteristic of event-driven applications: The absence of messages conveys information.

The parent has a model of how the home functions and the parent expects to be notified when reality deviates significantly from this model. A parent can function only because he or she can estimate characteristics of the state of the home without monitoring the home continuously. In software engineering terms, the parent’s expectation is a contract between the parent and a support system: family, friends, and others. Their joint expectation of what is, and what is not, normal in the home is based on an informal model of the home.

Note: In event-driven interactions, the absence of messages conveys information.

People function only because (possibly informal) contracts enable them to be aware of their environments without constant, continuous monitoring (refer to Figure 2-8). Likewise, designs of components of EDA systems are based on contracts that enable designers to conclude that the absence of messages to components conveys information. Event-driven interactions are fundamental to the operation of families, enterprises, governments, and EDA systems; organizations and event-based IT systems function only because people and components depend on others to detect and respond to events.

Let’s look at contracts in event-driven interactions in more detail:

A contract is for an interval of time. It may have a termination time or it may be open-ended. A parent on a trip has an informal contract with the support system for at least the duration of the trip.

A contract is between an agent and the rest of the system. The agent has expectations of the rest of the system, and the system has expectations of the agent. A parent on a business trip expects the system to notify the parent accurately and in a timely fashion when a critical situation occurs at home; it doesn’t matter whether the parent is notified by a son or a daughter, and it doesn’t matter whether the notification is delivered by a hotel operator or a colleague at the office. The contract deals with the response to a situation and not with the identities of agents executing the action or the mechanism by which information is disseminated. Contracts that specify what must be done but don’t specify how it must be done allow components of an EDA system to be modified without impacting other components in the system, provided the contracts remain unchanged.

A contract is a collection of when-then rules: when certain situations arise, then respond in the following ways. For example, when a kitchen fire occurs, then call emergency services (such as 911) and attempt to put out the fire. Sometimes a when-then rule is broken down further into an event-condition-action rule; that is, when an event occurs, determine if a condition holds, and carry out the specified action if it does.

The actions in when-then rules may be required to be executed in a timely fashion (though the specifications about time may be informal rather than quantitative). A parent on a business trip expects to be informed soon—say, within an hour—after a critical event at home. This timeliness gives the parent confidence that nothing unusual has happened in the last hour if he or she hasn’t heard anything. A system does not help parents respond effectively if it informs them about emergencies only months after they occur. Timeliness enables an agent to deduce that nothing untoward has happened in a small time interval if the agent hasn’t received a message to the contrary.

Contracts for Request-Driven Interactions

A contract in a request-driven interaction is between the client and server participating in the interaction. The server’s contract specifies that if it receives a request in the schema specified by the server, then the server will execute the specified service and return results to the client in a specified schema. For example, a service that receives requests containing lengths in feet and then converts these lengths to meters may require requests to be positive decimal numbers. This server’s contract is that it will accurately convert the value, given in feet, in the client’s request to meters and reply with the value in meters.

The differences between contracts for event- and request-driven interactions are a consequence of the different goals of these interactions. A contract for a requestdriven interaction has the following features:

The contract between the client and server is for an interaction that begins with a request and ends with a reply; unlike event-driven interactions, the contract does not specify a time horizon nor is it open-ended. Compare expectations that users have about search engines (request-driven interactions) and alerts engines (event-driven interactions). A user who executes a search waits for a single reply; the interaction ends when the user receives the reply. By contrast, a user who enters a request to an alerts engine expects to get periodic notifications; the interaction ends only when the user cancels the alert service.

A contract is between a client and a server, not between a client and the rest of the system.

A contract is a relation between a request, the reply, and the state of the server when the request was received by the server.

Contracts in request-driven interactions may include response time constraints in service level agreements; these contracts specify how quickly a server must respond to a client’s request. Generally, there are no constraints on when a client must invoke a server. A client may invoke a server frequently or not at all. Servers cannot infer the states of clients from the absence of requests.

A contract may specify that a request-reply interaction is transactional: it is either completed successfully or not done at all.

Contracts for Time-Driven Interactions

Consider a meeting of an engineering manager and an offshore development team. Each person comes to the meeting with some knowledge; during the meeting some of this knowledge is exchanged with others; and each person leaves with additional knowledge. The meeting changes the states of the participants. The contract for a time-driven interaction can be specified as a relation between the states of the agents immediately before and immediately after the interaction.

A contract for a time-driven interaction is different from contracts for event- or request-driven interactions. A contract for a time-driven interaction is a relation between pre- and post-interaction states of all agents participating in the interaction; the contract for a request-driven interaction is a relation between a request by a client and a reply by a server; and the contract for an event-driven interaction is described in terms of when-then rules.

Hybrid Systems: Combinations of Interaction Types

You saw that each of the basic types of interaction has strengths and some weaknesses. Hybrid systems exploit the strengths of each of the interaction types by using combinations of the basic types. The PC-cubed trends suggest that hybrid systems with composite types of interaction will become more widespread in the future. Humans are hybrid, composite systems in the sense that people have used event-, request-, and time-driven interactions since the dawn of history. IT systems that are optimized to support human activity will, likewise, be hybrid systems.

Note: Hybrid systems that combine different interaction types will become widespread.

Let’s start by looking at the price trend: the exponential growth over the last half century in the ratio of the cost of an hour of a person’s time—whether the person is a medical doctor, manager, lawyer, or engineer—to the cost of a standard IT operation such as the addition of two numbers on a computer. This trend tells you that computational patterns will evolve in the following directions:

Proactive —People are getting expensive compared to information processing operations at an exponential rate; so an economical strategy is to carry out computational tasks proactively—do tasks even before they are requested. The results of these tasks may turn out to be not needed; but saving you time on some occasions, while discarding unneeded results on other occasions, is cost effective. Costs of carrying out computations, whether needed or wasted, will decrease over the years, while the benefits of reduced delay will increase. Carrying out tasks proactively requires systems to predict or speculate about results users will need. This, in turn, requires systems to learn each user’s behavior pattern. The more the system knows about you, the quicker it will be able to tell you what you need to know, even before you ask. (Issues of privacy are discussed in Chapter 4.) Proactive computations are often event-driven. For example, a web-services company may proactively determine restaurants that will interest you based on your current location, the current time, when you last ate, your habits, and your food preferences; this analysis is event-driven because it depends on your location—and where you are at a point in time depends, in large part, on events.

Personal information manager —An interruption can be a distraction at one point in time and valuable at another depending on the receiver’s context. What is required is an application that manages your information—all the notifications pushed to an agent and all the information pulled proactively by an agent operating on your behalf. This application estimates your current context based on information it has about you—such as your location, the searches you are doing, and the IT applications that you are using—and determines whether a piece of new information is important enough to merit interrupting you. Heads of states and CEOs of large corporations have chiefs of staff who acquire information proactively, who know the current contexts of their bosses, and who determine whether their bosses should be interrupted to receive new information. The PC-cubed trends make software chiefs of staff both necessary and possible for the rest of us. A personal information manager is a hybrid system with a substantial event-driven component—it manages events that it detects and information pushed to you.

Ideas of speculative computation and dynamic settings of interrupt statuses have been discussed in the IT literature on parallel computing and operating systems. The driver behind these ideas is the increasing ratio of the costs of delay to the costs of IT resources. The same driver is applicable to people. Next, let’s look at a few examples of hybrid systems that combine different types of interaction, carry out proactive computations, and use personal information managers in normal office activities and in EDA systems.

Note: Proactive, speculative computing is cost effective.

Capture of Event Information in Folders

A problem with proactively pushing event-driven information to a user—by visual or auditory alerts on computers or phones—is that the user may not be interested in that particular information at that time. Though a person going on a trip wants to know about the hotels in which he will be staying, he doesn’t want an important meeting to be interrupted by alerts about hotels. The fundamental problem here is one of context. A user interested in information from multiple domains may want to focus on a specific domain at a specific time.

Consider a sales manager who has to deal with multiple contexts such as sales processes in her different territories, marketing campaigns, and travel schedule. When her administrative assistant receives an event object—say, a notification that a hotel booking has been confirmed—the assistant does not interrupt the manager when the assistant knows that the manager is in an important meeting. So, the assistant places the information in a travel folder. The manager requests information about her trip when her context shifts to planning trips, and the assistant replies to the request with information pulled from the travel folder. If, however, the assistant receives a notification that the assistant realizes requires immediate attention from the manager, then the assistant may interrupt the manager. Thus, the assistant plays the role of personal information manager.

The assistant has an event-driven role when the assistant receives event objects, such as notifications of hotel bookings from a travel agent. The assistant also plays the role of a server, with the manager as a client, in a request-driven interaction that gives the manager the data she requests by pulling data from folders. Thus, the assistant is an adaptor that consumes event objects in event-driven interactions and serves event objects in request-driven interactions. You will see adaptors from one kind of interaction type to another—such as from event-driven to request-driven, from requestdriven to event-driven, or from event-driven to time-driven—in most applications (see Figure 2-12). This is analogous to the adaptors that you use every day: the power cord in your computer receives high-voltage alternating current from the plug point and supplies low-voltage direct current to your computer.

Note: Adaptors that convert one type of interaction to another are important components of event-processing applications.

An application in which a personal information manager acquires and organizes information, and interrupts you only when information arrives that is critical to your current context, has the benefits of both event- and request-driven interactions. The application has the benefit of celerity because you will be interrupted if an event is important, enabling you to handle the event immediately. On the other hand, the application optimizes a precious asset: your uninterrupted time. This application is an example of a hybrid system that derives strength by combining different types of interaction.

E-mail with filters is another example of a composition of event- and requestdriven interactions. E-mail is sent on an event-driven basis. (The actual underlying protocol by which e-mail is obtained by a receiver may be request-reply, but in essence the delivery of e-mail is triggered by the event of the sender sending a message.) Received e-mail is placed in folders by filtering algorithms. You request mail from the folder appropriate to your current context. The e-mail server acts as an adaptor that consumes event objects in event-driven interactions and serves event objects in request-driven interactions. The e-mail server acts as a simple personal information manager, receiving mail and organizing it in folders for you.

Search engines are examples of hybrid systems that combine time-, request-, and event-driven interactions. Search engines crawl websites periodically and organize information in repositories. You execute a search by using a request-reply interaction and obtain alerts by event-driven interactions.

Figure 2-12: Adaptors between interaction types.

Location-based services will become increasingly proactive. Internet services companies will know where you are and where your friends and colleagues are (and possibly even know where the people you would rather avoid are). The services will predict where you are going and the activities you are about to do, and then download results of searches and other computations, based on these predictions, to your mobile phone.

Predictive systems that warn about forthcoming events are, as one might expect, primarily event-driven. The detection of past events leads to predictions of more serious events. For example, a hurricane far out at sea may not cause much immediate damage; however, the detection of a distant storm may result in a prediction that a hurricane will hit populated areas later. A drop in stock prices in foreign stock markets overnight may lead to a prediction that prices in domestic stock markets will drop in the next trading day. Increases in click-through activity in a marketing campaign website may lead to predictions of greater call volume and sales. Predictions enable proactive computations to be executed and other steps to be taken in preparation for future events. Predictive systems are often hybrid systems that are triggered by events, (such as a change in your location) and carry out proactive calculations (such as what you are likely to want in your new location) but then wait for a request from you before giving you results of the calculation.

Data Acquisition

Many data-acquisition systems are hybrid systems that combine time-, request-, and event-driven interaction patterns. Consider, for example, applications that help traders of electric power and other volatile commodities. These applications monitor several sources of information such as electronic markets, websites that offer weather predictions, news sources, and sensors that estimate power on transmission lines. The process of collecting data from websites outside the enterprise is often done through request-driven interactions: an agent in the enterprise requests a server outside the enterprise for data and waits for a reply. Agents in the enterprise poll external sources of data according to some time schedule, with a polling interval large enough to ensure that the external sites aren’t overloaded and small enough to ensure that events are detected quickly. Thus, the acquisition of external data often combines time- and request-driven interactions.

The agent within the enterprise that acquires external data periodically may send this data on to other agents in the enterprise only when the data changes significantly. Repeatedly sending identical messages can be inefficient; therefore, the agent sends notifications in an event-driven way—that is, only when relevant changes take place in external data. Thus, the acquisition and dissemination of external data often combines time-, request-, and event-driven interactions.

Responses to Events

Many responders interact using the time-driven pattern; for example, systems send periodic digital signals to devices that control thrust in engines. When you turn on cruise control in your car, you are, in effect, establishing a contract with the car to keep the car’s speed at the specified level until you either step on the brake or turn off cruise control. The cruise control system detects events when you turn the control on and when you brake. The system controls fuel flow into the engine by sending periodic signals in a time-driven manner. Thus, the cruise control’s interactions with you are event-driven whereas its interactions with the engine are time-driven.

Some agents receive event objects and react by executing request-driven interactions such as invoking a web service or updating a database. These agents are eventdriven on one side and request-driven on the other. Detections of rare threats, such as tsunamis, are carried out using event-driven interactions, but the responses—such as assigning first responders to different threat regions—are often executed using request-driven interactions.

Summary

The pattern of interactions and decision-making among people in an enterprise is similar to the interaction patterns among components in IT systems. Basic types of interaction include time-driven, request-driven, and event-driven interactions. Each of the basic types has advantages and therefore many applications are hybrid systems that employ combinations of these types.

The business trends, described in Chapter 1, that drive demand for event processing impact how IT systems use different types of interaction. These business trends are summarized in Figure 2-1. Business needs for agility, timeliness, and information availability have resulted in greater reliance on event-driven interactions. The combination of the trends of technology producer push and consumer pull, summarized in the PC-cubed trends—price, pervasiveness, performance, connectedness, celerity, and complexity—impact the ways in which interaction types are combined in applications.

Different types of interaction between components evolved at different points in the history of IT for good reasons; a study of these reasons helps us to estimate how software will continue to evolve. Even in the 1950s some IT components were requestdriven and some were event-driven; the relative prevalence of request-driven interactions increased over time with widespread use of client-server interactions; and now technology and business needs are leading to increasing use of event-driven interactions.

Informal expectations about component behavior, or formal contracts about components, help in designing systems and clarify the utility of different types of interaction in different settings. IT applications have combinations of the basic interaction types, and therefore adaptors that convert from one type of interaction to another are useful in most applications. Proactive, predictive systems that use combinations of the basic interaction types will get more common as IT costs continue to drop relative to the costs of workers’ time and costs of non-IT devices.

When discussing the relative merits of EDA, SOA, event-driven SOA (EDSOA), asynchrony, synchrony, or other concepts, it is helpful to cut through to the basics and ask “What is going on at the most basic level?” And the answer is this: interactions among people and among software components.