Source systems are generally not modeled to propagate events to external sources other than alerts and warnings. These systems might have to be re-engineered to participate as sources for event streams. If an integration infrastructure exists, like an EAI backbone or ESB, then messages flowing through the infrastructure can be routed to an event stream processor without the need to re-engineer back-end systems. The number of external system adapters that can be linked to the event-driven application affects the breadth of sources from which events can flow to an event processor.

Stage 2: Process Events
The first step in processing the events flowing from different sources is to normalize them into a model that can be processed using a common programming model. This normalization is generally done using the adapters. Various operations can be performed on the events once they are normalized. The following basic set of operators is required to implement applications to process event streams:

1. Filter Events operators remove events from the stream that do not satisfy a certain condition. For example, in a stream of credit card transaction events, a filter operator can be configured to remove events with a transaction value of less than $100.
2. Join Events operators correlate and merge events from multiple streams to create a single stream of events. Because matching events from the streams may arrive at different times, these operators hold unmatched events from a stream until all matching events are received. Once all the events are received, the operator then creates a new event with the combined set of attributes. For example, the operator might correlate hospital report events and virus outbreak report events from a region to create an aggregated message that has virus information and hospital reports for a specified region within a certain time window.
3. Aggregate Events operators group events in a stream. The grouping can be done based on a sliding window, time, or the order in which the events were received. The grouping creates a collection of events, and various statistical operations can be performed on the collection. For example, you could compute the rate of change of inventory in the previous three weeks.
4. Sequencer operators order events flowing in a stream and eliminate duplicates by a specified attribute. If a gap in the order occurs, the source system can be notified to send a duplicate.
5. Relational operators perform Boolean operations on events in multiple streams.

Stage 3: Outbound Actions
Event processors can perform many operations, such as tracking a key performance indicator, monitoring the emergence of an event pattern, or looking for an exceptional event. Once a triggering condition is met, the event processor takes an outbound action.

In the context of an ESB or EAI backbone, the event processor can invoke any of the services available on the ESB as an outbound action. These services might include a business process, an alert, an update to a Web page, or others.

Architectural Overview
Event-driven architecture addresses a challenge created by traditional integration models that create cohesive and loosely coupled services and functions. Although loose coupling has some benefits, it makes it difficult to correlate activities that are occurring in disparate services and systems. Event-driven architecture can plug into existing infrastructure and receive events from disparate systems and services to address this challenge (see Figure 2).

Event-driven applications (event stream processors) can receive events from business processes, legacy systems, databases, ESBs, external services, and other sources.

A Sample Use Case
To put these concepts and ideas into action, the following simple scenario implements a solution. PennyLotto is a fictitious online gambling company where users create online accounts and then transfer funds from checking accounts or credit cards to their online gambling accounts. Users can also receive funds from credit cards that are not in their name. These funds are used for various online gambling activities managed by PennyLotto, and can be transferred back to users' bank accounts at any time.

PennyLotto faces an interesting problem: it received reports that some users add funds to their accounts using stolen credit cards and immediately transfer the funds to bank accounts, effectively using PennyLotto accounts as staging zones for stolen funds.

PennyLotto has a service-oriented infrastructure where customers can perform their operations from an approved kiosk, or online, or by calling a telephone agent. The infrastructure is highly secured, and every operation is authenticated and authorized.

Technology of Choice
This example is implemented using an open source product called Intelligent Event Processor (IEP). IEP is a general-purpose event processor engine based on the Java Business Integration (JSR 208) standard. IEP provides the design-time and runtime capability for delivering event-driven applications. The design-time editors for IEP are provided as NetBeans plug-ins, and the applications developed using IEP can be deployed on the GlassFish Application Server.

Implementation
The solution to this problem is to look for suspicious patterns of activities by users. The system should track three types of events initiated by a user in a 24-hour time frame: Deposit Funds, Gamble, and Withdraw Funds. These events could occur either in a single session or across multiple user sessions from different channels, such as using a kiosk to deposit funds and the online channel to withdraw funds. The pattern to look for is this: both a Deposit Funds event and a Withdraw Funds event occur in a 24-hour window, but without a Gamble event. An alert is sent when this pattern is detected.

Figure 3 illustrates the NetBeans design-time view of the event processor model. The three Web Service entry points for event streams in this model are: CC_to_Lotto to receive Deposit Funds events, Betting_Activity to receive Gamble events, and Lotto_to_Bank to receive Withdraw Funds events. In the topmost event stream, the 1_day_window_1 operator aggregates Deposit Funds events in a 24-hour time window for every user. In the middle event stream, the  1_day_window_2 operator aggregates Gamble events in a 24-hour time window for every user. In the middle event stream, the 1_day_window_2 and Betting_Activity_Last_Day operators aggregate Gamble events in a 24-hour time window for every user. The Detect_Threat operator matches Withdraw Funds events from the Lotto_to_Bank operator with the aggregated data to detect the pattern. An event is sent to the Send_Alert operator when the pattern is detected. The Send_Alert operator sends an alert whenever an event is received from the Detect_Threat operator.

The NetBeans project, test drivers, and scripts can be downloaded.

Summary
EDA has multiple variations, and what is described in this article is just one of them: event stream processing. Processing event streams has been possible for some time now, but the enhancements in technology, tooling, and readiness of the IT infrastructure to take advantage of these enhancements have come together to shape how new sets of business challenges are addressed. EDA-based solutions can reside alongside and non-intrusively interact with systems based on many other architectures, extending the reach of EDA-based applications.

Resources

• IEP Service Engine Home
• PennyLotto sample
• Example from technical blog
• OpenESB technical blogs

• Back to the Future with Cloud Computing