[rules-dev] Re: RuleFlow preview

Wed Feb 28 00:02:37 EST 2007

Rich - what documentation is that? for the 3.0.5 production release there is
a full manual  - or are you talking about the in-IDE help for 3.1m1?

Michael.

On 2/27/07, Rich Halsey <rich_halsey at bellsouth.net> wrote:
>
>  Hi Mark,
>
> Your explanation does alleviate my concern about "implict parallelism".
> I'm assuming that this design does not preclude various rules being an
> integral part of multiple rule-flow-groups. I wasn't quite sure how to
> read that into your explanation.
>
> At the very least least, based on your new features list and rule flow,
> JBoss Rules (JBRules) seems to be set for a quantum leap forward and
> position it as a "pragmatic", world-class rules engine. I say "pragmatic" to
> emphasize the difference over other rules engines that are acclaimed by
> marketing people and are "stuffed with fluff" to compensate for their
> weaknesses.
>
> AND, we must not forget that JBRules is the most cost-effective solution
> (in terms of feature per cost) out there - bar none !!!!! I would advise all
> corporate/governmental IT managers to seriously consider training their
> staff on JBoss Rules BEFORE I would allow any rules engine vendors on the
> premises. After some intitial exposure to JBoss Rules, the staff could then
> make an informed comparison to any other rules engine out there.
>
> CONGRATULATIONS !!!!!!!!!!!!
>
> Rich Halsey
> Pensacola, FL
> USA
>
> P.S. When will the JBoss Rules documentation be ready ?? It all seemed to
> be empty when I downloaded the software alst week.
>
>
>
>
>
> "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.orghttps://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/bd615868/attachment.html 