Mark,

One thing that I forgot to comment on was how the flow architecture with its 
splits and joins can be used to emulate "work flow patterns". I am VERY pleased 
to see this as it (in my opinion) gives rules flow an enormous amount of 
logical processing power that is just not present in an ordinary rules 
processing environment.

Again, congratulations !!

Rich Halsey




"GENIUS IS THE ULTIMATE WEAPON"

....God grant me...
The senility to forget the people I never liked
The good fortune to run into the ones that I do
And the eyesight to tell the difference."

  ----- Original Message ----- 
  From: Mark Proctor 
  To: Rules Dev List 
  Cc: Rich Halsey ; James C. Owen 
  Sent: Monday, February 26, 2007 7:58 AM
  Subject: Re: [rules-dev] Re: RuleFlow preview


  Our implementation is a light layer to provide "wait states" for one or more 
rules, it uses a similar principle to agenda-groups (Clips modules) to 
partition the execution. Activated rules are placed in temporary buckets 
(rule-flow-groups), instead of onto the agenda, when the rule-flow-group is 
activated the bucket empties onto the Agenda for normal execution, when all the 
emptied rules are fired the next rule-flow-groups are activated. 

  The system is still "parallel" in nature, in that the agenda is still 
responsible for executing rules and the agenda can have more than one rule on 
it at at time. In our implementation all the rules in the rule-flow-group will 
be put onto the agenda for execution, at the same time standard rules can also 
continue to be managed and executed by the agenda, and agenda groups (clips 
modules) still continue to operate - all in parallel.

  A rule that is specified to execute as part of a rule-flow-group can also be 
part of an agenda-group, but that use case is discouraged because it can get 
quite hairy unless you really know what you are doing :) As it means a 
rule-flow-group can be activated, the rules moved onto their respective 
agenda-groups, where any rules not in agenda-groups that do not have focus will 
not fire, the next rule-flow-group will not activate untill all rules for the 
current rule-flow-group have fired, regardless of the agenda-groups they are in.

  The limitation at the moment is that the temporary bucket has no ability to 
handle different start instances and differentiate between the rules in it's 
bucket of the same rule-flow, but you can have multiple different rule flows 
executing in parallel. We purposefuly kept it simple for "version 1" to build 
up the functionality needed for rule flow. The use cases for parallel execution 
of the same flow are not easy - as one instance can catch up and over take 
another instance on the same flow. Also if a rule in a rule-flow-group 
activates which of the two current instances for the same rule flow are 
responsible for firing it? The same issue arrises for when you have the same 
rule-flow-group in multiple rule-flows. We are currently not sure how best to 
handle these types of situations; maybe you could help us on those use cases? 
Or even provide a patch :)

  Mark
  Rich Halsey wrote: 

    Hi Mark,

    The part in the document where it says: 
    "At this point, ruleflow-groups should not be reused in more than one 
ruleflow, and you should not

    start a new instance of a process before the previous one has ended." 

    will be the weak link in the chain, i.e. there should not be any reason why 
rule-flow-groups should not be reused nor having multiple instances since rules 
are implicitly parallel in operation. This was what I found to be the problem 
with ILOG's JRules back in the v4.0 edition. It turned JRules into a clunky 
procedural processing engine (which was not what we needed at that time).

    However, I am very proud to see that Jboss Rules (JBRules) has successfully 
evolved to this point. You (and your team) are to be commended for your efforts.

    Tally-ho !!

    Rich Halsey










    "GENIUS IS THE ULTIMATE WEAPON"

    ....God grant me...
    The senility to forget the people I never liked
    The good fortune to run into the ones that I do
    And the eyesight to tell the difference."

      ----- Original Message ----- 
      From: Mark Proctor 
      To: Rules Dev List 
      Sent: Monday, February 26, 2007 5:12 AM
      Subject: RuleFlow preview


      I thought everyone on the dev list would be interested in reviewing and 
providing feedback on Kris' excellent work on RuleFlow - includes screenshots :)

      Mark
      -------- Original Message -------- Date:  Mon, 26 Feb 2007 01:51:29 +0100 
            From:  Kris Verlaenen <[EMAIL PROTECTED]> 
            Subject:  Ruleflow 



I've attached a document describing how ruleflow is implemented /
could be used in the future.  If anyone has got any suggestions or
improvements (on the API I'm proposing, or things you would like to
see differently), just let me know asap.

I think I'll be able to commit a first working version on svn soon.
Still have to include conditional connections (where a connection is
only selected if its condition evaluates to true), and some smaller
stuff.

Kris

    ----------------------------------------------------------------------------
_______________________________________________
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

Reply via email to