Today I have broken life-long record in the length of a single session with the dentist --- more than 3 hours (I had to go out in the middle and restart the parking card which allows 2 hours at a time); this is time of setting up plans for next year and there are plenty of plans --- to be involved in 1/3 of my time in some activity, only when the number of "1/3 of your time" becomes bigger than 3, then the phrase "1/3 of your time" becomes tricky. Anyway -- today I would like to write about "event-at-a-time" and "set-at-a-time" processing, as it seems that people don't understand this issue well. We'll take it by examples:
- "event-at-a-time" is a processing type in which when an event is detected, this event is evaluated against the relevant patterns to determine if the addition of this event (together with possible more events) satisfies the pattern.
- "set-at-a-time" is a processing type in which patterns are evaluated against a set of events after all the set has been detected.
Examples:
- look at the pattern: And (E1, E2) -- when the relevant instance of E1 arrives this becomes a potential pattern, whe
never the relevant instance of E2 arrives - then the pattern is satisfied. A concrete example: E1 = the buyer received the merchandise, E2 = the seller received the money for the same transaction. The order does not matter - the transaction is closed if both of them occurred. This is an "event-at-a-time" processing since it looks at each event individually when it comes and determined what is the state of that pattern- instance. - look at the pattern: Increasing (E1.A) -- when the set of all relevant instances of E1 arrives - then the evaluation is done on the entire set. A concrete example: E1 = Temperature measurement, A = Value. When all the values (e.g. in a specific time window) arrive, there is an ability to determine if the values are indeed always increasing in time.
It is interesting to point out that patterns that are geared towards "event-at-a-time" can be implemented as "set-at-a-time", in this case, looking for patterns periodically instead of immediately, note that "set-at-a-time' does not necessarily means : time series processing, the size of the set may be unknown in advance, and the time difference between the different elements in the set may not be fixed.
It is also possible to implement "set-at-a-time" patterns using "event-at-a-time" - in an incremental fashion.
While some applications are better handled easily and more efficiently by one of these two styles -- some applications will need both, so hybrid processing will be required for those.
More on this - later.
4 comments:
Does the distinction between "event at a time" and "set at a time" depend on your representation of time?
When I was doing Year2000 work for a major supermarket chain, we looked at the following example. If one freezer breaks down at a minute past midnight, that is an event of type A. If say a hundred freezers all break down at the same time, that is not a hundred independent instances of a type A event, but a single instance of a type B event.
But of course the messages events don't all arrive simultaneously. You can't infer a type B event from a single report, but you don't wait until you have a hundred reports either. So the point at which the set is complete is indeterminate. We have what Lacan calls "a moment to conclude".
Hi Richard. The "set at a time" vs. "event at a time" is not related to the representation of time, but to the way that the event processing software works. There are processors that are working evet-at-a-time and those working in "batches" of event, typically those whose language is based on SQL.
cheers,
Opher
I accept that your starting point is the functionality of the event processing software, but surely there is some difference in the business requirements and/or external system behaviour that corresponds to these two implementation patterns?
Another related issue is of what we might call event smoothing. For example, measuring the fuel in the tank when the fuel is sloshing around. Or catching speeding motorists based on average speed rather than spot cameras. So there is some algebra (possible a form of calculus) that converts a set of events into a single event.
Hi Richard. As there are no benchmarks or good classification of applications, my observation is that sometimes people are hacking software written with other assumptions in mind to perform their requirements. I hope that when the dust clears on the classification issue - there will be better correlation. As for the second part -- sure, set of events can be reduced to a single derived event. I'll write about derivations in one of the next postings.
stay well,
Opher
Post a Comment