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

[Tina]

So I  would look at data item X -> Y -> Z and insert X as an item, Y as an
item, and Z as an item, with a unique id for the source combination of [X ->
Y -> Z]?  Hmm....   That does look like an interesting solution.

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

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