WebLogic Event Server and Distributed Caching

by Seth White
09/10/2007

Abstract

WebLogic Event Server (WL EvS) is a platform for developing and deploying event-driven applications. Distributed caching technology offers a number of benefits such as high availability (HA) and increased performance and scalability to applications that process real-time events. This article describes how developers can use WebLogic Event Server and distributed caching together to achieve these benefits for event-driven applications. A complete sample application and sample code is provided with the article.

Introduction

WebLogic Event Server (WL EvS) is a lightweight, modular application server for event processing applications. Event processing applications are fundamentally concerned with processing streams of real-time events, often with very demanding latency requirements. Examples of event processing applications can be found in the financial, telecommunications, manufacturing, and retail industries, among others. For example, an event processing application in the financial domain might process market data feeds looking for buy or sell opportunities.

Distributed caching is a relatively mature technology, and there are a number of existing caching products in the marketplace, including GemStone's GemFire, Tangosol's Coherence, and GigaSpaces' Data Grid. A distributed cache is a set of data that is cached in-memory across several different nodes in a distributed system. Distributed caching products typically support a number of in-memory caching topologies such as replicated, partitioned, and tiered caches. Distributed caching solutions also support reading and writing cached data from/to a persistent store such as a relational database.

Distributed caching technology can provide a number of important benefits to event-driven applications. Chief among these is high availability. For example, an event processing application might publish output events to a replicated, distributed cache, thereby making the results of its computation highly available. Distributed caching can also increase the performance and scalability of event-driven applications. For example, many event-driven applications need to join stream data with external data, such as data retrieved from a persistent store. A cache can be used to accelerate access to non-stream data, thereby dramatically increasing application performance.

This article presents a sample, event driven financial application—the "in-play" application—which demonstrates how WebLogic Event Server can be used with the GemFire distributed cache. The sample application provides a concrete example of how distributed caching can provide event-driven applications with the benefits of high availability and scalability. The application also demonstrates how to use a facade design pattern with Spring to minimize dependencies on a particular distributed caching solution. We also show how the extensible configuration system of the Event Server can be used to integrate the configuration metadata of the distributed cache with the rest of the server's configuration. Although GemFire is used in the sample application, the general approach to integration is applicable to other caching systems.

The article begins by presenting an overview of WebLogic Event Server and the use of distributed caching technology in event-driven applications. The remainder of the article presents the sample application and some conclusions.

WebLogic Event Server Overview

WebLogic Event Server is an application server designed specifically for real-time, event-driven applications. Event-driven applications are concerned with processing streams of events that typically are delivered to an Event Server instance from an external source. For example, Figure 1 illustrates a scenario in which stock trade events from several stock markets are being processed by an event-driven application. When the application detects a particular pattern in the trade events, it notifies event subscribers or other external systems. Usually, the number of events received from external sources is several orders of magnitude higher than the number of events generated by the application.

Figure 1: A typical event-driven application scenario

Internally, WebLogic Event Server is a lightweight, modular application server based on BEA's microServices Architecture (mSA). Figure 2 is a high-level diagram of the Event Server software stack. Figure 2 shows the Event Server running on BEA's real-time JVM, which offers deterministic garbage collection (DGC). This is appropriate for applications with demanding requirements for deterministic behavior and low latency, such as many financial applications. The Event Server is pure Java, however, so it can run on other JVMs as well.

Figure 2 also illustrates that the Event Server uses OSGi to provide the core of its modular architecture. If you are not familiar with OSGi, don't worry. We will explain the necessary pieces of OSGi as we go along. For now, the important thing to note is that both server subsystems, such as the logging and configuration subsystems, as well as developer-written applications are packaged as OSGi modules—modules are called "bundles" in OSGi. One implication of this is that developers need to understand enough about OSGi to package the applications that they write as OSGi bundles.

Figure 2. WebLogic Event Server architecture

WebLogic Event Server is a full-fledged application server that offers event-driven applications a full set of the services that they need to do their work. Figure 3 shows some of the more important service modules (or bundles) that the Event Server provides. For example, the Event Server supports access to relational database systems through JDBC. An Event Server can act as a JMS client. Authentication and authorization services can be used to specify a set of users that are allowed to perform administrative actions. The Event Server also supports work managers to handle threading concerns.

Figure 3. WebLogic Event Server services

Let's take a closer look at the structure of Event Server applications. The Event Server programming model is based on the Spring Framework. An Event Server application is composed of a network of application components that form an event processing network. There are four basic component types: Adapter, Stream, Processor, and POJO. The Event Server provides implementations of the Stream and Processor components, so developers just need to configure components of these types in order to use them. Adapters and POJOs, however, are written by an application developer. Figure 4 shows an example event processing network.

Figure 4. Example event processing network

As Figure 4 shows, adapters are the components that are responsible for providing connectivity to external event sources, such as market data feeds. Internally, adapters convert incoming event stream data into event objects that are consumed and processed by downstream components in the event processing network. Event objects can be JavaBeans that expose a typed set of properties or a Map whose entries represent property name/value pairs.

A Stream component is really an in-memory queue. The purpose of streams is to provide buffering for events and also control over the threading behavior of the application. By default, the Stream size is 1024, which means that a stream can buffer 1024 events. In the event processing network in Figure 4, the Stream provides some amount of decoupling between the adapters that are producing events and the processor that is consuming them. Once an adapter creates an event object and sends the event to the Stream, control can return to the adapter immediately (provided that the Stream is not full), and the adapter can continue reading data from the external event source and producing additional events. Events that have been placed in the Stream will be dequeued and sent to the processor by a separate thread. The number of threads that work at removing events from a stream when events are present is dynamically configurable as is the size of the Stream. In other words, these Stream parameters can be tuned while the application is running in order to improve performance.

Processors are where much of the work is performed in many event processing applications. To efficiently support operations such as filtering and joining streams of events, the Event Server provides a declarative Event Processing Language (EPL)—a query language based on SQL that has been extended with some special features for real-time event processing. A processor is configured with a set of EPL queries that it executes continuously as new events arrive. The set of queries for a processor can also be changed dynamically while the application is running. EPL queries generate output events that are sent to downstream components, such as the POJO in Figure 4.

POJOs are user-written components that can contain arbitrary business logic. POJOs give application developers access to the full power of Java in creating event-driven applications. POJOs can be simple components that forward events to an external system, or complex components that perform some more elaborate processing of events than can be expressed in EPL.