Event-driven architecture poised for wide adoption

LOS ANGELES -- Just as many IT shops are starting to get their arms around the service-oriented architecture (SOA) approach now that Web services standards are emerging, there's already a "next big thing" on the development horizon, according to Gartner Inc.

Four years from now, "mere mortals" will begin to adopt an event-driven architecture (EDA) for the sort of complex event processing that has been attempted only by software gurus building operating systems or systems management tools, and sophisticated developers at financial institutions, predicted Roy Schulte, an analyst at Stamford, Conn.-based Gartner, which held its Web Services and Application Conference here last week.

Fortunately for IT shops, the EDA approach is complementary to SOA, which forward-thinking IT shops are starting to employ in greater numbers as they forge ahead with Web services. Taking an SOA-based approach, developers build an application by assembling "services," or software components that define reusable business functions.

One of the main advantages of the SOA approach is that by building standards-based interfaces between components, developers can incrementally construct applications and swap out, reuse and modify components without having to concern themselves with their inner workings. Those who build Web services typically describe the interfaces using the Web Services Definition Language and send XML-based messages between components using SOAP over HTTP.

But Schulte said connecting services occurs in a linear, predictable sequence, whereas an event-driven architecture allows for multiple, less predictable, asynchronous events to happen in parallel and trigger a single action.

Simple event-driven processing has been in common use for at least 10 years with technology such as IBM's or Tibco Software Inc.'s message-oriented middleware and, in the past few years, message-driven Enterprise JavaBeans, he noted.

But Schulte predicted that complex event processing (CEP) will start to become mainstream in 2007, as application developers and systems and business analysts strive to do more business in real time. Paving the way for the trend will be faster networks, the arrival of general-purpose event management software tools and the emergence of standards for event processing beginning in 2005, he said.

Hints that CEP will become mainstream include Palo Alto, Calif.-based Tibco's acquisition of Praja Inc. and IBM's work on event-broker technology, Schulte claimed. "It's obviously the first step for IBM, and the next step will be complex event processing," he said.

David Luckham, a professor of electrical engineering at Stanford University and author of a book on CEP, The Power of Events, said the goal of CEP is rather simple: delivering understandable information about what's happening in IT systems. That information, in turn, can be used for a variety of purposes, such as detecting unusual activity, improving security and recognizing advantageous scenarios in CRM and supply-chain systems.

"The events in IT systems contain untapped information. CEP lets you extract it and use it in ways you want to," he said.

Luckham predicted that CEP will start creeping into Web services, middleware and application servers in 2005. By 2008, he foresees the emergence of CEP standards, languages and complex event-pattern search engines. Ubiquity of CEP will come in 2012, he forecasted.

To prepare for EDA, Schulte advised companies to look at their application requirements to see if there are places where they could do simple event processing instead of SOA to design part of an application. Leading-edge companies should also look to implement complex event processing for applications that bring a competitive advantage, he said.

Meanwhile, users who still haven't adopted SOA are trying to sort it all out. "Before you get time to deploy one thing, the next thing's already out," said Vito Iannuzzelli, a senior systems architect at New Jersey Manufacturers Insurance Co. in West Trenton, N.J.

Complementary Development Approaches

SERVICE-ORIENTED ARCHITECTURE (SOA) Service: A software component, or collection of software components, that implements a reusable business function, such as adding a new customer or looking up a customer's account balance. Service-oriented architecture: An approach for designing and building applications that tie together services, which are defined by their interfaces. The SOA approach has gained favor with companies building standards-based Web services interfaces to new and existing applications to enable them to interoperate or be combined into a new composite application. An SOA-based application consists of business components that supply services and other programs that act as clients, or "consumers," of those services. In a Web services scenario, the communication between the service consumer and the service is typically done via request-response, through XML-based messages sent via the Simple Object Access Protocol over HTTP. Because the components are loosely coupled, developers can swap one component for another without concern about the inner workings. The SOA approach stands in stark contrast to a monolithic architecture, which is characterized by tight dependence between all parts of the application. Benefits: Eases incremental development and maintenance of large distributed applications. Allows companies to reconfigure applications without rewriting much code or changing databases. Promotes reuse of business components and data in multiple applications and for multiple end-user access channels (including mobile, Web, desktop and batch program clients). Simplifies integration by introducing standards and separating steps of wrapping, layering and composing. Limitations: Incomplete standards, so all programs must either use low-function, lowest-common-denominator standard middleware (such as SOAP), adopt the same middleware product from one vendor or use cumbersome gateways between disparate middleware products. Difficulties associated with reusing services among disparate development teams. Does not eliminate the need for integration technology to cope with the semantic differences between applications. Many application-specific services cannot be reused. EVENT-DRIVEN ARCHITECTURE (EDA) Business event: A change in the state of an enterprise. Software event: An object that is a record of an activity, such as the opening of a customer account or the placing of an order. It's not what happened; it's a documentation of what happened. Event-driven architecture: An approach for designing and building applications in which events trigger messages to be sent between independent software modules that are completely unaware of each other -- decoupled, as opposed to the loosely coupled services that are inherent in the SOA-based approach. An event source typically sends messages to middleware, and the middleware matches the messages to the subscription criteria of programs that want to be notified of the events. Messages are typically sent using the publish-and-subscribe approach because it enables the simultaneous delivery of messages to multiple destinations. A rules-based event processing agent may be used to listen to incoming events from perhaps thousands of different sources and filter, map and apply constraints to those events using sophisticated rules. Benefits: Eases incremental development and maintenance of large distributed application sets that include unpredictable, parallel or asynchronous activities. More efficient than the SOA approach if there are multiple destinations for the same data, because the source sends the event only once. An SOA-based client would have to make successive calls. Facilitates fast, low-cost reconfiguration and assembly of business components in new business processes. Promotes reuse of business components in multiple applications and for multiple end-user access channels. Limitations: Very incomplete standards, so all programs must use the same middleware product from one vendor or cumbersome gateways between disparate middleware products. Inexperience of application developers and architects designing complex event processing applications. General-purpose EDA middleware products, particularly event processing agents, are sold by small vendors with few production references. Developers must assemble and integrate the development tools, management and security facilities. Source: Gartner Inc., Stamford, Conn.