4:08 p.m.
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/
5:39 p.m.
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 : mobile
http://www.redhat.com/consulting/
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:30 p.m.
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(a)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 : mobile
http://www.redhat.com/consulting/
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
6:35 p.m.
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(a)codehaus.org
<mailto:mproctor@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
1:10 a.m.
Mark and Edson,
Thank you both for prompt responses. I certainly understand your position on the Drools
XML language, and I also agree that using an open standard would have its benefits going
forward. Now that we know DrlDumper is only intended to be a debugging tool, and that it
does not work in future versions, we will need to rethink our solutions. Edson, I'll
email your redhat.com account and hopefully we can chat sometime on Wednesday.
Additionally, I have a request regarding documentation. If it has been decided that Drools
XML is dead and that no one should be allowed to revive it, Red Hat documentation must
reflect that decision. Currently, the Drools 5.4.Beta Expert User Manual (section 5.11)
and the BRMS 5.2 reference guide (section 4.11) say, "All the features are available
with XML that are available to DRL." Both docs also prescribe the use of XmlDumper,
DrlDumper, DrlParser, and XmlPackageReader for round-trip translations between XML and
DRL. It is clear from post on the user-list that others have been mislead by the docs as
well, so we should see to it that they are fixed. If there is a better avenue to request
that all 5.x docs be updated, please let me know.
Once again, thanks for your help. I'm sure we will be in touch in the coming days.
Regards,
---
Justin Holmes
Red Hat Consulting
410.599.8432 : mobile
http://www.redhat.com/consulting/
________________________________________
From: rules-dev-bounces(a)lists.jboss.org [rules-dev-bounces(a)lists.jboss.org] On Behalf Of
Edson Tirelli [ed.tirelli(a)gmail.com]
Sent: Tuesday, January 10, 2012 7:30 PM
To: Rules Dev List
Subject: Re: [rules-dev] Drools XML Language and Tools Development
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@codehaus.org<mailto:mproctor@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@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@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>
4:18 a.m.
Hi Justin.
I read your postings regarding the XML language with great interest.
Last year I also needed the Drools XML language for a similar usecase:
simply transforming custom rules (defined by JPA Entity metdata)
to xdrl files. Like you, I also read the Drools documentation where it
described that XML is a possible solution to this. Like you said, it
looked like the right tool for the job - including xsd validation.
So I started developing but soon stumbled across some missing
functionality within the XML parser. Posting to the mailing list showed
that xml shouldn't be used anymore. Since these were minor parsing
problems and development was half-way through, I contributed
some patches to make it work.
Sadly, development at our company was stopped abruptly last year, so I
couldn't move on/finish the project. Now our company plans to
continue that work. So I am also interested in possible alternatives. We
haven't such complex scenarios as you describe - only simple expressions
by now. We used Drools 5.1 with the XML patches I mentioned before.
I would appreciate if you could post the results of your discussion with
Edson and Mark to the mailing list. So I might rethink finishing the
project with XML. At the latest when it comes to upgrading Drools to the
current version I'm afraid we have to move to an alternative.
BTW: +1 for updating the Drools documentation regarding XML support.
Regards
Veit
Am 11.01.2012 08:10, schrieb Justin Holmes:
Mark and Edson,
Thank you both for prompt responses. I certainly understand your position on the Drools
XML language, and I also agree that using an open standard would have its benefits going
forward. Now that we know DrlDumper is only intended to be a debugging tool, and that it
does not work in future versions, we will need to rethink our solutions. Edson, I'll
email your redhat.com account and hopefully we can chat sometime on Wednesday.
Additionally, I have a request regarding documentation. If it has been decided that
Drools XML is dead and that no one should be allowed to revive it, Red Hat documentation
must reflect that decision. Currently, the Drools 5.4.Beta Expert User Manual (section
5.11) and the BRMS 5.2 reference guide (section 4.11) say, "All the features are
available with XML that are available to DRL." Both docs also prescribe the use of
XmlDumper, DrlDumper, DrlParser, and XmlPackageReader for round-trip translations between
XML and DRL. It is clear from post on the user-list that others have been mislead by the
docs as well, so we should see to it that they are fixed. If there is a better avenue to
request that all 5.x docs be updated, please let me know.
Once again, thanks for your help. I'm sure we will be in touch in the coming days.
Regards,
---
Justin Holmes
Red Hat Consulting
410.599.8432 : mobile
http://www.redhat.com/consulting/
________________________________________
From: rules-dev-bounces(a)lists.jboss.org [rules-dev-bounces(a)lists.jboss.org] On Behalf Of
Edson Tirelli [ed.tirelli(a)gmail.com]
Sent: Tuesday, January 10, 2012 7:30 PM
To: Rules Dev List
Subject: Re: [rules-dev] Drools XML Language and Tools Development
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@codehaus.org<mailto:mproctor@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@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:07 a.m.
On 11/01/2012 07:10, Justin Holmes wrote:
Mark and Edson,
Thank you both for prompt responses. I certainly understand your position on the Drools
XML language, and I also agree that using an open standard would have its benefits going
forward. Now that we know DrlDumper is only intended to be a debugging tool, and that it
does not work in future versions, we will need to rethink our solutions. Edson, I'll
email your redhat.com account and hopefully we can chat sometime on Wednesday.
Additionally, I have a request regarding documentation.
Send in a github pull
request for your doc updates, and we'll apply
straight away.
If it has been decided that Drools XML is dead and that no one should
be allowed to revive it,
It's not a case of "shouldn't". What we
don't want is some partial
attempt that ends up cuasing a lot of work for the core developers. If
someone comes along with a strong plan and commits to it and delivers,
then of course we'll consider it.
Red Hat documentation must reflect that decision. Currently, the
Drools 5.4.Beta Expert User Manual (section 5.11) and the BRMS 5.2 reference guide
(section 4.11) say, "All the features are available with XML that are available to
DRL." Both docs also prescribe the use of XmlDumper, DrlDumper, DrlParser, and
XmlPackageReader for round-trip translations between XML and DRL. It is clear from post on
the user-list that others have been mislead by the docs as well, so we should see to it
that they are fixed. If there is a better avenue to request that all 5.x docs be updated,
please let me know.
Once again, thanks for your help. I'm sure we will be in touch in the coming days.
Regards,
---
Justin Holmes
Red Hat Consulting
410.599.8432 : mobile
http://www.redhat.com/consulting/
________________________________________
From: rules-dev-bounces(a)lists.jboss.org [rules-dev-bounces(a)lists.jboss.org] On Behalf Of
Edson Tirelli [ed.tirelli(a)gmail.com]
Sent: Tuesday, January 10, 2012 7:30 PM
To: Rules Dev List
Subject: Re: [rules-dev] Drools XML Language and Tools Development
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@codehaus.org<mailto:mproctor@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@lists.jboss.org<mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org<mailto:rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
4734
days inactive
4735
days old
6 comments
4 participants
participants (4)
-
Edson Tirelli -
Justin Holmes -
Mark Proctor -
Veit Guna