[rules-users] Dynamic object structure Drools use case?
Wolfgang Laun
wolfgang.laun at gmail.com
Tue Apr 21 08:44:06 EDT 2009
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
More information about the rules-users
mailing list