<HTML xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<HEAD><!-- Template generated by Exclaimer Template Editor on 11:17:06 Saturday, 2 February 2013 -->
<STYLE type=text/css>P.dea69ab5-aeea-474e-a86f-14b336b4c86b {
MARGIN: 0cm 0cm 0pt
}
LI.dea69ab5-aeea-474e-a86f-14b336b4c86b {
MARGIN: 0cm 0cm 0pt
}
DIV.dea69ab5-aeea-474e-a86f-14b336b4c86b {
MARGIN: 0cm 0cm 0pt
}
TABLE.dea69ab5-aeea-474e-a86f-14b336b4c86bTable {
MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
page: Section1
}
</STYLE>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<meta name="Generator" content="Microsoft Word 12 (filtered medium)" />
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Lucida Console";
panose-1:2 11 6 9 4 5 4 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:14.0pt;
font-family:"Lucida Console";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Lucida Console";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</HEAD>
<BODY lang="EN-US" link="blue" vlink="purple">
<P>
<div class="WordSection1">
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>Nice. Very straight forward too.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>To summarize my understanding:<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>Given an initial "business rule" all that has to be done is to implement a Fluent Builder tool that generates the business rule re-write as<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>1. an initial root rule (e.g. "car"), that when fired activates a "Collector"<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>2. a set of n extended rules (1 for each L-Value predicate participant in the original business rule)<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>3. whenever rule i (of the n extended rules) matches, rule i does Collector booking in its RHS consequence processing. (accounting for predicate participant i)<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>4. generate a final set of rules that match on the Collector’s account of success/failure and reports on any specific details of that accounting in these final set of rules’
callback(s) to the Collector implementation (e.g. your RHS invoke of Collector.missing() to render “price > 1000” as point of failure)<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>I think I get it, starting to exercise this now.<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>THANKS WOLFGANG!<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D>P.S. Wolfgang, do you have any comment wrt to using WM Listener(s) and their event callback processing (in conjunction w/ this pattern) as an effective tactic for helping
to account/audit for when rules fail to fire?<o:p></o:p></span></p>
<p class="MsoPlainText"><span style=font-family:"Calibri","sans-serif";color:#1F497D><o:p> </o:p></span></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">-----Original Message-----<br />
From: rules-users-bounces@lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Wolfgang Laun<br />
Sent: Saturday, February 02, 2013 5:26 AM<br />
To: Rules Users List<br />
Subject: [rules-users] How to track constraint truth [was: Non short circuit ANDing]<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">To summarize the discussion of the major part of the cited thread:<o:p></o:p></p>
<p class="MsoPlainText"> * There are situations when it is of interest to learn which of the several constraints of a rule are true and which block it from firing.<o:p></o:p></p>
<p class="MsoPlainText"> * It is known that manually writing a set cooperating rules can solve this problem (e.g., Rule Design Pattern "Learning the Reason for<o:p></o:p></p>
<p class="MsoPlainText">Failure")<o:p></o:p></p>
<p class="MsoPlainText"> * Some automatism supporting the creation of such a set would help<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Considering such a support, one wonders which level of complexity in the primary rule it must be able to handle. The task in itself procures a limitation, e.g., when one pattern must match so that a binding is available which is used
in a successive pattern. (More<o:p></o:p></p>
<p class="MsoPlainText">formally: the dependency graph of bindings restricts the investigation of the truth of LHS sub-terms.) Furthermore, any solution using reverse-engineering from the internal representation of a LHS isn't simple, and the API for accessing
a compiled rule isn't "stable".<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">But I think that simple scenarios can be handled by a simple rule authoring tool. I'll explain this by using an example: a rule investigating offered cars according to a buyer's wishes:<o:p></o:p></p>
<p class="MsoPlainText">class Car {<o:p></o:p></p>
<p class="MsoPlainText"> String colour;<o:p></o:p></p>
<p class="MsoPlainText"> int price;<o:p></o:p></p>
<p class="MsoPlainText"> int horsepower;<o:p></o:p></p>
<p class="MsoPlainText"> boolean abs;<o:p></o:p></p>
<p class="MsoPlainText">}<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">rule "car"<o:p></o:p></p>
<p class="MsoPlainText">when<o:p></o:p></p>
<p class="MsoPlainText"> $car: Car( colour == "red", price < 1000, horsepower >= 150, abs == true ) then ... end<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">To permit the individual investigation of constraints, this might be rewritten as:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">rule "car"<o:p></o:p></p>
<p class="MsoPlainText">when<o:p></o:p></p>
<p class="MsoPlainText"> $car: Car()<o:p></o:p></p>
<p class="MsoPlainText">then end<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">rule "car colour == \"red\"" extends "car"<o:p></o:p></p>
<p class="MsoPlainText">when<o:p></o:p></p>
<p class="MsoPlainText"> Car( this == car, colour == "red" )<o:p></o:p></p>
<p class="MsoPlainText">then // Gosh, a red one!<o:p></o:p></p>
<p class="MsoPlainText">end<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">rule "car price < 1000" extends "car"<o:p></o:p></p>
<p class="MsoPlainText">when<o:p></o:p></p>
<p class="MsoPlainText"> Car( this == car, price < 1000 )<o:p></o:p></p>
<p class="MsoPlainText">then // Hey, it's cheap enough!<o:p></o:p></p>
<p class="MsoPlainText">end<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">And so on. - For a fully automatic process, a "Collector" fact has to be maintained for each fact (or Cartesian product of facts) matching the initial rule (i.e., "car"). Into this Collector, positive results from the extending rules
are injected, so that, ultimately, it can be examined for full information. Here's a couple of examples of rules doing just that, with the rule id and failure count as positional<o:p></o:p></p>
<p class="MsoPlainText">properties:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">rule "success"<o:p></o:p></p>
<p class="MsoPlainText">when<o:p></o:p></p>
<p class="MsoPlainText"> $c: Collector( "car", 0; )<o:p></o:p></p>
<p class="MsoPlainText">then<o:p></o:p></p>
<p class="MsoPlainText"> System.out.println( "Found the car I want: " + $c.get( "car" ) ); end<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">rule "almost"<o:p></o:p></p>
<p class="MsoPlainText">when<o:p></o:p></p>
<p class="MsoPlainText"> $c: Collector( "car", 1; )<o:p></o:p></p>
<p class="MsoPlainText">then<o:p></o:p></p>
<p class="MsoPlainText"> System.out.println( "Almost the car I want: " + $c.get( "car" ) );<o:p></o:p></p>
<p class="MsoPlainText"> $c.missing();<o:p></o:p></p>
<p class="MsoPlainText">end<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Given the Car( "red", 1200, 160, true ), the second rule fires and produces:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Almost found the car I want: Car [colour=red, price=1200, horsepower=160, abs=true]<o:p></o:p></p>
<p class="MsoPlainText">missed: price < 1000 in Car<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">How to write the original rule is the last point. The actual user interface could be simpler, but here is a basic fluent API:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">public String makeRuleText(){<o:p></o:p></p>
<p class="MsoPlainText"> RuleSet ruleSet = new RuleSet( "com.sample", "car" )<o:p></o:p></p>
<p class="MsoPlainText"> .add(new BasicPattern( "car", Car.class ) )<o:p></o:p></p>
<p class="MsoPlainText"> .add( new Constraint( "colour == \"red\"" ) )<o:p></o:p></p>
<p class="MsoPlainText"> .add( new Constraint( "price < 1000" ) )<o:p></o:p></p>
<p class="MsoPlainText"> .add( new Constraint( "horsepower >= 150") )<o:p></o:p></p>
<p class="MsoPlainText"> .add( new Constraint( "abs == true" ) );<o:p></o:p></p>
<p class="MsoPlainText"> return ruleSet.toString();<o:p></o:p></p>
<p class="MsoPlainText">}<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Cheers<o:p></o:p></p>
<p class="MsoPlainText">Wolfgang<o:p></o:p></p>
<p class="MsoPlainText">_______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">rules-users mailing list<o:p></o:p></p>
<p class="MsoPlainText"><a href="mailto:rules-users@lists.jboss.org"><span style=color:windowtext;text-decoration:none>rules-users@lists.jboss.org</span></a><o:p></o:p></p>
<p class="MsoPlainText"><a href="https://lists.jboss.org/mailman/listinfo/rules-users"><span style=color:windowtext;text-decoration:none>https://lists.jboss.org/mailman/listinfo/rules-users</span></a><o:p></o:p></p>
</div>
<BR /><BR />
<HR id=HR1 />
<BR /><SPAN style="FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt">NOTICE:
Morgan Stanley is not acting as a municipal advisor and the opinions or views
contained herein are not intended to be, and do not constitute, advice within
the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer
Protection Act. If you have received this communication in error, please destroy
all electronic and paper copies and notify the sender immediately.
Mistransmission is not intended to waive confidentiality or privilege. Morgan
Stanley reserves the right, to the extent permitted under applicable law, to
monitor electronic communications. This message is subject to terms available at
the following link: <A style="FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt" href="http://www.morganstanley.com/disclaimers">http://www.morganstanley.com/disclaimers</A>
If you cannot access these links, please notify us by reply message and we will
send the contents to you. By messaging with Morgan Stanley you consent to the
foregoing.</SPAN><BR />
<P></P>
<P></P></P></BODY>
</HTML>