[prev in list] [next in list] [prev in thread] [next in thread]
List: geronimo-dev
Subject: Re: JSR94
From: David Jencks <david () coredevelopers ! net>
Date: 2003-10-31 4:04:34
[Download RAW message or body]
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,
anyway).
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" <jules@coredevelopers.net>
> To: <geronimo-dev@incubator.apache.org>
> 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
>> *************************************/
>>
>>
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic