[rules-dev] drools-api

[Geoffrey De Smet]

It will a step in the good direction to split the public api from the 
implementation api,
but I wouldn't start defining a DroolsService without deep OSGi 
experience - it's to easy to make design flaws and to hard to clean them 
up later.

As for Spring: Spring likes thread-safe singletons which it can inject 
where needed, so the current KnowledgeBaseFactory with a public no-arg 
constructor is perfect for that.

Further improves would be to create a thread-local KnowledgeBase 
wrapper: it's a dummy implementation of the KnowledgeBase interface, a 
thread-safe singleton, injected in services into a global field, which 
uses a thread local variable to hold KnowledgeBase instances to which it 
delegates (and lazily instantiates if needed). That way ppl don't have 
to do factory.newKnowledgeBase() and pass the thread-unsafe kb along as 
a local variable.

As for OSGi: Maybe some with more OSGi experience can clarify the exact 
impact?

With kind regards,
Geoffrey De Smet


Mark Proctor schreef:
> Been giving this more thought, and i think we need to develop this at 
> the same time as doing spring and osgi integration (where my knowledge 
> is week). Instead I'm thinking we should have a service approach - 
> DroolsService which returns a the provider implementation (which we will 
> just call a factory now).
> KnowledgeBaseFactory factory = DroolsService.locateKnowledgeBaseService()
> KnowledgeBase kb = factory.newKnowledgeBase();
> 
> Anyway please give me feedback on the best way to get this right, so 
> that we can provide both a standalone approach and a integrated 
> spring/osgi approach without creating a bloated api with lots of hoops 
> to jump through.
> 
> Mark
> 
> Mark Proctor wrote:
>> As discussed previously:
>> http://www.mail-archive.com/rules-dev@lists.jboss.org/msg00757.html
>>
>> I have added an incomplete drools-api module, which we are now using 
>> to flesh out our design.
>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/
>>
>> The idea is not to be rules or process centric but knowledge centric. 
>> It also gives us an opportunity to clearly lable what is a public api 
>> and what isn't - anything no in drools-api is not public :)
>>
>> It uses Factories with static methods to create and return instances. 
>> The factory delegates this creation to a provider, the provider can be 
>> set or loaded - obviously the provider impl does not exist in drools-api.
>>
>> Remember RuleBases are now KnowledgeBases, so lets take 
>> KnowledgeBaseFactory - this now looks like this:
>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/KnowledgeBaseFactory.java 
>>
>>
>> Notice it's all static methods, for easy use. The Factory can have the 
>> provider set via the api, this hopefully makes it spring/guice/mc 
>> friendly, or it will attempt to discover the class name to load, and 
>> finally it tries the hard coded provider that we know will exist in 
>> drools-core/drools-compiler.
>>
>> The provider interface is very simple, and is just responsible for 
>> implementing the delegated method:
>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/KnowledgeBaseProvider.java 
>>
>>
>> This level of flexability is to hopefully encourage other 
>> implementations for the workflow or rules - in theory it would wrap 
>> OSWorkflow and/or Jess - will be an interesting exercise to see how 
>> far this possible.
>>
>> We still have a lot more to flesh out and then we need to make the 
>> providers to adapt to existing 
>> drools-core/drools-compiler/drools-decisiontable classes. We are going 
>> to try to avoid refactoring those classes, where ever possible, to 
>> retain as much backwards comptability with 4.0 as possible for what 
>> will become a deprecated api.
>>
>> Can I ask any developer helping fleshout out the api and providers to 
>> think carefully about what we expose publicly, we want to minimise 
>> this to give as clean as exposure as possible. For instance do we need 
>> to expose ProcessInstance.setState, is a user ever likely to change 
>> the state? The other thing to think about is "developer" apis, where 
>> end users won't change setState but a developer creating a WorkItem 
>> plugin may do - so separation of concerns with read/write splits may 
>> make sense....
>>
>> I'll email the list once it's fleshed out further and actually working :)
>>
>> Mark
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>