A Transparent New Year
Posted by Louis Lovas
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.
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
A software developer is a person or organization concerned with facets of the software development process. They can be involved in aspects wider than design and coding, a somewhat broader scope of computer programming or a specialty of project managing including some aspects of software product management. This person may contribute to the overview of the project on the application level rather than component level or individual programming tasks. Software developers are often still guided by lead programmers but also encompasses the class of freelance software developers.
Other names which are often used in the same close context are software analyst and software engineer.
With time and a little luck, differences between system design, software development and programming are more apparent. Already in the current market place there can be found a segregation between programmers and developers, being that one who actually implements is not the same as the one who designs the class structure or hierarchy. Even more so that developers become systems architects, those who design the multi-leveled architecture or component interactions of a large software system.
(see also Debate over who is a software engineer)
Posted by: viagra online | Friday, January 15, 2010 at 08:32 AM
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.
Posted by: buy generic viagra | Friday, February 19, 2010 at 09:28 AM
Please one more post about that.I wonder how you got so good. This is really a fascinating blog, lots of stuff that I can get into. One thing I just want to say is that your Blog is so perfect
Posted by: buy xanax | Monday, August 01, 2011 at 09:17 PM