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

[Wolfgang Laun]

It seems to me that adding a property "chain" with a unique value for each
chain would solve (part of) the problem since then you could write s.th.
like
   X( $chain : chain, foo == whatever )
   Z( chain == $chain, bar == anyval )

Or am I way off?
-W

2009/4/21 Tina <colemanserious at gmail.com>

> 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
>>
>>
>
> _______________________________________________
> 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/9df1e6d4/attachment.html