I have had some really interesting surprises since I started looking into
integrating JESS with EJBs.
The difference between a stateless and a stateful session bean turns out to
be real interesting:
(a) the stateful session bean is intended to be accessed by a
specific client because the state held
by the bean may relevant only to that specific client, e.g.,
JESS has been engaged to make
some determination using a generic set of rules, BUT, the
facts are specific to this client. Other
clients may get a JESS/EJB object (with some generic
ruleset), but they will NOT see the
results from the previous client.
(b) the stateless session bean is intended to be seen/used by ANY
client and ALL clients may
see the results, e.g., JESS has been engaged to make a
determination using a set of generic rules
with facts that are common to ALL clients. In other words,
whatever properties JESS modifies
will show up in ALL clients because all clients have copies
of the facts.
This tells me to not make vast assumptions about EJBs (of which I had been
guilty of ). Also, there may
be more than one JESS/EJB model (depending on what I intend to accomplish
when I call JESS). I
sure hope I have this right - this is turning into a downright exercise !
Not to mention the fun I'm having
porting EJB code from one app server to another.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 04, 2002 5:27 PM
Subject: Re: JESS: JESS & EJB
>
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
