[rules-dev] refactoring for a knowledge oriented product

[Mark Proctor]

Christine wrote:
>> I'm just doing a brain dump of how I think I'd like to see the 5.0 api
>>     
> move, where we move from a rule oriented framework to a knowledge
> oriented framework for rules and processes.
>
> sounds interesting. how exactly do you see processes, integrated in the
> knowledgebase, other than just calling ordinary java classes in the then
> part of a rule? Will there be support for other AI-type algorithms?
>   
Have you looked at the RuleFlow stuff in 4.0.x? That forms the basis of 
our work to move full process support.
There is nothing planned for 5.0 beyond rules, processes and cep. But 
yes I'd like to see other things be included, if they
can be integrated and unified in a meaningful way.
> Christine
>
>   
>> A rough namespace and interface mapping could be as follows:
>> org.drools
>>     KnowledgeBase <- RuleBase
>>     StatefulKnowledgeSession <- StatefulSession
>>         -extends both RuleSession and ProcessSession
>>         -in theory someone could have a rule or process specific impl
>>           although we will continue with the combined approach for now
>>     StatelessKnowledgeSession <- StatelessSession
>>     RuleSession
>>         -contains the rule specific api from WorkingMemory
>>     ProcessSession
>>         -contains the process specific api from WorkingMemory
>> org.drools.events
>> org.drools.knowledge.defintions
>>                     KnowledgeDefinitionPackage <- Package
>>                        -Possible just KnowledgePackage
>>                          but I like reinforcing that these are definitions
>> org.drools.knowledge.defintions.rules <- org.drools.rule
>> org.drools.knowledge.defintions.processes
>> org.drools.knowledge.defintions.models
>>     -will eventually contain our ontology stuff
>> org.drools.knowledge.defintions.models.facttemplate <-
>> org.drools.factemplates
>> org.drools.knowledge.defintions.models.pojo
>>     -our current pojo model stuff should probably go here too
>> org.drools.knowledge.engines.rules <- org.drools.reteoo (and common,
>>     
> base, spi etc which will also be refactored)
>   
>> org.drools.knowledge.engines.processes
>>
>> We will create a drools-api module. This will contain all public user
>>     
> apis for all modules in the project, which will allow us to support
> service frameworks better, such as OSGi. This will also allow us to more
> easily differentiate from public stable apis and internal apis.
>   
>> To get compability with 4.0.x we'll have a drools4-adapter jar, which
>>     
> will keep all the 4.0 names and just wrap and delegate to the new impl.
> We won't be able to achieve 100% api comptability, but we should be able
> to for all the most common public apis.
>   
>> Mark
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>     
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20080508/c7b813aa/attachment.html