Mutability and aggregations

[woolfel]

I haven't had time to finish the power of events, but I thought I'd ask this questions anyways. Going back to the trading example. Say we want to know what the average bid/ask price is and compare it to the actual transaction price. Assuming the system allows the user to cancel a bid/ask, "should the system recalculate the aggregate?"

Humans are error-prone and make mistakes. If the system didn't update the aggregate, the margin of error could increase over time. Say we have a rule that gets a running average every 10 minutes, 20 minutes, 30 minutes and hour.

At T0 Joe Trader enters a buy order for 100,000 shares of IBM.
At T1, Joe's boss notices he made a mistake and tells joe
At T2 Joe cancels the order and changes it to 1,000 shares of IBM.

From a business perspective, I want the aggregates to be correct. This means the system must recalculate any aggregate related to that transaction. From an end user perspective, I see several challenges.

1. how should the EP language handle this?
2. if the EP language allows extensions and/or built in libraries for calculations, how should the system handle this? Clearly, we need to tell the system the corrective calculation for each function. We might have average and updateAverage.
3. In the situation where other rule uses the average, the system needs to provide Logical truth maintenance. My question is this, "Which CEP engines support logical truth maintenance?" If a CEP engine doesn't provide logical truth maintenance, my question is "why? and what is the justification?"

Related to the issue of mutability is temporal versioning. If the user wants to see the cause of any given event at any given time, the system must provide temporal versioning. If it doesn't, it wouldn't provide accurate information. How many CEP engines address these issues?

I ask because the last 8 months I've been building a multi-dimensional temporal versioning system in my day job. I'm curious to hear if other people have ventured into these issues in the context of event processing.

peter

[hgilde]

Some products support the situation you are talking about. But note that many EPLs do not have the concept of truth. They process events as data, not facts.

Taking a step back to think about your particular scenario, I wonder if such a system is needed. I wonder what kind of average is being calculated in this case, because the answer will determine how a cancel maps into the average. For example, the cancel could map in as simply a negative value that would cancel out the previous positive value. From a market perspective, it is likely that the value should be included in the average forever, because it was a live order and it doesn't matter that it was a mistake.

I have to say that from my experience, generic temporal versioning sounds better than it really is. It becomes too easy for the human creating the rules to make big mistakes by misinterpreting the effects of multiple updates/versions. Not to mention the exponential increase in the required storage and logic tests for each event. Unless you have a paradigm for describing generic temporal versioning that I don't know of.

The successes that I have seen for temporal versioning are not generic but are geared to a specific goal or a specific type of change that is to be versioned and propagated. Being geared to a specific solution, such things might be hard thing to justify in a general product.

[woolfel]

Some products support the situation you are talking about. But note that many EPLs do not have the concept of truth. They process events as data, not facts.

Taking a step back to think about your particular scenario, I wonder if such a system is needed. I wonder what kind of average is being calculated in this case, because the answer will determine how a cancel maps into the average. For example, the cancel could map in as simply a negative value that would cancel out the previous positive value. From a market perspective, it is likely that the value should be included in the average forever, because it was a live order and it doesn't matter that it was a mistake.

I have to say that from my experience, generic temporal versioning sounds better than it really is. It becomes too easy for the human creating the rules to make big mistakes by misinterpreting the effects of multiple updates/versions. Not to mention the exponential increase in the required storage and logic tests for each event. Unless you have a paradigm for describing generic temporal versioning that I don't know of.

The successes that I have seen for temporal versioning are not generic but are geared to a specific goal or a specific type of change that is to be versioned and propagated. Being geared to a specific solution, such things might be hard thing to justify in a general product.

In my case, the system I'm working on has 2 dimension beyond bi-temporal versioning. I agree that a general purpose temporal versioning system is probably over kill for a CEP product. I ask because I don't know the answer to the question, but feel it is worth discussing.

I suppose one could map cancel such that it becomes a transaction with a negative value, but that feels a bit odd to me. The potential issue I see with mapping is it adds over head to pattern matching. Now we're not matching on the actual transaction, we're matching on a wrapper. To insure the system works correctly, the wrapper object for that transaction has to be uniquely identified and we have to have an efficient way of correlating multiple wrapper object instances for the same transaction. Looking at existing literature on pattern matching, that doesn't feel like a good general purpose solution. This is based on my experience writing rule engines and my current understanding of pattern matching theory.

peter

[guyos]

There is a post from Opher Etzion that is very relevant in my opinion. http://epthinking.blogspot.com/2007/12/on-deleted-event-revised-event-and.html
I am sure there are lots of ways\ideas on how to implement this but first and for most the language needs to support this. For example a cancel order is a converse event of a buy order and therefore the engine will need to cancel the effect of the buy order in an average computation. BTW the cancellation effect can be context based and not cancel all the effects of buy order - perhaps just the average calculation, but in detecting if someone frequently places buy orders and then cancels them we want to identify this pattern and therefore NOT remove the buy order from this pattern.

[DLuckham]

Peter, first of all, could you complete the information necessary to understand your example:

At T0 Joe Trader enters a buy order for 100,000 shares of IBM.
At T1, Joe's boss notices he made a mistake and tells joe
At T2 Joe cancels the order and changes it to 1,000 shares of IBM.

From a business perspective, I want the aggregates to be correct. This means the system must recalculate any aggregate related to that transaction.

What should the values of the aggregates be at X, Y and Z where T0 < X < T1 < Y <T2 < Z?
Your question seems to be about CEP engines having a capability to "change" events, i.e., make them mutable? Do I understand you correctly?
In most systems, any change in an aggregate is a new event.
Old errors should be recorded.
In your example there are events that signify (or record) Joe's actions and Joe's boss' actions. And there are events that record the tracking of the system with aggregate computations.
You say,

if the EP language allows extensions and/or built in libraries for calculations, how should the system handle this? Clearly, we need to tell the system the corrective calculation for each function. We might have average and updateAverage.

I dont understand what you mean by "corrective action".
If you mean changing an event - and here we're talking about event objects that record previous actions - I'd say that was a very dangerous thing to try doing.
Just think of the inconsistencies you can get into.

Any decent CEP engine should allow for calls to library functions supplied by the user, the results of which may be recorded in events, or in state computations that may be used in executing user-supplied rules.
But I would not expect engines to have those function built in.

For example a cancel order is a converse event of a buy order and therefore the engine will need to cancel the effect of the buy order in an average computation. BTW the cancellation effect can be context based and not cancel all the effects of buy order - perhaps just the average calculation, but in detecting if someone frequently places buy orders and then cancels them we want to identify this pattern and therefore NOT remove the buy order from this pattern.

If you cancel a buy order, that's a new event.
If you change an average, that's a new event.
You cannot remove events that have happened.
You cannot delete or reverse history.

Now there are examples where events may be mutable, but the ones I can think of involve uncertainty and probabilistic events (sense: things that may have happened). In these cases it is not clear what actually happened.
This is an area of complex event processing that has not been explored.

[guyos]

If you cancel a buy order, that's a new event.
If you change an average, that's a new event.
You cannot remove events that have happened.
You cannot delete or reverse history.

Deleting is already an implementation discussion and as you point out this would be wrong - you shouldn't change history.
cancel a buy order is a new event but by specifying that it is a converse event of the 'place buy order' event it specifies to undo the effect of the event (and not delete it).
I would expect the implementation to be more of reducing the nominator by the order value and denominator by the order amount and not deleting the event from history. Maybe there are other and better ways to implement this - but thats not the main point here.
In this regards, looking at the second part of my example, you may be using the 'place buy order' event for other patterns even though its effect on the average has been undone
So no intention in deleting\changing history rather a role of an event can change in a pattern upon a new event with a converse relationship.

[DLuckham]

So no intention in deleting\changing history rather a role of an event can change in a pattern upon a new event with a converse relationship.

Not sure what kind of patterns you are thinking about here.
A pattern intended to operate in the kind of "event climate" you describe should express somethng like:
A at T and B at T1 and not Cancel A at T2 where T < T1and T2 <= T1;
A, B and Cancel A are event templates and T, T1 and T2 are time variables.

So A would have to happen first, and if cancel A happened by the time B happened, the pattern would not match. Does this do what you want?

[woolfel]

There is a post from Opher Etzion that is very relevant in my opinion. http://epthinking.blogspot.com/2007/12/on-deleted-event-revised-event-and.html
I am sure there are lots of ways\ideas on how to implement this but first and for most the language needs to support this. For example a cancel order is a converse event of a buy order and therefore the engine will need to cancel the effect of the buy order in an average computation. BTW the cancellation effect can be context based and not cancel all the effects of buy order - perhaps just the average calculation, but in detecting if someone frequently places buy orders and then cancels them we want to identify this pattern and therefore NOT remove the buy order from this pattern.

thanks for link, Opher's entry is relevant.

[woolfel]

Peter, first of all, could you complete the information necessary to understand your example:

At T0 Joe Trader enters a buy order for 100,000 shares of IBM.
At T1, Joe's boss notices he made a mistake and tells joe
At T2 Joe cancels the order and changes it to 1,000 shares of IBM.

From a business perspective, I want the aggregates to be correct. This means the system must recalculate any aggregate related to that transaction.

What should the values of the aggregates be at X, Y and Z where T0 < X < T1 < Y <T2 < Z?
Your question seems to be about CEP engines having a capability to "change" events, i.e., make them mutable? Do I understand you correctly?
In most systems, any change in an aggregate is a new event.
Old errors should be recorded.
In your example there are events that signify (or record) Joe's actions and Joe's boss' actions. And there are events that record the tracking of the system with aggregate computations.
You say,

if the EP language allows extensions and/or built in libraries for calculations, how should the system handle this? Clearly, we need to tell the system the corrective calculation for each function. We might have average and updateAverage.

I dont understand what you mean by "corrective action".
If you mean changing an event - and here we're talking about event objects that record previous actions - I'd say that was a very dangerous thing to try doing.
Just think of the inconsistencies you can get into.

Any decent CEP engine should allow for calls to library functions supplied by the user, the results of which may be recorded in events, or in state computations that may be used in executing user-supplied rules.
But I would not expect engines to have those function built in.

For example a cancel order is a converse event of a buy order and therefore the engine will need to cancel the effect of the buy order in an average computation. BTW the cancellation effect can be context based and not cancel all the effects of buy order - perhaps just the average calculation, but in detecting if someone frequently places buy orders and then cancels them we want to identify this pattern and therefore NOT remove the buy order from this pattern.

If you cancel a buy order, that's a new event.
If you change an average, that's a new event.
You cannot remove events that have happened.
You cannot delete or reverse history.

Now there are examples where events may be mutable, but the ones I can think of involve uncertainty and probabilistic events (sense: things that may have happened). In these cases it is not clear what actually happened.
This is an area of complex event processing that has not been explored.

I apologize for the vagueness. Let me try again. Say we have the following business use case.

At T0, 9:00 Joe Trader enters a buy order for 100,000 shares of IBM.
At T1, 9:14 Joe's boss Dilbert notices he made a mistake and tells joe "Joe, I think you have too many zeros on that order."
At T2, 9:16 Joe updates the order and changes it to 1,000 shares of IBM.

Say we have the following business rule:

if
- the transaction ticker is IBM
- the transaction type is "buy"
- the time is between 9:30 AM and 4:00 PM
then
- calculate the average shares per transaction every 15 minutes

When Joe Trader modifies his transaction, the system should subtract 100,000 shares, add 1,000 shares and recalculate the average. Since 16 minutes passed between T0 and T2, the system needs to find previous aggregate and modify it. In the situation where other rules use that aggregate, the system needs to find those dependencies and see if those results are still valid.

How would people solve this using CEP approach. I can think of several ways of doing this in a product rule engine, which doesn't involve any events at all. I'm curious to see what a CEP solution might look like and whether that approach really makes is simpler. If it doesn't make it simpler, is that the result of a specific CEP language and engine, or CEP methodology.

I agree that you can't change history. There have been times when I wish I could, but that's another story. My question was more specifically, how one would solve it using CEP engine and techniques.

I hope that explanation is less lame.

peter

[DLuckham]

A rule in a "CEP system or engine" is not required to "have events in it" or to be triggered by events.
It can be, e.g., purely a constraint on the state of a system, or an invariant on the values of some set of variables.
The "CEP approach" can be in some situations the same as any other approach.
If events are irrelevant, then don't use them!
I'll look at you example of the trader some more because maybe the timing and sliding time windows is what is at issue.

.