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 : mobile
http://www.redhat.com/consulting/