INTRODUCTION

Service-Oriented Architecture and Event-Driven Architecture

Over the last year, every time we wrote or spoke about service-oriented architecture (SOA)[1], we couldn’t help but include SOA’s interaction with event-driven architecture (EDA). We see, and speak to, two distinct interactions.

In the first interaction, the occurrence of an event (a notable thing that happens inside or outside your business) can trigger the invocation of one or many services. Those services may perform simple functions, or entire business processes. This interaction between events and services is commonly referred to as event-driven SOA. We describe this as a style of SOA[2].

In the second interaction, a service may generate an event. The event may signify a problem or impending problem, an opportunity, a threshold, or a deviation. Upon generation, the event is immediately disseminated to all interested parties (human or automated). The interested parties evaluate the event, and optionally take action. The event-driven action may include the invocation of a service, the triggering of a business process, and/or further information publication/syndication. In this interaction, the service is purely one of many event sources in a broader event-driven architecture.

Over the last few months, we have seen increasing interest in the SOA-EDA connection, both from enterprises and the vendor community. Enterprise architects and IT strategists are considering how to best create (evolve) an environment for IT and business agility. Thought leaders at leading SOA and integration vendors are coalescing visions and product strategies for SOA, integration, and event processing. This is all great to see.

However, we do have one concern and a point of caution for readers. Many SOA evangelists are only telling part of the event-driven architecture story: that of event-driven SOA. We fear this will lead to short-sided event architecture implementations. Enterprises could miss out on opportunities for real-time information flow and analysis, and complex event processing.

As a service to our architecture readers who think holistically, we have developed this overview report on event-driven architecture. In this report, we explain key event concepts, walk through event processing flows, and identify the major implementation components of an event-driven architecture.

EVENT-DRIVEN ARCHITECTURE BASICS

Event Basics

WHAT IS AN EVENT? An event is a notable thing that happens inside or outside your business. An event (business or system) may signify a problem or impending problem, an opportunity, a threshold, or a deviation.

Specification and Occurrence. The term event is often used interchangeably to refer to both the specification (definition) of the event, and each individual occurrence (instance) of the event.

Define in Business Terms. For an event to be meaningful to downstream subscribers (human and automated) it is imperative that the event (name and body) is specified in business terms, not data or application terms.

WHAT IS IN AN EVENT? Each event occurrence has an event header and event body. The event header contains elements describing the event occurrence, such as the event specification ID, event type, event name, event timestamp, event occurrence number, and event creator. These elements are consistent, across event specifications.

Event Body. The event body describes what happened. For example, if a retailer specified a low inventory threshold event, the event body would contain the information to communicate which product fell below the allowable threshold.

The event body must be fully described so any interested party can use the information without having to go back to the source system. For the low inventory threshold event, the event body would contain not only the product identifier, but also the product description, and the point in time inventory and threshold levels. To ensure events are understood by all consumers, a clear business lexicon or ontology should be used.

WHAT IS AN EVENT-DRIVEN ARCHITECTURE? In an event-driven architecture, a notable thing happens inside or outside your business, which disseminates immediately to all interested parties (human or automated). The interested parties evaluate the event, and optionally take action. The event-driven action may include the invocation of a service, the triggering of a business process, and/or further information publication/syndication.

Extreme Loose Coupling. By its nature, an event-driven architecture is extremely loosely coupled, and highly distributed. The creator (source) of the event only knows the event transpired. The creator has no knowledge of the event’s subsequent processing, or the interested parties. The traceability of an event through a dynamic multipath event network can be difficult. Thus, event-driven architectures are best used for asynchronous flows of work and information.

Event Processing Styles

There are three general styles of event processing: simple, stream, and complex. The three styles are often used together in a mature event-driven architecture.

SIMPLE EVENT PROCESSING. In simple event processing, a notable event happens, initiating downstream action(s). Simple event processing is commonly used to drive the real-time flow of work--taking lag time and cost out of a business.

STREAM EVENT PROCESSING. In stream event processing, both ordinary and notable events happen. Ordinary events (orders, RFID transmissions) are both screened for notability and streamed to information subscribers. Stream event processing is commonly used to drive the real-time flow of information in and around the enterprise––enabling in-time decision making.

COMPLEX EVENT PROCESSING. Complex event processing (CEP) deals with evaluating a confluence of events and then taking action. The events (notable or ordinary) may cross event types and occur over a long period of time. The event correlation may be casual, temporal, or spatial. CEP requires the employment of sophisticated event interpreters, event-pattern definition and matching, and correlation techniques. CEP is commonly used to detect and respond to business anomalies, threats, and opportunities.

EVENT PROCESSING

In this section, we present example event flows for each style of event processing. The flows are represented logically, broken out into four layers. Before jumping into the event flows, we describe the logical layers.

Event Flow Layers

An event flow starts with the event being generated and culminates with the execution of any downstream (event-driven) activity. The four logical layers are as follows ...