It will a step in the good direction to split the public api from the
but I wouldn't start defining a DroolsService without deep OSGi
experience - it's to easy to make design flaws and to hard to clean them
As for Spring: Spring likes thread-safe singletons which it can inject
where needed, so the current KnowledgeBaseFactory with a public no-arg
constructor is perfect for that.
Further improves would be to create a thread-local KnowledgeBase
wrapper: it's a dummy implementation of the KnowledgeBase interface, a
thread-safe singleton, injected in services into a global field, which
uses a thread local variable to hold KnowledgeBase instances to which it
delegates (and lazily instantiates if needed). That way ppl don't have
to do factory.newKnowledgeBase() and pass the thread-unsafe kb along as
a local variable.
As for OSGi: Maybe some with more OSGi experience can clarify the exact
With kind regards,
Geoffrey De Smet
Mark Proctor schreef:
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 Proctor wrote:
> As discussed previously:
> I have added an incomplete drools-api module, which we are now using
> to flesh out our design.
> 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:
> 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
> The provider interface is very simple, and is just responsible for
> implementing the delegated method:
> 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 :)
> rules-dev mailing list
rules-dev mailing list