Product Reviews

An event-driven architecture (EDA) reflects the real world in which businesses operate. The real world is constantly changing, chaotic, and unpredictable. An EDA enables organizations to make sense out of all the events occurring within their business, and to detect anomalous business situations by drawing together a number of indirectly related or independent events. Furthermore, EDA builds decision-making capabilities directly into business processes by using analytical insights to drive decisions. EDA offers organizations the ability to track events in real time, thus gaining an early awareness of issues, improving productivity, and reducing manual intervention and errors.

Event-driven architecture is not a new application pattern; applications have been supporting events for years. What's new is that vendors are now enhancing software infrastructure products and application frameworks to support events without complex custom coding. This article reviews one of the latest products to do so - Oracle EDA Suite.

The Need For Event-Driven Architecture
Today, EDA is gaining popularity, driven by the need to solve the following business issues:

• Organizations are suffering from an overabundance of data resulting from the "double whammy" of rising transaction volumes and the increasing speed at which data is produced. A typical business may produce millions of events on a daily basis. Financial services firms often process up to 150,000 external events each second, a number that is forecast to increase to 5 million within three years.
• Customers have come to expect dramatically faster customer service response times - pushing organizations to react and respond faster than ever before - and in many cases customers demand proactive communication and resolution. At the same time, customer interaction channels are continuing to increase, requiring near real-time coordination.
• Over the years, businesses have created increasingly complex, heterogeneous IT environments. With Internet-linked, distributed systems, along with the rise in service-oriented computer systems, the complexity of systems has increased significantly, as chains of services distributed across multiple boundaries interlink in ways that will make administrators pine for the days of linear, procedural codes that ran on a single machine. Understanding what is happening at any given moment within such multifaceted applications is difficult, and this complexity will only increase.
• Regulations such as Sarbanes-Oxley require up-to-the minute reporting and end-to-end process visibility.

Organizations must sense and respond to events across the extended enterprise rather than carrying out predetermined processes. Organizations that incorporate event-driven styles into their enterprise architecture can respond more quickly to changing business conditions, whereas current infrastructures for processing and managing events require complex and expensive software engineering.

EDA or SOA? Why Another Architecture?
Developers using a service-oriented architecture (SOA)-based approach build an application by assembling "services," or software components that define reusable business functions. SOA is based on a conventional request/reply mechanism. A service consumer invokes a service provider by sending a message asking for some action or data, and then has to wait until the completion of the operation on the provider side.

Unlike the request/reply approach of SOA, where callers must explicitly request information, EDA allows systems to respond dynamically as events occur. In an EDA, event producers publish events, and event consumers subscribe to receive these events as they happen. Moreover, the generation of an event is not dependent on the availability of a service to process that event; events therefore must be stored to support such instances when a subscriber is not available.

Apart from its support for parallel asynchronous flows of data - in which information is transmitted without any anticipation of an immediate reply, and in which there is no need for a continuous connection between systems - event handling exhibits a number of other characteristics that serve to distinguish it from service processing.

Events require not only one-to-one exchanges, but also the additional capability for one-to-many and many-to-many communications. In addition, event handling allows the publisher and the subscriber to interact without knowing anything about each other. The relationship between the two systems is purely in terms of the information sent and received. In contrast, interaction between service components generally involves linear bidirectional request/response communications between a "client" and "server" service, with the flow controlled by the initiator.

EDA in the Real World
Real-world examples of event-driven processes include demand-driven manufacturing and dynamic pricing. In demand-driven manufacturing, production is initiated upon the receipt of a customer order, rather than building to a quota determined from past sales. This reduces inventory and enables each order to be customized: for example, Dell Inc. can manufacture to order within a 24-hour cycle.

In a dynamic airline pricing system, each new booking "event" triggers a new pricing calculation for the next buyer. Dynamic pricing maximizes revenue by charging more if demand is strong and less if demand is weak.

Solving use cases such as these requires going beyond traditional business process automation, to enable rapid response to changing conditions. This requires the use of both service and event processing, which are compatible and reliant on each other. Using events to wire together business processes enables more decision-making to be transferred from man to machine.

This interaction between EDA and SOA is two-fold. The occurrence of an event can trigger the invocation of one or many services. Those services may perform simple functions, or entire business processes. Secondly, 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 take action if necessary. The event-driven action may include the invocation of a service, the triggering of a business process, and/or further publication or syndication of information.

SOA delivers software functions as loosely linked services that can be plugged, unplugged, or combined to form new applications. EDA enables organizations to respond instantly to any relevant event. It is clear that organizations need both SOA and EDA within their enterprise architectures. EDA is not the successor to SOA; it is its sibling. Neither is it new: simple event-driven processing has been in common use for at least ten years with message-oriented middleware. However, one of the main advances in the past few years has been the emergence of higher-level programming tools and paradigms that make EDA implementation much less daunting.

The remainder of this article will focus on the requirements of an EDA and how Oracle EDA Suite supports those requirements.

Requirements of an EDA Solution
Successfully implementing an event-driven architecture requires the following components:

• Data and Event Collection Infrastructure: A real-time scalable infrastructure is required for event handling. Data is most valuable when it is fresh and can be acted upon immediately; stale data that cannot be used to anticipate events before they happen is of little value. The platform must provide both the scalability and reliability required to handle the vast amounts of real-time data that will be generated from EDA applications.
• Event Filtering: Not all events are of equal significance. It is important to be able to filter events - especially in high-volume cases such as RFID - to ensure networks and applications are not overwhelmed.
• Complex Event Processing (CEP): CEP deals with the task of processing multiple streams of simple events with the goal of identifying the meaningful events within those streams. CEP helps discover complex, inferred events by analyzing other events.
• Messaging Backbone: A messaging backbone that handles standards-based, multiprotocol messaging is required to support heterogeneous IT environments in which events are generated from a variety of sources and technologies, such as enterprise applications, databases, and RFID sensors.
• Visualization and Actionable Alerts: Users need to be able to visualize the events that are occurring within their businesses. They need to be able to quickly determine the nature of the problem, drill down into operational data, and take action directly.

Oracle EDA Suite
The Oracle EDA Suite consists of a subset of Oracle's middleware platform - Oracle Fusion Middleware - that allows customers to identify, analyze, and respond to business events in real time. Oracle EDA Suite can be implemented on its own or in conjunction with the companion Oracle SOA (Service-Oriented Architecture) Suite. Both share several overlapping components, including Oracle Enterprise Service Bus.

Oracle EDA Suite comprises the following components: Oracle Enterprise Messaging Service, Oracle Enterprise Service Bus, Oracle Business Rules, Oracle Business Activity Monitoring, and Oracle Sensor Edge Server. These components are described in more detail below.

Oracle Enterprise Messaging Service
Oracle Enterprise Messaging Service (OEMS) provides a standard messaging platform for EDA. OEMS is built on Java 2 Enterprise Edition (J2EE) standards such as the Java Message Service (JMS) and the J2EE Connector Architecture (JCA). For organizations that want to integrate their existing messaging technology with the Oracle platform, the OEMS JCA Connector implementation supports WebSphere MQ, TIBCO Enterprise JMS, and SonicMQ integration. PL/SQL and C APIs are also provided to allow integration with non-Java applications. In addition, Oracle Enterprise Messaging Service also leverages the security and high-availability features of Oracle Database and Oracle Real Application Clusters (RAC).

Oracle Enterprise Service Bus
Oracle Enterprise Service Bus (ESB) fully supports all the capabilities you would expect from a leading enterprise service bus: data transformation and document enrichment using XSLT or XQuery transformation, business rules, system cross-references, and domain value mapping. Oracle ESB provides connectivity by leveraging Oracle Adapters, which provide standards-based access to virtually any data source. Oracle ESB also supports content-based routing and content filtering. A novel feature is support for multiple protocols in the messaging bus, including JMS, SOAP, JCA, WSIF, JDBC, HTTP, and FTP. This means that organizations can get enterprise service bus capabilities - messaging, routing, and transformations - running on their choice of underlying protocol.

In contrast to Oracle BPEL Process Manager, which orchestrates long-running stateful business processes, Oracle ESB delivers high-performance messaging in support of both stateless and stateful service orchestration. Oracle ESB can capture the intermediate steps of a business process, allowing critical usage patterns to be identified and integrated into decision support systems in real time. Usage patterns can be identified to streamline business processes, or even head off problems before they cause irrevocable damage.

Oracle ESB combines event-driven and service-oriented approaches to simplify integration across heterogeneous platforms. It acts as an intermediary layer to enable communication between different application processes. A consumer or an event can trigger a service deployed onto Oracle ESB. It supports synchronous and asynchronous data flows, facilitating interactions between one or many stakeholders (one-to-one or many-to-many communications). Oracle ESB provides all the capabilities required for both service- and event-oriented architectures. (Figure 1 shows the ESB Control Console, which is used to manage messaging.)

Oracle Business Rules
Oracle Business Rules enables business analysts to easily define, update, and manage key decisions and policies governing business processes and applications.

Oracle Business Rules consists of the Rule Author tool, a Rules engine, and a Rules SDK. The Rule Author tool presents a simple interface for declaring rules that can be used by both programmers and business analysts. Rule Author generates the Oracle Rules language in a repository for use by the Rules engine. This language provides integration with Java programs, Web services, and XML documents. The Rules engine is a fast and efficient JSR-94 compliant RETE-based engine written in Java. The Rules SDK provides a rules-editing interface that allows applications to generate custom rules. The SDK is attractive for applications that define policies via their own special graphical interfaces. You can develop applications in Oracle BPEL Process Manager - part of Oracle SOA Suite - and capture business policies that are part of business processes by using the Rules engine. In this way, changes to business policies can be made without touching the business processes themselves. The Rules engine also supports integration with third-party engines such as iLog.