Automatic rules files importing

[amedranogil]

Add a SynchronousBundleListener to the Drools (or any Rule engine), which searches installed bundles for rule files, in the public packages of the bundle, and automatically adds them to the rule base of the engine.
The reverse process: automatically remove all rule files from the rule base when the bundle is being uninstalled; should also be managed.

use uAALBundleExtender as example of how to use this OSGi feature.

Advantages:

• Define different set of rules within a bundle, each in a different file, each identified uniquely through the same mechanism as package-class used in java
• These bundles can be created with the Drools IDE, only requiring the extra work of defining the POM to define the bundle.
• Drools files can coexist together with their support javacode.
• Aggregate different rule sets, and support code into a single bundle
• Aggregate different bundles into karaf_feature-like components, easing the interoperability between rule-based features. (maybe when there are enough rule-features we can catalogue them similarly to our ontologies)
• Managing conditional rule loading: public rules will automatically be loaded, private or protected packages will not, these rule sets can be managed by the bundle itself, and only it decides when these rules should be loaded (and unloaded), through the existing mechanism (which will support back-compatibility)

[cstockloew]

This would only work locally, but not if the reasoner and the bundle containing the rule are on different nodes.

[amedranogil]

Yes that is a limitation, there is no intention of hiding that, it is just a "more friendly" way of incorporating code.
If we look at it from the deploy manager perspective, this means that these types of deployed applications will require the reasoner in the installed node; and thus it must be stated in the app descriptor.

[cstockloew]

If we have a generic ontology for rules (which was already proposed), then we could create a "helper" bundle that would be installed on all nodes with those apps (maybe with the app having a direct dependency on it), collect the rules, and send a service request to add the rule to the appropriate reasoner. But maybe it's better not to be too automatic in this case. What if an app has several rules and they can be activated separately?

However:

• how do 'rules' look like?
• what about security (i.e. security manifest)?

[amedranogil]

Concretely fro Drools the rules are files (very similar to java source files). The drools reasoner wrapper has a service profile which allows to send the string source which then is sent to the reasoner (which just parses it and add it for execution); along with other services to unload the servie (it assigns an ID when loading the source).

So initially, yes the helper can be executed in any node in uSpace then the file is serialized in the service call. But I find it that in some cases this might be difficoult to maintain (say for example the issuing node disconnects before sending the "release" call, the code will be kept by the reasoner for ever). This is reason why I propose to embed the helper with in the reasoner itself, so that the source rules are in the same node and such cases are then managed by developer.

About the security it is also tricky, initially Drools can call methods with in thier scope (OSGi shares), but this call is within the drools source code, so maybe there is some issue with the plugin. This is the other reason why the modules need to be on the same node as the reasoner.

BTW this brings me to conclude the wraper must expose to the rules a generic publisher and a service caller. so this idea of rule-only modules to properly work.

[amedranogil]

The Drools reasoner must have a generic service Caller, and Context Publisher (aside from the "all" context event subscriber), that can be refferenced uniformly from the drools source files, in order to perform call and publishing operantions.

This is just a reminder to include it and add it to the documentation.