I have most of an implementation for ConnectionManager written for Geronimo, but haven't finished the deployment parts.
I haven't studied the rules spec nor drool yet.
Although there are obvious advantages to interfacing to an external rules engine, perhaps written in C, through a JCA connector, I have some doubts about the desirability of channeling communications to an in-vm rules engine through JCA. Here's an outline of why.
JCA (outbound) connectors are good when these conditions hold:
1. Connections to the resource manager (rules engine in this case) are expensive to set up, but once set up can be used indefinitely without significant overhead by many calls in different contexts. (These might be restricted to the same security context, i.e. user).
2. Transaction context needs to be exported.
3. Security context translation is required.
For an in-vm rules engine, (2) is definitely undesirable. IMO any access to transactional resources (such as other ejbs) needs to be made in the same tx context as the request to the rules engine. Setting up a transaction branch is useless wasteful overhead.
I believe (3) is also totally useless and undesirable for an in-vm rules engine.
This leaves (1), which I am less sure about. I believe it comes down to the question of how expensive it is to set up an instance of a rule set, with no data in it, and how this compares with the overhead of jca-managed pooling. IMO the data must be reloaded inside each transaction anyway. Unfortunately I don't have any actual experience with this. I can comment that my original jboss integration used a jca approach, and I later rewrote it without the jca layer. The non-jca code was much simpler.
-----------------------
Reminding everyone that I haven't read the spec yet, I'd also like to mention that I see two approaches to using a rules engine in an app server. In one, which I have seen hints is the approach used in the spec, something (such as a session bean) makes explicit calls to a rules engine when it wants to check something (or have a rules triggered action happen). I suppose we could call this "Bean Managed Rules" in analogy to BMP and BMT.
It's also possible to integrate the rules engine transparently and orthogonally to an existing ejb application, by applying rules to the parameters of ejb method calls (on the way in) and the parameters and results (on the way out). This could be called "Container Managed Rules". This was the approach I took with the JBoss integration. In an interceptor-based ejb container this is very easy to do, by writing an interceptor.
----------------------
Can someone who has read the spec indicate whether the spec requires the app server to have any particular support for rules engines or whether the already-required jca stuff suffices? If no app server "parts" are required, then I'd concentrate first on checking over the Drools jca implementation to see if it is complete. If some app server parts are required, I'd appreciate a brief description of what they are.
Many thanks /********************************** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **********************************/
On Thursday, October 30, 2003, at 03:06 PM, Chris Perrin wrote:
Jules,
Well let's slate self-booting Expert Management Systems for next week. :)
This week I think I've got enough to do with trying to wrassle (I can say
wrassle, I'm from Kansas) Drools into JCA for Geronimo. Then I get to write
a rules deployer. Then the Matrix...er Expert Management System. :)
Since I think some of the Drools authors are helping Geronimo, does anyone
know who did the JCA for JBoss?
----- Original Message ----- From: "Jules Gosnell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 30, 2003 5:00 PM Subject: Re: JSR94
Firstly - I know nothing about Drools :-( - yet...
However, thinking about it, this seriously raises the bar in terms of abstraction levels within easy reach to Geronimo developers.
Wandering off into wacky land... - If e.g. cluster partitioning and
session migration were coupled to the rules engine, it could employ far
more sophisticated algorithms to decide what to do than I am likely to
have time to code in Java...
I look forward to day that the first Geronimo-Management-Expert-System boots itself :-)
Jules
James Strachan wrote:
On Thursday, October 30, 2003, at 09:28 pm, Chris Perrin wrote:
Continuting thought, sorry... Although, I guess all we would need to do is deploy a drl file or something that the deployer would recognize and incorporate...
Agreed. Making drools play nice with the deployer to deploy & undeploy
rule sets would rock.
James ------- http://radio.weblogs.com/0112098/
-- /************************************* * Jules Gosnell * Partner * Core Developers Network (Europe) * http://www.coredevelopers.net *************************************/
