geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: JSR94
Date Fri, 31 Oct 2003 04:04:34 GMT
My first JBoss project was to integrate the JEOPS rule engine into 
JBoss, and I wrote most of the JBoss jca support  (as of last June, 

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  

Many thanks
* David Jencks
* Partner
* Core Developers Network

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 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" <>
> To: <>
> 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
>>> -------
>> -- 
>> /*************************************
>>  * Jules Gosnell
>>  * Partner
>>  * Core Developers Network (Europe)
>>  *
>>  *************************************/

View raw message