[rules-dev] drools-api

[Mark Proctor]

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