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/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 > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev