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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users