We need to implement the Jess rules engine into a clusterable distributed environment. The question lies in how Jess is deployed.
It would appear that it cannot be deployed inside of an App Server because Jess does it's own threading. After some research into JSR 94 (Rules engine API/SPI) it is still unclear how Jess would actually run in our environment. I seem to remember that Clipse ran as a single server instance and that our EJB's across the cluster would access this single instance. I also believe that Jess would have to run in this way, as a single server, however Jess itself is not a server.
So how does an EJB in a cluster access the single instance of Jess? Do we write an RMI server to wrap the Jess instance (as suggested in "Jess in Action"), or do we some how use JCA to connect each App Server to Jess?
So far we've written the RMI wrapper, but it seems like this could be easier.
Subscribe to:
Post Comments (Atom)
5 comments:
Why do you have to run it behind RMI? Why not just use it like any other java library. If Jess caches rules then you can probably have jess engine instance pool, and then simply get one instance and call a method on it.
2 Reasons. One is that Jess plays with it's own thread pool and I thought that was a no-no in an app server environment. Two - Each Jess server has its own set of rules. We need a single set of rules that can change dynamically, so if each server had an instance of the rules engine we would have a synchronization nightmare. Think of a Rules Engine as a database or LDAP server. You can't deploy it with an application... As far as I know.
Instead of threads to do things asynchronously, they should have considered using JMS/MDB.
This would also solve the problem of a cluster-wide dynamic configuration.
Admittingly, this would probably lead to a complete rewtrite :-(
F. Degenaar
I'm not sure that would be a smart architecture either, since Jess basically acts as its own server. The real scary thing is that Jess is the Reference Implementation for JSR 98, so you would think that it would easily fit into a J2EE environment but it doesn't appear to.
Oops, I meant JSR 94 in my last comment.
Post a Comment