[rules-users] Integrating Drools with rules from a legacy BRMS

[Wolfgang Laun]

On 29/05/2012, bdolbeare <bdolbeare at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>