Primer: Event-Driven Architecture

What is it?

One of the few instances in which the real-world benefits of a technology came before the hype. The term “event-driven architecture” refers to any applications that react intelligently to changes in conditions, whether that change is the impending failure of a hard drive or a sudden change in stock price.

Is it a product?

Not yet. Companies such as Rhysome and Neon Systems sell development tools designed to help programmers build event-driven software; more powerful tools are on the way from IBM, BEA Systems, Microsoft and others that will make it easier for event-driven applications to communicate using standardized protocols. Event-driven architecture is more a set of guidelines than a product. The active ingredient: a small piece of software called an agent that can sit on a particular machine and watch for something to happen. In a systems-management system, it could be watching for a hard drive to fail. On a Web server, it could be waiting for a customer to push the “Buy” button.

Can’t any application do that?

Probably, but most application techniques rely on a request-reply process in which they send a message to other applications asking for some action or data, then have to wait for the reply before doing anything.

Rather than wait for one activity, agents can launch several responses, each of which can be completed independently, often with no further action from the agent. Agents can also be told to watch for a range of events that may or may not happen, and may happen in an order that’s hard to predict.

“You could do this before, but it took a heroic effort,” says Ray Schulte, vice president and research team leader for application integration at Gartner Inc. “So that was limited to a few high-payback applications like trading.”

So what’s the goal?

As the technology becomes more sophisticated and standards are certified, agent-based systems will help companies actively manage and maintain their technology as well as business processes. This task is now too difficult and expensive to develop in other ways.

So why is this a big deal now?

As Web services become more capable and popular, their strengths and weaknesses are more apparent. They could allow an unprecedented amount of sophisticated communication among business applications, but that communication would only be as reliable as the medium and the languages through which they communicate. The languages are easy to use but don’t have the bulletproof reliability that message-oriented middleware provides. And the medium—well, the medium is the Internet.

Vendors are trying to make event-driven development easier by adding communications-broker software called Enterprise Services Buses to their portal software. ESBs will use standardized protocols to let event-driven applications communicate and make them as reliable as middleware-based applications.

ESBs and the standards they’ll rely on are still at least six months off, however, so companies interested in events will for now have to stick with tools and techniques that come out of a programmer’s lair, not packaged products that saturate with sizzle before substance.