[rules-dev] Re: RuleFlow preview

[Michael Neale]

I think that is an example of a "pragmatic" way to solve something that
backwards chaining could possibly achieve, but in a perhaps more intuitive
way. I don't think its what is talked about in the literature is quite the
same, but still, this is very useful.

Thanks for the kind words !


On 2/27/07, Rich Halsey <rich_halsey at bellsouth.net> wrote:
>
>  *Mark,*
> **
> *In yet another point of interest, I also see the JBoss Rules "rules flow"
> as a very elegant form of backward chaining implementation/modeling. For
> example, in the PDF file from Kris Verlaenen, the ultimate goal of
> "Process Order" cannot be accomplished without the completion of "Check
> Order" which may/may not (?) complete without "Update Order". As opposed to
> the engine hunting through all of the conditions and actions to find an
> appropriate path for the backward chaining, the model implies how it is to
> be done and the system will guarantee the flow with its split and join nodes
> via forward chaining - but, if and only if the backward chaining
> pre-conditions are satisfied.*
> **
> *I'm not sure who will agree with what I have said, but this is the way
> that it appears to me as a rules engineering person.*
> **
> *Thanks,*
> **
> *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* <mproctor at codehaus.org>* *
> *To: **Rules Dev List* <rules-dev at lists.jboss.org>* *
> *Cc: **Rich Halsey* <rich_halsey at bellsouth.net>* ; **James C. Owen*<jco at kbsc.com>
> * *
> *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* <mproctor at redhat.com>* *
> *To: **Rules Dev List* <rules-dev at lists.jboss.org>* *
> *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 **<kris.verlaenen at gmail.com>*<kris.verlaenen at gmail.com%3E> 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
> **rules-dev at lists.jboss.org* <rules-dev at lists.jboss.org>*https://lists.jboss.org/mailman/listinfo/rules-dev* <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/20070228/2485784b/attachment.html