[jboss-dev-forums] [Design of JBoss jBPM] - Re: jbpm drools integration meeting

Wed Aug 9 14:06:54 EDT 2006

Hi Jeff,

"Jeff" wrote : | 1) Task Assignment. 
  | 

For calculating the actual actorId (user or group) that is responsible for a certain task, i think that rules are not really suited.  Jeff, you obviously have more real life experience so i would appreciate your comment on this.  One of the big problems i see is that with rules you're not sure if you'll find 0, 1 or more solutions.

But i DO think that rules are suited to calculate all the constraints that people have to satisfy in order to apply for a certain task.  So the rule base could calculate those constraints after the rules have fired, a plain hibernate query could be build from those results.  Would that approach make sense ?  Another advantage would be that we don't have to assert the whole identity store into the working memory.  The datamodel of the idenity store might have to have a generic way of managing properies for people so that the rules can produce plain (hibernate?) criteria that express the constraints.

"Jeff" wrote : | Perhaps some kind of 
  | | partitionable / composite working memory is required.
  | 

I think that would make sense.  But mark and michael will know better then me.

"Jeff" wrote : | 2) Actions / Nodes. This involves invoking rules as at a node 
  | | in a process, either from an action configured on the node 
  | | itself or associated with some node event.
  | 

Maybe the rules only need to be fired when the process data (== facts) change.  So i think i should add a variable-update event or something like that.  So that the rules can be fired after each variable update.  I'm still in doubt wether explicit rules invocations on a specific location in the process make sense.  

"Jeff" wrote : | communicate the results of the rule execution. I.e., the 
  | | right hand side would invoke 
  | | contextInstance.setVariable("resultsOfRuleExecution", "some result").
  | 

Another option could be that after a rules calculation, certain facts could be fetched from the working memory and submitted into the process variables.  The variable names could be part of the action handler configuration.  But probably this is not possible because the working memory doesn't yet have named facts, right ?

So how do we collect the new data that is generated by the rules ?  Should the rules themselves distinct between an assert and a setVariable on the process ?  Defining contextInstance as a global variable seems the best approach to me.  But it would be great if the facts were named, rules only contain asserts and jbpm was able to collect all new asserted information in the process variables transparantly.

Maybe my next answer is not quite in the context of your point, but it relates to this and i have been thinking about this after our london meeting.

In my opinion, rules sources, process sources are on the same level as java sources.  They're best managed in a source control system like CVS or SVN.  The fact that projections of rules and processes can be presented in pictures that make sense for non-tech business people does not change this.  We should be careful in our admin consoles not to include process and rule updates that are not synched with the source code just for the sake of the business user.  We can only do that if there is a clear strategy on how the sources will be kept in sync.  This is important cause i do NOT think that in general, rules and processes are stand-alone things that can be managed by non-techies.  While the graphical projection of processes and rules make sense, both processes and rules will most likely include technical details.  So processes and rules cannot live in isolation, but they will be integrated in plain java development.  Therefor, they cannot be managed by business users alone and it is important that we still keep an eye on the development environment.  We should prevent that a developer has to change some code in CVS and then update the rule DB and then update the process DB to start testing.  This creates a very difficult deployment structure.  Similarly, we have to prevent that the admin console allows for updates in the deployment that have to be synched back with the development sources.

I just want to warn that by focussing too much on the business user, we might introduce a complex sourcecontrol, build and deployment for the development team.

This does not mean that business users can't have what they want.  They still can have their GUI editing of processes and rules, but it should be in sync with the technical development source code control system.

"Jeff" wrote : | 3) Decision Nodes. 
  | 

Even if in natural english it makes sense that 'a decision is based on rules', I'm not sure if a rule engine is the proper instrument to calculate a decision-node in a jpdl process.  Again as with task assignment, you're not sure if there will be 0, 1 or more results coming out of the rule engine calculation.  The decision node needs exactly *1* result: namely the name of the transition to take.

So finding the proper use cases on how the technologies make sense together would be more interesting for me that showing how the two can be hooked up together technically.  The latter part is not so hard, i think.

"Jeff" wrote : | This requirement would be supported by a "rule flow jpdl" 
  | | (much like the Seam "page flow" jpdl). 
  | 

yes, that could be done in another process language.   it probably could be done with jpdl as well, but a special purpose process language would give you much more convenience over the more generic jpdl.

"Jeff" wrote : | I am not sure this requirement involves persistent wait 
  | | states. 
  | 
A node would be a wait state, but it wouldn't have to be persisted.

"Jeff" wrote : | I don't understand Tom's comment "By default, jBPM will fire 
  | | all rules when a process variable is updated."
  | 
  | 

I mean that there is one use case in which the combination of rules and process makes good sense to me (much more then in assignment or decisions): That is where the process variables are the facts in a working memory and the rules calculate derived information from process variables.  That derived information might also be stored as process variables (as discussed above).  To keep the derived information up to date, all rules need to be fired for each time, a process variable changes.  So that is where we need some sort of event in jbpm that allows us to inject the 'fireAllRules' after each setVariable in the jbpm context.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964121#3964121

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964121