<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaTempEditStyle"></style><style title="owaParaStyle"><!--P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
</head>
<body ocsi="x">
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: x-small">
<div></div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma">Hello Devs<a></a><a></a>,</font></div>
<div dir="ltr"><font face="tahoma"></font> </div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma">My name is Justin Holmes and I'm a Middleware Consultant for Red Hat. I'm currently staffed on an engagement that provides a very interesting use case for Drools. In particular, our teams currently believes
that the Drools XML Language would be the best possible solution for one of our problem. We are aware that the Drools XML language has not been developed for sometime and is considered deprecated. Additionally, the application will need to support Drools CEP<a></a><a></a>
functionality in the near future. Before we begin crafting a custom solution, we would like to ask:
<br>
1) Is the XML language truly the best option for our use case? <br>
2) If it is the best option, how do we begin developing the XML language and tools (XMLPackageReader<a></a><a></a>) to fully support at least BRMS<a></a><a></a> 5.2?</font></div>
<div dir="ltr"><font face="tahoma"></font> </div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma"><strong>Context: </strong>
</font></div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma">Client is using Drool 5.1.1 and we are migrating to BRMS<a></a><a></a> 5.2. There are two independent workflows of interest:
</font></div>
<div dir="ltr"><font face="tahoma"></font> </div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma"><strong>1) Rule Authoring and DRL<a></a><a></a> generation</strong>: The rule assets and metadata are kept in a custom format (both relational DB and XML) in order to decouple it from the runtime.
Thus, the client wrote their own GUI and content manager instead of using Guvnor<a></a><a></a>. The custom GUI allows business users to author 3 types of content, as well as rules for these types of content, using a guided-rule editor with domain specific
language. The following steps occur when a user wants to produce a new version of a rule:</font></div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma"><a></a><font color="#000000" size="2" face="Tahoma"><a></a></font><font color="#000000" size="2" face="Tahoma"><font color="#000000" size="2" face="Tahoma">i</font></font>) GUI saves LHS rule logic
in an XML database using MathML<a></a><a></a> (<a href="http://www.w3.org/Math/">http://www.w3.org/Math/</a>), and then saves everything else in a relational database.<br>
ii) iBATIS<a></a><a></a> pulls down the corresponding database and XML entries and populates POJOs<a></a><a></a>. There is 1 class definition per content type.<br>
iii) Cumbersome application code translates POJOs<a></a><a></a> into Drools PackageDescr<a></a><a></a> (~5000 lines of code, not using fluent API). This step produces a very strange and convoluted<a></a> representation of the LHS of each RuleDescr<a></a><a></a>.
It works with DrlDumper<a></a><a></a> 5.1.1 but does not work properly with the BRMS<a></a><a></a> 5.2 version of DrlDumper<a></a><a></a> (MVEL<a></a><a></a> Template). This is the source of our problem.
<br>
iv) PackageDescr<a></a><a></a> is dumped into a valid DRL<a></a><a></a> string with Drools DrlDumper<a></a><a></a><br>
v) Custom content manager does some versioning and then stores DRL<a></a><a></a> in an XML database</font></div>
<font color="#000000" size="2" face="Tahoma">
<div dir="ltr"><br>
<strong>2) Deployment and Runtime: </strong>App is deployed daily and will have dozens of runtimes during that 24 span. When deployed, it pulls all rules from the database and builds several KnowledgePackages<a></a><a></a>, which are cached, and then used throughout
the day.</div>
<p><font face="tahoma"></font> </p>
<p> </p>
<p><strong><font face="tahoma">Proposed Solution:</font></strong></p>
<p><font face="tahoma">Because the app code that performs step iii) is so convoluted and will need to be modified in order to support CEP<a></a>, we want to pursue a more maintainable<a></a> solution to provide the translation and abandon<a></a> the mess that
is already in the application. We feel that rewriting this code with the fluent API is just as dangerous as the present code. Additionally, the rules are far too variable to use Rule templating<a></a>.</font></p>
<p><font face="tahoma"></font> </p>
<p><font face="tahoma">So, we propose to translate the client's custom rule assets and metadata into the Drools XML Language, parse the XML and dump out DRLs<a></a><a></a>. We will likely need to use the existing intermediate POJOs<a></a> for this. The most
difficult piece in the puzzle by far is translating the LHS of rules, and of course this is the part that is broken currently in our system. We believe that it should be MUCH easier to translate the well formatted MathML<a></a><a></a> representation of the
LHS to the Drools XML schema using XSLT<a></a><a></a>, than to translate it to PackageDescrs<a></a><a></a> with Java code. There are also the additional benefits of validation and portability presented by XML. The downside here is that the XML language and
tools are out of date, so we would need to develop these solutions first. </font>
</p>
<p> </p>
<p> </p>
<p>Both consultants on this project have been interested in contributing to the Drools project and we feel this could be the perfect entry point. We realize this is a complicated question and presenting it over email is limiting, so please feel free to contact
me by phone.</p>
<p><font face="tahoma"></font> </p>
<p><font face="tahoma"></font> </p>
<p><font face="tahoma">Thank you,</font></p>
<p>---<br>
Justin Holmes<br>
Red Hat Consulting<br>
410.599.8432 : mobile<br>
<a href="http://www.redhat.com/consulting/">http://www.redhat.com/consulting/</a></font></p>
<div class="BodyFragment"> </div>
</div>
</body>
</html>