<font size="2">I&#39;m trying to get a handle on whether Drools is the right
tool for the job we have at hand.  Based on what I&#39;ve seen in the
documents and examples, I believe it could be, but that we&#39;re
definitely taking a more difficult path.  Interested in thoughts from
folks with more experience than me.<br>
<br>Our project is looking for a solution to let us deal
with streaming data, and determine whether each individual data item
meets a rule&#39;s criteria.  </font><font size="2">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.)  </font><font size="2">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&#39;t
directly know that X&#39;s parent is Y, whose parent is of type Z, which
then has a property named &#39;foo&#39;.  (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&#39;re working with.  For us, we&#39;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.)<br>
<br></font><font size="2">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.  <br><br>I&#39;ve tried the following approach, but it &quot;smells&quot; wrong:<br>
- 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&#39;ve shown that inserting an event again has my desired effect, I haven&#39;t yet figured out how to query the set of rules, and provide adapter classes for each rule.]<br>
</font><br>I&#39;m also considering a DSL approach, trying to determine if that would allow me to somehow transform the problem.<br><br>Any insights or feedback would be wonderful.  In-house, we
don&#39;t yet have a great depth of expertise with Drools, so I&#39;m interested
in tapping a broader pool of knowledge and experience.  I&#39;ve only got access to Drools 4 in my environment.  I can try alternate approaches in Drools 5 at home, but can&#39;t use that solution as yet for our problem space.<br>
<font color="#888888"><br>- Tina</font>