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 <[email protected]> > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
