Editor-in-Chief Project Editorptgmedia.pearsoncmg.com/images/9780321322111/samplepages/0… · But if EDA presents new challenges, it also emerges in an era of new opportunity. The

Many of the designations used by manufacturers and sellers to distinguish theirproducts are claimed as trademarks. Where those designations appear in this book,and the publisher was aware of a trademark claim, the designations have beenprinted with initial capital letters or in all capitals.

The authors and publisher have taken care in the preparation of this book, but makeno expressed or implied warranty of any kind and assume no responsibility for errorsor omissions. No liability is assumed for incidental or consequential damages inconnection with or arising out of the use of the information or programs containedherein.

The publisher offers excellent discounts on this book when ordered in quantity forbulk purchases or special sales, which may include electronic versions and/or customcovers and content particular to your business, training goals, marketing focus, andbranding interests. For more information, please contact

U.S. Corporate and Government Sales(800) [email protected]

For sales outside the United States, please contact

International [email protected]

Visit us on the Web: informit.com/aw

Library of Congress Cataloging-in-Publication Data

Event-driven architecture : how SOA enables the real-time enterprise /Hugh Taylor ... [et al.].

p. cm.

Includes bibliographical references.

ISBN-13: 978-0-321-32211-1 (pbk. : alk. paper)

ISBN-10: 0-321-32211-8 (pbk. : alk. paper) 1. Service-oriented architecture(Computer science) 2. Discrete-time systems. 3. Business--Data processing. 4. Business enterprises--Computer networks. I. Taylor, Hugh.

TK5105.5828.E94 2009

004.6'82--dc22

2008055032

Copyright © 2009 Pearson Education, Inc.

All rights reserved. Printed in the United States of America. This publication isprotected by copyright, and permission must be obtained from the publisher prior toany prohibited reproduction, storage in a retrieval system, or transmission in anyform or by any means, electronic, mechanical, photocopying, recording, or likewise.For information regarding permissions, write to:

Pearson Education, Inc.Rights and Contracts Department501 Boylston Street, Suite 900Boston, MA 02116Fax (617) 671-3447

ISBN-13: 978-0-321-32211-1ISBN-10: 0-321-32211-8

Text printed in the United States on recycled paper at RR Donnelley inCrawfordsville, Indiana.First printing March 2009

Editor-in-ChiefMark Taub

Acquisitions EditorGreg Doench

Development EditorMichael Thurston

Managing EditorKristy Hart

Project EditorBetsy Harris

Copy EditorKaren Annett

IndexerKen Johnson

ProofreaderDebbie Williams

Technical ReviewersCliff BergKevin DavisDavid Kane

PublishingCoordinatorMichelle Housley

Cover DesignerChuti Prasertsith

Senior CompositorGloria Schurick

Foreword

It’s been 15 years since the dawn of the Web, and we are still absorbingthe lessons it teaches us about decentralization, loose coupling, stan-dards, and resource representation. Even when technology seems tomove quickly, it can take a long time to understand, appreciate, andapply the core principles it embodies.

The roots of event-driven architecture run even deeper. Twenty-fiveyears ago, the graphical user interface forever changed how we thinkabout applications. Suddenly, the event loop became a central organiz-ing principle. Programs listened to events, processed them, andresponded to them—sometimes by firing new events. There was noother way to effectively support fickle and unpredictable users who areliable to do anything whenever they want.

Enterprise software systems, of course, serve whole populations offickle and unpredictable users. Some are customers, some are suppliers,and some are business partners. Here too, effective software has to listenwell and respond intelligently.

It sounds simple, and conceptually it is. But while the stream ofevents produced by a GUI application is defined by the operating sys-tem, and is well understood by the programmer, an enterprise applica-tion lives in a connected world. Just as the resource-oriented Webarchitect has to learn how to design stateless resources, so must theevent-oriented enterprise architect learn how to design stateless events.

But if EDA presents new challenges, it also emerges in an era of newopportunity. The tools and techniques of service-oriented architectureare becoming more mature, more interoperable, and more manageable.

With a strong SOA skeleton in place, EDA can weave the enter-prise’s nervous system. This book explains why event-driven architectureyields smart and resilient enterprise software, and shows you how to start“thinking EDA.”

—Jon Udell

Preface

About This Book

As professionals in the enterprise architecture field, we have observedthe recent and spectacular rise of the concept of service-oriented archi-tecture (SOA) with excitement tempered by concern. The new stan-dards-based architectural paradigm promises great advances ininteroperability among previously incompatible software applications.In turn, it has the potential to deliver gains in agility and IT cost control.Perhaps most exciting, though, is the potential for SOA to make possiblethe realization of event-driven architecture (EDA), an approach toenterprise architecture that yields a high level of agility by increasingsystems’ awareness and intelligent responses to relevant events.

At the same time, it became clear to us that the steps required todesign and deploy an EDA, or an SOA, its master set of architecturalcharacteristics, were far from obvious. Even going beyond the fact thatthe technology and standards are immature and, thus, challenging, thepractice of uniting software with an overarching standards-basedapproach that extends outside the enterprise is a new field, lacking inmany of the guiding principles of infrastructure, governance, and bestpractices that hold together most traditional forms of architecture anddevelopment.

For better or worse, some software vendors are now bringing whatthey call EDA suites to market. However, the commercial offerings inEDA tend to be quite narrowly defined and vendor-centric. As such,they are inadequate on their own to offer much in the way of instructionon the overall best practices required for EDA.

We perceive a need among architects for a book that combines boththe theory of EDA—the grand vision that led to its formation and the

essential nature of the paradigm—with a practical look at building anEDA over an SOA implementation in the real world. This book is nei-ther all theory nor all practice. It is a blend, with the idea that true suc-cess with EDA depends on a good understanding of both aspects of theparadigm.

To understand how this book is set up and what it contains, wethought it would make sense first to take a quick look at the definition,history, and context of EDA and SOA. These two related architecturalstyles are not as new as they seem, though recent developments in stan-dards have led to breakthroughs in their potential realization.

Inside This Book: The Path to EDA

Even for a lot of experienced architects and developers, the implicit con-nection between EDA and SOA has not been intuitively obvious. A lot ofIT pros react to SOA with a sentiment akin to, “That’s really cool. Nowwhat?” These questions are completely legitimate. Imagine someonehanding you a violin and declaring, “Oh, good, now I get to hearMozart.” That person is making several assumptions, including that youknow what the violin is, how to play it, and how to play Mozart in partic-ular. In many IT situations, it is not always evident how loose couplingand a service orientation will take you to an EDA. If your boss drops aVisual Studio 2008 pack on your desk and says, “Now you will deliver anEDA,” you might not necessarily know how to get from here to there.That is the purpose of this book.

Much of this book is dedicated to helping you understand where therubber meets the road in turning the vision of EDA into a reality. In sodoing, we delve into detail on the subject of SOA, providing the essentialbuilding blocks of the most versatile and effective EDAs. We addressone of the great unanswered questions posed in the wake of SOA’s high-profile arrival on the IT scene: How do you actually get to the achieve-ment of business goals that EDA enables using the actual technologiesthat make up SOA? The leap from Web services and SOA to the fulfill-ment of EDA, and its attendant agility and IT cost savings, requiressome serious discipline.

Preface xiii

Part I—The Theory of EDA

This book consists of two parts. Part I, “The Theory of EDA,” covers thetheoretical aspects of EDA. The path to EDA, which we guide youthrough in this book, starts with an understanding of what EDA is. Part Ibegins with a thorough theoretical definition of EDA. We cover the corecomponents of EDA, such as event consumers and producers, messagebackbones, Web service transport, and so on. We also describe the basicpatterns of EDA, including simple event processing, event stream pro-cessing, and complex event processing.

From this definition, we then explore the current context of EDA,which is the jungle of interoperability challenges that we all face in largeenterprises. Having thus set up the situation that we face—we wantEDA (or at least, we should consider it)—we see how difficult it can beto attain. Enter SOA, and its open interoperability, which paves the wayfor the realization of EDA.

In addition to defining EDA, we explore the SOA-EDA connectionin depth. In our view, any serious attempt to develop an EDA today willrely on the use of SOA technology as it is emerging in the marketplace.The EDA of tomorrow will run on Web services and enterprise servicebuses. The EDA components—the event producers, consumers, andprocessors—will all be Web services. We will flesh out this vision of EDA.

The conclusion of Part I consists of examples of EDAs and how theymight function. We explore examples of how businesses and otherorganizations might ideally use EDA to further their objectives. This setof examples provides a transition to Part II, “EDA in Practice,” of thebook, which moves you into the reality of EDA and how it might beapproached in an actual enterprise setting.

Part II—EDA in Practice

Part II begins with Chapter 6, “Thinking EDA.” This chapter exploresways to identify the ideal use of an EDA, or a partial EDA in realizing aset of business objectives. Chapters 7 and beyond present a set of casestudies of EDA. Some of these case studies are based on real companies.Others are partially hypothetical, but based on real-life experiences wehave had in the world of enterprise architecture.

In each case study, we describe the organizations involved as well asthe technological and business challenges and objectives that they have.We look at the ways in which the business and technological situationwould benefit from an EDA approach. We look at the practical issues

xiv Preface

that arise in its design and implementation. Our goal is to include, whererelevant, some organization and non-IT issues, such as project manage-ment and communication. Of course, we get into depth on the technolo-gies required to birth the EDA.

Throughout the case studies, we look at a number of related topicsin the field of enterprise architecture that have relevance for learningabout EDA. These include SOA infrastructure, governance, and secu-rity. Wherever possible, we try to point out business issues that are rele-vant, but perhaps not apparent to the technology reader, as well astechnology issues that might not be noticed by the business reader.

One of our other goals is to instill in you a good sense of when to usean EDA approach and when not to, for the paradigm is not a panacea forall IT and business problems. This issue reminds of the story of a manwho once approached a famous surgeon and said, “You make moremoney in a week than I make in a year. I don’t think it’s fair. Is what youdo so special?” The surgeon replied, “Surgery itself isn’t that compli-cated. I could probably teach you to do it in a few weeks. What takes thetraining and skill is knowing when not to operate, and what to do whensomething goes wrong. Learning those two things can take years.”

So it is with EDA. Developing a Web service is not hard for an expe-rienced developer. Knowing how to use the functions of an SOA to cre-ate an EDA, though, is another matter. And, like the surgeon, you wouldbe well served by understanding when to use and not use the EDAapproach. If you take away nothing else from this book, consider thatthere are many cases where an EDA is not the optimal solution to a busi-ness issue.

Who Should Read This Book, and How TheyShould Read It

If you’re holding this book in your hand, you are probably involved withinformation technology. If you are not in technology, we really admireyour desire to be a broadly informed citizen. We have written this bookin fairly deep, but not excessively detailed, technical language.

This is not a book that is awash in code or extensive jargon. We havemade the choice to skip the deep, deep techie language because of thelikely blend of readers that we expect to find. The subject of EDA can beof interest to the work of a vast audience. EDA itself is an area that is

Preface xv

inherently interdisciplinary. EDA naturally throws together developers,line-of-business people, IT managers, security specialists, architects, andnetwork operations people. There is probably a whole EDA book foreach of those disciplines. Luckily for us, someone else will write them.We want to present the topic in a unified approach that a multiplicity ofreaders can absorb.

Our other guess is that you probably work at a large organization orwith an entity that interfaces with large organizations. Whether you workat a corporation, public sector organization, or educational institution,the issues for EDA are the same. We come from the corporate world, sowe have a tendency to talk about “business value” a lot. If you can’t relateto this, we are sorry, but for stylistic reasons we need to use just one mea-sure of efficiency, and in our world, that measure is usually dollars. So,when we talk about “business value,” we mean the economy of effortrequired to produce a result. It’s a concept that can translate into anyorganizational agenda.

xvi Preface

Introduction

Event-Driven Architecture: A Working Definition

Event-driven architecture (EDA) falls into the maddening category of atechnology paradigm that is half understood by many people who claimto know everything about it. Although we recognize that we, too, mightnot know absolutely everything there is to know about EDA, we believethat it is necessary to set out a working definition of EDA that we canadhere to throughout this book. Getting to an effective working defini-tion of EDA is challenging because EDA must be described at a suffi-ciently high level that is comprehensible to nontechnologists, but at thesame time not so high level as to sound vague or irrelevant.

An event-driven architecture is one that has the ability to detectevents 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 meritsattention 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 actuallyfrom 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. Theshift in temperature is the event, the “change in state” that triggers thereaction of the thermostat, which, in turn, affects the action of theheater.

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

1

turns on the headlights, and adjusts the front windshield defroster. All ofthese things were formerly the driver’s responsibility, but now the car’sinternal system uses its intelligence to react. An EDA is an architecturethat 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, anEDA must have certain capabilities, including the ability to detectevents, transmit messages among its components that an event hasoccurred, process the reaction to the event, and initiate the reaction tothe 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 differentnames in practice, and this is one of the great hurdles to getting a feel forwhat 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. Forexample, if your credit card is simultaneously used in two separate geo-graphical locations, those two events can be “heard” by the credit cardprocessing systems and examined for a potential fraud pattern. Thecredit card fraud detection EDA is set up to listen for events that indi-cate potential fraud and respond—or not respond—depending on a setof rules that are programmed into the event processors. If the chargeoccurring out of state is at a mail order merchant where you haveshopped before, the system might not deem the event pattern to be afraud. If the second charge is for a high-dollar value at a merchant whereyou have not shopped before, the EDA might trigger a response thatplaces a warning or “watch” status on your credit card account. Or, theactivity might prompt a person to call you and find out if you have lostyour card.

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

2 Introduction

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

One commonly used technology that is analogous to EDA is theWeb itself. When you use a browser, you are initiating an integrated ses-sion with a remote system of which you have no specific knowledge. Inall probability, you have no idea who programmed it, what language it’swritten in, where it is, and so on. Yet, your browser can pull whateverinformation it is permitted to get and show it to you in a format that youcan understand. The event of requesting the uniform resource locator(URL) triggers the action that results in the display of the HypertextMarkup Language (HTML) content in your browser window. As wedevelop our explanation of EDA, though, you will see that the Web is avery simple EDA.

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

The Enterprise Nervous System

Where would the IT industry be without metaphors? Even the idea ofusing the word architecture to describe how Byzantine networks ofhardware, software, and data are configured shows how reliant we are onabstraction to achieve an understanding of what we are trying to accom-plish in enterprise IT. In the spirit of metaphors, then, we shall borrow aconcept from human physiology, the central nervous system, to furtherour understanding of EDA.

If your cat steps on your toe, how do you know it? How do you knowit’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 toefire 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 thatmuch” and “It was probably a cat.” Or, if you saw the cat, the signals from

Event-Driven Architecture: A Working Definition 3

your optic nerve are synthesized with those from your toe, each invokingyour mental data store of animals and likely toe steppers, and you shouldknow 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 imagineif your central nervous system didn’t work well and you confused the catwith the lion. As Figure I.1 shows, you might shoot your cat and pet thelion, which would then eat you.

4 Introduction

Perception:Cat stepped on toe.

Reaction:Pet the cat.

Event:Cat steps on toe.

Perception:Lion stepped on toe.

Reaction:Shoot the cat.



Reaction:Pet the lion.

Event:Lion steps on toe.

Figure I.1 The human nervous system as a metaphor for the enterprise. When thecat steps on your toe, do you recognize it as a cat, or mistake it for a lion?

Our enterprises have their own nervous systems, too. Our Web sites,enterprise resource planning (ERP) systems, customer relationshipmanagement (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, assessesthe input and reacts. Of course, the corporate brain might contain a fewactual brains as well, in the form of employees, but their sensory input isdetermined by the enterprise nervous system. For example, if there is anincrease in cash withdrawals at a bank, the banking systems, acting likenerve sensors in our toe, fire 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

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

If our enterprises were living beings, most of them would need somepretty intensive neurological care. Unlike a well-functioning person,whose nervous system can learn how to react to different stimuli anddetermine the best way to handle a given situation based on sensoryinput and mental processing, the typical enterprise has a nervous systemthat is hardwired to react in a specific set of ways that might not be idealfor every situation. In the cat-on-toe situation, most of our enterpriseswould probably expect the worst and then shoot in the general directionof the cat. Or, perhaps a more realistic version of the metaphor—theenterprise wouldn’t even know that anything had stepped on its toe, orthat it even had a toe. It would be completely unaware most likelybecause 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 systemthat 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-drivenarchitecture is an approach to IT that gives the enterprise the ability toimprove its nervous system and have a level of adaptability and aware-ness that it needs. This is what we typically hear described as agility: theability to react intelligently to stimuli and also continually reshape thereaction as circumstances change.

Data is powerful, if you can see it and know what to do with it. Toparaphrase Levitt and Dubner and their great book, Freakonomics, anEDA provides potential adaptation data that exists in streams that wecan’t possibly see on our own. Levitt and Dubner characterize the Inter-net as a “gigantic horseshoe magnet waved over an endless sea ofhaystacks, plucking the needle out of each one.” Similarly, an EDA—thenervous system—gives us a way to acquire data and to make the data wehave meaningful. For example, if we knew that every day we experiencewhat it feels like to have a lion stepping on our toe, followed by no nega-tive reaction, we might learn to ignore it as unimportant—or begin toassume that it’s not a lion. That’s fine, until a lion does step on our toe…

Building an EDA to instill good functioning to the enterprise nerv-ous system involves getting the various sensors, message pathways, andreacting logic processors to work together. In broad terms, this is knownas interoperation, and it is the heart of the new EDA discussion going ontoday.

Event-Driven Architecture: A Working Definition 5

The “New” Era of Interoperability Dawns

Reading about EDA as a “new” idea might give you a sense of déjà vu. Aswe saw with the familiar credit card fraud example, EDA is not a newconcept. However, the current crop of EDAs uses proprietary standardsfor communication, and although they work well, they are, in effect,tightly coupled EDAs that can only share information among systemsthat use a compatible standard. For instance, it is possible to set up afairly effective EDA if all systems are built on the same platform. Ven-dors have long provided high-performance pub/sub engines for compat-ible systems. The only problem is, as we know, not everyone is on thesame platform, despite the dramatic sales efforts of some of Silicon Val-ley’s best and brightest minds. The good news is that many platform ven-dors have released new service-based EDA products, which do not relyon tight coupling.

The quest for a well-functioning enterprise nervous system has beenthe catalyst for the development of EDA for many years. Why, then, isEDA receiving such renewed and intense interest today? The reason hasto do with the explosion in interoperability and the standardization ofdata across multiple enterprises, which changes the game of EDA.

Ultimately, the existence of an EDA is dependent on interoperabil-ity among systems. You can’t have awareness and reaction to events if thesystems cannot communicate with one another. Existing EDA setups areinvariably tightly constrained and narrow in their functionality because ithas been so difficult, or costly, to achieve the level of interoperation ofEDA components needed for any kind of dynamic or complex EDAfunctionality. That is now changing. Today, with the advent of open stan-dards and the breakthroughs in system interoperability from service-oriented architectures (SOAs), it is now possible to establish EDAs thatare far more intelligent, dynamic, and far-reaching than ever before.

To put the interoperability evolution in context, we will share a lunchconversation we had recently with a man who had been responsible fordesigning and implementing the basic underpinnings of the worldwideairline reservation and automated teller machine infrastructures. In thelast few years, he has been involved in other pursuits, so he was eager tolearn about SOA and EDA, the new tech trends that he had been hear-ing so much about in the industry media.

When we explained how the related concepts of SOA and EDAallowed, for the first time ever, truly open interoperation among hetero-geneous software applications, regardless of operating system, network

6 Introduction

protocol, or programming language, he gave us a perplexed look. “That’snew?” he asked with a slight smirk. “That idea has been around since1961.”

And, of course, he was right. The idea of open interoperability hasbeen in the air for decades. Just like the automobiles have been aroundsince the late 1800s. Even today, we still use a combustion engine todrive the wheels, so the essence hasn’t changed much. However, neverbefore have cars been so reactive to our needs and their surroundings.

The same evolution is true for the software and the circumstancesthat we find ourselves in now, in 2009. Over the last eight years, from2001 to 2009, we have seen an unprecedented shift in the IT industrytoward the use of open standards for the purpose of integrating diversesoftware applications. Also, more and more companies are exposingtheir data in a standardized fashion further expanding the circle ofopportunity.

This all started back in 2001…. An unusually broad group of majorIT companies, including IBM, Oracle, Microsoft, BEA, and others,agreed to conform to a specific set of Extensible Markup Language(XML) standards for interoperation between software applications.These standards, known collectively as the Web Services protocol, pro-vide a technological basis for any application in the world to exchangedata or procedure calls with any other application, regardless of location,network, operating system, or programming language.

Specifically, the major standards that were ratified included SimpleObject Access Protocol (SOAP), which is the message formatting stan-dard, Web Services Description Language (WSDL), which sets out astandard document format with which to describe a Web service, andUniversal Description, Discovery, and Integration (UDDI), a Web serv-ices registry application programming interface (API), that are availablefor use in a particular domain.

Thus, Web services are software-based interfaces that are univer-sally understandable, self-describing, and universally discoverable. Asour colleague Jnan Dash, the legendary lead engineer of the OracleDatabase, puts it, the combination of the Internet and Web servicesmakes possible a kind of “universal dial tone” for all applications. (TheInternet is the dial tone and Web services give you the ability to “dial.”)With Web services, it is entirely possible for an application written in Cto interoperate with a J2EE application without the need for any propri-etary middleware. As a whole, the large-scale development and integra-tion of Web services is a key step toward developing a service-oriented

The “New” Era of Interoperability Dawns 7

architecture (SOA). SOA represents a model in which functionality isdecomposed into small, distinct units (services—for example, Web serv-ices), which can be distributed over a network and can be combinedtogether and reused to create business applications. These services com-municate with each other by passing data from one service to another orby coordinating an activity between two or more services.2 The industryvision that is fueling the SOA trend is that one day virtually any applica-tion needed in your enterprise (whether it is inside your firewall or not)will be available as a Web service and will be freely interoperable withother applications, enabling the decomposition of application function-ality into small units that can interoperate or be orchestrated in compos-ite applications. This vision is idealized, and it is likely that a full-blownSOA of this type will never actually come into existence. However, manyare approaching the paradigm in steps.

Many enterprises have begun to introduce service-orientation intheir architectures, selectively exposing capabilities through Web serv-ices in configurations that suit specific business needs and selectivelyservice enabling core legacy systems. This is a remarkable achievementfor an industry that was very much in the doghouse after the Y2K panicand dot.com fiascos of 2001. The most striking thing about SOA, beyondthe fact that Web services standards were adopted simultaneously bymany large IT vendors, is the fact that it actually works. SOA is verymuch the technological trend of the moment, and it is everywhere. Yousee SOA as a prominent feature set in products from Microsoft, Oracle,IBM, SAP, and so on. Virtually every major technology company hasannounced an SOA strategy or even shifted their entire market focus tobeing service-oriented. A sure sign that SOA had reached prime timewas when Accenture announced that it was going to spend $450 millionon an SOA consulting initiative for its global clients.

SOA removes much, if not all, of the proprietary middleware andnetwork compatibility blockages that inhibit rapid changes in applicationintegration. As a result, they can loosen the coupling between applica-tions. Given how important agility is, tight coupling is rightly held out asthe enemy of agility. Loose coupling is the enabler of agility and SOAdelivers loose coupling. Changes become simpler, faster, and cheaper.As integration agility becomes reality, so does EDA and its increasedawareness. Therefore, SOA delivers the necessary agility required for anEDA. However, achieving this goal of EDA through loose couplingwithout destroying a range of security, governance, and performance

8 Introduction

standards requires a great deal of planning and work. And, as we start tosee, the path from where we are now, to SOA and then EDA, is notalways clear.

The ETA for Your EDA

This is not a cookbook, but it can put you on track for finding the rightuse for EDA in your organization and getting it started. At the very least,our intent is to familiarize you with this exciting new technological para-digm—and you will need this familiarity if you are a professional work-ing in technology today. EDA and SOA are appearing in a myriad ofcommercial IT offerings and technological media articles. You need toknow about EDA.

How you approach EDA is up to you, and if your career has beenlike ours, you might agree that rushing is seldom a good idea, especiallywhen a new technology is involved. Our goal is to inform and stimulateyour thinking on the subject. Whatever the ETA is for your EDA, onlyyou will know the right way to proceed. Our wish is to give you theknowledge and insight you need to make it a success.

Endnotes

1. Michelson, Brenda. “Event Driven Architecture Overview.”Paper published by Patricia Seybold Group (2/2/2006).

2. Wikipedia, http://en.wikipedia.org/wiki/Service-oriented_architecture.

Endnotes 9

http://en.wikipedia.org/wiki/Service-oriented_architecture

http://en.wikipedia.org/wiki/Service-oriented_architecture

C H A P T E R 3

Characteristics of EDA

Firing Up the Corporate Neurons

Getting to a complete understanding of event-driven architecture(EDA) takes us on a step-by-step process of learning. First, we discussedthe enterprise nervous system and the way EDAs are formed by con-necting event listeners with event consumers and event processors, andso on. Then, to explain how these EDA components will likely be real-ized in today’s enterprise architecture, we learned about Web servicesand service-oriented architecture (SOA). To get the full picture, though,we now need to get into depth on the characteristics and qualities ofEDA components.

If the EDA components are like the neurons in the enterprise nerv-ous system, then we need to understand how their “synapses” and neuralmessage pathways work if we want to form a complete picture of EDA.We need to know how they actually can or should work together to real-ize the desired functionality of an EDA. In this context, we go moredeeply into the concept of loose coupling and also explore in depth theways that an EDA needs to handle messaging between its components.With the key concepts defined, we then lay out a thorough definition ofEDA, using an idealized EDA as an example.

Revisiting the Enterprise Nervous System

Returning to our cat scenario, if your cat steps on your toe, how do youknow it? How do you know it’s a cat, and not a lion? You might want topet the cat, but shoot the lion. And, perhaps most important, how canyou be sure that your body and mind learn how to distinguish between

63

the cat and the lion in the first place? How do you keep learning toprocess sensory experiences? The world is constantly changing, so ournervous systems, and our EDAs, must be flexible, adaptable, and fastlearners. We want our EDAs to be as sensitive, responsive, and teach-able as our own nervous systems. To get there, we need to endow ourEDA components with nervous system–like capabilities.

When the cat’s paw presses against your toe, the nerve cells in yourtoe fire off a signal to your brain saying, “Hey, something stepped on mytoe.” In this way, the neurons in your toe are like event producers. Theneural pathways that the messages follow as they travel up your spine tothe brain are like the messaging backbone of the EDA. Your brain is atonce an event listener and an event processor. If you pet the cat, yourhand and the nerves that tell your hand to move are event reactors. Fig-ure 3.1 compares the EDA with your nervous system.

64 Chapter 3 Characteristics of EDA

The Brain:Event Listener


Reaction:Pet the cat.


The Brain:Event Processor

The Hand:Event Reaction

Toe Neuron:Event Producer

Spinal Cord:Message Backbone

Figure 3.1 The human nervous system compared with an EDA.

The nervous system analogy is helpful for getting the idea of EDAon a number of levels. In addition to being a useful model of the EDAcomponents in terms that we can understand (and perhaps, more impor-tant, that you can use to explain to other less-sophisticated people), wecan learn a lot about how an EDA works by understanding how thenerves and brain communicate and share information. As a first step inmapping from nervous system to EDA in terms of its characteristics, we

look at event-driven programming, a technology that is comparable to anEDA and quite familiar, as well as informative.

Event-Driven Programming: EDA’s Kissing Cousin

We all use a close cousin of EDA on a daily basis, one whose simplicitycan help us gain a better understanding of EDA, perhaps without evenrealizing it. It’s called event-driven programming (EDP) and it’s commonin most runtime platforms. It’s also found in CPU architectures, operat-ing systems, GUI interfaces, and network monitoring. EDP consists ofevent dispatchers and event handlers (sometimes called event listeners).Event handlers are snippets of code that are only interested in receivingparticular events in the system. The event handler subscribes to a partic-ular event by registering itself with the dispatcher. The event dispatcherkeeps track of all registered listeners then, when the event occurs, notifieseach listener through a system call passing the event data.

For example, you might have a piece of code that executes if the usermoves the mouse. Let’s call this a mouse event listener. As shown in Fig-ure 3.2, the mouse event listener registers itself with the dispatcher—inthis case, the operating system. The operating system records a callbackreference to the mouse event listener. Every time the user moves themouse, the dispatcher invokes each listener passing the mouse move-ment event. The mouse movement event signals a change in the mouseor cursor position, hence a change in the system’s state. Other examplesof event-driven programming can be found in computer hardware inter-rupts, software operating system interrupts, and other user interfaceevents, such as mouse movements, key clicks, text entry, and so on.

Revisiting the Enterprise Nervous System 65

ClickNo Click

Function

Mouse EventListener

ClickNo Click

Function

Mouse EventListener

No Click

Figure 3.2 The PC’s instruction to listen for mouse clicks is an example of event-driven programming (EDP), a close cousin of EDA. When the mouse is clicked, themouse click event listener in the PC’s operating system is triggered, which, in turn,activates whatever function is meant to be invoked by the mouse click. When themouse is not clicked, the event listener waits.

Wikipedia describes event-driven programming as, “Unlike tradi-tional programs, which follow their own control flow pattern, only some-times changing course at branch points, the control flow of event-drivenprograms [is] largely driven by external events.”1 The definition pointsout that there is no central controller of the flow of data, which is coun-terintuitive to the way most of us were taught to program.

The reason we bring this up is to emphasize a key distinctionbetween EDP and conventional software: a lack of a central controller.This distinction is critical to understanding how EDA works. When youfirst enter the programming world, you’re taught how to write a “HelloWorld” program. You might learn that a program has a main methodbody from which flow control is transferred to other methods. The mainmethod is treated like a controller (see Figure 3.3).


EndStart

Main Method: Step 1 Main Method: Step 2Input ActionState2

ActionState1

Figure 3.3 In a conventional programming design, a controller method controls theflow of data and process steps.

In contrast, in event-driven programming, there are no central con-trollers dictating the sequence flow. As shown in Figure 3.4, each com-ponent listening for events acts independently from the others and oftenhas no idea of its coexistence. When an event occurs, the event data isrelayed to each event listener. The event listener is then free to react tothat information however it chooses, perhaps activating a process specif-ically intended for that particular event trigger. The event information isrelayed asynchronously to the event listeners so multiple listeners reactto the event data at the same time, increasing performance but also cre-ating an unpredictable order of execution.

Figure 3.4 In event-driven programming (EDP), event listeners receive state changedata (events) and pass them along to event dispatchers, which then activateprocesses that depend on the nature of the triggering events.

As shown in Figure 3.4, the listeners execute concurrently. This isquite different from the typical program that controls the flow of data. Ina typical program, the controller method calls out to each subcompo-nent, passes relevant data, waits for control to return, then continues tothe next one—a very predictable behavior. Of course, the controllermethod could take an asynchronous approach, but the point is that onehas a predefined flow of data whereas the other does not.

When waiting for events, event listeners are typically in a quiescentstate, though occasionally you’ll see a simulated event-driven modelwhere event listeners cyclically poll for information. They sleep for apredefined period then awaken to poll the system for new events. Thesleep time is usually so small that the process is near real time.

Similar to EDP-based systems, EDA relies on dynamic binding ofcomponents through message-driven communication. This provides theloose coupling and asynchrony foundation for EDA. EDA componentsconnect to a common transport medium and subscribe to interestedevent types. Most EDA components also publish events—meaning theyare typically publishers and subscribers, depending on context. Thebiggest difference between EDA and EDP is that EDP event listenersare colocated and interested in low system-level events like mouse clicks,whereas EDA event consumers are likely to be distributed and interestedin high-level business actions such as “purchase order fulfilled.”


Process A

Event Action Action

Action

Action

Event

Action Action

Event

Action

Process B

Process C

Action

Action ActionState1

MessageBackbone

EventListener

EventListener

EventListener

More on Loose Coupling

Let’s go deeper on loose coupling, a core enabling characteristic ofEDA. You can’t have EDA without loose coupling. So, as far as we EDAbelievers are concerned, the looser the better. However, getting to aneffective and workable definition of loose coupling can prove challeng-ing. If you ask nine developers to define loose coupling, you’ll likely getnine different answers. The term is loosely used, loosely defined, andloosely understood. The reason is that the meaning of loose coupling iscontext sensitive. For EDA purposes, loose coupling is the measure-ment of two fundamentals:

■ Preconception■ Maintainability (Changeability)

Preconception: The amount of knowledge, prejudice, or fixedidea that a piece of software has about another piece of software

Preconception is a quality of software that reflects the amount ofknowledge, prejudice, or fixed idea that one piece of code has aboutanother piece of code. The more preconception that an application (or apiece of an application) has in relation to another application with whichit must interoperate, the tighter the coupling between the two. The lesspreconception, the looser the coupling. We’ve all seen tight couplingthat stems from high levels of preconceptions. Think of systems whereevery configuration attribute and every piece of mutable text is hard-coded in the system. It can take days just to correct a simple spellingmistake. During design, these systems all made a single, yet enormous,configuration preconception—they assumed that the configurationwould be set at compile time and never need to be changed. You willnever get to the flexibility of configuration that you need to build anEDA with this kind of tight coupling.

Ultimately, to move toward EDA and SOA, you should strive forsoftware that makes as few presumptions as possible. To use a common,real-world example of tight coupling, consider a point-of-sale (POS) pro-gram calling a credit card debit (CCD) program and passing it a creditcard (CC) number. As shown in Figure 3.5, the POS program has a pre-conceived notion that it will always be calling the CCD program andalways be passing it a CC number, hence the two systems are now tightlycoupled.


Maintainability: The level of rework required by all participantswhen one integrated component changes


Card Number/ID

POS System

Cashier isAuthentic

Validate

Figure 3.5 In this classic example of tight coupling, a POS system sends a creditcard number to a CCD program and requests a validation, which is indicated by areturned value of isAuthentic. The two systems are so tightly bound together theycan almost be viewed as one single system.

Maintainability, the other EDA-enabling component of loose cou-pling, refers to the level of rework required by all participants when oneintegrated component changes. When a piece of software changes, howmuch change does that introduce to other dependent software pieces?Best practices dictate that we should strive for software that embracesand facilitates change, not software that resists it. As a rule, the looserthe coupling between components or systems, the easier it is to makesoftware changes without impacting related components or systems.

Consider the hard-coded POS system described previously. A sim-ple configuration change requires a source code change, compilation,regression testing, scheduled system downtime, downtime notifications,promotion to production, and the like. A system that resists change isconsidered a tightly coupled system.

Now let’s suppose we begin to alleviate our headaches by removingsome of the system’s preconceived ideas. As a start, let’s assume we makethe following two changes:

■ First, we remove the hard-coded instructions from our systemcode, and instead let behavior be driven by accessing valuesstored in a configuration file (presumably read into memory atinstantiation).

■ Second, we enable our system to be dynamically reconfigured(meaning our system would have a mechanism for reloading newversions of the configuration file while still active).

In this case, making a simple change to our configuration file, such asindicating that an entry in coupon format is a valid form of payment oreven correcting a spelling mistake, only requires a regression test and asignal sent to the production system to reload its configuration. The sys-tem is maintainable—we updated the system while it stayed in produc-tion, and we did so without compiling a lick of code.

We have also successfully decreased the coupling between our sys-tem and its configuration. The system is now loosely coupled withrespect to this context but it might still be tightly coupled in other areas.We have only increased its loosely coupled index. We have increased itschangeability and decreased its preconception with respect to configura-tion, but how does it interact with other modules or components? Itmight be tightly coupled with other software.


What Your CFO Is Thinking

Imagine that you are the owner of this tightly coupled POS system, and yourCFO tells you that, as of some very rapidly approaching date, she expects thePOS systems to accept coupons as a form of payment in addition to creditcards. Unlike the credit cards, which have a 16-digit identifying number and amatching expiration date, the coupons have a 10-character identifier com-posed of letters and numbers. When you tell your CFO that it might take youthree months to make this change, she is not going to be too interested inthe issues of maintainability and preconception involved in the POS soft-ware, but you know that these two tight coupling demons are to blame. Thecoupons might actually provide you with a good pretext to start discussing anEDA/SOA approach to POS. You can tell the CFO that you can make futurecoupon transitions faster if you loosen up the coupling in the POS systems.

This is where the meaning of loose coupling is context sensitive. Wecan say the system is loosely coupled if that statement is made within thecontext of the configuration file. We can also say it is not loosely coupledif the statement is made referring to its integration techniques.

This example oversimplifies the situation because hard-coded sys-tems are often very difficult to modify into configuration-driven systems,and even harder to modify to dynamically configuration-driven systems,but the points are valid. We did decrease the tight coupling and ease ourheadache. Moreover, we can see that significant rework time would havebeen saved had the system designers taken this approach from thebeginning.

To illustrate our point, we have just used an example where weincreased the degree of loose coupling of the system by loosely couplingconfiguration attributes. However, the term is typically used to referenceintegration constraints. Two or more systems are tightly coupled when theirintegration is difficult to change because of each system’s preconceptions.

Our previous point-of-sale (POS) scenario is an example of twotightly coupled systems. Changes in either system are very likely tonecessitate changes in the other. At the extreme (though not uncom-mon) end of this spectrum, the overall design might be so tightly inte-grated that the two systems might be considered one atomic unit.

The POS system has preconceived notions about how to interactwith the CCD system. For example, the POS system calls a specificmethod in the CCD system, named validate, passing it the CC num-ber. Now suppose the CCD system changes the method name toisAuthentic. This might happen if a third party purchased the CCDsystem, for example.

What we want to do is isolate those changes so that we do not have tochange our POS system with every vendor’s whim. To loosen up thearchitecture, let’s exercise a design pattern called the adapter pattern.We will add an intermediate (adapter) component between the POS andCCD systems. The sole purpose of this component is to isolate the pre-conceived knowledge of the CCD system. This allows the vendor tomake changes without adversely affecting the POS system.

Now vendor changes in the CCD system are isolated and can bebridged using the intermediate component. As the diagram in Figure 3.6illustrates, the vendor can change the method name and only theadapter component needs to change.


Figure 3.6 The insertion of an adapter between the POS and CCD systems loosensthe coupling. Changes to the CCD system are isolated and can be bridged using theadapter.

This reduces the POS system’s preconception about the CCD givingthe systems greater changeability. In essence, we now have greater busi-ness flexibility because we now have the freedom to switch vendors if wechoose. We can swap out the Credit Card Debit (CCD) product foranother just by changing the adapter component.

The true benefits of the design shown in Figure 3.6 are radically evi-dent when we talk about multicomponent integration, which is shown inFigure 3.7. Here, the benefits are multiplied by each participating com-ponent. This is also where the return on investment shows throughreuse. Understand that the up-front time spent on building the adapteris now saving more money with each use. The more you use it, the moreyou’ll save.


Card Number/ID

POS System

Cashier isAuthentic

Validate

isAuthentic

Adapter

Figure 3.7 Use of adapters in multicomponent integration.

The argument can be made that we have now only shifted the tightcoupling to our adapter, which is true, though we have added a layer ofabstraction that does, in fact, increase maintainability of the system.We’ll demonstrate how to fully decouple these systems when we talkabout event-driven architecture later in this chapter.


ERP

User

Cashier

CRM

Partners

CICS Apps

ERP

User

Cashier

CRM

Partners

CICS Apps

Adapters

Adapters

There will always be a degree of coupling. Even fully decoupled com-ponents have some degree of coupling. The desire is to remove as muchas possible but it is naïve to think the systems will ever be truly decou-pled. For example, service components need data to do their job, and assuch will always be coupled to the required input data. Even a compo-nent that returns a time stamp is tightly coupled with the system call usedto retrieve the current time. As we strive for loose coupling, we shouldremember that the best we can achieve is a high “degree of looseness.”

More about Messages

Coupling, loose or tight, is all about messages. For all practical purposes,it is only possible to have loose coupling and EDA, with a messagingdesign that decouples the message sending and receiving parties andallows for redirection if needed. To see why this is the case, let’s look attwo core aspects of messaging: harmonization and delivery. Harmoniza-tion is how the components interact to ensure message delivery. Deliv-ery is the messaging method used to transfer data.Message harmonization is how the components interact toensure message delivery.

Harmonization can be synchronous or asynchronous. Synchronousmessaging is like a procedure call shown in Figure 3.8. The producercommunicates with the consumer and waits for a response before con-tinuing. The consumer has to be present for the communication to com-plete and all processing waits until the transfer of data concludes. Forexample, most POS systems and ATMs sit in a waiting state until transac-tion approval is granted. Then, they spring back into life and completethe process that stalled as the procedure call was completed. Compara-ble examples of synchronous messaging in real life include instant mes-saging, phone conversations, and live business meetings.


Figure 3.8 Example of synchronous messaging, a process where the requestingentity waits for a response until resuming action.

In contrast, asynchronous messaging does not block processing orwait for a response. As Figure 3.9 illustrates, the message consumer inan asynchronous messaging setup need not be present at the time oftransmit. This is the most common form of communication in distrib-uted systems because of the inherent unreliability of the network. Inasynchronous messaging, messages are sent to a mediator that stores themessage for retrieval by the consumer. This allows for message deliverywhether the consumer is reachable or not. The producer can continueprocessing and the consumer can connect at will and retrieve the await-ing messages. Examples include e-mail (the consumer does not need tobe present to complete delivery), placing a telephone call and leaving avoice mail message (versus a world without voice mail), and discussionforums.


Integrated Application

1 State: Active 3 State: Active2 State: Waiting

2 Processing Response

Request for Data Response

Integrated Application

1 State: Active 3 State: Active – ResumesActivity Based on

Response to Request

2 State: Active withOther Processes

2 Processing Response

Request for Data Response

Figure 3.9 Example of simple, point-to-point asynchronous messaging.

There are multiple ways to execute message delivery whether syn-chronously or asynchronously. Synchronous messaging includesrequest/reply applications like remote procedure calls and conversa-tional messaging like many of the older modem protocols. Our focushere is on asynchronous messaging. Asynchronous messaging comes intwo flavors: point-to-point or publish/subscribe.Message delivery is the messaging method used to transfer data.

Point-to-point messaging, shown in Figure 3.9, is used when many-to-one messaging is required (meaning one or more producers need torelay messages to one consumer). This is orchestrated using a queue.Messages from producers are stored in a queue. There can be multipleconsumers connected to the queue but only one consumer processeseach message. After the message is processed, it is removed from thequeue. If there are multiple consumers, they’re typically duplicates of thesame component and they process messages identically. This multiplicityis to facilitate load balancing more than multidimensional processing.

Publish/subscribe messaging, shown in Figure 3.10, is used whenmany applications need to receive the same message. This wide dissemi-nation of event data makes it ideal for event-driven architectures. Mes-sages from producers are stored in a repository called a topic. Table 3.1summarizes the differences between the two modes of message flow.Unlike point-to-point messaging, pub/sub messages remain in the topicafter processing until expiration or purging. Consumers subscribe to the topic and specify their interest in currently stored messages. Inter-ested consumers are sent the current topic contents followed by any newmessages. For others, communication begins with the arrival of a new message.

Topics provide the advantage of exposing business events that can beleveraged in an EDA. One consideration is the transaction completeindeterminism, and we will soon explore ways to handle this.


Figure 3.10 Example of publish/subscribe (pub/sub) asynchronous messagingusing a message queue.

Asynchronous messaging requires a message mediator, or adapter.This can be achieved using a database, native language constructs likeJava Channels, or the most common provider of this functionality, mes-sage-oriented-middleware (MOM). MOM software is a class of applica-tions specifically for managing the reliable transport of messages. Thisincludes applications like IBM’s WebSphere MQ (formally MQSeries),Microsoft Message Queuing (MSMQ), BEA’s Tuxedo, Tibco’s Ren-dezvous, others based on Sun’s Java Messaging Specification (JMS), anda multitude of others.

JMS is the most prominent vendor-agnostic standard for message-oriented-middleware. Before its creation, messaging-based architec-tures were locked in to a particular vendor. Now, most MOMapplications support the standard, making it the primary choice forimplementation teams concerned with vendor-agnostic portability.


Publisher A

Subscriber Subscriber

Publisher B Publisher C

BBB

Message QueueA, A, B, A, C, C, C, A, B, B, A

Table 3.1 Point-to-Point Versus Publish/Subscribe


Point-to-Point Queues Publish/Subscribe Topics

Single consumer Multiple consumers

Preconceived consumer Anonymous consumers

Medium decoupling High decoupling

Messages are consumed Messages remain until purged or expiration

The Ideal EDA

Having taken our deep dive into the key characteristics of EDA, we cannow examine a workable, if idealistic definition of EDA. With the usualcaveat that no architecture will, in all likelihood, ever embody EDA in100% of its functionality, we can define EDA as an enterprise architec-ture that works in the following ways:

EDA: What It Is

■ An EDA is loosely coupled or entirely decoupled.■ An EDA uses asynchronous messaging, typically pub/sub.■ An EDA is granular at the event level.■ EDAs have event listeners, event producers, event processors, and

event reactors—ideally based on Simple Object Access Protocol(SOAP) Web services and compatible application components.

■ An EDA uses a commonly accessible messaging backbone, suchas an enterprise service bus (ESB) as well as adapters or interme-diaries to transport messages.

■ An EDA does not rely on a central controller.

EDA: What It Does and What It Enables

■ An EDA enables agility in operational change management.■ An EDA enables correlation of data for analytics and business

process modeling, management, and governance.

■ An EDA enables agility in realizing business analytics and dynam-ically changing analytic models.

■ An EDA enables dynamic determinism—EDA enables the enter-prise to react to events in accordance with a dynamically changingset of business rules, for example, learning how to avoid shootingthe cat and petting the lion (in contrast to controller-based archi-tectures that can be too rigid to be dynamic, for example, shootingthe cat, not being aware of the lion).

■ An EDA brings greater consciousness of events to the enterprisenervous system.

Though we delve more deeply into the ways that SOAP Web serv-ices enable EDA later in the book, we want to go through a basic expla-nation at this point because our described use of Web services as eventproducers might appear confusing to some readers. Much has been writ-ten about Web services in recent years, and, indeed, many of you likelyalready work with them. It might seem incorrect to characterize a Webservice as a “producer” of SOAP Extensible Markup Language (XML)event state messages when Web services, to be accurate, actuallyrespond to invocation, perhaps sending off SOAP XML if instructed todo so. This is, of course, correct. A SOAP Web service does not transmita SOAP message without being triggered to do so. Thus, when we talkabout Web services functioning as event producers, we are describingWeb services that are specifically programmed to send event data to themessage backbone. These event Web services could be triggered byactivities occurring inside an application or by other Web services. Thereason we suggest that event producers should be configured in thisway—as Web services that transmit event state data upon invocation—isthat there is a high level of utility in transmitting the event data in theportable, universally readable SOAP XML format.

Figure 3.11 revisits our phone company example and shows a high-level model of how its systems would function and interoperate in anideal EDA. Let’s make a few basic observations about how the com-pany’s EDA works. With an EDA, in contrast with the traditional enter-prise application integration (EAI) approach, the company’s threesystem groups all send event data through adapters and message listen-ers to a service bus, or equivalent EDA hub that manages a number ofpub/sub message queues for all systems that need that event data tocarry out their tasks.

The Ideal EDA 79

Figure 3.11 A high-level overview of an event-driven architecture at a phonecompany. Each system group is loosely coupled with one another using standards-based pub/sub asynchronous messaging.

As shown in Figure 3.12, using a dynamic determinism model, theorder management system can now listen for overages in minutes andunpaid bills that occur in billing and line management system events andrespond to them according to the business rules. Thus, if “John Q”exceeds his allowance of wireless minutes and fails to pay for the over-age, the business rules contained in the order management system willdeny him the right to add new services to his account.


MessagingBackbone

Order ManagementEvent Producer

Line ManagementEvent Producer

Branch Outlets

Event Driven ApplicationsEvent Processors

Call CenterEvent

Billing SystemEvent Producer

Call CenterEvent

EventAccounting and Finance Department

Printer Server FarmsEvent

Service Center TerminalEvent

Event

Pub/Sub

Pub/SubPub/Sub

Event Listeners

MessagingBackbone

Order Management

Line Management

EDA App:John Q cannot have new servicesadded until he pays hisminutes overage.

Event 2:John Q’s exceeds hisminutes allowance.

Event 1:John Q’s minutes overageis not paid.

Billing System

Pub/Sub

Pub/SubPub/Sub

Figure 3.12 In the phone company EDA example, separate events in two systems—an overage in wireless minutes and an unpaid balance in the billing system—arecorrelated by an application that then denies the order management system theability to grant the customer a new service request.

The order management system does not have to have the kind ofpreconception about the line management system that it needed to haveto provide this function under the EAI model. The two systems aredecoupled but still interoperating through the EDA. The billing systemis the event producer and the order management system is the eventconsumer.

Figure 3.13 shows how event listeners detect the two separateevents—the unpaid overage charge and the overage in minutes itself.The EDA-based application that authorizes or declines the new servicerequest subscribes to the event publishing done by the line managementand billing systems. The combination of events—unpaid balance andoverage of minutes—combines to change the state of John Q’s account.The change in state is itself an event. John Q’s status goes from “eligible”to “ineligible” for new services. If John Q requests new services, theorder management system looks to the EDA application to determine ifJohn Q’s status is eligible.

The Ideal EDA 81

Line Management Billing System

Order Management

Messaging Backbone

Event Message Stream<Billing,JoeA,OveragePaid><Billing,RobB,OveragePaid><Billing,BillC,OveragePaid><Billing,JohnQ,OveragePaid><Line,TomA,Under><Line,DickB,Under><Line,HarryC,Under><Line,JohnQ,Under><Line,RonR,Under><Line,BillyJackJimBobC,Under>

Event Listener(listening for “OverageUpaid”)

What is status ofJohn Q?

Approve newservice request?

Eligibility State Database

Event Listener(listening for “Over”)

Decision

EDA App

Figure 3.13 The EDA-based application subscribes to event data that is publishedand consumed by event listeners on separate systems. This gives the EDA-basedapplication the ability to have awareness of changes in state related to John Qwithout tightly coupling any of the applications involved in the query.

EDA opens new worlds of possibility for IT’s ability to serve its busi-ness purpose. Think of all the business events a system could leverage ifevents were exposed—examples include events such as order processingcomplete, inventory low, new critical order placed, payment received,connection down, and so on. Today, it’s a struggle to expose the neededevents because they’re hidden away within legacy systems. It’s commonto resort to database triggers or polling to expose these critical actions,

but imagine the supportable agility if the systems exposed those actionsnatively.

Exposing system actions is the root of most integration complexities.“Upon completion of processing at System A, send result to system B,”and so on. Most legacy systems were not designed with unanticipateduse in mind. They assumed they would be the only system needing theinformation and thus didn’t expose key event data for easy access. Ifyou’re lucky, the system will provide an application programming inter-face (API) to retrieve data, but rarely will it facilitate publishing an eventor provide any event retrieval mechanism. Because events are typicallynot exposed, the first thing you have to do is create an algorithm todetermine an event occurred. Often, legacy system events have to beinterpreted by correlating multiple database fields (e.g., “If both of thesetwo fields change state, then the order has been shipped…”). Imaginehow much easier integration would be if such event actions werenatively exposed.

Event-driven architectures are driven by system extensibility (notcontrollability) and are powered by business events. As shown in Figure3.13, event handlers listen to low-level system events while EDA agentsrespond to coarser-grained business events. Some agents might onlyrespond to aggregate business events, creating an even coarser systemresponse.

EDAs are based on dynamic determinism. Dynamic determinismrelates to unanticipated use of applications and information assets.Events might trigger other services that might be unknown to the eventpublisher. Any component can subscribe to receive a particular eventunbeknown to the producer. Because of this dynamic processing, thestate of the transaction is managed by the events themselves, not by amanagement mechanism.

EDA embraces these concepts, which facilitate flexibility and exten-sibility, ultimately increasing a system’s ability to evolve. This is accom-plished through calculated use of three concepts—loose coupling,asynchrony, and stateless (modeless) service providers—though it does-n’t come free. EDA brings inherently decentralized control and a degreeof indeterminism to the system.

One of the main benefits of EDA is that it facilitates unanticipateduse through its message-driven communication. It releases informationpreviously trapped within monolithic systems. When designing EDAcomponents, you should design for unanticipated use by producing


events that can provide future value whether a consumer is waiting ornot. Your EDA components should be business-event-intuitive, publish-ing actions that are valued at a business level.

Imagine an EDA billing component. After it has finished billing acustomer, it should announce the fact even if there is no current need.What if all financial actions were being sent via events? Recognizing thatthere was no immediate need for these events when the systems wereoriginally built, look at how beneficial it would be today. Imagine howeasy that would have made your company’s Sarbanes-Oxley complianceefforts. Of course, it takes a degree of common sense in determiningwhat might be of value in the future, but it’s safe to say that most con-crete business state changes will be valued. The caution to note here,though, is that it is possible to create an event publishing overload thatoverwhelms system and network capacity.

EDA components should also be as stateless as possible. The systemstate should be carried in the event, not stored within a component vari-able. In some situations, persistence is unavoidable, especially if thecomponent needs to aggregate, resequence, or monitor specific events.However EDA components should do their job and pass on the datathen return to process or wait for the next event. This gives the systemultrahigh reuse potential and flexibility. The flexibility of an EDA is lead-ing to emerging concepts that leverage events at a business process level.

Consciousness

EDA brings consciousness to the enterprise nervous system. Withoutevent-driven architecture (EDA), enterprises operate as if they’re on lifesupport. They’re comatose (brain dead), meaning they are unaware oftheir surroundings. They cannot independently act on conditions withoutbrokered instruction or the aid of human approval. Service-orientedarchitectures (SOAs) define the enterprise nervous system, while EDAbrings awareness. With the right mix of smart processing and rules, EDAenables the enterprise nervous system to consciously react to internal andexternal conditions that affect the business within a real-time context.

Consciously reacting means the architecture acts on events inde-pendently without being managed by a central controller. Underlyingcomponents react to business events in a dynamic decoupled fashion.This is in contrast to the central controller commonly seen in SOAs.

Imagine the analogy of our consciousness with a cluster of functionalcomponents. Sections of consciousness process certain information, just

The Ideal EDA 83

like each component has an area of expertise. Components wait for per-tinent information, process, and fire an output event. The output mightbe destined to another component or to an external client. Our con-sciousness works in the same manner, processing information and send-ing output to either other synaptic nodes or externally, perhaps throughvocal communication. In both of these cases, the messages were not sentto a central controller to decide where to route or what to do. The behav-ior is inherent in the design.

This is in direct contradiction to the way we teach and learn to pro-gram. Schools and universities teach us to start every project with a cen-tral controller. In Java, this would be the main method, where thesequence of control and the flow of information are controlled. This typeof system is tightly coupled with the controller and is difficult to makedistributed. Today’s architectures need to be looser coupled and moreagile than we’ve been taught.

Today’s systems need true dynamic processing. Systems are classi-fied as dynamic or static, but, in reality, most systems are static; they havea finite number of possible flows. If a system has a central controller, it’sdefinitely static even if control branches are based on runtime informa-tion. This makes testing easier because of the degree of predetermina-tion but does not provide the agility of a dynamic system.

A central controller with a limited number of possibilities decreasesagility. When the system needs to change outside of those possibilities,new rules and branches are added, increasing the tight coupling andcomplicating the architecture. Over time, the branching rules becomeso complex that it’s nearly impossible to manage and the system turnslegacy.EDA is about removing the rigidity created by central controland injecting real-time context into the business process.

We need to be clear about one thing here: When we talk aboutremoving central control, we are not suggesting that you can be effectivein an EDA by removing all control from the application. An uncon-trolled application would quickly degenerate into chaos and lock itselfup in inaction, or in inappropriate action. Real-world autonomic systemssee this: Three moisture-ridden sensors in a B-2 bomber sent bad data tothe aircraft’s computer, causing it to fly itself into the ground. Anotherexample is the human body’s response to significant blood loss: If thebody loses a large volume of blood, the brain detects the fact that it’s notgetting enough oxygen (decreased blood) and automatically dilates thevascular system and increases the heart rate. If the blood loss is due to an


open wound, this serves only to lose blood faster! So when we talk aboutEDA’s lack of reliance on central control, we mean that the control is dis-tributed in the form of business rules—and distributed rules must beconfigured to trigger appropriate actions. The event components con-tain business rules that are implemented as each event component isactivated. The result is an application, or set of applications, that oper-ates under control, but not with a central controller.

Event-driven architectures insert context into the process, which ismissing in the central controller model. This is where the potential for atruly dynamic system emerges. Processing information has a contextualelement often only available outside of the central controller’s view.Even if that contextual change is small, it can still have bearing on theway data should flow.

One contextual stimulus is the Internet. The Internet has opened upbusinesses to a new undressing. Business-to-business transactions,blogs, outsourcing, trading partner networks, and user communitieshave all cracked open the hard exterior of corporations. They provide aneasily accessible glimpse into a corporation’s inner workings that wasn’tpresent before. This glimpse inside will only get larger with time makingthe inner workings public knowledge and making media-spin-doctoringof unethical practices more evident.

Don Tapscott in The Naked Corporation2 talks about how the Inter-net will bring moral values to the forefront as unethical practicesbecome more difficult to cover and financial ramifications increase.Businesses will be valued on their financial standing along with reputa-tion, reliability, and integrity. This means businesses will have to changetheir process flow based on external conditions such as worldly eventsand do so efficiently.

Information is being aggregated in different ways. Businessprocesses are changing and being combined in real time with externaldata such as current worldly events. Because of the increased exposurethrough the Internet, questionable businesses practices are beinguncovered. Sometimes, these practices are unknown to the core busi-ness, hence businesses want to react quickly to the publicity. Imagine anews investigation that uncovers a major firm is outsourcing labor to acompany involved in child slavery. For example, company X is exposedfor buying from a cocoa farm in West Africa’s Ivory Coast that uses childslavery. The business would immediately want to stop their businesstransactions with that company and reroute them to a reputable supplierbefore the damage becomes too great.

The Ideal EDA 85

For ethical reasons, eBay continually blocks auctions that attempt toprofit from horrific catastrophes like major hurricanes, a space shuttleaccident, or even a terrorist attack like 9-11. Imagine the public impres-sion of eBay if this was not practiced and they profited from theseevents.

Now imagine having a system that’s worldly aware enough to cir-cumvent business processes if these cases should occur. Suppose thissystem had an autonomous component that compares news metadatawith business process metadata and curtails the process at the first signof concern. The huge benefits definitely outweigh the calculated risks.Simply rerouting a purchase order to another supplier with comparableservice levels definitely has a big upside. If the autonomous deductionwas correct, it might have saved the company millions in bad press whilemaintaining their social responsibility. If it was wrong, then no real harmwas done because the alternate company will still deliver on time.

A similar scenario could support eBay’s ethics. An autonomous com-ponent that compares news metadata with auction metadata could with-hold auctions based on real-time news events. If correct, it could savethe company from public embarrassment. If wrong, little harm was doneother than to delay an auction start time.

EDA can provide this dynamic monitoring, curtailing, and self-heal-ing. Event-driven architecture facilitates bringing these external con-texts into the business process. The idea is that the separation betweenconcrete business process and day-to-day reality is blurring. Businessesmight be required to change their process based on unexpected externalevents. This is much different from the days where an end-to-end busi-ness process happened within a company’s boundary (and control).Combining this need with the traditional business need for rapid changemeans flexible architecture design is paramount. One way to ensure thisflexibility is through the SOA/EDA way—by reducing central controland adding context to the business process.

BAM—A Related Concept

Business Activity Monitoring (BAM) is related to EDA, but differentenough that we discuss it in brief. Our goal is to help you differentiatebetween BAM and EDA, as the two ideas are often used interchange-ably in IT discussions. We do not think they are interchangeable.


BAM is the idea that business decisions would be better and moretimely if they were based on timely information extracted through busi-ness activities that are exposed near real time. Too often, decisions aremade based on warehoused data that is stale or misrepresented becauseof the available gathering technique. Event-driven architectures make iteasier to tap into key business activities. BAM components monitorthese activities, aggregate the information, watch for anomalies, sendwarnings, and represent the data graphically.

Historically, most of the activity in this area was achieved with in-house built dashboards. Now we’re seeing more vendor products in thespace. BAM is most useful in situations where quick critical decisions areimportant. Interesting applications of this concept include illustratingKey Performance Indicators (KPI), watching for homeland securityanomalies, monitoring supply chain activities, and discovering business-to-business (B2B) exchange patterns. Implementing a BAM solutionwithin your EDA is almost always a good idea.

Chapter Summary

■ In this chapter, we move forward with our metaphor of EDA asthe enterprise nervous system and match the EDA compo-nents—event producers, listeners, processors, and reactors—totheir equivalent in the nervous system. Event producers and con-sumers are likened to the sensory nerve endings that pick up andrelay information about our senses to our brain, which is like anevent processor. Reactions, such as physical movements, are likethe event reactors. For additional context and framework, we lookat event-driven programming, a core technology of most PCs, as acomparable example of events, event listening, and event pro-cessing on a lower level of functioning than an EDA.

■ To complete our understanding of how EDA works, we then carrythis enterprise nervous system idea further and take an in-depthlook at the characteristics of EDAs and their components. Again,our focus is on the EDA of the future: an implicit, complex, anddynamic EDA, one that can adapt easily to changes and continu-ally expand its reach of event detection and event reaction.

Chapter Summary 87

■ EDA components must be loosely coupled to function dynami-cally. Loose coupling requires that EDA components have lowlevels of preconception about each other and maintainability. AnEDA works best if each component functions independently,with little need to know about the other components it is commu-nicating with, and few ramifications if one component is modified.

■ EDAs, unlike conventional applications, do not rely on centralcontrollers.

■ Events (state change notifications) are central to an EDA. Anevent can take the form of a message and an EDA is a message-based idea. To work, an EDA’s loosely coupled components mustbe able to produce and consume messages. The messages couldbe related to event listening, processing, or reactions. The moreeasily the messages can flow across the EDA (which might spanmultiple enterprises), the better the EDA will work.

■ Asynchronous, or publish/subscribe (pub/sub) messaging, is oneof the best foundations for an EDA. As the EDA componentscommunicate with one another, they feed messages (events) intoan event bus. Event listeners receive the events, and then EDAcomponents process the event data as required by the EDA’sdesigned purpose. Pub/sub is ideal for EDAs because it removesa lot of message flow dependencies from individual components.It is simpler, for example, to connect event listeners usingpub/sub than to tightly couple them together, where changes inconfiguration are costly and slow to accomplish.

■ To achieve loose coupling and asynchronous messaging, an EDArelies on message intermediaries. In some cases, these are knownas service buses.

■ The ideal EDA, therefore, is a loosely coupled, pub/sub-basedarchitecture, with low levels of preconception and high degrees ofmaintainability among the components.


Endnotes

1. Wikipedia. Event-Driven Programming. August 2004.http://en.wikipedia.org/wiki/Event-driven_programming.

2. Tapscott, Don. The Naked Corporation. New York: Free Press, 2003.

Endnotes 89

http://en.wikipedia.org/wiki/Event-driven_programming

Index

Aaccidental architectures, examples

of, 25agents

auditing, 149defining, 149domain agents, 151infrastructure agents, 151message backbones, 151simple agents, 150typing, 150

aggregation agents, 151agility, SOA-EDA development, 135airline flight control EDA case study,

159-160ATCSCC software, 161FEDA

adding new users to, 168auditing, 169autonomic response, 168bottleneck analytics, 170bottleneck awareness, 169bottleneck resolution

capacity, 169carrying state in, 181-182cost-effective integration, 171

customizable front-endinterfaces, 168

data transformation in, 171, 178-180

enabling technology factors in,174-175

ESB federation in, 177event web service life cycles,

191-195extensibility, 171extensible front-end

interfaces, 168functional requirements, 168-170high-level architecture, 172-174local event processing, 171minimal impact on existing

systems, 171mitigation of risks in, 198-199,

203-204organization in, 199-200project life cycle, 201-203project risks in, 197real-time awareness, 168reliability, 169reporting, 169security, 169

295

SOA governance in, 182-187,190-196

success metrics, 204-205system level communications, 169system requirements, 171“what-if” modeling, 169

ripple effect, 163-166analysis (real-time), EDA and, 101anti–money laundering SOA-EDA

case study, 209, 223-224EDICTS

compatible developmentpractices, 253

defining reference architectures,242-244

integrating with bank’s SOA, 251joint planning with enterprise

architecture teams, 252-253matching requirements with

internal controls, riskmitigation and compliance,246-248, 251

optimizing ownership, 234-242SOA governance, 254-258

event clouds, 222event listeners, 232event producers, 222, 227, 231-232IT aspects of, 216, 219-221rules engines, 222SOBA, 228, 231

application designreducing central control in, 142

carrying state inside events, 147-148

controllers versus trustedexecutors, 142-146

designing for unanticipated use, 148

enabling autonomous behavior, 148

unanticipated use, designing for, 148

application integrationEAI, 29-30middleware, 29-30

asynchronous messagingcoupling, 75JMS, 77message mediators, 77MOM, 77point-to-point messaging, 76-77publish/subscribe messaging, 76-77

ATCSCC (Air Traffic Control SystemCommand Center) software, 161

auditinganti–money laundering SOA-EDA

case study, 216, 219-221FEDA, 169

augmenting agents, 150autonomic response (FEDA), 168autonomous behavior, enabling, 148

BBAM (Business Activity

Monitoring), 86banks, money laundering

auditing, 216, 219-221prevention, 214-216, 219-221risks of, 212-213

benefits of EDA, calculating, 153

296 Index

BI (business intelligence), ProdCoEDA-PI integration case study, 287

bottleneck analytics (FEDA), 170bottleneck awareness (FEDA), 169bottleneck resolution capacity

(FEDA), 169BPM (business process modeling)

EDA and, 102interoperability and, 31-34

buses, message backbones, 151business extension as interoperability

driver, 28business functional requirements as

interoperability driver, 28

Ccase studies

airline flight control, 159-160ATCSCC software, 161FEDA, 167-187, 190-205ripple effect, 163-166

anti–money laundering SOA-EDAcase study, 209, 223-224



event clouds, 222event listeners, 232event producers, 222, 227,

231-232integrating with bank’s SOA, 251IT aspects of, 216, 219-221

joint planning with enterprisearchitecture teams, 252-253

matching requirements withinternal controls, riskmitigation and compliance,246-248, 251

optimizing ownership, 234-242rules engines, 222SOA governance, 254-258SOBA, 228, 231

ProdCo EDA-PI integration casestudy, 281

BI (business intelligence) in, 287event processing in, 288implementing, 292-293integration requirements,

284-287order fulfillment, 273-274productivity tools in, 275-276proposed EDA, 276-280sales proposals, 273-274target architecture for, 288,

291-292central control, reducing in

application designcarrying state inside events, 147-148controllers versus trusted executors,

142-146designing for unanticipated use, 148enabling autonomous behavior, 148

CEP (complex event processing), 22closed loop SOA, anti–money

laundering SOA-EDA case study, 258

code reusability, EDA and, 97-98commercial EDA, gaps in, 156-157

Index 297

complex event agents, 151complex event processing, 22compliance

EDA and, 107-108matching EDICTS requirements

with, 246-248, 251consciousness (enterprise nervous

systems), EDA as, 83-86content filtering, sample EDA suite,

154-156content-based routing, sample EDA

suite, 154-156context in EDA, 85context sensitivity, loose coupling, 71continuous auditing, anti–money

laundering SOA-EDA case study,217-221

contracts (services), SOA-EDAdevelopment, 124

controllersNew Order business process, role

in, 143-144trusted executors versus, 142-146

cost savings, SOA-EDA development, 134

costs of EDA, calculating, 153coupling

asynchronous messaging, 75defining, 60loose coupling

asynchronous messaging, 75component integration, 72-73context sensitivity, 71defining, 68maintainability, 69POS (point-of-sale) program

example, 68, 71

SOA development, 123software preconception, 68syncrhonous messaging, 74-76

SOA, loose coupling, 60-61synchronous messaging, 74-76tight coupling

asynchronous messaging, 75synchronous messaging, 74-76

customizable front-end interfaces(FEDA), 168

Ddata access, uniform methods in

SOA-EDA development, 135data enrichment, sample EDA

suite, 154data integrity (lineage) in SOA-EDA

development, 135data transformation, FEDA, 171,

178-180datasheets, sample EDA suite, 154dictionary of events, 150domain agents, 151dynamic determinism, EDA, 82dynamic system processing, 84

EEAI (enterprise application

integration), 29-30eBay, ethics and, 86EDA (event-driven architectures)

airline flight control case study, 159-160

ATCSCC software, 161

298 Index

FEDA, 167-187, 190-205ripple effect, 163-166

anti–money laundering SOA-EDAcase study, 209, 223-224



event clouds, 222event listeners, 232event producers, 222, 227,

231-232integrating with bank’s SOA, 251IT aspects of, 216, 219-221joint planning with enterprise




application design, reducing centralcontrol in, 142-148

benefits of, 82BPM (business process

modeling), 102compliance, 107-108context in, 85cost and benefit calculation in, 153defining, 1-3, 14-19, 35-36, 78development of, 9, 23

application integration, 29-30enterprise nervous systems, 3-5,

63-64

interoperability, 6-7, 24-34, 37SOA, 8

dynamic determinism, 82EDA-PI integration

potential benefits of, 267-272ProdCo case study, 273-281,

284-288, 291-293EDP and, 65-67enterprise agility, 101enterprise nervous systems, as

consciousness of, 83-86event consumers, 17event listeners, 17, 81event processors, 17, 22event producers, 16event publishers, 16event reactions, 18-19events

defining, 14detecting, 81exposing, 81-82system state in, 83

examples of, 1-2explicit EDA, 21functional agility, 101functions of, 78gaps in commercial EDA solutions,

156-157governments and, 103-105health-care services and, 106implementing, 149implicit EDA, 21inadequate human link in, 262IT and

code reusability, 97-98security monitoring, 92, 95service virtualization, 99

Index 299

software integration, 95-97system monitoring, 92

loose couplingcomponent integration, 72-73context sensitivity, 71maintainability, 69software preconception, 68

managingagent typing, 150event management, 149

messaging backbone, 19network traffic and, 152operational agility, 101overview of, 15-16paradigmatic EDA, assembling,

20-21parallel paradigm of, 149performance and, 152real-time analytics, 101reasons for not implementing, 152sample EDA suite

content filtering, 154-156content-based routing, 154-156data enrichment, 154datasheet for, 154ESB, 156

service requests, 128SOA

defining, 38-39governing, 39-42managing, 39, 42

SOA-EDA developmentagility in, 135business case scenarios, 136-137business value of services, 124cost savings, 134

data integrity (lineage) in, 135enterprise services, 116enterprise-level architecture

teams, 119ESB, 113-114, 125-128event service creation, 112granularity of services, 123long-term design strategies

for, 119long-term development

strategies, 122loose coupling, 123maintenance costs, 135management options, 130-132ROI (return on investment),

134, 137service brokers, 128-129service contracts, 124service design, 122service networks, 115-118steps of development, 120-121TCO (total cost of

ownership), 134uniform data access

methods in, 135strategic agility, 101system extensibility, 82system state in, 83web services, 58, 79

EDICTS (Event-Driven InternalControls Tracking System)

compatible development practices, 253

designing for long-term successdefining reference architectures,

242-244

300 Index

integrating with bank’s SOA, 251matching requirements with


optimizing ownership, 234-242joint planning with enterprise

architecture teams, 252-253SOA governance, 254-258

EDP (event-driven programming), 65defining, 66event listeners in, 66-67event publishers, 67event subscribers, 67

endpoints (service), SOA-EDAdevelopment, 115

enterprise agility, EDA and, 101enterprise architecture teams,

anti–money laundering SOA-EDA case study, 252-253

enterprise nervous systems, EDAas consciousness of, 83-86development of, 3-5, 63-64

enterprise services, 116enterprise-level architecture teams,

SOA development, 119ESB (enterprise service buses)

FEDA, 177management fabrics, 126-128sample EDA suite, 156SOA-EDA development, 113-114,

125-128ethics

eBay and, 86Internet and, 85

event clouds, anti–money launderingSOA-EDA case study, 222

event consumers, 17event listeners, 17

anti–money laundering SOA-EDAcase study, 232

detecting events, 81EDP, 66-67security monitoring, 95

event processors, 17CEP, 22event stream processing, 22ProdCo EDA-PI integration case

study, 288simple event processing, 22

event producers, 16, 222, 227, 231-232event publishers, 16, 67event services, creating, 112event stream processing, 22event subscribers, EDP, 67event-driven programming. See EDPevents

carrying state inside, 147-148data enrichment, 154defining, 1, 14dictionary of, 150EDA

detecting in, 81exposing in, 81-82

event consumers, 17event listeners, 17event processors, 17, 22event producers, 16event publishers, 16local event processing, FEDA, 171managing, 149reactions to, 18-19system state in EDA, 83web service life cycle in FEDA,

191-195

Index 301

executors (trusted), controllers versus,142-146

explicit EDA (event-drivenarchitectures), 21

extensibilityEDA, 82FEDA, 171

extensible front-end interfaces(FEDA), 168

FFAA (Federal Aviation

Administration), ATCSCCsoftware, 161

fabrics (management), services, 126-128

FEDA (flight event-drivenarchitecture), 167, 205

adding new users to, 168auditing, 169autonomic response, 168bottleneck analytics, 170bottleneck awareness, 169bottleneck resolution capacity, 169carrying state in, 181-182cost-effective integration, 171customizable front-end

interfaces, 168data transformation in, 171, 178-180enabling technology factors in,

174-175ESB federation in, 177event web service life cycles,

191-195extensibility, 171

extensible front-end interfaces, 168functional requirements, 168-170high-level architecture, 172-174local event processing, 171minimal impact on existing

systems, 171mitigation of risks, 198-199, 203-204organization in, 199-200project life cycle, 201-203project risks, 197real-time awareness, 168reliability, 169reporting, 169security, 169SOA governance in, 182-187,

190-196success metrics, 204-205system level communications, 169system requirements, 171“what-if” modeling, 169

filtering content, sample EDA suite,154-156

front-end interfaces (FEDA), 168functional agility, EDA and, 101

G–Hgoverning SOA, 39-42governments, EDA and, 103, 105granularity of services, SOA

development, 123

health-care services, EDA and, 106implicit EDA (event-driven

architectures), 21

302 Index

Iinfrastructure agents, 151integration

EAI, 29-30middleware, 29-30money laundering process, 211

internal controls, matching EDICTSrequirements with, 246-251

Internet, ethics and, 85interoperability

application integration, 29-30BPM and, 31-34defining, 26-27drivers of

business extension, 28business functional

requirements, 28EDA development, 6-7, 24-34long-term interoperability,

promoting, 37promoting, 37

ITanti–money laundering SOA-EDA

case study, 216, 219-221EDA and

code reusability, 97-98security monitoring, 92, 95service virtualization, 99software integration, 95-97system monitoring, 92

J–LJMS (Java Messaging Specification),

asynchronous messaging, 77

layering (money laundering process), 211

local event processing, FEDA, 171long-term interoperability,

promoting, 37loose coupling

asynchronous messaging, 75component integration, 72-73context sensitivity, 71defining, 68maintainability, 69POS (point-of-sale) program

example, 68, 71SOA, 60-61, 123software preconception, 68synchronous messaging, 74-76

Mmaintainability (loose coupling), 69maintenance costs, SOA-EDA

development, 135management fabrics, services, 126-128managing

EDAagent typing, 150event management, 149

events, 149SOA, 39, 42

message backbones, 19, 151message mediators, 77messages

asynchronous messagescoupling, 75JMS, 77message mediators, 77MOM, 77

Index 303

point-to-point messages, 76-77publish/subscribe messages, 76-77synchronous messages, coupling,

74-76messaging hubs, ESB

management fabrics, 126-128SOA-EDA development, 113-114,

125-128middleware, application integration,

29-30MOM (message-oriented-

middleware), asynchronousmessaging, 77

money launderinganti–money laundering SOA-EDA

case study, 209, 223-224compatible development

practices, 253defining reference architectures,

242-244event clouds, 222event listeners, 232event producers, 222, 227,

231-232integrating with bank’s SOA, 251IT aspects of, 216, 219, 221joint planning with enterprise




banks andauditing, 216, 219-221prevention, 214-216, 219-221risks involved, 212-213

process of, 211risks of, 212-213scope of the problem, 212

monitor agents, 151

N–ONaked Corporation, The, 85network traffic, EDA and, 152New Order business process,

controllers role in, 143-144

operational agility, EDA and, 101order fullfillment, ProdCo EDA-PI

integration case study, 273-274

Pparadigmatic EDA (event-driven

architectures), assembling, 20-21parallel paradigm of EDA

(event-driven architectures), 149performance

EDA, 152monitoring, anti–money laundering

SOA-EDA case study, 257-258persistent agents, 150PI (productivity infrastructure), 263

EDA-PI integrationpotential benefits of, 267-272ProdCo case study, 273-281,

284-288, 291-293

304 Index

importance of, 264overview of, 264-266potential of, 267process workflow, 264-266

placement (money launderingprocess), 211

point-to-point messaging, 76-77policy metadata repository,

anti–money launderingSOA-EDA case study, 257

POS (point-of-sale) programs, loosecoupling example, 68, 71

preconception, defining, 68prevention agents, 151processing events, FEDA, 171ProdCo EDA-PI integration case

study, 281BI (business intelligence) in, 287event processing in, 288implementing, 292-293integration requirements, 284-287order fulfillment, 273-274productivity tools in, 275-276proposed EDA, 276-280sales proposals, 273-274target architecture for, 288, 291-292

publish/subscribe messaging, 76-77

Q–Rreactions to events, 18-19real-time analytics, EDA and, 101real-time awareness (FEDA), 168reference architectures, defining in

EDICTS, 242-244registry, anti–money laundering

SOA-EDA case study, 256

reliability, FEDA, 169reporting, FEDA, 169reusing code, EDA and, 97-98ripple effect (airline flight control),

163-166risk mitigation, matching EDICTS

requirements with, 246-248, 251ROI (return on investment), SOA

development, 134, 137routing content, sample EDA suite,

154-156rules engines, anti–money laundering

SOA-EDA case study, 222

Ssales proposals, ProdCo EDA-PI

integration case study, 273-274security, FEDA, 169security monitoring

EDA and, 92, 95event listeners, 95

service brokers, 128-129service endpoints, SOA-EDA

development, 115service networks, SOA-EDA

development, 115-118service-based integration, 50service-orientation, defining, 49services

business value of, SOAdevelopment, 124

contracts, SOA development, 124defining, 49granularity of, SOA

development, 123management fabrics, 126, 128

Index 305

requests in EDA, 128SOA-EDA development,

creating, 122virtualization, EDA and, 99web services

event web service life cycles inFEDA, 191-195

management options, 133services versus, 51

simple agents, 150simple event processing, 22sleep state, event listeners in EDP, 67SOA (service-oriented

architectures), 47anti–money laundering SOA-EDA

case study, 209, 223-224compatible development

practices, 253defining reference architectures,

242-244event clouds, 222event listeners, 232event producers, 222, 227,

231-232integrating with bank’s SOA, 251IT aspects of, 216, 219-221joint planning with enterprise




benefits of, 48

buildingagility in, 135business case scenarios, 136-137business value of services, 124cost savings, 134data integrity (lineage) in, 135enterprise-level architecture

teams, 119ESB (enterprise service buses),

125-128granularity of services, 123long-term development

strategies, 122loose coupling, 123maintenance costs, 135management options, 130-132ROI (return on investment),

134, 137service brokers, 128-129service contracts, 124service design, 122steps of development, 120-121TCO (total cost of

ownership), 134uniform data access

methods in, 135defining, 38-39, 59development of, 48EDA creation, 8

enterprise services, 116ESB (enterprise service buses),

113-114event service creation, 112service networks, 115-118

evolution of, 118governing, 39-42, 182-187, 190-196long-term design strategies for, 119

306 Index

loose coupling in, 60-61managing, 39, 42service-orientation, defining, 49services

defining, 49service-based integration, 50web services versus, 51

web servicesservices versus, 51SOAP, 52-54UDDI, 58WSDL, 55-57

SOAP (Simple Object Access Protocol)intermediaries, anti–money

laundering SOA-EDA casestudy, 256-258

web services, 52-54, 79, 112SOBA (service-oriented business

applications), anti–moneylaundering SOA-EDA case study,228, 231

software integration, EDA and, 95-97software preconception (loose

coupling), 68specialty agents, 151state, carrying in

events, 147-148FEDA, 181-182

static system processing, 84strategic agility, EDA and, 101synchronous messaging, coupling,

74-76system extensibility, EDA, 82system level communication in

FEDA, 169system monitoring, EDA and, 92system state in EDA, 83

TTapscott, Don

ethics and the Internet, 85Naked Corporation, The, 85

TCO (total cost of ownership), SOAdevelopment, 134

tight couplingasynchronous messaging, 75synchronous messaging, 74-76

tightly coupled architectures, 31traffic (network), EDA and, 152transformation agents, 150transforming data, FEDA, 171,

178-180trusted executors versus controllers,

142-146

U–VUDDI (Universal Description,

Discovery, and Integration), 58, 256

unanticipated use, designing for, 148

virtualization (services), EDA and, 99

W–Zweb services

EDA and, 58enterprise services, 116event services

creating, 112life cycles in FEDA, 191-195

management options, 133

Index 307

message descriptions in WSDL, 125service networks, SOA-EDA

development, 115-118services versus, 51SOAP, 52-54, 79UDDI, 58WSDL, 55-57

“what-if” modeling (FEDA), 169WSDL (Web Services Description

Language), 55-57, 125

308 Index

Documents

Editor-in-Chief Project Editorptgmedia.pearsoncmg.com/images/9780321322111/samplepages/0… · But if EDA presents new challenges, it also emerges in an era of new opportunity. The