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(a)gmail.com&gt; > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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(a)gmail.com&gt; > 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(a)gmail.com&gt; > > 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(a)gmail.com&gt; >> >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users