Event driven architecture (EDA) may change the face of service-oriented architecture -- and all of IT for that matter -- as we know it. That's the view of John Bates, vice president of Apama Products and researcher at Cambridge University, who recently spoke with SearchWebService's Rich Seeley.Today, data is static, and queries are dynamic. In event-driven architecture, data is dynamic, and queries are static.
That sounds like an awfully bold claim. In fact, we've heard these same words used many times before, especially over the past 15 years. "(Fill in the blank) is going to change the face of computing as we know it."
Is there anything different going on here? Bates is the scientist who helped pioneer the event-driven technology. He said that SOA has already proven a disruptive force in the world of IT, but adding complex event processing (CEP) to it could create "a new physics of computing," he said.
As Bates explained it in the article, EDA is about the data and what happens to it. Data has traditionally been stored and indexed, and basically sits there until its queried by users and accessed by applications:
Is EDA the next evolution of SOA? As I've mentioned in previous posts, Jack van Hoof and Brenda Michelson very aptly describe what to expect with event driven architecture, or EDA.
"Data is static, and queries are dynamic." In event-driven SOA, however, data is constantly on the move. "The rules that you're using to monitor the data and take action are fairly static, and it's the data that's dynamic. The data is continuously changing. So you have to structure your software to take into account that paradigm shift."
Jack van Hoof wrote that EDA delivers the loose coupling that is only promised -- but not delivered -- by SOA. "EDA is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message."
Brenda Michelson says EDA is not the next evolution for SOA, but an architecture that can effectively work in conjunction with SOA. Brenda has another, more holistic, term for where things are evolving: "business driven architecture." She observes the "most viable, agile architectures will be comprised of a blend of architecture strategies, including (but not limited to) service-oriented architecture, event-driven architecture, process-based architecture, federated information, enterprise integration and open source adoption. How you blend, depends on your business."
Bates feels EDA alone will soon be a force to be reckoned with. The technology extends "where you're actually going to compose complex distributed systems from components that produce and consume events," he said. "At the moment, most complex event processing applications are single-point applications like algorithmic trading or telecommunications monitoring. We're heading toward a world with SOA whereby you might have multiple different event-based systems cooperating in bigger event-based business processes. This would be something like your trading system is sending events, which may be picked up by your risk management system, which may be picked up by your compliance system."
Perhaps EDA will become a greater part of the lexicon over the coming months and years as vendors look for the Next Big Thing to glom on to. After all, 'SOA' is probably getting stale -- and perhaps a bit overused -- as a marketing pitch.