What follows is my podcast with Dr. K. Mani Chandy, the Simon Ramo Professor of Computer Science at the California Institute of Technology, in which we discuss event driven architecture and how it relates to SOA, which Mani will also be covering in-depth at the ebizQ's SOA in Action Virtual Conference, coming this October 28th and 29th.
Listen to or download the 11:13 podcast below:
Download file
---TRANSCRIPT---
First of all, can you just give me a brief history of Event Driven Architecture?
Yeah, Event-driven architecture or EDA has two parents. One is Enterprise Application Integration and the other is sense and response systems. So the first parent EAI has an emphasis on loose coupling. So client server systems primarily use request reply mechanisms to communicate. The client makes a request and the server replies. And often the request reply interaction is transactional. By contrast, interactions and EDA are asynchronous. An agent sends a message or deposits an item of data in the repository and the creator of the data object does not make a request to a specific service for an action. The creator just deposits the message, the data object in some place. And clients, or servers, or requestors get that information and then respond appropriately.
So EDA appears in the 1970s in message queuing systems and later in enterprise service buses and this is the EAI parent. The other parent is sense and response. So sense and response systems detect critical events and respond to them in time sensitive manner. And developers of defense systems have been pioneers in this area. In the last decade, many companies have developed sense and respond applications in finance particularly in trading. Now however, sense and response systems are being used in every aspect of life including management of water, food, energy, security, health and so on. So that's where EDA came from.
What are the differences between EDA and SOA?
Well, EDA and SOA are complementary. The SOA in its abstract definition is a modular architecture. So the emphasis on modularity and the modules and encapsulates services. However, almost all discussions about how services are invoked in SOA are couched in terms of client server request replying. The fundamental principles of modularity in SOA apply to EDA as well. So if we think in terms of modularity they're very complementary architectures. As said earlier, the emphasis of EDA is on a asynchrony.
So producers of information put data out there into space and consumers are given copies of data object relevant to them. The emphasis is on the asynchronous communication and there are many different ways of connecting producers and consumers. So EDA is different from SOA for those people who define SOA primarily in terms of synchronous, request reply, client server interactions. EDA is complementary to SOA for those people who think of SOA primarily in terms of a modular architecture where the modules encapsulate different types of services.
Now I would imagine that an enterprise listening to this probably wants just to know so exactly, what are the cost benefits of EDA as compared to SOA?
Well, there are several costs and benefits to EDA some of them apply to SOA as well. So Roy Schulte and I classify them using the acronym "REACTS", R-E-A-C-T-S, after the first letters of each category. Now, I'll just run through them very quickly. So "R" is for Relevance. So data pushed to you by an EDA application may not be relevant to what you are doing at that point. For example, you may be interrupted by an alert about an issue in marketing while you're immersed in solving an engineering problem. In this case, the alert is a distraction it's even a nuisance. The problem is that the EDA application doesn't know your current context, its guessing what your context is.
By contrast, in request reply interactions, the server doesn't need to estimate the client's context because the client specifies exactly what the client wants. The benefit of EDA, the benefit asynchrony here is that the system is continuously working on your behalf without your asking it to do something for you that are "E" for effort and that's the amount of effort that the business user has to invest to get the quality of application that helps the business user make decisions. Again, I want to emphasize how important the business user is in actually using an EDA application. It's primarily for business and not primarily for IT.
"A" is for the accuracy of the data. For example, a false positive warning, an inaccurate warning about a tsunami will result in beaches being cleared unnecessarily and a false positive warning about fraud will cause credit cards to be suspended unnecessarily. "C" is for completeness. You must gain complete situation awareness from the data pushed to you. The system must help ensure that the CFO is aware of serious fraud. It must ensure that IT is aware of intrusion into its network, that's where "C" comes in. "T" is for timeliness. And of course, there's not much to be said about that.
And "S" is for security. So security is particularly important in EDA applications because these applications make entrance into the business system available to multiple points. So the smart grid is a good example of an EDA application where the grid has connections to homes and all across the country and potential hackers can enter the network through these multiple points. Now if you compare the REACTS categories to those in SOA, you get similar things but not as intensely present in SOA as in EDA.
Do you see the use of EDA becoming widespread in enterprises?
Yes, indeed I do for several reasons. Again, I use an acronym to remember these reasons. The acronym is "PC cubed". So price, pervasiveness and performance are part of a technology push and connectedness, celerity, speed, and complexity, are part of the consumer pull. And I'll just run them again very briefly. So the price of data sources whether they are sensors or RSS feeds or other kinds of data sources is getting very low even vanishingly small, a lot of them free. For example, the price of an exometer might have been, oh, a couple hundred dollar a few years ago and is now in the $80 range because they're been used in cell phones and laptops and many other places. So prices of data sources is coming down. They're also getting pervasive; they're all over the place. And the kinds of sources whether you're looking for news, articles, information about celebrities, blogs, they're pervasive; they're everywhere.
The performance of these devices in computers as you know, are always getting better so that's the three "Ps". Now the "Cs" that are driving the consumer to ask for more so one is connectedness. When the consumer is connected by a cell phone, laptops all over the U.S. and indeed all over the world. Celerity, they're expecting much quicker response from business, much quicker response from each, other certain places like Facebook, they're keeping track of what each other is doing all the time and those expectations carry over from social networks or business. And finally, they're looking for much more complex kinds of interactions, much more complex kinds of events.
Of course, in finance, we see really complex events where you're trying to detect patterns of stock prices and relate them to commodity prices. But you also see complex events in consumer applications where you'd like to know when a given item becomes cheap with one vendor versus another and there's expectations from the community, the consumer community about these three things: connectedness, celerity, and complexity. So these collections of things, these PC3 things push for price, pervasiveness, performance and demand from a connectedness, celerity, and complexity will keep driving use of EDA both in the enterprise and the consumer space.
What do you see for future of both EDA and SOA?
I see a great opportunity for both in the next, I say, 20 years starting now. And again, I want to emphasize that I see EDA and SOA as complementary and I really see them being used in all aspects of daily life. I mean management of food, water, energy, health, security and logistics and I can go through each of them in some detail. And what we call smart systems. A lot of talk about smart systems and smart system architectures are fundamentally based on principles from EDA and SOA. And the benefits of these event-driven architecture applications will be directly visible to the business, they'll be directly visible to the customer and so I think acceptance of these applications and demand for these applications will grow virally and so I see a great future for them.
Great to know. To those listening, I recommend you pick up Mani's book Event Processing: Designing IT Systems for Agile Companies. Also, make sure you check out ebizQ's upcoming SOA in Action Virtual Conference.
Leave a comment