Hi all,
Well, after much churning with Stateful/Stateless
Session Beans (& Entity Beans) I am beginning to re-think why
I would want to integrate JESS with EJBs. I
finally arrived at the notion of using pure JMS Messaging and
having
JESS situated within a client to interact with
the message content. Ironically, two of the most successful
projects
that I have seen in 15 years used this
architecture.
On the other hand, EJBs seem to have many
constraints that preclude the notion of a "constant service".
i.e.,
JESS providing a state-based inferencing service
for clients. My test for the JESS/EJB integration would be to
use the "pumps/tanks" example found in the JESS
code section. The PropertyChangeSupport seems to throw
a BIG monkey wrench into the EJB machine.
It also seems that many of the EJB constraints
are geared towards precluding the use of
multi-threaded code (my opinion).
So, for the future I will direct my attention
towards using a JMS/JESS layered architecture. Obviously, the
"pumps/tanks" example will not work as written
but I'm sure some event-based message work-around could be
formulated to achieve the same effect. Surely the
message latency cannot be any worse than the "blocking"
of the RMI-based EJBs.
Anyhoo - that is my thought for the
day.
