Excerpts

Preface About This Book As professionals in the enterprise architecture field, we have observed the recent and spectacular rise of the concept of Service-Oriented Architecture (SOA) with excitement tempered by concern. The new standards-based architectural paradigm promises great advances in interoperability amongst 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 possible the realization of Event-Driven Architecture (EDA), an approach to enterprise architecture that yields a high level of agility by increasing systems' awareness and intelligent responses to relevant events. At the same time, it became clear to us that the steps required to design and deploy an EDA, or an SOA, its master set of architectural characteristics, were far from obvious. Even going beyond the fact that the technology and standards are immature and thus challenging, the practice of , uniting software with an overarching standards-based approach that extends outside the enterprise is a new field, lacking in many of the guiding principles of infrastructure, governance, and best practices that hold together most traditional forms of architecture and development. For better or worse, some software vendors are now bringing what they call EDA suites to market. However, the commercial offerings in EDA tend to be quite narrowly defined and vendor-centric. As such, they are inadequate on their own to offer much in the way of instruction on the overall best practices required for EDA. We perceive a need amongst architects for a book that combines both the theory of EDA - the grand vision that lead to its formation and the essential nature of the paradigm - with a practical look at building an EDA over an SOA implementation in the real world. This book is neither all theory nor all practice. It is a blend, with the idea that true success with EDA depends on a good understanding of both aspects of the paradigm. To understand how this book is set up and what it contains, we thought it would make sense first to take a quick look at the definition, history, and context of EDA and SOA. These two related architectural styles are not as new as they seem, though recent developments in standards have lead to breakthroughs in their potential realization. Inside This Book: The Path to EDA Even for a lot of experienced architects and developers, the implicit connection between EDA and SOA has not been intuitively obvious. A lot of IT pros react to SOA with a sentiment akin to, "That's really cool. Now what?" These questions are completely legitimate. Imagine someone handing you a violin and declaring, "Oh, good, now I get to hear Mozart." That person is making several assumptions, including that you know what the violin is, how to play it and how to play Mozart in particular. In many IT situations, it is not always evident how loose coupling and a service-orientation will take you to an EDA. If your boss drops a VisualStudio.Net pack on your desk and says, "Now you will deliver an EDA," you may not necessarily know how to get from here to there. That is purpose of this book. Much of this book is dedicated to helping you understand where the rubber meets the road in turning the vision of EDA into a reality. In so doing, we will delve into detail on the subject of SOA, providing the essential building blocks of the most versatile and effective EDAs. We will address one 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 achievement of business goals that EDA enables using the actual technologies that comprise SOA? The leap from Web services and SOA to the fulfillment of EDA, and its attendant agility and IT cost savings requires some serious discipline. Part I - The Theory of EDA This book consists of two parts. Part I, The Theory of EDA, covers the theoretical aspects of EDA. The path to EDA, which we will guide you through in this book, starts with an understanding of what EDA is. Part I begins with a thorough theoretical definition of EDA. We will cover the core components of EDA, such as event consumers and producers, message backbones, web service transport and so on. We will also describe the basic patterns of EDA, including Simple Event Processing, Event Stream Processing, and Complex Event Processing. From this definition, we will then explore the current context of EDA, which is the jungle of interoperability challenges that we all face in large enterprises. Having thus set up the situation that we face: we want EDA (or at least, we should consider it), we see how difficult it can be to attain. Enter SOA, and its open interoperability, which paves the way for the realization of EDA. In addition to defining EDA, we will explore the SOA-EDA connection in depth. In our view, any serious attempt to develop an EDA today will rely on the use of SOA technology as they are emerging in the marketplace. The EDA of tomorrow will run on Web Services and Enterprise Service Buses. The EDA components - the event producers, consumers, and processors, will all be Web Services. We will flesh out this vision of EDA. The conclusion of Part I will consist of examples of EDAs and how they might function. We will explore examples of how businesses and other organizations might ideally use EDA to further their objectives. This set of examples will provide a transition to Part II of the book, which moves you into the reality of EDA and how it might be approached in an actual enterprise setting. Part II - EDA in Practice Part II begins with Chapter 6,Thinking EDA. This chapter explores ways to identify the ideal use of an EDA, or a partial EDA in realizing a set of business objectives. Chapters 7 and beyond present a set of case studies of EDA. Some of these case studies are based on real companies. Others are partially hypothetical, but based on real life experiences we have had in the world of enterprise architecture. In each case study, we will describe the organizations involved as well as the technological and business challenges and objectives that they have. We will look at the ways in which the business and technological situation would either benefit from an EDA approach. We will look at how the practical issues that arise in its design and implementation. Our goal is to include, where relevant, some organization and non IT issues, such as project management and communication. Of course, we will get into depth on the technologies required to birth the EDA. Throughout the case studies, we will look at a number of related topics in the field of enterprise architecture that have relevance for learning about EDA. These include SOA infrastructure, governance, and security. Wherever possible, we will try to point out business issues that are relevant, but perhaps not apparent to the technology reader, as well as technology issues that may not be noticed by the business reader. One of our other goals is to instill in you a good sense of when to use an EDA approach and when not to, for the paradigm is not a panacea for all IT and business problems. This issue reminds of the story of a man who once approached a famous surgeon and said, "You make more money in a week than I make in a year. I don't think it's fair. Is what you do so special?" The surgeon replied, "Surgery itself isn't that complicated. I could probably teach you to do it in a few weeks. What takes the training and skill is knowing when not to operate, and what to do when something goes wrong. Learning those two things can take years." So it is with EDA. Developing a Web service is not hard for an experienced developer. Knowing how to use the functions of an SOA to create an EDA, though, is another matter. And, like the surgeon, you would be well served by understanding when to use and not use the EDA approach. If you take away nothing else from this book, consider that there are many cases where an EDA is not the optimal solution to a business issue. Who Should Read This Book, and How They Should Read it If you're holding this book in your hand, you are probably involved with information technology. If you are not in technology, we really admire your desire to be a broadly informed citizen. We have written this book in fairly deep, but not excessively detailed technical language. This is not a book that is awash in code or extensive jargon. We have made the choice to skip the deep, deep techie language because of the likely blend of readers that we expect to find the subject of EDA of interest to their work. EDA itself is an area that is inherently interdisciplinary. EDA naturally throws together developers, line of business people, IT managers, security specialists, architects, and network operations people. There is probably a whole EDA book for each of those disciplines. Luckily for us, someone else will write them. We wanted to present the topic in a unified approach that a multiplicity of readers could absorb. Our other guess is that you probably work at a large organization, or with an entity that interfaces with large organizations. Whether you work at a corporation, public sector organization, or educational institution, the issues for EDA are the same. We come from the corporate world, so we have a tendency to talk about "business value" a lot. If you can't relate to this, we are sorry, but for stylistic reasons we need to use just one measure of efficiency, and in our world, that measure is usually dollars. So, when we talk about "business value", we mean the economy of effort required to produce a result. It's a concept that can translate into any organizational agenda. (c) Copyright Pearson Education. All rights reserved. Excerpted from Event-Driven Architecture: How SOA Enables the Real-Time Enterprise by Angela Yochem, Les Phillips, Frank Martinez, Hugh Taylor All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.