Geeks With Blogs

News
Charles Young
My fellow BizTalk MVP, Leonid Ganeline, asked if I would comment further on mechanisms to govern sequential flow in rules in MS BRE.    He was picking up on some comments I made in my article comparing WF and MS BRE rule performance (see http://geekswithblogs.net/cyoung/archive/2007/08/12/114597.aspx#143628).
What I had in mind was the use of state transition patterns within rule sets.   These can be used to layer a degree of sequential control over the set-based pattern matching approach taken by engines like MS BRE.   The basic pattern is simplicity itself, and very common.     What I generally do is assert an additional 'context' fact to the engine (typically some custom .NET object) in which I maintain a state specifier (e.g., a simple string property).   I can then group rules together to match specific states, and use a low-priority rule in each group to change the state.   The 'sequential' flow is then governed by the state transitions.   Of course, any single group of rules that match the same state do not operate in a sequential fashion amongst themselves.   However, you can always just have one main rule per state if you wish.   Here is a very, very simple example of the kind of pattern I have in mind.

/*********************************************
 * Group 1 - 'Started' state
 ********************************************/
 
Rule 1
IF
 AND
    Context.CurrentState == "started"
    MyFactA.Property1 > 5
    MyFactB.Property1 < MyFactA.Property
THEN
 MyFactB.Property1 = MyFactA.Property1
 assert MyFactB
 
Rule 2 (priority -1)
IF
 Context.CurrentState == "started"
THEN
 Context.CurrentState = "initialised"
 assert Context
 
/*********************************************
 * Group 2 - 'Initialised ' state
 ********************************************/

Rule 3
IF
 AND
    Context.CurrentState == "initialised"
    MyFactA.Property2 == "USA"
THEN
 MyFactA.SetCountryCode("01")
 
Rule 4
IF
 AND
    Context.CurrentState == "initialised"
    MyFactA.Property2 == "UK"
THEN
 MyFactA.SetCountryCode("44")
 
Rule 5 (priority -1)
IF
 Context.CurrentState == "initialised"
THEN
 Context.CurrentState = "completed"
 assert Context
 assert MyFactA  // convenient place to re-assert MyFactA 
                        // to avoid loops if, for example, 
                        // MyFactA.SetCountryCode() changes the 
                        // state of MyFactA.
 
/*********************************************
 * Group 3 - 'Completed' state
 ********************************************/
 
Rule 6
IF
 AND
    Context.CurrentState == " completed "
THEN
    MyFactA.Property1 = 0 
    MyFactB.Property1 = 0
 
/********************************************/

The low-priority ‘state transition’ rules are rules 2 and 5.   Group 2 contains two main rules, whereas the other groups have just one main rule.
Personally, I think MS BRL (and the Rules Composer) should provide a built-in abstraction for this design pattern - i.e., provide a way of grouping rules by state, and declaring how to transition to a new state when a group has completed its work.   If this was supported, it would not be necessary to explicitly define an additional low-priority rule in each group.
This design pattern can be a little difficult to maintain in MS BRE currently because the rule composer displays rules in alphabetic order in the UI, regardless of the order in which you created them, and so you cannot see the groupings and state transitions.   The answer to this, of course, is to adopt a rule naming convention which makes the pattern more explicit in the UI.
I used this design pattern recently when creating a rule set for applying Bayes Theorem.   See   http://geekswithblogs.net/cyoung/archive/2007/08/27/114988.aspx.   The rule set was written for other rule engines (Jess and CLIPS), but uses exactly the same principle.   I have ported the rule set to MS BRE, but just need to clear a potential commercial hurdle before publishing the code.
You can download a slide set for a presentation I gave earlier this year at an architect's conference from http://download.microsoft.com/documents/uk/msdn/architecture/architectinsight/2007/collaboration/COL01-Rules-Processing-in-Business-Processes.ppt.   There is a slide in the set which illustrates how a declarative rule set might map onto a process (I've used a BizTalk orchestration to represent the process).
Posted on Sunday, September 16, 2007 1:06 PM Microsoft Business Rule Framework | Back to top


Comments on this post: MS BRE: State Transition Pattern

# re: MS BRE: State Transition Pattern
Requesting Gravatar...
Thanks Mark

I'm aware of Drools RuleFlow, and consider this to be a really good idea - a higher-level abstraction of the sort I talked about in the post. It's good to see this kind of innovation in the world of rule engines. I think I'm right in saying (I'm sure you'll correct me if I'm wrong) that RuleFlow is implemented in terms of conditional chaining of rule-sets - i.e., each rule group is treated, in effect, as a discrete rule set, and the RuleFlow governs the sequential invocation of those rule sets. The pattern I describe is a little different, and builds rule groups into a single rule set, using 'semaphore' rules to govern state transitions. Comes to much the same thing, ultimately. Indeed, although I would previously have assumed that the design pattern above is the more efficient approch, I'm not so sure, after my recent investigations into performance, that this is bound to be the case, and even if it is, the overhead of chaining rule sets as per RuleFlow is likely to be so low as to be insignificant.

It's worth noting, in addition to what I wrote above, that the policy chaining approach, which is a technique illustrated in a Microsoft SDK example application, is another approach that could be used in MS BRE to implement a sequential pattern of processing. In Microsoft's sample code, the chaining is controlled by asserting policy objects as facts, and using rules to select and execute those policies. This, I think, is again slightly different to the RuleFlow approach which I think controls chaining outside of the rules engine. Again, it comes to much the same thing, though.
Left by Charles Young on Sep 16, 2007 11:26 PM

# re: MS BRE: State Transition Pattern
Requesting Gravatar...
Here is some history on using RETE engines to handle scenarios that are "state machine" like. One of the first is to use a control fact like Context.currentState, which gives you the ability to control state within a single ruleset. The real downside is it can stress the agenda. If a rule engine doesn't implement an efficient agenda, using a control fact approach can end up having a major performance impact. For an engine that has efficient agenda, it's not an issue.

The second is to divide the rules into modules and control the flow by switching focus. This technique goes back to ART and CLIPS. One reason auto-focus was invented, was to make it easier to do flow control. The downside of using modules to do flow control or immitate state machine is that rules that match fully will get added to the agenda. In some cases, that may not be efficient if the rules in a given model might never fire.

A third approach is to do a hybrid. It's difficult to say which method is better. My thought is to look at the actual use case and determine that case by case. Another option is to generate a specialized discrimination network that is taylored specifically for the flow. By specialized, I don't mean RETE. If a process is has states that are rarely used at runtime, it doesn't make sense to evaluate those rules. Just some random thoughts
Left by peter lin on Sep 18, 2007 1:15 AM

# re: MS BRE: State Transition Pattern
Requesting Gravatar...
Good stuff, Peter. Thanks.
Left by Charles Young on Sep 18, 2007 9:37 AM

# re: MS BRE: State Transition Pattern
Requesting Gravatar...
No this is faster and more efficient than using a semaphore, which as Peter states is heavy on the agenda; nor are the rulesets chained. It's actually an extension of how agenda-groups (which Drools also supports), or modules as Jess/Clips call them and mentioned in peter's second paragraph, but instead of a stack in the case agenda-groups it's a linear definition.
Left by Mark Proctor on Sep 19, 2007 2:42 AM

# re: MS BRE: State Transition Pattern
Requesting Gravatar...
I forgot one more technique in the list. A forth technique is to compile rule flows into separate RETE networks. The flow is controlled by the engine. This is similar to what Mark describes. In fact, he and I discussed this several times last year. As far as I know, ART was doing this a long time ago, so it's not new. Those who have been around 15-20 years and worked at ART would recognize this as old stuff. I first came across these techniques in 2001 working with Said Tabet, who worked at both Inference and ART.
Left by Peter Lin on Sep 19, 2007 5:10 AM

# re: MS BRE: State Transition Pattern
Requesting Gravatar...
I think the Hybrid method is the best,but it is just they way we have always done this type of thing.
Left by Kennesaw Georgia Real Estate on Feb 05, 2008 3:12 AM

# re: MS BRE: State Transition Pattern
Requesting Gravatar...
ILOG Rules for .NET supports this pattern. In a ruleflow, you can define your state conditions up front as transitions. The transitions in turn will only fire tasks in the ruleflow as needed. The transitions may reason on any state data within your object model. Moreover, the tasks that fire are able to dynamically select rules or fire a pre-defined set of rules.
Moreover, you can choose to use Rete in any of the tasks to take advantage of its highly optimized agenda (RetePlus) or use sequential execution.

http://www.ilog.com/documentation/rulesnet30/HTML/tutrnt/tutrnt_ruleflows6.html

http://www.ilog.com/documentation/rulesnet30/HTML/usrstd/usrstd_rf16.html



Left by Chris Berg on Sep 24, 2008 9:34 PM

# re: MS BRE: State Transition Pattern
Requesting Gravatar...
Thanks Chris

Several engines provide built-in ways to handle this pattern. MS BRE is not very sophisticated in this respect, but maybe will be extended one day to handle this better.
Left by Charles Young on Sep 25, 2008 9:29 AM

Your comment:
 (will show your gravatar)


Copyright © Charles Young | Powered by: GeeksWithBlogs.net