[rules-users] Complex validation logic for hierarchies with Drools

[Oleg Yavorsky]

Hi.

I've got a lot of domain objects represented as instances of classes generated from XSD using Castor. My goal is to implement validation framework for whole tree which contains complex "when"  conditions (see bellow). Furthermore, rules definitions should be very easy for unexperienced user to change so I need DSL.

Now I use reflection to assert whole tree of objects to working memory along with additional context information (like stack of parents associated with particular object). Then I use eval() in LHS to call boolean functions which performs checks in plain Java to see if object in particular context. But I think that this is ugly approach and it doesn't solve other cases. I'm new to Drools but something tells me that  it can give me more elegant solution for such problems.

Here is an example of possible hierarchy (used XSD to better represent it). Make note that in production case similar hierarchy is more complex and has a lot of objects. Sorry, but I don't know how to format it in email.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.example.org/ClientService"
    xmlns:tns="http://www.example.org/ClientService"
    elementFormDefault="qualified">

    <complexType name="ClientService">
        <sequence minOccurs="0" maxOccurs="1">
            <element name="ClientInfo">
                <complexType>
                    <sequence>
                        <element name="Name" type="string"/>
                        <element name="AccountID" type="string" minOccurs="0" maxOccurs="1"/>
                    </sequence>
                </complexType>
            </element>
            <element name="ServiceDescription" minOccurs="0">
                <complexType>
                    <sequence>
                        <element name="Name" type="string"/>
                        <element name="Status">
                            <simpleType>
                                <restriction base="string">
                                    <enumeration value="VERIFIED"/>
                                    <enumeration value="ACCEPTED"/>
                                    <enumeration value="DENIED"/>
                                </restriction>
                            </simpleType>
                        </element>
                    </sequence>
                </complexType>
            </element>
        </sequence>
        <attribute name="Type">
            <simpleType>
                <restriction base="string">
                    <enumeration value="BRONZE" />
                    <enumeration value="SILVER"/>
                    <enumeration value="GOLD"/>
                </restriction>
            </simpleType>
        </attribute>
    </complexType>
</schema>

And here are possible validation cases:

1. "ClientInfo" contained inside "ClientService" with type "GOLD" should have "AccountID" assigned.
2. "ClientService" with type "BRONZE" could have up to 3 "ServiceDescription"
3. "ServiceDescription" contained inside "ClientService" with type "BRONZE" should has status "ACCEPTED"
4. "ClientInfo" should have "AccountID" assigned if there is "ServiceDescription" with name "SUBSCRIPTION"

I'd like to come up with rules definition that looks like this (for 3-d example):
rule "Validate status for BRONZE"
when
    Validating ServiceDescription
    Contained in ClientService having
        type equals to "BRONZE"
then
    # Validate status
end

In this rule  ServiceDescription, ClientService and type literals could be anything else (so I don't need to create DSL for each object in domain). But this could be easily done through  reflection.

Any help with possible approach will  be highly appreciated.

Oleg.

       
---------------------------------

Вы уже с Yahoo!? Испытайте обновленную и улучшенную. Yahoo! Почту!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070713/11329542/attachment.html