重磅推荐
《面向SOA的事件驱动架构设计与实现(英文版)》由泰勒、Angela Yochem、Les Phillips、Frank Martinez所著，说明了在SOA和Web Service应用中如何增强事件驱动架构。 本书描述了EDA环境中SOA基础设施、治理、安全的作用，介绍了EDA核心组件和EDA模式，说明了如何设计灵活的无状态事件，对突发的客户、供货商和业务合作者做出反应，介绍了定位技术和业务挑战，如项目管理和通信等。
【目录】
Foreword
Preface
Introduction
Event-Driven Architecture:A Working Definition
The峃ew嶦ra of Interoperability Dawns
The ETA for Your EDA
Endnotes
PART I THE THEORY OF EDA
Chapter 1 EDA:Opportunities and Obstacles
The Vortex
EDA:A Working Systemic Definition
The(Not So Smooth)Path to EDA
Defining Interoperability
Drivers of Interoperability
Application Integration:A Means to Interoperate
Interoperation and Business Process Management
Is There a Diet for All This Spaghetti?
How Architecture Promotes Integration
Management and Governance
Chapter Summary
Endnote
Chapter 2 SOA:The Building Blocks of EDA
Making You an Offer You Can`t Understand
SOA:The Big Picture
Defining Service
Service-Based Integration
Web Services
What Is SOA?
Loose Coupling in the SOA
Chapter Summary
Chapter 3 Characteristics of EDA
Firing Up the Corporate Neurons
Revisiting the Enterprise Nervous System
The Ideal EDA
BAM凙 Related Concept
Chapter Summary
Endnotes
Chapter 4 The Potential of EDA
Introduction
EDA`s Potential in Enterprise Computing
EDA and Enterprise Agility
EDA and Society`s Computing Needs
EDA and Compliance
Chapter Summary
Chapter 5 The SOA-EDA Connection
Getting Real
Event Services
The Service Network
Implementing the SOA and Service Network
How to Design an SOA
The Real岯ottom Line
【内容简介】
《面向SOA的事件驱动架构设计与实现》主要介绍事件驱动架构（Event-Driven Architecture,EDA）技术的理论与实践。在EDA理论部分，阐述了EDA的核心组件——事件消费者、事件生产者和消息基础设施等三个关键要素，以及EDA的三种基本模式，即事件处理、事件流处理和复杂事件处理等；后说明了EDA设计的关键点，即开放的互操作性，以及基于SOA实现EDA的技术途径。在EDA实践部分，利用航班飞行控制、反洗钱、生产力基础设施架构3个案例对EDA的应用进行了深入讨论，不仅有对案例背景和EDA需求的详尽介绍和分析，还有基于SOA（尤其是成熟的ESB技术）实现EDA的具体描述，具有比较大的实践指导意义，也是《面向SOA的事件驱动架构设计与实现》有特色的部分。
《面向SOA的事件驱动架构设计与实现》可作为研究生、企业技术人员了解和应用EDA的入门教材，也可供信息系统架构人员、高级软件工程师、应用科研人员等参考学习。
【免费在线读】
Introduction
Event-Driven Architecture: A Working De.nition
Event-driven architecture (EDA) falls into the maddening category of a technology paradigm that is half understood by many people who claim to know everything about it. Although we recognize that we, too, might not know absolutely everything there is to know about EDA, we believe that it is necessary to set out a working de.nition of EDA that we can adhere to throughout this book. Getting to an effective working de.ni-tion of EDA is challenging because EDA must be described at a suf.-ciently high level that is comprehensible to nontechnologists, but at the same time not so high level as to sound vague or irrelevant.
An event-driven architecture is one that has the ability to detect events and react intelligently to them. For our purposes―and we dis-cuss this in great detail later on―an event is a change in state that merits attention from systems. Brenda Michelson, a technology analyst, writes, “In an event-driven architecture, a notable thing happens inside or out-side your business, which disseminates immediately to all interested par-ties (human or automated). The interested parties evaluate the event, and optionally take action.”1
One of the simplest examples of an event-driven system is actually from the noncomputer world. It is known as a thermostat. The thermo-stat is a mechanical device that turns the heat on or off based on its pro-grammed reaction to an event, which is a change in temperature. The shift in temperature is the event, the “change in state” that triggers the reaction of the thermostat, which, in turn, affects the action of the heater.
We can see another simple example in the evolution of the automo-bile. Cars are becoming increasingly intelligent by reacting intelligently to their surroundings. If rain hits the windshield, the automobile recog-nizes the rain event and automatically turns on the windshield wipers,
Introduction
turns on the headlights, and adjusts the front windshield defroster. All of these things were formerly the driver’s responsibility, but now the car’s internal system uses its intelligence to react. An EDA is an architecture that acts in the same way: It detects events and reacts to them in an intel-ligent way. To be able to detect events and react to them intelligently, an EDA must have certain capabilities, including the ability to detect events, transmit messages among its components that an event has occurred, process the reaction to the event, and initiate the reaction to the event if that is called for. In generic architectural terms, these capa-bilities translate into the concepts of event producers, event consumers, messaging backbones, and event processors. These go by many different names in practice, and this is one of the great hurdles to getting a feel for what an EDA is at its core.
Many examples of EDAs occur in the realm of information systems, though most of the ones currently deployed are limited in scope. For example, if your credit card is simultaneously used in two separate geo-graphical locations, those two events can be “heard” by the credit card processing systems and examined for a potential fraud pattern. The credit card fraud detection EDA is set up to listen for events that indi-cate potential fraud and respond―or not respond―depending on a set of rules that are programmed into the event processors. If the charge occurring out of state is at a mail order merchant where you have shopped before, the system might not deem the event pattern to be a fraud. If the second charge is for a high-dollar value at a merchant where you have not shopped before, the EDA might trigger a response that places a warning or “watch” status on your credit card account. Or, the activity might prompt a person to call you and .nd out if you have lost your card.
Or, imagine that an FAA air traf.c control application needs to know the probability of rain in a certain location. At the same time, the Air Force needs the same data, as does NASA. Assuming that the weather data is collected and available on a server somewhere, it is possible to tightly couple that server, and the software running on it, with the FAA, Air Force, and NASA’s respective systems. Although this type of approach is frequently used, it is far easier to arrange for the weather application to publish the weather data and enable the subscribers (the FAA et al.) to get the data they need and use it however they need to use it. The weather status event of the weather application publishes the weather data so that the data subscribers can use it to drive the architec-ture. This is an event-driven architecture.
Event-Driven Architecture: A Working De.nition
In this EDA, the FAA, Air Force, and NASA are integrated with the weather system by virtue of the fact that there is no speci.c coupling between the applications. Of course, they exchange data, but the appli-cations are completely separate and have no inherent knowledge of one another. The developers do not need to know each other, and there is no need to coordinate. However, for it to work, they do need standards. To effectively disseminate and process events, the publisher and the sub-scriber might agree to use a commonly understood message format and a compatible transport mechanism.
One commonly used technology that is analogous to EDA is the Web itself. When you use a browser, you are initiating an integrated ses-sion with a remote system of which you have no speci.c knowledge. In all probability, you have no idea who programmed it, what language it’s written in, where it is, and so on. Yet, your browser can pull whatever information it is permitted to get and show it to you in a format that you can understand. The event of requesting the uniform resource locator (URL) triggers the action that results in the display of the Hypertext Markup Language (HTML) content in your browser window. As we develop our explanation of EDA, though, you will see that the Web is a very simple EDA.
An EDA consists of applications that are programmed to publish, subscribe, or take other actions upon events triggered by applications with which they share no formal coupling. For this reason, EDA has been likened to a “nervous system” for the enterprise.
The Enterprise Nervous System
Where would the IT industry be without metaphors? Even the idea of using the word architecture to describe how Byzantine networks of hardware, software, and data are con.gured shows how reliant we are on abstraction to achieve an understanding of what we are trying to accom-plish in enterprise IT. In the spirit of metaphors, then, we shall borrow a concept from human physiology, the central nervous system, to further our understanding of EDA.
If your cat steps on your toe, how do you know it? How do you know it’s a cat, and not a lion? You might want to pet the cat, but shoot the lion. When the cat’s paw presses against your toe, the nerve cells in your toe .re off a signal to your brain saying, “Hey, someone stepped on my toe.” Also, they send a message that says something like, “It doesn’t hurt that much” and “It was probably a cat.” Or, if you saw the cat, the signals from
Introduction
your optic nerve are synthesized with those from your toe, each invoking your mental data store of animals and likely toe steppers, and you should know pretty quickly that it was, indeed, a cat that stepped on your toe. Your central nervous system is a massively complex set of sensory recep-tors, wires, and integration points, known as synapses. The nervous sys-tem is critical to your functioning and survival in the world. Just imagine if your central nervous system didn’t work well and you confused the cat with the lion. As Figure I.1 shows, you might shoot your cat and pet the lion, which would then eat you.
Our enterprises have their own nervous systems, too. Our Web sites, enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, databases, and network infrastructures, for example, all work to feed the corporate equivalent of sensory infor-mation to the corporate “brain.” The corporate brain, in turn, assesses the input and reacts. Of course, the corporate brain might contain a few actual brains as well, in the form of employees, but their sensory input is determined by the enterprise nervous system. For example, if there is an increase in cash withdrawals at a bank, the banking systems, acting like nerve sensors in our toe, .re off withdrawal data to the corporate brain. The neurons in the corporate brain then route the data to its destination, which could be an automated bank cash reserve management system, the executive management team of the bank, or a combination. As our
Event-Driven Architecture: A Working De.nition
brain assesses and reacts to the cat stepping on our toe, the corporate brain of the bank must assess the input of the withdrawal spike and react.
If our enterprises were living beings, most of them would need some pretty intensive neurological care. Unlike a well-functioning person, whose nervous system can learn how to react to different stimuli and determine the best way to handle a given situation based on sensory input and mental processing, the typical enterprise has a nervous system that is hardwired to react in a speci.c set of ways that might not be ideal for every situation. In the cat-on-toe situation, most of our enterprises would probably expect the worst and then shoot in the general direction of the cat. Or, perhaps a more realistic version of the metaphor―the enterprise wouldn’t even know that anything had stepped on its toe, or that it even had a toe. It would be completely unaware most likely because it was never given the ability to be aware.
Like the person whose knee-jerk reaction is to shoot the cat regard-less of what is going on, most of our enterprises have a nervous system that is not well set up to receive the data equivalent of sensory input, process it, know what it is, and react in an appropriate way. Event-driven architecture is an approach to IT that gives the enterprise the ability to improve its nervous system and have a level of adaptability and aware-ness that it needs. This is what we typically hear described as agility: the ability to react intelligently to stimuli and also continually reshape the reaction as circumstances change.
Data is powerful, if you can see it and know what to do with it. To paraphrase Levitt and Dubner and their great book, Freakonomics, an EDA provides potential adaptation data that exists in streams that we can’t possibly see on our own. Levitt and Dubner characterize the Inter-net as a “gigantic horseshoe magnet waved over an endless sea of haystacks, plucking the needle out of each one.” Similarly, an EDA―the nervous system―gives us a way to acquire data and to make the data we have meaningful. For example, if we knew that every day we experience what 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 to assume that it’s not a lion. That’s .ne, 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, and reacting logic processors to work together. In broad terms, this is known as interoperation, and it is the heart of the new EDA discussion going on today.
Introduction
The “New” Era of Interoperability Dawns
Reading about EDA as a “new” idea might give you a sense of déjà vu. As we saw with the familiar credit card fraud example, EDA is not a new concept. However, the current crop of EDAs uses proprietary standards for communication, and although they work well, they are, in effect, tightly coupled EDAs that can only share information among systems that use a compatible standard. For instance, it is possible to set up a fairly 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 the same 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 rely on tight coupling.
The quest for a well-functioning enterprise nervous system has been the catalyst for the development of EDA for many years. Why, then, is EDA receiving such renewed and intense interest today? The reason has to do with the explosion in interoperability and the standardization of data 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 the systems cannot communicate with one another. Existing EDA setups are invariably tightly constrained and narrow in their functionality because it has been so dif.cult, or costly, to achieve the level of interoperation of EDA components needed for any kind of dynamic or complex EDA functionality. 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 that are far more intelligent, dynamic, and far-reaching than ever before.
To put the interoperability evolution in context, we will share a lunch conversation we had recently with a man who had been responsible for designing and implementing the basic underpinnings of the worldwide airline reservation and automated teller machine infrastructures. In the last few years, he has been involved in other pursuits, so he was eager to learn about SOA and EDA, the new tech trends that he had been hearing so much about in the industry media.
When we explained how the related concepts of SOA and EDA allowed, for the .rst time ever, truly open interoperation among heterogeneous software applications, regardless of operating system, network
The “New” Era of Interoperability Dawns
protocol, or programming language, he gave us a perplexed look. “That’s new?” he asked with a slight smirk. “That idea has been around since 1961.”
And, of course, he was right. The idea of open interoperability has been in the air for decades. Just like the automobiles have been around since the late 1800s. Even today, we still use a combustion engine to drive the wheels, so the essence hasn’t changed much. However, never before have cars been so reactive to our needs and their surroundings.
The same evolution is true for the software and the circumstances that we .nd ourselves in now, in 2009. Over the last eight years, from 2001 to 2009, we have seen an unprecedented shift in the IT industry toward the use of open standards for the purpose of integrating diverse software applications. Also, more and more companies are exposing their data in a standardized fashion further expanding the circle of opportunity.
This all started back in 2001…. An unusually broad group of major IT companies, including IBM, Oracle, Microsoft, BEA, and others, agreed to conform to a speci.c 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 exchange data or procedure calls with any other application, regardless of location, network, operating system, or programming language.
Speci.cally, the major standards that were rati.ed included Simple Object Access Protocol (SOAP), which is the message formatting stan-dard, Web Services Description Language (WSDL), which sets out a standard document format with which to describe a Web service, and Universal Description, Discovery, and Integration (UDDI), a Web serv-ices registry application programming interface (API), that are available for use in a particular domain.
Thus, Web services are software-based interfaces that are univer-sally understandable, self-describing, and universally discoverable. As our colleague Jnan Dash, the legendary lead engineer of the Oracle Database, puts it, the combination of the Internet and Web services makes possible a kind of “universal dial tone” for all applications. (The Internet 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 C to 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
