I think it is an interesting idea. I haven't ever used JCA - and I, like most others, kind of turn a blind eye to things that are technically "naughty" in JEE land, but it is interesting that JCA offers ways to allow this. I think there might be a bunch of people interested in this - sounds like a lot of work to maintain though?
I've cleaned up (somewhat) my source and dumped it at https://code.google.com/p/drools-jca/source/checkout.
This is a project that attempts (successfully as far as I can tell but who knows) to make Drools a Java EE citizen by way of the JCA specification.
The way that I've implemented the resource adapter relies (at the moment) on several make-a-private-method-accessible hacks in Drools 5.1.0.
Among other things I've brutally hacked out the sections of Drools that rely on Threads and have subclassed and whatnot so that they now use the JCA-mandated WorkManager and BootstrapContext#getTimer().
The resource adapter sets up a KnowledgeAgent which consults a changeset and monitors it. When a new KnowledgeBase is detected, the agent rebuilds it. Client calls are blissfully unaware of all of this.
The general gist of the project is that you should, from an EJB, be able to do this, provided your container is set up properly:
@Resource
private KnowledgeBase kb;
...and that KnowledgeBase will be a "front" for the "real" KnowledgeBase managed by the resource adapter.
I've declared the resource adapter as not supporting transactions, because it's unclear to me what it would mean for it to do so. One area that is unexplored is what happens if you are in a transaction in your EJB, and you stuff your EJB's copy of, say, an EntityManager into the rules as a global. Does "not supporting transactions" mean that the transaction of which the EntityManager was most recently a part will be suspended? Or is this sleight-of-hand possible?
As confirmed on the rules-user list, no further synchronization or anything like that is (apparently) necessary from a caller's point of view.
The project is built in two parts: the raw jars part (drools-jca) and the RAR wrapper around it (drools-rar). This allows the drools-jca part to be tested by an embedded instance of OpenEJB, which is a Java EE 6 compliant (mostly) application server. It also allows the consumer to decide whether to build his own "skinny" rar or to use the drools-rar project as is.
Please please please give me feedback on this in case I've done something horribly wrong.
Best,
Laird
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev