Hi David,
So it looks like JRules lets you directly match on member variables of
Java objects. I wonder how useful this is in practice: sometimes
members hold useful state that corresponds to observable properties,
but other times they don't. I think for the kinds of Java classes I
write I'm not sure this would be very useful.
In any case, let's assume that it -is- useful. I think what you would
need, then, first of all, would be a version of the defclass command
which builds deftemplates whose slots correspond to member variables
of a class, learned via reflection. Together with a member-oriented
version of definstance, which builds facts using these templates from
actual objects of the class, you've got the equivalent of Jess's
"definstance static."
Now, to do dynamic definstances, you need to build some kind of notification
sink to which you can hand the modified object. The sink would keep
track of the Fact that went with each object (it would be implemented
in collaboration with member-definstance) and it would retract and reassert
the associated fact whenever a member changes (precisely what the
current PropertyChange stuff does.)
As long as you don't call "modify" on an associated fact inside Jess,
everything would work just fine. If you want to use modify, then you'd
need to hook into the modify function, but that wouldn't be hard
either.
So, anyway, I think what I'm saying is that what you want could be
implemented using a module of two Userfunctions and some additional
associated code that all shared some state. The only tricky part I can
see would be providing a generally useful definition of which member
variables should be exposed in the deftemplates. Perhaps you'll have
to hand-write a list for each class? How does JRules handle this?
I am not interested in writing this right now, but would be glad to
kibitz if you or someone else wants to.
I think David Young wrote:
> Greetings. We are currently doing a comparitive prototype using Jess
> 6.0a and ILog JRules 3.0. Of particular interest is how well either
> product can be embedded into our existing (and well-established)
> network management system.
>
> I am aware of how well Jess interacts with Beans; however, the area in
> which Jess or JRules is targeted does not employ Beans, hence whatever
> we select will be required to reason over conventional Java
> objects. I'm wondering if anyone has experience embedding Jess into a
> "legacy" Java system. I've written a small Jess prototype using the
> introspection facilities provided; for example:
>
> (defrule handle-standing-condition
> ?obj <- (fault-data (object ?fd))
> (test (eq
> (get-member ?fd cond_def)
> (get-member ext_fault STANDING)))
> =>
> (set-member ?fd severity
> (get-member ext_fault WARNING))
> (retract ?obj))
>
> However, this style doesn't appear to lend itself to more complex
> rules and is less elegant (and perhaps efficient) than say:
>
> (defrule handle-standing-condition
> ?obj <-(fault-data (cond_def ?cond&=(get-member ext_fault WARNING)))
> =>
> (...))
>
> JRules appears to have a distinct advantage here, in that it imposes
> no specific requirement (eg. "must be a Bean") on the classes it can
> reason about. Conversely, JRules also requires "manual intervention"
> when Java objects are modified outside of the knowledge base; there's
> no "automatic" mechanism such as the PropertyChangeListener that Jess
> utilizes.
>
> In any event, I could use some guidance here. Rewriting our existing
> classes as Beans is not feasible at this time, and creating a suite of
> "wrapper Beans" around these classes conjures up maintenance
> nightmares. Thanks for your assistance.
>
> Regards,
>
> --
>
> -------------------------------------------------------------
> David E. Young
> Fujitsu Network Communications "The fact that ... we still
> ([EMAIL PROTECTED]) live well cannot ease the pain of
> feeling that we no longer live nobly."
> -- John Updike
> "Programming should be fun,
> programs should be beautiful"
> -- P. Graham
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list (use your own address!) List problems? Notify [EMAIL PROTECTED]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
