[rules-dev] drools-api

[Mark Proctor]

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
>