A Rete instance is more like a database than an EJB -- an entity EJB is like a single row of a table in a database. Therefore, my personal opinion (and it's just an opinion, because I've never deployed an EJB-based application) is that Jess should live in a separate server app, perhaps accessed by RMI, in the same way that the database often will. Clients would contact EJBs, and the EJBs would talk to the "Jess server." A generic Jess server wouldn't be hard to write, and one specific to a given application would be even easier. A simple one might expose only one method: executeCommand()!
I think James Patterson wrote: [Charset iso-8859-1 unsupported, filtering to ASCII...] > RE: JESS: JESS & EJBTechnically I don't know the answer. My understanding is that a >bean's life cycle is like the java GC - each implementation can handle it >differently. A good EJB should be service orientated - a request comes in, the bean >is either instantiated or reused, and then the left for dead. The container may or >may not "destroy" it. So, even though the bsave/bload option is there, it isn't very >practical (I think) for my problem. We have potentially, hundreds of rules and 10's >of thousands of facts (most of which are not short and simple). Most importantly, we >are looking for a good response time on the "new fact -> rule fires" cycle. > > Any comments? > > James > --------------------------------------------------------- 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] --------------------------------------------------------------------
