It's
been a while since I've put a few thoughts in print on these pages on
event processing, but that's not to say I've not been busy. We've
wrapped up quite a successful year in the Apama division
within Progress software. For this year, 2009 we've got quite a
number of new features and capabilities in store for the Apama CEP
platform. We will be extending the breadth and depth our event
processing language (EPL) to meet the challenges we've seen in
the market and a vision we have for the future. Of course you will see
announcements in our standard marketing press
releases but I (and others) will explore the technical merits of those new
features in these blog pages in much more detail. Something we've
not done that much of in the past. There are many historical
reasons for that not really worth explaining. Suffice to say our
intention is to be more transparent in the coming year.
To kick that off, it's worth starting a bit of a tutorial on the
Apama EPL, a language we call MonitorScript. I'll begin with
the basics here and in subsequent blogs build upon these main
concepts, providing insight into the power and flexibility of our EPL.
And as we
release new extensions and capabilities it will be easier to explain
the benefits of those new features. So without further ado, here
is the first
installment.
First a few basic concepts...
- Apama MonitorScript is an imperative programming
language with a handful of declarative statements. This is an important
consideration and one we highlight as a distinction in our platform
against competitive platforms that are based on a declarative
programming model. The imperative model provides a more
natural style of development similar to traditional languages like java
and C++.
- The language is executed at runtime by our CEP engine called the
Correlator.
Second a few basic terms...
- A monitor
defines the outer most block scope, similar to a class in java or C++. It is the basic building block of Apama applications.
A typical application is made up of many monitors. As you might imagine
monitors need to interact with one another, I'll explore that
capability in a later blog.
- A event
defines a well ordered structure of data. The EPTS
Glossary definition has a handful of great examples of Events
- A listener,
defined by the on statement,
declares or registers interest in an event or event pattern. In a large
application it's the Correlator runtime engine that will typically
process 1,000's or even 10,000's of registered event patterns. In our
example below we just have one.
- An action
defines a method or function similar to java or C++.
- The onload()
action is a reserved name (along with with a few others) that is
analogous to main() in a java program.
To put it all together... "A monitor typically listens for events and takes one or more actions when an event pattern is triggered."
The language sports a number of capabilities that will be
familiar to anyone schooled in java, C++ or any traditional
imperative programming language. I won't bore with all the nuances of
data types and such obvious basics, those are well articulated in our
product documentation and customer training courses. I will
however, focus on the unique paradigm of event processing.
Apama MonitorScript, a basic monitor.
event
StockTrade {
string symbol;
float price;
integer quantity;
}
monitor
StockTradeWatch {
StockTrade Trade;
action onload {
on all
StockTrade():Trade processTick;
}
action processTick {
log "StockTrade
event received" +
" Symbol = " +
Trade.symbol +
" Price = " +
Trade.price.toString() +
" Quantity = " +
Trade.quantity.toString() at INFO;
}
}
|
This monitor called StockTradeWatch
defines an event of type StockTrade. Events can originate from many
sources in the Apama platform, the most obvious would be an adapter
connected to a source of streaming data (i.e. stock trades as example
shows), but they can come from files, databases, other monitors,
even monitors in other Correlators.
The onload action declares a listener for events of type StockTrade (i.e. on all StockTrade). When the monitor StockTradeWatch receives StockTrade events, the action processTick
is invoked. As you can see in this example we simply log a message
to indicate that it occurred. The obvious intent is that this monitor
will receive a continuous stream of StockTrade
events, each one will be processed in-turn by the processTick
action. One can be more selective in the event pattern with a
listener, such as on all StockTrade(symbol="IBM"). I will explore the details of event patterns and complex listeners later on.
As I mentioned, I've started with a simple example that shows the
basics of the Apama EPL, MonitorScript. It demonstrates the simplicity
by which one can declare interest in a particular event pattern,
receive matching events and act on them in your application (i.e.
action).
In subsequent installments I will demonstrate more complex
features highlighting the power of the language. That's all for
now.
You can find the second installment here.
Regards,
Louie
