Introduction

Event-Driven Architecture: A Working De.nition

Event-driven architecture (EDA) falls into the maddening category of a technology paradigm that is half understood by many people who claim to know everything about it. Although we recognize that we, too, might not know absolutely everything there is to know about EDA, we believe that it is necessary to set out a working de.nition of EDA that we can adhere to throughout this book. Getting to an effective working de.ni-tion of EDA is challenging because EDA must be described at a suf.-ciently high level that is comprehensible to nontechnologists, but at the same time not so high level as to sound vague or irrelevant.

An event-driven architecture is one that has the ability to detect events and react intelligently to them. For our purposes―and we dis-cuss this in great detail later on―an event is a change in state that merits attention from systems. Brenda Michelson, a technology analyst, writes, "In an event-driven architecture, a notable thing happens inside or out-side your business, which disseminates immediately to all interested par-ties (human or automated). The interested parties evaluate the event, and optionally take action."1

One of the simplest examples of an event-driven system is actually from the noncomputer world. It is known as a thermostat. The thermo-stat is a mechanical device that turns the heat on or off based on its pro-grammed reaction to an event, which is a change in temperature. The shift in temperature is the event, the "change in state" that triggers the reaction of the thermostat, which, in turn, affects the action of the heater.

We can see another simple example in the evolution of the automo-bile. Cars are becoming increasingly intelligent by reacting intelligently to their surroundings. If rain hits the windshield, the automobile recog-nizes the rain event and automatically turns on the windshield wipers,

Introduction

turns on the headlights, and adjusts the front windshield defroster. All of these things were formerly the driver`s responsibility, but now the car`s internal system uses its intelligence to react. An EDA is an architecture that acts in the same way: It detects events and reacts to them in an intel-ligent way. To be able to detect events and react to them intelligently, an EDA must have certain capabilities, including the ability to detect events, transmit messages among its components that an event has occurred, process the reaction to the event, and initiate the reaction to the event if that is called for. In generic architectural terms, these capa-bilities translate into the concepts of event producers, event consumers, messaging backbones, and event processors. These go by many different names in practice, and this is one of the great hurdles to getting a feel for what an EDA is at its core.

Many examples of EDAs occur in the realm of information systems, though most of the ones currently deployed are limited in scope. For example, if your credit card is simultaneously used in two separate geo-graphical locations, those two events can be "heard" by the credit card processing systems and examined for a potential fraud pattern. The credit card fraud detection EDA is set up to listen for events that indi-cate potential fraud and respond―or not respond―depending on a set of rules that are programmed into the event processors. If the charge occurring out of state is at a mail order merchant where you have shopped before, the system might not deem the event pattern to be a fraud. If the second charge is for a high-dollar value at a merchant where you have not shopped before, the EDA might trigger a response that places a warning or "watch" status on your credit card account. Or, the activity might prompt a person to call you and .nd out if you have lost your card.

Or, imagine that an FAA air traf.c control application needs to know the probability of rain in a certain location. At the same time, the Air Force needs the same data, as does NASA. Assuming that the weather data is collected and available on a server somewhere, it is possible to tightly couple that server, and the software running on it, with the FAA, Air Force, and NASA`s respective systems. Although this type of approach is frequently used, it is far easier to arrange for the weather application to publish the weather data and enable the subscribers (the FAA et al.) to get the data they need and use it however they need to use it. The weather status event of the weather application publishes the weather data so that the data subscribers can use it to drive the architec-ture. This is an event-driven architecture.

Event-Driven Architecture: A Working De.nition

In this EDA, the FAA, Air Force, and NASA are integrated with the weather system by virtue of the fact that there is no speci.c coupling between the applications. Of course, they exchange data, but the appli-cations are completely separate and have no inherent knowledge of one another. The developers do not need to know each other, and there is no need to coordinate. However, for it to work, they do need standards. To effectively disseminate and process events, the publisher and the sub-scriber might agree to use a commonly understood message format and a compatible transport mechanism.

One commonly used technology that is analogous to EDA is the Web itself. When you use a browser, you are initiating an integrated ses-sion with a remote system of which you have no speci.c knowledge. In all probability, you have no idea who programmed it, what language it`s written in, where it is, and so on. Yet, your browser can pull whatever information it is permitted to get and show it to you in a format that you can understand. The event of requesting the uniform resource locator (URL) triggers the action that results in the display of the Hypertext Markup Language (HTML) content in your browser window. As we develop our explanation of EDA, though, you will see that the Web is a very simple EDA.

An EDA consists of applications that are programmed to publish, subscribe, or take other actions upon events triggered by applications with which they share no formal coupling. For this reason, EDA has been likened to a "nervous system" for the enterprise.

The Enterprise Nervous System

Where would the IT industry be without metaphors? Even the idea of using the word architecture to describe how Byzantine networks of hardware, software, and data are con.gured shows how reliant we are on abstraction to achieve an understanding of what we are trying to accom-plish in enterprise IT. In the spirit of metaphors, then, we shall borrow a concept from human physiology, the central nervous system, to further our understanding of EDA.

If your cat steps on your toe, how do you know it? How do you know it`s a cat, and not a lion? You might want to pet the cat, but shoot the lion. When the cat`s paw presses against your toe, the nerve cells in your toe .re off a signal to your brain saying, "Hey, someone stepped on my toe." Also, they send a message that says something like, "It doesn`t hurt that much" and "It was probably a cat." Or, if you saw the cat, the signals from

Introduction

your optic nerve are synthesized with those from your toe, each invoking your mental data store of animals and likely toe steppers, and you should know pretty quickly that it was, indeed, a cat that stepped on your toe. Your central nervous system is a massively complex set of sensory recep-tors, wires, and integration points, known as synapses. The nervous sys-tem is critical to your functioning and survival in the world. Just imagine if your central nervous system didn`t work well and you confused the cat with the lion. As Figure I.1 shows, you might shoot your cat and pet the lion, which would then eat you.

Our enterprises have their own nervous systems, too. Our Web sites, enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, databases, and network infrastructures, for example, all work to feed the corporate equivalent of sensory infor-mation to the corporate "brain." The corporate brain, in turn, assesses the input and reacts. Of course, the corporate brain might contain a few actual brains as well, in the form of employees, but their sensory input is determined by the enterprise nervous system. For example, if there is an increase in cash withdrawals at a bank, the banking systems, acting like nerve sensors in our toe, .re off withdrawal data to the corporate brain. The neurons in the corporate brain then route the data to its destination, which could be an automated bank cash reserve management system, the executive management team of the bank, or a combination. As our

Event-Driven Architecture: A Working De.nition

brain assesses and reacts to the cat stepping on our toe, the corporate brain of the bank must assess the input of the withdrawal spike and react.

If our enterprises were living beings, most of them would need some pretty intensive neurological care. Unlike a well-functioning person, whose nervous system can learn how to react to different stimuli and determine the best way to handle a given situation based on sensory input and mental processing, the typical enterprise has a nervous system that is hardwired to react in a speci.c set of ways that might not be ideal for every situation. In the cat-on-toe situation, most of our enterprises would probably expect the worst and then shoot in the general direction of the cat. Or, perhaps a more realistic version of the metaphor―the enterprise wouldn`t even know that anything had stepped on its toe, or that it even had a toe. It would be completely unaware most likely because it was never given the ability to be aware.

Like the person whose knee-jerk reaction is to shoot the cat regard-less of what is going on, most of our enterprises have a nervous system that is not well set up to receive the data equivalent of sensory input, process it, know what it is, and react in an appropriate way. Event-driven architecture is an ap