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/[email protected]/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
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
