I have been writing on a small white paper on our Reakt language. There’s a first draft posted on this blog a while ago and here’s a second draft. Comments are most welcome.

Reakt™ – The ruleCore CEP language

A White Paper from ruleCore DRAFT ^rev2

Introduction

The Rulecore CEP Language – Reakt! – When you need to react immediately. Reakt is a language for complex event processing, or CEP for short. It is designed to provide a powerful and productive tool for developers, allowing them to quickly create solutions for detecting critical business situations in real-time. Reakt is not a traditional programming language. Reakt is a business situation description language. By using a declarative approach it allows the developer to concentrate on what kind of situations to detect and not how The design goal of Reakt is to provide a way for organisations to react immediately to critical situations. It achieves this goal by finding related events from streams of inbound events. What events a critical situation consists of, and how the events are related, are defined by the user using Reakt. Reakt allows the user to specify conditions and temporal relationships which must hold in order for the events to be considered a noteworthy situation. When the situation is detected by Reakt, an user defined real-time report is created which provides actionable information about the situation. Allowing the enterprise to react immediately. This short white paper gives an informal description of the language and explains the different language elements using examples instead of formal definitions.

Overview

Rulecore Reakt is a small domain specific complex event processing language designed for detecting situations by observing streams of events. An event is a description of something that happens. For example ‘engine started’, ‘order created’, ‘invoice sent’ or other types of events which are relevant to your business. The events originate normally from your internal business systems, from your suppliers or other partners. You can also get events from public data sources like Facebook, Twitter or events extracted from news feeds or weather and traffic data feeds. A situation is a formal description of a combination, a pattern, of events as they happen over time along with optional restrictions among the events. A simple example of situations that you might want to detect:

"A vehicle has crossed River Thames in London more than 10 times during the last three hours"

or

"ParcelDelivery event came before Order Event unless delivery is of type priority one"

Main Reakt language features:

• Continuous Evaluation – Designed to operate on live streams of events as they happen.
• Declarative – Rules and other items are specified using a high-level declarative approach.
• Modular – Rules are defined using modular and re-usable building blocks.
• Temporal – Handling of time is an integral part of Reakt. Timing restrictions and other temporal conditions can be stated using a number of declarations.
• Location Aware – Reakt includes built in support to understand location information and other geographical objects such as zones.
• Implementation Independent – The elements of Reakt are defined using standard XML and are implementation independent. Different implementations can be created in order to provide specialized execution environments.
• Automatic Life Cycle Management – Rule instances are created and deleted automatically in response to events. Rule instances are analyzed and deleted if their situation is determined to be undetectable.
• Dynamic Context Management – Each rule instance maintains its own virtual view into the streams of inbound events. The view provides a window into the incoming event streams in order to create a dynamic context for rule evaluation.
• Separation of Concerns – Reakt uses reusable blocks for;
  • Selection of events from the inbound stream
  • Rule life cycle management
  • Situation definition
  • Rule trigger reporting

The design goals of Reakt is to provide a language which allows the user to describe complex situations consisting of multiple events with non trivial temporal and geospatial relationships. The language is declarative. Lacking any procedural elements provides a base for formal verification and automated optimization and analysis of the language. Machine Friendly. A design assumption made early in the language design was that it is likely that computer systems will use Reakt to create and modify rules more frequently than humans. The rate at which new rules need to be created and old ones modified is assumed to be high. Thus the language was designed to be easily understandable by machines and at the same time being reasonably human readable for system developers. Friendly XML. The current version of Reakt uses XML for its syntax. XML was chosen to take advantage of existing knowledge among developers, known standards and existing tools for generating and parsing. It would also be possible to create alternative syntaxes for Reakt. For example to create a more compact human friendly representation for business users. EDA Building block. The Reakt language was designed to support execution environments which fits into an architectural style called Event Driven Architecture (EDA). In order be a natural building block in an EDA, the ruleCore Reakt language and its supporting execution environment, the ruleCore CEP Server, was designed to be completely event driven. This purely event driven approach allows all systems in a distributed messaging architecture to integrate with ruleCore using simple events as their only communication mechanism.

The System Information Model

The System Information Model, or SIM for short, is both the name of the information model used by ruleCore CEP Server and the name of the run-time data structure modeled after the familiar DOM model, commonly used to represent information originating from XML. The SIM contains all information about different Reakt items such as rules, situations and other types of run-time information. The SIM is part of the ruleCore CEP Server implementation and not the language definition. But as all the language elements are executed against the SIM, it is described here briefly. Different implementations can implement varying information models. The appearance of the SIM can also vary  in ruleCore CEP Server depending on which dynamically loadable modules are present in the system. The SIM is used for various purposes, for example:

• Listing available definitions – All definitions of items such as rules, views, zones, entities, situations and actions can be found in the SIM. Definitions are created using the systems events, for example AddRuleDef, AddSituationDef and AddActionDef.
• Listing user defined events – Before an event can be sent into ruleCore CEP Server, it must be defined using the AddEventDef system event. The SIM contains all user defined events.
• List of rule instances – When a rule instance is created, it’s state and internal data structures can be monitored by querying the SIM. The ruleCore CEP Server provides a query mechanism using XPath. But other implementations might query the SIM using other methods.
• Monitoring situation progress – As a situation develops, its progress can be monitored by querying the SIM.
• Examine view contents – Each rule instance is executed in an unique context of events called the event stream view. The view contains a window into the inbound stream of events and contains only semantically related events.
• Referencing items – When an item such as a rule needs to reference other items it is done using references through the SIM.
• Component Specific Data – Each plug-in component that extends the engine creates an entry in the SIM and may add any component specific information.

The SIM consists internally of dynamic data structures which are updated as needed when the internal state of the ruleCore CEP Server changes in response to inbound events. These data structures have an external representation which is the user’s view of the SIM. The external representation of the SIM can be treated as a DOM document which can be queried using XPath and transformed using XSLT. XPath queries can be executed against the SIM using the SysInfoQuery system event. If is also useful to note that the ruleCore CEP Server uses events for all tasks. Special pre-defined system events are used to create rules and other items in ruleCore CEP Server in addition to monitor the run-time state of the rule evaluation.

Structure of a Rule

The main language element in Reakt is the rule. Reakt uses a class of rules called reactive rules to provide its situation detection capabilities. Reactive rules should not to be confused with production rules or other types of rules which must be explicitly evaluated. A rule in Reakt is never explicitly evaluated, its evaluation is automatically managed by the execution environment in response to inbound events. A rule consists of a number of elements, the main ones being:

• Initialization directives - Specifies which events can lead to the creation of a rule instance
• Termination directives – Specifies what causes a rule instance to be deleted.
• The rule level – Specifies on what level in the rule hierarchy instances should be created.
• Trigger Directives – Controls how and when to report Rule triggering.
• The View – A reference to a view, providing execution context for the rule.
• The Situation – A reference to a situation to track and detect situations.
• The Action – A reference to an action, which will generate an event when
  • the situation is detected, or
  • if the situation is determined to be undetectable.

General Rule Attributes

Each rule has a name and a attribute which can be used limit the number of rule instances that can be created of a particular rule. A common usage of the limit is to create a singleton rule, of which only one single instance can exist. Rules at every level can publish their trigger events externally so that they are visible outside of the ruleCore CEP Server. All rule declarations includes a level specification. Every rule instance is created on a specific level in a hierarchy of rules. Level zero is the level on which inbound events arrive. Thus the lowest level for a rule is 1 (one). A rule will only see events from a level directly below it. For example, three levels of rules where the rule at level one sees the inbound events:

<Rule name="New Location" limit="1000" level="1"> … </Rule>

<Rule name="Zone Entry" limit="1000" level="2"> … </Rule> <Rule name="Zone Exit" limit="1000" level="2"> … </Rule>

<Rule name="Zone Visit" limit="1000" level="3"> … </Rule>

Rule Life Cycle Management

Rule instances are automatically created and deleted based on directives in the rule declaration section. Create. The <Initialize> declaration controls when a new rule instance can be created. All rule instances are created in response to events. The <Initialize> section lists those events which can lead to new rule instances being created. Create a rule instance when an event of type GPSPosition arrives. <Initialize> <Assert> <Event> <base:XPath>sim:EventDef[@eventType="GPSPosition"]</base:XPath> </Event> </Assert> </Initialize> The <Key> declaration is the unique key for each rule instance. The key consists of one or multiple properties of the init events. <Key> <Property name="Vehicle"/> <Property name="Zone"/> </Key> The key declaration allows for easy detection of situations per something. For example, the above key declaration creates rule instances which are per vehicle and zone. So there would be rule instances created for each unique combination of vehicle and zone. Terminate. The <Terminate> section determines when a rule instance is deleted. The <Terminate> section consists of a number of directives which allows for creation of flexible termination strategies. A rule could for example be terminated when it has triggered three times, when it’s view is empty, on a specific date and time or when a particular event arrives. <Terminate> <Triggered count="3"/>

<ViewEmpty name="ZoneEntry"/>

<Time>2010-01-31T00:00:00Z</Time> <Assert> <Event> <base:XPath>sim:EventDef[@eventType="Location"]</base:XPath> </Event> </Assert> </Terminate>

Rule Triggering

A rule may trigger when one of two things happen; the situation is detected or it is automatically determined that the situation is undetectable in the future. Depending on the terminate declarations a rule can fire one or multiple times.

<Trigger> <SituationDetected/> <UndetectableSituation/> </Trigger>

When a rule triggers, its action part is executed. The action part creates an event and thus the visible result when a rule triggers is a new event, created according to your specification.

Trigger Reporting

Related to rule triggering is the reporting of the rule triggering. The triggering of the rule and reporting that triggering is separated in two stages. Thus it is possible to postpone the report of a rule triggering. For example, it is possible to report rule triggering, or multiple triggerings, each minute or when the rule has triggered five times or whichever comes first. It is also possible to limit the trigger reports so that only a specified number of reports are created. The most common case is to create rules whose triggering is reported only once. <Report>

<Every trigCount="10" timeframe="00:10:00"> <Max count="234"/> <AtTermination/>

</Report>

References

The rule also contains a reference to the rule’s view, situation and action. All references in Reakt are specified using XPath and executed against the SIM. The view reference contains a reference to a view declaration. The view provides the context in which the rule is executed

<Views> <ViewRef name="ZoneEntry"> <base:XPath>sim:ViewDef[@name='ZoneEntry']</base:XPath> </ViewRef> </Views>

The situation reference contains a reference to the situation which is evaluated in the context of the view.

<Situations> <SituationRef name="ZoneEntry"> <base:XPath>sim:SituationDef[@name="ZoneEntry"]</base:XPath> </SituationRef> </Situations>

The action reference contains a reference to the action part which generates a new event when the rule triggers.

<Actions> <SituationDetected situationName="ZoneEntry"> <ActionRef name="ZoneEntry" eventVisibility="external"> <base:XPath>sim:ActionDef[@name="ZoneEntry"]</base:XPath> </ActionRef> </SituationDetected> </Actions>

Complete Rule Example

Here is a complete example of a rule.

<Rule name="ZoneEntry" limit="1000" level="1">

<!– Create rule instance per Vehicle and Zone –>

<Key> <Property name="Vehicle"/> <Property name="Zone"/> </Key>

<!– Create a rule instance then the Location event arrives,

if one does not exists per the key above –>

<Initialize> <Assert> <Event> <XPath>EventDef[@eventType="Location"]</XPath> </Event> </Assert> </Initialize>

<!– Delete rule instance when rule has triggered 300 times, the view is

empty of at the specified time or when the Reset event arrives –>

<Terminate> <Triggered count="300"/>

<ViewEmpty name="ZoneEntry"/>

<Time>2010-01-31T00:00:00Z</Time>

<Assert> <Event> <XPath>EventDef[@eventType="Reset"]</XPath> </Event> </Assert> </Terminate>

<!– Report rule triggerings every 10th triggering of every tenth minute

or at rule termination, report a maximum of 234 triggerings –>

<Report>

<Every trigCount="10" timeframe="00:10:00"> <Max count="234"/> <AtTermination/> </Report>

<!– Trigger rule when situation is detected –>

<Trigger> <SituationDetected/> </Trigger>

<Views> <ViewRef name="ZoneEntry"> <XPath>ViewDef[@name='ZoneEntry']</XPath> </ViewRef> </Views>

<Situations> <SituationRef name="ZoneEntry"> <XPath>SituationDef[@name="ZoneEntry"]</XPath> </SituationRef> </Situations>

<Actions> <SituationDetected situationName="ZoneEntry"> <ActionRef name="ZoneEntry" eventVisibility="external"> <XPath>ActionDef[@name="ZoneEntry"]</XPath> </ActionRef> </SituationDetected> </Actions>

</Rule>

The View

The rule declaration contains a reference to a view. The view provides the context in which the rule is evaluated. The view keeps related events together and selects only interesting events from the inbound stream of events. Each rule instance contains its own private view instance. The view contains a collection of events. The view is kept updated based the stream of inbound events. The view provides a dynamically changing execution environment for the rule as each rule instance is executed in the context of its view. The view consists of a number of declarations, each specifying a property of an event that must be true in order for the event to be present in the view. All these declarations are evaluated to determine which events are present in the view of each rule instance. Example of properties available:

• The type view property is used to include events into the view only if they are of the specified type.
• The maxage view property defines the maximum age for each event in the view. You could for example use the age property to let each rule instance see only events from the past 10 minutes.
• The maxcount property defines the maximum number of events in the view. You could for example use this property to limit the view to contain only the last 100 received events.
• The match property defines which event properties must match in order for them to be included in the same view. You could for example require that the property CustomerID matches on all events in the view, thereby creating a view which contains events about the same customer.
• The assert property defines an XPath expression that must evaluate to true for all instances of a specified event type. The assert property could for example be used to compare a certain element in the event body with a constant.

<ViewDef name="ZoneEntry"> <Properties> <!– All events in the view must be of types InsideZone or OutsideZone –> <Type> <Event> <XPath>EventDef[@eventType="InsideZone"]</XPath> </Event> <Event> <XPath>EventDef[@eventType="OutsideZone"]</XPath> </Event> </Type> <!– All events in the view must be from the same vehicle –> <Match name="vehicle"> <Value> <Event> <XPath>EventDef[@eventType="OutsideZone"]</XPath> </Event> <Property name="Vehicle"/> </Value> <Value> <Event> <XPath>EventDef[@eventType="InsideZone"]</XPath> </Event> <Property name="Vehicle"/> </Value> </Match> <!– All events in the view must be from the same zone –> <Match name="zone"> <Value> <Event> <XPath>EventDef[@eventType="InsideZone"]</XPath> </Event> <Property name="Zone"/> </Value> <Value> <Event> <XPath>EventDef[@eventType="OutsideZone"]</XPath> </Event> <Property name="Zone"/> </Value> </Match> <!– Keep only the last 100 events in the view –> <MaxCount>100</MaxCount> </Properties> </ViewDef>

Situation

A situation describes an interesting combination of multiple events as they occur over time. The situation detection capability of Reakt have the following features.

1. Declarative – Complex situations are described using a high level declarative approach, avoiding complex procedural solutions using traditional programming languages.
2. Temporal support – Support for describing temporal relationships between events. Timing restrictions such as deadlines for detection can easily be added.
3. Extensible – The situation detector is designed to be extended with new task specific detector nodes.
4. Monitoring – The detector is designed to be monitored and thus the progress of situation detection can easily be tracked.

As a situation describes an interesting combination of multiple events as they occur over time, it must start somewhere. A situation starts developing when a specific initiator event occurs. This is the first event in what could possibly be a fully developed situation consisting of multiple events. This also means that a situation has an exact point in time where is starts developing, namely the timestamp of the initiator event. The situation develops over time and can either be detected at some point in time or automatically determined to be undetectable. A situation can develop over long periods of time and consist of a large number of contributing events. The ruleCore CEP Server provides a persistent rule state allowing rule instances and their situations to survive restarts and unexpected crashes. The progress of a situation, as it develops, can be followed by submitting a query event to the ruleCore CEP Server about the state of a particular rule’s situation detector. The degree of completion of a situation can be monitored to provide an early warning about a situation which could possibly be detected soon. For example, detect when a vehicle has been outside a zone for at least five seconds: <SituationDef name="OutsideZone5s"> <Detector> <After timeframe="00:00:05"> <Not> <EventPickup> <XPath>Views/View[@default='true']/Events/Event[@eventType="InsideZone"]<XPath> </EventPickup> </Not> </After> </Detector> </SituationDef> The above situation example is detected when the innermost event pickup does not pick up any events from the view five seconds after the rule instance was created. If InsideZone events have arrived into the view during those five seconds the situation is not detected. A situation is defined using a tree with detector nodes. The <Detector> node is the root of the situation detector. Each node can be either true or false depending on its semantics. One of the central detector nodes is the <EventPickup> node which selects events from the view. It selects events by executing a XPath query against the view. If the query returns any events from the view, the <EventPickup> node becomes true. The detector is evaluated each time it is possible that changes in the view or temporal conditions in detector nodes can affect the state of the detector.

Action

Actions are executed as the last part of a rule’s evaluation in response to a detected situation, or optionally when it is determined that a partially detected situation can’t be detected at any point in the future. An action is used to create a new event. The new event is called the reaction event and is used to notify external systems about a detected situation. Different events can be created for a detected situation and for undetectable situations. The outbound event created by the action is created using a XSLT stylesheet. The stylesheet is executed in the context of the rule and can access all the events that contributed to the detection of the situation. The stylesheet can also access the events present in the view at the time the action is evaluated.

Reakt is a trademark of Rulecore KB of Sweden. Rulecore is a registered trademark of Rulecore KB of Sweden

• A small tailor made language. Maybe looking something like Erlang or F#? 
• A formally defined model specially developed for event processing, think of the relational model as comparison, which provides a solid foundation.
• Small light weight libraries which contains the essentials needed for event processing. Used as a base for complete stand alone server of to implement CEP functionality in various kínds of applications.
• Services for processing live data targetting various domains. Like finance (already happening?), logistics, sensor networks, SCADA and that kind of things.
• More specialised CEP tools which solve one particular problem in the CEP domain. For example event enrichment or aggregation. One size does not fit all, as the database community already knows.
• Better GUI concepts, the ones today are too low level.

So, where’s CEP heading? 

That’s a question that I’m asked a couple of times each week. Those that know a bit about CEP are a bit worried that the current solutions have not caught on. Sure, in some sectors they have. For example in the capital markets there are now a decent number or installations from several vendors. But the real mainstream adaptation is not here if you ask the outsiders. We that work with CEP would really love to hear that CEP is now mainstream, but it is not there yet.

At least CEP have left the early adopter stage, the startups are now acquired or living a post-startup life. That is, those that are still alive.

It seems that those that made it as ‘independent’ vendors, have gone after a solution approach and sell more of a solution to a specific domain instead of pure technology.

Many of the bigger vendors have now some kind of CEP capability to offer. Most of them bought one of the smaller vendors a while ago. Notably Microsoft seem to have created StreamInsight inhouse. But from what I hear, none of the big vendors are selling lots of CEP licenses.

So, there is some activity both at the smaller and bigger vendors, but the real rush seems to be a couple of years away.

What I think is required is a better understanding of what CEP is and from that we need to create better tools, using better concepts. The current concepts in CEP looks to me as a first wave of something. Nothing wrong with them. But I would be very surprised if this would be the optimal way to do CEP.

We need better concepts, perhaps an underlying theory and some kind of collecting agreement on what it The Right Way to do CEP. That’s things that will take some time. Perhaps not a valid comparison, but it tool a while before SQL was The Way To Go in the data storage world.

But I’m sure there are interesting concepts coming. The current ideas seems all be rooted in the SQL or rules concepts. But I would love to see a new freash approach to CEP that treats CEP as an own field. I someone would do that I’m sure more creative ideas would emerge than reusing old concepts from other fields.

My be would be to use a small tailor made language as a base and then build some clever abstractions using that… The language has to be small and complete in order to be a good candidate to build future CEP solutions on. Flexible enough to give some headroom to build different kinds of product, but on the same base.

A good idea? A bad one? Do you have other ideas for CEP 2.0?

I tried to look through my google alerts on CEP and there seems not be much exciting news in the world of CEP. The best news is that Event Processing in Action (the book) is ready. I tried to read the PDF, but the acrobat on Linux was so slow that it took a minute or so to turn the page. The pdf format seems to be seriously broken considering other problems like painfully slow search, slower than text search used to be in 1987.

Apart from the book there seems to be very little new cool stuff. The existing projects seems to progress with a steady pace. In some cases there seems to have been very little action lately, but it seems hard for both the commercial vendors and the open source projects to find a way to the minds of the mainstream. Not sure what this is a sign off, have to think about that…

My guess is that the next 12 months will be critical for most CEP vendors and open source projects. I have the feel that there’s a new wave of solutions and tools coming up. It would be interesting to see what v2.0 of the event processing concepts are.

Now time for some CEP googling to get updated…

The blog is taking a short break while I’m relaxing away from office… See you all in the spring..  in a couple of weeks…

Show your latest work here!

   http://2010.ruleml.org/ruleml-2010-challenge.html

I just started to read "Event Processing in Action", the final version. It’s a brand new book coming to your favorite store any day.

I really like this book. It’s so good. This is the kind of book on event processing that I have been waiting for. I think the authors, Opher Etzion and Peter Niblett, really gets event processing.

Hopefully this book will teach many professionals and students that there is something more to event processing than just real-time processing of data. The fact that we are processing events and not data should be obvious as one reads this book.

I wish I had more time to read. But today Sweden is closed. Nobody works. So don’t even think of calling anybody here today. We are celebrating Midsummer’s Eve. One of those really old traditions up here in the north. If you live in a place where it’s dark and cold most of the year you surely appreciate a good party around the time for summer solstice. If I were younger, I would have been drunk all day. Now, it’s more like spending time with my wonderful family and good friends and their kids.

At least a few high-frequency traders have learned to make a killing by detecting the more simplistic algo strategies deployed by basic pension funds and mutual funds, buying the next stock the funds plan to buy, and then selling it to them at a higher price. This may not be illegal, but it’s almost certainly unfair to the funds’ investors. “It is increasingly clear that there are quite a number of high-frequency bandits in the high- frequency-trading community who pump up volume statistics, front-run investor orders, increase transaction costs, and hurt real liquidity,” David Weild, an adviser at Grant Thornton and a former vice chairman of Nasdaq, told me.  – http://www.theatlantic.com/magazine/archive/2010/07/monsters-in-the-market/8122/

When this is what the public reads about CEP, then I think we might have a minor image problem.

StreamInsight webpage (where you can find some more recent information such as white papers, help documents, examples, trial download):

• http://www.microsoft.com/sqlserver/2008/en/us/r2-complex-event.aspx

StreamInsight blog and public forum:

• http://blogs.msdn.com/streaminsight/
• http://social.msdn.microsoft.com/Forums/en-US/streaminsight

Research papers: 

The original CIDR paper (some of the stuff in this paper is out-dated, for example, the presence of transaction-time in the logical tables):

• http://www.cidrdb.org/cidr2007/papers/cidr07p42.pdf

A technical report about some more detailed implementation aspects:

• http://research.microsoft.com/pubs/70517/tr-2007-158.pdf

Two more recent papers from the StremInsight group: 

Recursive query processing in a streaming system with temporal algebra:

• http://research.microsoft.com/pubs/101567/FFP-2009-camera.pdf

A description of StreamInsight and behavioral targeted advertising:

• http://research.microsoft.com/pubs/101568/MicrosoftCEPDemo.pdf

ETALIS is one of them, it is an open source engine for event processing based on the Logic Programming paradigm.

ETALIS engine implements a corresponding “ETALIS Language for Events” that is a rule-based declarative language. ETALIS is a research prototype created by Darko Anicic at FZI Forschungszentrum Informatik an der Universität Karlsruhe.

The ETALIS project is founded on novel algorithms, and implementing event-driven backward chaining rules. The rules enable derivation of complex events in a data-driven fashion. Apart from event processing, ETALIS features strong inference capabilities as well as easy integration with databases and transactions.

Future plans include to develop some unique features of ETALIS that can be particularly efficient or easy implemented in a *logic-based* EP.

For instance, event-driven workflows that are dynamically modified while executing can be one area of research. Workflow modifications, being done on-the-fly, need also to be verified at run time (as changes can disable workflow executions or make it infinite though workflows featured the finite termination property). This is one example where a logic approach can help. Event-driven dynamic workflows are useful in many areas including edBPM, Cloud Computing etc.

Another use of ETALIS logic approach in EP is related to event revision and world of database transactions. ETALIS can handle transactions in a logic framework. When transactions are mixed with event processing, event revision become necessary. Transaction are executed in the all-or-nothing fashion. Now events that are triggered during executions of some transactions, that later turned out to be unsuccessful, need to be retracted (in the same vain as transactions are rolled back). These events can be already used in building more complex events. This implies that also these complex events should be retracted too. ETALIS is using the logic to find out the consequences of events retractions on other more complex events.

It’s nice to seen the addition of another declarative CEP rule languate apart from the Reakt language implemented by the ruleCore CEP Server. Even though both languages are rule based and declarative it shows that ETALIS comes from a more formal and theorethically correct research world whereas the Reakt language was designed by software developers without too much concerns of formal correctness.

I will follow ETALIS with great interest as I think it could evolve into a really powerful language.