COM R. Schulte

Transcription

1 R. Schulte Research Note 7 July 2003 Commentary Event-Driven Applications: Definition and Taxonomy Simple event-driven applications are becoming widespread in mainstream enterprises. More-powerful complex-event processing is a niche phenomenon today but will become more common by Although system software, such as operating systems and network and systems management (NSM) tools, has implemented events widely for years, business applications have underutilized events. As business requirements escalate and event-enabling technologies become more available, enterprises will increase the number and sophistication of their event-driven applications. What Is an Event? The term "event" has two meanings in this research. Ordinary events just mean something that happened that is, a large or small change in the state of the universe. In software engineering, however, an event is the automated record of what happened. Software events are objects, often packaged as messages, that describe an ordinary event. Ordinary Events Ordinary events include a house purchase, a stock trade, college graduation and clicking a computer mouse. Events encompass smaller, contributing events. For example, a house purchase may involve multiple meetings, house tours, phone calls, , bank transactions and so forth. Even the tiniest action, such as picking up a pen, results in events (for example, a change in the location of the pen). However, it is seldom useful to analyze events on this fine level of detail. Events are not instantaneous; they result from processes that occur over time. Buying a house may take months. For our purposes, the most important kind of ordinary event is a business event. A business event is a meaningful change in the state of the enterprise or of something relevant to the enterprise, such as a customer order, an employee address change, the arrival of a shipment at a loading dock, a bill payment or a truck breakdown. Software Events Every enterprise has ordinary business events, even if it has no computers. However, software events only come into existence if they are generated by an application or some other software to describe such business events. Not all business events are documented by software events. For example, when a Gartner 2003 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 person enters an order (a business event), an application program typically records the transaction by updating a database. If this just changes existing data elements (such as sales records and account balances) and any new data is scattered among various tables, then no identifiable software event is created. However, it is often useful for the application to send a message that contains some description of the order (for example, customer name, date, time, item descriptions and quantities) to another application to trigger further processing (see "The Case for Event-Driven Design"). This message describes a particular happening and is a software event (strictly speaking, the message is the form of the event, although programmers often refer to the message as being the event). In event-driven design, a mundane business event, such as a book purchase, could cause a dozen application programs in different locations to emit hundreds of software events over the course of a week. For example, the online-shopping program will send an event when the book is added to the shopping cart, an order-processing program may later send an event to a bank credit card system, and another event may trigger a royalty payment to the author. These are application-level events because they have business meaning and are created and received by applications. Other kinds of software events are continuously generated in the background by the operating system, NSM tools and other system software. Software events that are sent and received by system software are outside the scope of this research because they are not part of application design. However, some system events do affect business users. For example, if a computer fails, an NSM event may be sent to a business activity monitoring (BAM) tool that notifies a business manager that a customer care center application is down. Another example: When a mouse is clicked (a tiny ordinary event) on a screen icon, system software that controls the graphical user interface generates an event that triggers a particular event-driven procedure in a Visual Basic program. This is an example of event-driven programming, not high-level event-driven application design, and is therefore also outside of our scope. Taxonomy Event-driven business applications can be sorted into four categories: Simple event-driven (or message-driven) applications, where application programs explicitly send and receive messages directly to and from each other for example, through message-oriented middleware (MOM) Event-driven applications that are mediated by integration brokers, which transform and route simple event messages according to logical rules Event-driven applications that are directed by business process management (BPM) engines that manage the end-to-end flow of a multistep process using special, BPM-oriented types of events Complex-event processing (CEP) applications, where a sophisticated event manager logically evaluates multiple events to enable decoupled, parallel, asynchronous application processing or BAM Simple Events Simple-event-driven processing is roughly synonymous with message-driven processing. Messages are sent in one direction from an application source to one or more application sinks (recipients). The applications are logically decoupled because they do not "hard wire" any assumptions about each other beyond a shared understanding of message contents. A common mistake is to confuse conceptual design with lower-level implementation. Event-driven processing as a design concept can be implemented with almost any kind of middleware or protocol, 7 July

3 theoretically even TCP/IP or a remote procedure call (RPC). However, event-driven applications are usually built on MOM, Web services or both. Examples of MOM include IBM's Event Broker, IBM's MQSeries, Microsoft Message Queuing (MSMQ), Tibco Software's Rendezvous, and any of the Java Message Service (JMS) MOM products (whether embedded in application servers or unbundled). MOM products that support publish-and-subscribe (pub-sub) are particularly useful for sending events. Not all MOM messages are events. A MOM message may contain a file, a multimedia object that represents no particular activity (for example, a person's portrait), a collection of events packaged together, or a set of parameters for an RPC. None of these messages is an event. A MOM message is (the form of) a software event only if it signifies the occurrence of one particular ordinary event. A software "document" containing a purchase order, loan application, insurance claim or other transaction can be considered a kind of denormalized event if it is sent one way. Such documents, commonly formatted in Extensible Markup Language (XML), are software events in spirit because they contain the digital record of a business event. However, they are less elemental than a strictly designed software event that documents a single change of state. A document is forwarded from one application to the next with various changes and additional data elements, so it is a running log of state changes. If a document is used in a two-way, request/response pattern, then it is not an event even in spirit (see "Event-Driven Architecture Complements SOA"). Enterprises traditionally handled most events (including documents) in batch processes. They have gradually increased their use of near-real-time event-driven computing during the past 10 years. Individual event messages and documents are now widely used in many mainstream applications, including business-to-business (see "B2B Application Integration Is Typically Event-Oriented"). However, a substantial minority of application developers still do not fully understand where events should be used. Their applications invoke a procedure through a method call, or write data to a database or file, when sending an event through MOM or Web services would be more effective. Brokered Event Processing It is often useful to insert an integration broker between an application that sends a simple event and the application(s) that receives the event. Integration brokers perform syntactic and semantic transformation on messages. Integration brokers also perform content-based routing, often using pub-sub communication. Brokers apply application-level intelligence using rules, in contrast to plain communication middleware, such as a MOM, which only provides basic event delivery. Integration suites from vendors such as IBM, Mercator Software, Microsoft, SeeBeyond Technology, Sybase, Tibco, webmethods and Vitria Technology contain such brokers. Integration brokers are also found in application platform suites, some packaged applications and other software products (see "Events Will Transform Application Servers"). The use of an intermediary, such as a broker, is a big step beyond simple event-driven computing, because some decisions on the flow of data and the flow of control are moved out of the end-point applications and into the broker. Although this is different from conventional application design, it is not too difficult for mainstream architects and developers to do. Most large enterprises use an integration broker in at least one application, and many have several different brokers in production. We estimate that about 20 percent of new, integrated applications in 2003 will use an integration broker someplace, and that half of the new integrated applications in 2006 will use a broker (0.7 probability). Note that brokers also support service-oriented architecture (SOA), so they should not be considered just as eventoriented tools. 7 July

4 BPM-Enabled Applications BPM is a different approach from either simple event-driven or brokered applications. BPM software manages process flows by "remembering" the status (holding state data) for each instance of a process. It uses rules to evaluate the context and events, and then triggers execution of the appropriate next steps. BPM engines use events in two ways: Like a broker, they can trigger an application by sending an event that contains application data, using MOM, Web services or another mechanism (alternatively, they also can invoke a program as a service, using Remote Method Invocation, Web services or another request/response mechanism, just as brokers can). Unlike a plain integration broker, however, BPM engines often use specially tailored BPM event messages to communicate between a BPM adapter and a central BPM engine to mark the start or end of an activity. These special system software events help to coordinate the process, but they are not business events. They do not carry application data and are not sent or received by an application program. BPM engines use such events to fork and join the flow of control based on logical rules. All of the major broker vendors, including those listed in the previous section, offer BPM engines that complement their integration brokers. Integration-oriented BPM specialists such as Fuego, Metaserver, Pegasystems and Savvion also support this. Complex-Event Processing CEP is radically different from simple, brokered or BPM-enabled event processing. CEP is enabled by some type of event management software, such as a centralized event manager or a set of distributed event-processing agents. Event managers use rules to: Filter events (selecting or discarding events based on their type and attributes) Aggregate sets of events into higher-level complex events by matching events to patterns Detect event patterns that violate constraint conditions An event manager may create new events to send to applications or to other event managers, or, like a BPM engine or broker, it may directly invoke an application through an application program interface in a request/response manner. CEP is most effective if the event messages carry extra information regarding relationships (relating this event with other events) or causality (historical background on how the event came about). Such data are not included in routine application messages (simple events), so they must be inserted by CEP adapters ("event transformers"). Often, an entire message is tailored for CEP purposes, carrying no business data from application to application. (For further explanation of CEP, see "The Power of Events," by David Luckham, Addison Wesley, 2002, ISBN ) CEP is currently found in leading-edge, niche business applications. The earliest practical use of CEP at an application level was in computer hardware simulation to help debug CPU designs. CEP is also used in business process diagnostics, security and fraud detection. One of the major drivers for the adoption of CEP in business applications is BAM. CEP is a core enabler of BAM and is built into many BAM tools already on the market (see "Opportunistic BAM Pits Users Against IT Planners"). CEP use will further accelerate as architects become more aware of its ability to enable dynamic, parallel, asynchronous processing. A few enterprises have built CEP into business applications by re-purposing NSM-style event managers to handle application events. Others have used event management software from pioneering 7 July

5 vendors such as Apama, ispheres, Systar and others. A few BPM vendors, including Pegasystems and Savvion, and integration vendors, including Tibco and Vitria, have varying degrees of CEP capabilities in their products today. Bottom Line: We recommend that enterprises use a mix of service-oriented architecture and simple event-driven design in most large new applications. Brokered and business-process-managementenabled event-driven approaches should be used in heterogeneous application integration scenarios where the data and flow routing must be systematically designed and managed. Complex-event processing should be reserved for business activity monitoring and for leading-edge projects where agility must be maximized and the enterprise is willing to invest in emerging CEP technology. 7 July