[rules-dev] Drools XML Language and Tools Development
Mark Proctor
mproctor at codehaus.org
Tue Jan 10 19:35:36 EST 2012
A RuleML and/or RIF parser to Drools would certainly be welcome :)
Mark
On 11/01/2012 00:30, Edson Tirelli wrote:
>
> Just to add to Mark's comments, there are options for you to move
> forward.
>
> The main bit that probably got you off track is the DRLDumper. That
> class was used mainly for debugging purposes. No code in Drools makes
> use of it, and because of that, we didn't have any extensive tests in
> place for it... result is it broke and no one noticed until a couple
> months ago. I will try to take some time to fix it for 5.4 (it is
> wrong in 5.2/5.3) or just remove it completely, as again, it is not
> used by drools itself... it was just a debugging utility class we used
> some time ago.
>
> Regarding the options for this customer, I suggest we move this
> discussion to an internal thread. Open a ticket or mail me directly on
> the corporate e-mail and we can continue from there.
>
> Regards,
> Edson
>
> On Tue, Jan 10, 2012 at 6:39 PM, Mark Proctor <mproctor at codehaus.org
> <mailto:mproctor at codehaus.org>> wrote:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Mark
>
> On 10/01/2012 22:08, Justin Holmes wrote:
>> Hello Devs,
>> 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:
>> 1) Is the XML language truly the best option for our use case?
>> 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?
>> *Context: *
>> Client is using Drool 5.1.1 and we are migrating to BRMS 5.2.
>> There are two independent workflows of interest:
>> *1) Rule Authoring and DRL generation*: 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:
>> i) GUI saves LHS rule logic in an XML database using MathML
>> (http://www.w3.org/Math/), and then saves everything else in a
>> relational database.
>> ii) iBATIS pulls down the corresponding database and XML entries
>> and populates POJOs. There is 1 class definition per content type.
>> 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.
>> iv) PackageDescr is dumped into a valid DRL string with Drools
>> DrlDumper
>> v) Custom content manager does some versioning and then
>> stores DRL in an XML database
>>
>> *2) Deployment and Runtime: *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.
>>
>> *Proposed Solution:*
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Thank you,
>>
>> ---
>> Justin Holmes
>> Red Hat Consulting
>> 410.599.8432 <tel:410.599.8432> : mobile
>> http://www.redhat.com/consulting/
>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> JBoss by Red Hat @ www.jboss.com <http://www.jboss.com>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120111/aa7b00a8/attachment-0001.html
More information about the rules-dev
mailing list