![]() ![]() ![]() ![]() ![]() ![]() |
This section contains information on the following subjects:
WebLogic Event Server is a low latency, Java based middleware framework for event driven applications. It is a light weight application server which connects to high volume data feeds and has a complex event processing engine (CEP) to match events based on user defined rules.
WebLogic Event Server has the capability of deploying user Java code (POJOs) which contain the business logic. Running the business logic within WebLogic Event Server provides a highly tuned framework for time and event driven applications.
The following graphic provides a high level view of an event-driven system:
An event-driven system is generally comprised of several event sources, the real-time event-driven (WebLogic Event Server) applications, and event sinks. The event sources generate streams of ordinary event data. The WebLogic Event Server applications listen to the event streams, process these events, and generate notable events. Event sinks receive the notable events.
Event sources, event-driven applications, and event sinks are de-coupled from each other; one can add or remove any of these components without causing changes to the other components. This is an attribute of event driven architectures.
Event-driven applications are rule-driven. These rules, or queries, which are persisted using some data store, are used for processing the inbound stream of events, and generating the outbound stream of events. Generally, the number of outbound events is much lower than that of the inbound events.
WebLogic Event Server is a middleware for the development of event-driven applications. A WebLogic Event Server application is essentially an event-driven application.
Next, consider the application itself, which is hosted by the WebLogic Event Server infrastructure, a light-weight container. It can be described by the following diagram:
A WebLogic Event Server application typically comprises of four main component types. Adapters interface directly to the inbound event sources. Adapters understand the inbound protocol, and are responsible for converting the event data into a normalized data that can be queried by a processor (i.e. event processing agent, or processor). Adapters forward the normalized event data into Streams. Streams are event processing endpoints. Among other things, streams are responsible for queuing event data until the event processing agent can act upon it. The event processing agent removes the event data from the stream, processes it, and may generate new events to an output stream. The user code registers to listen to the output stream, and is triggered by the insertion of a new event in the output stream. The user code is generally just a plain-old-Java-object (POJO). The user application makes use of a set of external services, such as JMS, WS, and file writers, to forward on the generated events to external event sinks.
Adapters, streams, processors, and business logic POJOs can be connected arbitrarily to each other, forming event processing networks (EPN). Examples of topologies of EPNs are:
Scenario: no processing is needed, aside adaptation from proprietary protocol to some normalized model.
Scenario: straight through processing to user code.
Scenario: two layers of event processing, the first processor creates causality between events, and the second processor aggregates events into complex events.
EPNs have two important attributes.
First, event processing networks can be used to create hierarchy of processing agents, and thus achieve very complex processing of events. Each layer of the EPN aggregates events of its layer into complex events that become simple events in the layer above it.
A second attribute of event processing networks is that it helps with integrability, that is, the quality of having separately developed components work correctly together. For example, one can add user code and reference to external services at several places in the network.
The use cases for WebLogic Event Server span a variety of businesses:
Automate stock trading based on market movement. Sample query: if, within any 20 second window, StockB rises by more than 2% and StockA does not, then automatically buy StockA.
Discover fraudalent activity by detecting patterns among events. Sample query: if a single ID card is used twice in less than 5 seconds to gain access to a city’s subway system, alert security for piggybacking.
Reduce false positive alarms. Sample query: When 15 alarms are received within any 5 second window, but less than 5 similar alarms detected within 30 seconds, then do nothing.
Monitor the vital signs of a patient and perform some task if a particular event happens. Sample query: When a change in medication is followed by a rise in blood pressume within 20% of maximum allowable for this patient within any 10 second window, alert nearest nurse.
The following list summarizes the main features of WebLogic Event Server:
wlevs.Admin
.
For information on supported configurations, see BEA WebLogic Event Server 2.0 in Supported Configurations: WebLogic.
![]() ![]() ![]() |