[rules-users] Dynamic object structure Drools use case?

[Tina]

Good question, Wolfgang.  Our end-users are aware of the structures that
they've created.  So, if they expect data to come in of type X, which may
have a parent somewhere up the chain of type Z, they'd write a rule looking
for data with property X.foo and Z.bar that meets certain conditions.
Effectively, they're writing rules to look for possible combinations of data
properties known to them.  (Note that I expect that I'm not going to be able
to make great use of Drool's Eclipse plugins or other GUIs to allow them to
pick fields.  I'm expecting to have to extend those plugins to deal with our
more abstract structures.)

If we only cared about data from type X in our rule, I could simply write
the rule directly to X, and map its properties directly.  But because I also
care about fields from Z, and that path from X to Z isn't a direct nested
path, I run into difficulties.



2009/4/21 Wolfgang Laun <wolfgang.laun at gmail.com>

> One thing that's not clear to me, but essential to a discussion of this
> problem: How do write (or even define) the rules if you don't know the
> actual properties the incoming Beans will have?
>
> -W
>
> 2009/4/21 Tina <colemanserious at gmail.com>
>
>> I'm trying to get a handle on whether Drools is the right tool for the job
>> we have at hand.  Based on what I've seen in the documents and examples, I
>> believe it could be, but that we're definitely taking a more difficult
>> path.  Interested in thoughts from folks with more experience than me.
>>
>> Our project is looking for a solution to let us deal with streaming data,
>> and determine whether each individual data item meets a rule's criteria.  Each
>> data item implements an interface, but the properties available on the
>> concrete objects differ wildly.   Also, each data item can be considered to
>> be composed of multiple levels of these data items.  One of the fields on
>> the interface is a getParent field, which returns the data item one level
>> up.  (In effect, we end up with a singly linked list.)  If X is the
>> object which we have a direct handle to, X.parent = Y, and Y.parent = Z, we
>> often want to look at Z.field as part of our rule.  I believe that the quirk
>> here is that, although the objects are JavaBeans, they are presented as an
>> interface which does not describe the property set of the bean.  Thus, I
>> don't directly know that X's parent is Y, whose parent is of type Z, which
>> then has a property named 'foo'.  (Beans here are essentially user-defined
>> structures for contributed code, and thus we have no real way of knowing
>> what properties are on a bean until we receive the bean.  When the users use
>> the beans, they obviously know which bean they're working with.  For us,
>> we're getting it downstream, and that bean could be any of a dynamically
>> growing variety, also with many different permutations of structures in the
>> linked list.)
>>
>> As a practical matter, the interface has a method getField(String,
>> String), whihc allows us to access specific fields both in the local bean
>> and in the beans available up its list.  That functionality is accomplished
>> through some reflection logic.
>>
>> I've tried the following approach, but it "smells" wrong:
>> - Create adapter classes per rule, and, given a data item, insert the item
>> again, adapted with a bean that gives access to the specific fields.  We
>> believe the # of rules will be 10 or less at any given time in the
>> operational system. This would require us to query the known rules, and
>> provide adapter classes for them, which seems completely counter to normal
>> patterns of use.  However, it would allow us to use a bean approach.  [Note
>> that although I've shown that inserting an event again has my desired
>> effect, I haven't yet figured out how to query the set of rules, and provide
>> adapter classes for each rule.]
>>
>> I'm also considering a DSL approach, trying to determine if that would
>> allow me to somehow transform the problem.
>>
>> Any insights or feedback would be wonderful.  In-house, we don't yet have
>> a great depth of expertise with Drools, so I'm interested in tapping a
>> broader pool of knowledge and experience.  I've only got access to Drools 4
>> in my environment.  I can try alternate approaches in Drools 5 at home, but
>> can't use that solution as yet for our problem space.
>>
>> - Tina
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090421/9c77515e/attachment.html