Event-driven architectures: Understanding concepts, benefits and the bottom line for data management |
 |
By Wayne Kernochan, SearchDataManagement.com contributor
14 Oct 2008 | SearchDataManagement.com |
|
|
What is an event-driven architecture (EDA) all about?
To appreciate the benefits of EDA, it first helps to understand it historically. Event processing has been with us almost as long as there have been databases. Transactions fired at a database are events, and the database filters those events according to business rules that tell the database which events should trigger an action and what that action should be (usually the action is encoded in a stored procedure). Systems management follows much the same pattern: lots of little agents monitoring for events, which are sent back as alerts to a central site, which in turn reports the events and can semi-automatically decide whether to respond and invoke specific software for each case.
What is new over the last few years is the idea of a service-oriented architecture (SOA) that spans an enterprise network using standardized software interfaces. The basis of an SOA is often an enterprise service bus (ESB), which acts to route calls from Web service consumer code, such as a Web browser, to Web service provider code, such as an enterprise application.
This means that the ESB sees all major interactions between software, and as each call (represented as a "message") passes through the ESB, the ESB has the opportunity to do event processing to it: either to route it to an event handler or apply its own. To put it another way, the event-enabled ESB can now see all the events already flying back and forth to and from systems management software, databases and specific applications for specific types of events.
Then it can filter them, report on them and act on them.
Event-driven architecture's true value
Conceptually, an EDA is any loosely coupled middleware that focuses on handling events. However, in the real world, the ESB offers a platform on top of which an EDA is much easier to build – so, practically speaking, an EDA is an event-enabled ESB.
An EDA's true value lies not in taking over the handling of the events that existing applications are designed to process. Granted, just as in SOA, implementing this kind of loosely coupled, standardized architecture allows easier event-handler connectivity and more consistent use of corporate standards in security and business rules. An EDA really shines, however, when it comes to combining events of different types.
An EDA moves event processing out of hard-coded existing applications to the enterprise level. That enables a developer to write enterprise-spanning applications to combine, say, the alert that an important sale has taken place and the alert that you are out of inventory in that product. By writing applications on top of this distributed platform, the developer can choose which events to handle (e.g., complex event processing). Developers can also add alerts and real-time critical reports to existing applications that have none. Even more interesting, they can do things like set up an automated response loop to detect, take-initial-actions and alert people to handle critical business situations faster than a human-based business process.
In the second part of this article, find out more about event-driven architectures' implications for enterprises and data management professionals.
About Infostructure Associates:
Infostructure Associates is an affiliate of Valley View Ventures that aims to provide thought leadership and sound advice to both vendors and users of information technology. This article is the result of Infostructure Associates' sponsored research. Infostructure Associates believes that its findings are objective and represent the best analysis available at the time of publication.
|
|
|
|
