Oracle is now coming out with an event-driven architecture (EDA) based on Oracle's ability to support business...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
rules. What is the potential of an EDA, and how could DB2 help users to achieve the full benefits of an EDA?
The basics of an EDA
An EDA is about communications between software. A typical program communicates with another via APIs (application program interfaces), or, in the case of object-oriented programs and Web services, via messages that can span multiple systems. An event-driven application communicates with another event-driven application by publishing an "event," a message that is caused by a change in the state of the originating application. The message is delivered to all subscribing event-driven applications that have requested that type of event. An EDA is the software infrastructure that supports communications between event-driven applications.
In the real world, some version of an EDA has been around for 30 years -- the database. A database detects events corresponding to transactions that change key data. It determines what to do about those events by using business rules such as "if this customer tries to withdraw more than $1 million from his account, don't do it; instead, alert the bank manager and bar the doors." Stored procedures that perform "triggers" and "alerts" are the software that carries out actions in response to those events.
A trigger combines a set of criteria and a stored procedure to be invoked when the criteria are met. The stored procedure is a piece of application logic stored in the data store. Enterprises can use stored-procedure technology to store a data store's worth of alternative actions. Enterprises can use triggers to define business rules and determine actions to be taken when those rules are invoked.
An alert is a specialized stored procedure that delivers a message to an end user, programmer, administrator, and/or application. Enterprises may use alerts to notify executives or operators of mission-critical or business-critical events.
In the typical enterprise, these database-embedded business rules, triggers and alerts eliminate ambiguity about enterprise policy, enforce security, improve data quality and increase operational efficiency. Programmers find that business rules and stored procedures simplify programming and program maintenance, allow applications that are more complex and reduce programming errors. Business rules and stored procedures can be precompiled and optimized.
EDA and database
An EDA extends the event-driven power of a database; but it also offers the database's power to a wider range of applications.
By allowing multiple databases from multiple vendors to participate in a stream of "event" transactions, the EDA in effect multiplexes events and their responses across a wider range of corporate data. Thus, in combination with EII (enterprise information integration) or similar technology, the EDA could potentially use the same event to invoke multiple triggers and alerts from multiple databases, in a coordinated fashion, or improve performance for a given "event response" by choosing the database that can respond quickest.
At the same time, not all events of interest to a corporate strategist are captured by transactions on databases. By rewriting applications to detect key events and offer them up to the "event bus," users can improve their ability to detect events that databases did not capture and to process these events using the database's business rules and stored procedures.
Like an SOA, the EDA can use an Enterprise Service Bus (ESB) to do its heavy lifting. That is, the ESB can handle the specifics of the communications between event-generating application and event-receiving application, as well as publishing events (in a repository) and subscribing to types of events (in the same repository). The difference is that here, the messages being handled are events that may or may not be invocations of services.
The difference between SOA and EDA
An SOA thinks of communications between applications in terms of requests for services and responses to those requests. An EDA thinks of communications between applications in terms of published events that are reacted to by subscribing applications.
In the real world, SOA and EDA are complements. An EDA allows special handling of application communications that are of vital importance to the enterprise. An SOA extends flexible application communications across the Web. The combination of the two, using an ESB with events that invoke services, gives the user both SOA's benefits and the ability to react quickly to key events. But an SOA is not necessarily an EDA, and an EDA is not necessarily an SOA.
The business value of an EDA
In the short run, enterprises are most effective when they react effectively -- responding quickly and appropriately to external events such as surges or decreases in sales, or internal events such as monthly financial reports. In the long run, enterprises are especially effective if they proact strategically -- if they change their course based on a long-term strategy, and then drive that change of course throughout the organization, appropriately incorporating new responses to expected and unexpected events. In either case, one of the keys to mastery of the enterprise's environment is fast and effective response to events.
The business value of an EDA is that it extends a database's power to deliver effective reaction and strategic proaction across the enterprise's applications. Moreover, an EDA's flexibility to include new event sources and targets means that it can adapt more readily to new business needs than a database can.
EDA so far
While implementation of EDAs is not widespread at present, EDAs are already being used to speed up the supply chain and manufacturing by more quickly reacting just-in-time techniques, or to speed reaction to financial markets for hedging strategies. EDAs are also being used to speed up key business processes, as in Griffiths Waite's high-risk-loan approval process.
Oracle's EDA announcement
On June 19, 2006, Oracle announced a new EDA that supports applications reacting to events at the business level. Oracle's EDA Suite includes:
- Oracle Business Activity Monitoring (monitoring and analyzing events in the network).
- Oracle Enterprise Service Bus (an ESB enhanced to route and distribute events).
- Oracle Sensor Edge Server (analogous to a real-time operating system, taking inputs from physical devices such as RFID sensors and feeding them to the network and applications).
- Oracle Enterprise Messaging (messaging configured for events, e.g., with event-oriented definition of Quality of Service).
- Oracle Business Rules (a "rules engine" to allow users to define (or incorporate existing) business rules and run them efficiently).
Oracle's EDA allows users to leverage existing SOA and middleware technologies. Thus, Oracle Fusion middleware permits users to "hot plug" another application server or another messaging solution from another vendor (e.g., JBoss and IBM WebSphereMQ) while the system is running.
Where DB2 may fit
There is no reason that IBM could not deliver an EDA comparable to Oracle's, if it wished. IBM has its own business process management capabilities, ESB and RFID support, as well as integration with a vast array of SOA and WebSphere middleware technologies.
Moreover, in IBM's EDA or another one, DB2 can play a key role as a source of event handlers, business rules, triggers and alerts. In particular, IBM and IBM's DB2 customers have a cache of business rules and stored procedures fully as sophisticated and business-specific as Oracle's.
One key aspect of EDAs remains to be noted: taking full advantage of an EDA requires that the user (and vendor) begin to think of applications and business processes as sequences of events and reactions to those events -- a very different programmer and designer mindset. Because of this "culture shock," initial implementations of EDAs are likely to focus on areas where the notion of event-driven programming has already been accepted and absorbed: existing transactional applications that can now be expanded across data sources for wider data-gathering and better performance.
There is a correspondence here between users' acceptance of SOAs and users' acceptance of EDAs. It is clear that, five or six years down the pike, the majority of users' applications are not yet fully incorporated into an SOA -- much less business-critical applications. The EDA, therefore, may very well be five to 10 years from full implementation.
Nevertheless, the game is worth the candle. SOAs are allowing users to inhale a wider variety of information and invoke a wider variety of functionality to improve the enterprise. The EDA, for those who seek the "real-time enterprise," is the other shoe dropping. Once implemented, it improves the enterprise's ability to zero in on key data among this mass of new information, react to it effectively and proact strategically, and take all of these actions more rapidly. And IBM in general, and DB2 in particular, have strong cards to play in helping customers to implement EDAs.
About the author
Wayne Kernochan is president of Infostructure Associates, an affiliate of Valley View Ventures that aims to provide thought leadership and sound advice to both vendors and users of information technology. This document 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.