<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Rule base systems typically had simple languages. Data structures
where either list or frames, the number of constructs are very
limited. Complex expressions, such as nested accessors did not exist
- like with Drools 3.0. That made it very easy to support a 1 to 1
mapping in xml.<br>
<br>
Around Drools 4 out langauge become more expression, we started to
allow complex expresisons inside of patterns. In Drools 5.3 that is
even more so. It quickly became obvious that xml representation fo
drools would also need a representation for java expressions, this
was going to be a lot of work - especially as we would probably have
to change a lot of the existing xml.<br>
<br>
It seems very few people are using the xml, certainly no one seemed
to care about it. Xml parsers and schemas is something that every
java developer can do, but no one has come forward maintain this. So
we've let it die.<br>
<br>
I'm not sure I'd want to resurrect it, for a one of piece of work.
It's likely the maintainenance of this would soon fall back on the
core developers.<br>
<br>
I think I'd rather see xml efforts around RuleML and/or RIF. So
imho if you want to do anything, do it around those. The downside is
that representing our more powerful constructs like sliding time
windows may not be possible in those languages, and you would need
to define extensions.<br>
<br>
Mark<br>
On 10/01/2012 22:08, Justin Holmes wrote:
<blockquote
cite="mid:72287B8BB6F38F4BA9818B32BD4EA94E08FFCD4182@AUSP01VMBX09.collaborationhost.net"
type="cite">
<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>
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000;
FONT-SIZE: x-small">
<div dir="ltr"><font color="#000000" face="Tahoma" size="2">Hello
Devs,</font></div>
<div dir="ltr"> </div>
<div dir="ltr"><font color="#000000" face="Tahoma" size="2">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 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) to fully support
at least BRMS 5.2?</font></div>
<div dir="ltr"> </div>
<div dir="ltr"><font color="#000000" face="Tahoma" size="2"><strong>Context:
</strong>
</font></div>
<div dir="ltr"><font color="#000000" face="Tahoma" size="2">Client
is using Drool 5.1.1 and we are migrating to BRMS 5.2. There
are two independent workflows of interest:
</font></div>
<div dir="ltr"> </div>
<div dir="ltr"><font color="#000000" face="Tahoma" size="2"><strong>1)
Rule Authoring and DRL 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. 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" face="Tahoma" size="2"><font
color="#000000" face="Tahoma" size="2"><font
color="#000000" face="Tahoma" size="2">i</font></font>)
GUI saves LHS rule logic in an XML database using MathML (<a
moz-do-not-send="true" href="http://www.w3.org/Math/">http://www.w3.org/Math/</a>),
and then saves everything else in a relational database.<br>
ii) iBATIS pulls down the corresponding database and XML
entries and populates POJOs. There is 1 class definition per
content type.<br>
iii) Cumbersome application code translates POJOs into
Drools PackageDescr (~5000 lines of code, not using fluent
API). This step produces a very strange and convoluted
representation of the LHS of each RuleDescr. It works
with DrlDumper 5.1.1 but does not work properly with
the BRMS 5.2 version of DrlDumper (MVEL Template). This is
the source of our problem.
<br>
iv) PackageDescr is dumped into a valid DRL string with
Drools DrlDumper<br>
v) Custom content manager does some versioning and then
stores DRL in an XML database</font></div>
<font color="#000000" face="Tahoma" size="2">
<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, which are cached, and
then used throughout the day.</div>
<p> </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, we want to pursue a
more maintainable solution to provide the translation
and abandon 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.</font></p>
<p> </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. We will
likely need to use the existing intermediate POJOs 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 representation of the LHS to the
Drools XML schema using XSLT, than to translate it
to PackageDescrs 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> </p>
<p> </p>
<p><font face="tahoma">Thank you,</font></p>
</font>
<p><font color="#000000" face="Tahoma" size="2">---<br>
Justin Holmes<br>
Red Hat Consulting<br>
410.599.8432 : mobile<br>
<a moz-do-not-send="true"
href="http://www.redhat.com/consulting/">http://www.redhat.com/consulting/</a></font></p>
<div class="BodyFragment"> </div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>