On 29/05/2012, bdolbeare bdolbe...@yahoo.com wrote:
I am working on integrating Drools with a legacy BRMS that was developed
in-house. The customers like the BRMS and are unwilling to migrate to
another tool such as Guvnor. The BRMS creates the rules in a proprietary
XML format. In order to integrate Drools with the BRMS, I need to convert
these rules to a format that Drools understands and that leaves me with
what
seems like 3 options:
1) Write some XSLT to transform the proprietary XML to Drools XML format.
This seems straightforward; however, I am concerned that the online
documentation states that the Drools XML format should be considered
deprecated. I'd hate to invest much time in this approach if the XML
support
is going to disappear in a future release.
Correct. This is not to be recommended at the moment.
2) Write my own parser that can convert the proprietary XML to classes in
the org.lang.descr package. I'm not sure if the Drools developers intend
for
others to use these classes directly. For instance, if they change
frequently, this approach may be difficult to maintain.
Parser seems to be exaggerated. First, XSLT would be capable of
generating any text. Second, given that you have an XML schema for
your proprietary XML format, you could use JAXB to generate Java
classes, and unmarshalling your XML rules files is a simple thing.
Generating a hierarchy of Drools internal objects to represent a
package equivalent to one of your rule XML files is a perfectly
feasible approach.
I can see one disadvantage - see 3)
3) Write my own parser that can convert the proprietary XML to DRL. This
approach seems unfortunate in that the rules would be parsed twice; first
to
convert them to DRL and then internally by the Drools DrlParser. Also,
this
doesn't seem to offer any benefit over approach 2 (except that I know DRL
well and wouldn't have to learn how the org.lang.descr classes work [not
much documentation in those classes]).
My comments regarding parser apply here, too.
I see no disadvantage in the double transformation XML - DRL - BRL.
It has the advantage that you'll see Drools rules in DRL, a readable
representation which is lacking with #2. Moreover, acceptance by the
DRL parser ensures that the conversion is correct and does not violate
any DRL rule. With method #2 you might even create a binary package
that breaks at runtime, and then you'll be in trouble, as you'll
depend on utterly undocumented code. Contrariwise, support for
problems where you have DRL is readily available (on this list).
I'd put my money on approach #3, with JAXB deserialization.
-W
Right now, I'm leaning towards approach 2. Any thoughts or suggestions
would be appreciated.
--
View this message in context:
http://drools.46999.n3.nabble.com/Integrating-Drools-with-rules-from-a-legacy-BRMS-tp4017676.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
