What Defines Complexity in Rule Processing?
In GPS, GeoLogging and CEP I was really impressed with the movement toward multisensor data fusion and situation detection as commented by Alex and Marco. Both Alex and Marco realize that basic track-and-trace tends to be a supporting role in many CEP applications; and that one core functionality that “graduates” an application to a “CEP application” is the degree of complexity in the object-object situation refinement. (Note: there are some classes of tracking that are quite complex, for example Kalman Filters).
It appears to me that both Alex and Marco tend to agree that simple rule processing, an important subclass of event processing, does not necessarily automatically “graduate” an application to the status of “complex event processing.” However, as numerous readers have pointed out, processing rules can be quite complex. So, this leads us to the obvious question:
What Defines Complexity in Rule Processing?
I have been thinking about this question, and do not have a good answer. For example, I don’t think we can define “complex” as processing a simple rule or rule-based algorithm against high volumes of events (in a stream). This is not complex, per se. (Software vendors tried this early on and it went over like a lead balloon!)
So, what exactly would be the various parameters we could use to define, precisely, what is complexity in rule processing?
For example, in On rule complexity: A structural approach Dietz says:
This paper first examines existing accounts of rule complexity and presents a conceptual analysis of the term ‘rule’. It then proposes that ‘complex’ should not be equated with ‘difficult’, but used in a purely structural sense. Specifically a conditional formulation is proposed in which the number of concepts in the antecedent and the consequent, the number of subconditions, and the number of ‘if-then’ connections (subrules) within a given rule domain govern complexity.
In another example paper, Complexity Measures for Rule-Based Programs, O’Neal and Edwards said:
Software complexity measures are quantitative estimates of the amount of effort required by a programmer to comprehend a piece of code. Many measures have been designed for standard procedural languages, but little work has been done to apply software complexity concepts to nontraditional programming paradigms. This paper presents a collection of software complexity measures that were specifically designed to quantify the conceptual complexity of rule-based programs. These measures are divided into two classes: bulk measures, which estimate complexity by examining aspects of program size, and rule measures, which gauge complexity based on the ways in which program rules interact with data and other rules. A pilot study was conducted to assess the effectiveness of these measures. Several measures were found to correlate well with the study participants’ ratings of program difficulty and the time required by them to answer questions that required comprehension of program elements. The physical order of program rules was also shown to affect comprehension. The authors conclude that the development of software complexity measures for particular programming paradigms may lead to better tools for managing program development and predicting maintenance effort in nontraditional programming environments.
A quick survey of various authors on the topic of rules and complexity yields a number of interesting papers, but I did not come up with anything (yet) that would directly answer the question at hand, What Defines Complexity in Rule Processing?
Please post your thoughts and references.
Filed under: Analytics, Complex Event, Complex Event Processing, Event Processing
?????? ?? 13.11.2008. Complex Event Processing…
Complex Event Processing in the Real World - ???????? ?? ?????????? ???????? ?? ????? Oracle; Cyberstrategics…
Hi Tim
Here are a couple of observations.
You say “I don’t think we can define “complex” as processing a simple rule or rule-based algorithm against high volumes of events (in a stream). This is not complex, per se.” I totally agree, and I think few people in the rule processing community would disagree.
Many production systems use simplistic measures of complexity applied to individual rules. For example, they may use a count of the number of conditions, or the number of tuples matched and/or affected by a rule. These per-rule measures are typically used to drive conflict resolution strategies on the agenda. They do not, however, provide a reliable measure of the overall complexity of a rule-processing task.
The quote from O’Neal and Edwards broadens the scope of the notion of complexity to encompass a rating for the entire rule-based computation. I’ve never, myself, tried to formally quantify complexity or correlate it to relatively simplistic measures in this way, and it’s interesting that the authors claim to have found such correlation possible.
Some of the things I would consider to broadly indicate complexity in a typical forward-chaining engine are:
a) The number of distinct ‘types’ that a rule system processes.
b) The variation in the patterns of rule matching. A rule set with 10,000 highly similar rules may well be considered less ‘complex’ that a ruleset with 20 very different rules.
c) The number of joins that must be performed between sets of data tuples.
d) The degree of modification of data that will occur during rule processing which will result in re-evaluation of rule conditions. This is closely related to the mount of forward chaining and the the complexity of inferencing.
e) The degree of existential and/or universal quantification required during rule processing.
f) The degree of dependency on specific conflict resolution strategies (which tend to be rather opaque) to ensure correctness.
To this, you might add practical development consideration that may be specific to particular rule-processing systems, such as object-relational mappings, mapping to hierarchical structures such as XML, interaction with external systems and services (including external data stores), etc.
This list is hardly exhaustive, and is very biased towards a specific class of rule engine (i.e., Rete-based forward-chaining engines). Users of other types of rule processing technology would probably have a different perspective. I have no particular approach to offer in regard to formally quantifying complexity based on the above list. I tend to use these kinds of consideration to form a broad opinion of how complex a rule-set is.
It’s interesting to consider ‘complex event processing’ in this light. What originally grabbed my attention about CEP is that it is founded on the notion of inference based on pattern-matching (something familiar to many rules-processing people). Patterns of events from multiple sources are detected, and higher-order events are inferred. Having read your blog for some time, I have long-since grasped that CEP challenges vendors to support a multi-disciplinary approach which combines event processing (including rule-based event processing) with analytics and other approaches in order to deal with the complexity of the event cloud. And maybe, ultimately, that indicates an answer to your question. Maybe the real measure of rule complexity, or event processing complexity, can be determined simply by assessing the complexity of the problems that are being addressed and the degree of sophistication required to do the job. The complexity of event processing is surely a direct reflection of the presence of, and complexity of, the event cloud and the sophistication required to recognise patterns of causality and the higher-order events that arise from this.
PS. For the sake of completeness, another aspect of complexity, which does lend itself to formal quantification, is to analyse asymptotic time and space complexity. These measures are applied widely in computer science to algorithms of many different types. A rule set, processed by a specific engine, may be thought of as an algorithm (or more correctly, a meta-algorithm), and is therefore subject to being measured in these terms. I am, of course, talking about familiar big-O notation.
Hi Charles,
Thanks for visiting and for the well thought out reply. I think you have hit a home run in your reply.
The challenge is getting some of the central CEP players on board. For example, Professor Luckham was just quoted as saying:
What is a complex event? It is an event that could only happen if lots of other events happened,” answered David Luckham, author of the book The Power Of Events and professor emeritus at Stanford University
Ref: http://complexevents.com/?p=507
This definition of CEP is too broad to the point of being meaningless. These types of quotes do not help further the cause of CEP, in my opinion.
For example, if we have a network management platform that turns yellow after it receives 50 alerts from a single device, this would be a complex event according to what Professor Luckham told the press.
These types of simple aggregations do not define neither a complex event nor complex event processing. You said (above):
“What originally grabbed my attention about CEP is that it is founded on the notion of inference based on pattern-matching (something familiar to many rules-processing people). Patterns of events from multiple sources are detected, and higher-order events are inferred. Having read your blog for some time, I have long-since grasped that CEP challenges vendors to support a multi-disciplinary approach which combines event processing (including rule-based event processing) with analytics and other approaches in order to deal with the complexity of the event cloud.”
You are correct, but a number of CEP leaders, will not take such a stand. Professor Luckham refuses to comment, I assume because he does not want any conflict with the vendors (logos) that support his site (partners), and makes very broad statements that translate to “roll your mouse across your mouse pad is CEP”.
Clearly, we have a problem in the CEP space when folks try to make the definition of CEP so broad, that everything that involves processing more than one event is CEP, even if it is simply counting, aggregation, routing or tracking multiple events from a single source. I like David and have a great deal of respect for him; but he has clearly moved from academics, AI and a CEP “purist” to software marketing.
Thanks for bringing knowledge and independent thinking into the discussion, Charles.
Yours sincerely, Tim
Tim, I absolutely agree on your assessment of the confusion brought to the CEP world by too broad, not precise enough definitions. Those do not help.
Carlos