The Apama Event Processing Language, EPL, is a strongly typed language design specifically for the purpose of high-performance event processing.
Events are at the core of everything. Data comes into Apama as events and leaves as events. Communication within Apama is via events.
The fundamental language and runtime have a “shared nothing” architecture, where independent deterministic event processing agents, called “monitors” execute business logic in response to events of interest. Individual monitors communicate asynchronously by the passing of events. The design is heavily influenced by the concept of Communicating sequential processes - Wikipedia
The core concepts are:
- " event " - events have defined schemas, and in their simplest form can be considered like simple structs. They can also be considered as objects, and may additionally define logic.
- " context " - the correlator contains one or more execution contexts. EPL can dynamically create additional contexts. These lightweight runtimes are deterministic, and behind the scenes are scheduled across a pool of threads. Each context has its own input queue.
- Historical note - For the first few years (back in the early 2000’s) the correlator only has a single context, the “main” context in which new code is initially instantiated.
- " monitor " - the definition of a single processing agent is called a monitor. The monitor defines the business logic. Instances of a monitor execute within contexts. These instances are sometimes known as sub-monitors.
- " listener " - a listener can be thought of as the callback that is triggered when some logic needs to be executed in response to events of interest being received. One listener can register another new listener even before the next event is processed from the queue. Listeners are contained within monitors.
- " event expression " - this is how to describe the event pattern of interest that should trigger a listener
- “action” - an action can be considered similar to a method in other languages. An action can be a member of an event or a monitor.
- " channel " - events can be sent to channels, and monitors can register to receive events on given channels. Channels can be dynamically created in EPL as needed.
We’ve blogged about some of these concepts in other getting started materials.
When someone is new to EPL, the main concept to grasp is that everything is in response to an event of some form. Even time effective passes as events. Sometimes we have noted that users accustomed to GUI programming can pick up the language quickly as they are used to handling UI events in response to user interactions.
Earlier, we noted that in the core model of EPL monitors are independent shared-nothing constructs. One monitor cannot reference or invoke actions on another monitor and data-structures in the core model and language cannot be shared. EPL however does have a foreign function interface (called EPL Plugins), and if you step outside the core model via shared code on some other language then it is possible (with great care!) to share data. Indeed, the MemoryStore plugin is one such component that provides a powerful KV-store. More on plugins at another time.
EPL is typically interpreted, but on Linux (amd64) can be optionally compiled to microarchitecture-specific native code at the point of injection.
Some deep links into the current (v10.11) documentation:
- Understanding monitors and listeners (softwareag.com)
- Introduction to Apama EPL (softwareag.com) (ignore the section about “queries” at this stage)
- Developing Apama Applications in EPL (softwareag.com)
It’s relatively easy to get started with EPL, and we have various samples distributed either as part of a product installation, or if using within Cumulocity IoT then specific examples for EPL Apps are provided in the web interface there.
Fun fact: historically, “EPL” was called “MonitorScript”, and hence why the typical filename extension is “.mon”
Have fun learning EPL!
This is Day #6 of a short series of brief tips, tricks, hints, and reminders of information relating to the Apama Streaming Analytics platform, both from Software AG as well as from the community.
This series of articles will be published Monday-Friday only, with the occasional weekend bonus.