[rules-dev] drools-api

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/j... 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/j... 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