- knowledge-creation rules - rules that create more 'knowledge" - facts, data-elements etc... These rules can use various inference techniques - deduction, induction, abduction...
- behavioral rules - rules that cause something to be done, or prevent something from happen.
The EPL should include constructs with some similarity to these two types, but this does not say that existing rule languages can be taken as a basis, this is because the domain in event processing is events (not facts or data), and that event has a distinct semantics.
- The first type of construct in EPL is the "event derivation rules" which includes transformations (filtering, translation, aggregation, split, and enrichment) - these typically transform an event (aggregation is a special case, we'll dedicate a blog to it), and "pattern based derivation" which derives events, such that the instances of the derivers are selected as part of a detected pattern. We can see that all these types require specialized semantics, thus while there is similarity in ideas - it is not really rule semantics.
- The second is somewhat similar to the "orchestration" constructs of EPL - this is being performed in the leaf of the network - after all derivations occurred, the result event may (conditionally) perform some action related to a consumer (notify, orchestrate etc...), which is also known as ECA rules (event-condition-action). Note, that from architecture point of view, ECA rules are not done in the event processing network (i.e. they are not MEP or CEP), but they occur in the territory of the consumer - at the border of the EPN.
An interesting observation id that Complex Event Processing (CEP) as defined in the glossary, deals with derivation of new events, it is neither an instance nor an extension of ECA rules, since CEP deals with "knowledge creation" and ECA deals with behavior.
Some more discussion on this topics, and relation with "reaction rules" - later.
9 comments:
I've been using RETE based rule engines for 7 years and have implemented my own engine.
I agree rule languages aren't optimal or ideal for expressing event processing. Even though many engines provide collect and accumulate functionality, expressing a rule in those terms is awkward. Lately, I've been comparing StreamSQL and CLIPS inspired languages. Both feel are equally poor at expressing temporal logic.
this is just my opinion, but I think a language taylor for event processing is the best way. for example, it's difficult to express ideas like.
first occurance of a pattern within a given time window
the last occurance of a pattern
all occurances of a pattern
top 5 matches for the pattern within a given time interval
the bottom 5 matches
if the event occurs n times
I'm sure there are other examples, but those are the ones that are on the top of my head at the moment.
The essence of event processing is:
1. Discover
2. Do
This is a bit different from classic BPEL style processing. In BPEL, all of the interactions are fairly well defined beforehand.
In event processing you are typically "constructing" to a pattern, and once recognized (discovered), you want to Do something about it.
This may compel us to want to construct an entirely new language, but at the heart of it all we are constructing a pattern out of data, and there are a few popular data languages out there. But they lack important temporal, ranking and other aspects as you both point out.
Speaking from an adoption point of view... if there are possibilities of extending one or more current languages to include temporal, ranking, and other important features, we will increase the rate of adoption.
If this is reasonable, then the question is --> which data (or other) languages are prime candidates, for which extensions? This will help both developers and vendors alike, and then you can focus on the meaning of the extensions, rather than spend energy justifying a new language.
To Woolfel --
I agree that both CLIPS inspired languaged and streamSQL are both awkward way to express patterns, the new attempt to add patterns to streamSQL seems also awkward. I'll write in one of the next Blogs about pattern languages.
To Harvey - there are attempts to extend SQL, following your type of thinking that it is better to extend a well-known language, but the attempts result in very complex language. There is also a question of "who should compose the patterns" and do this population really know SQL - my next Blog will deal with this issue.
Opher
Hi Opher,
Certain kinds of situations like Trade Alerts Management and Fraud Prevention are cases where I have seen rule engines being used, but many rules end up having a very awkward form.
In my opinion, we will need two things in the current BRMS products.
1. Rule Engines must become Stateful
2. New additional constructs would be required to capture the new rule types and forms that you would encounter in a CEP problem.
And finally I wish you would define business rules from a decision centric perspective rather than a data centric perspective.
Event processing rules and decision management rules are not the same. Event processing using business rules is a good idea and requires some different capabilities, for sure. Once events are processed and correlated, however, there is still a need to take a business decision for which existing business rules products are very effective.
Check out this post on rules and CEP and this one on decision services.
JT
Author of Smart (Enough) Systems
ebizQ blog
I would kindly suggest that your take on Business Rules needs fleshing out. Head over to http://www.businessrulesgroup.org/home-brg.shtml to get more, for you and all your readers.
To James Taylor
I agree, decision rules and CEP are complementary, and decision rules have a role after the event processing is done.
To Dave Wright
Can you be more specific - what exactly need flesh out?
Opher
Post a Comment