You can still use jess with these objects even if they don't support
PropertyChangeListener event firing (I *believe* that they must still
conform to the naming conventions for bean properties - e.g. getXXX setXXX -
someone please correct me here if I am wrong.)
You should be able to use the static option with definstance.
See http://herzberg.ca.sandia.gov/jess/docs/functions.html#definstance
Good luck!
alan
> -----Original Message-----
> From: David Young [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 12, 2000 10:57 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: JESS: Reasoning over non-Bean objects
>
>
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
