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

[Wolfgang Laun]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20090421/dc5e0c40/attachment.html