5:12 a.m.
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(a)gmail.com>
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
6:38 a.m.
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 <kris.verlaenen(a)gmail.com>
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
7:58 a.m.
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 <mailto:mproctor@redhat.com>
*To:* Rules Dev List <mailto:rules-dev@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(a)gmail.com>
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:11 a.m.
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
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 <kris.verlaenen(a)gmail.com>
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:02 p.m.
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(a)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(a)codehaus.org>
*To:* Rules Dev List <rules-dev(a)lists.jboss.org>
*Cc:* Rich Halsey <rich_halsey(a)bellsouth.net> ; James C. Owen<jco(a)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(a)redhat.com>
*To:* Rules Dev List <rules-dev(a)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(a)gmail.com> <kris.verlaenen(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
9:24 a.m.
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 <kris.verlaenen(a)gmail.com>
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
10:19 a.m.
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
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 <kris.verlaenen(a)gmail.com>
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:06 p.m.
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(a)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(a)codehaus.org>* *
*To: **Rules Dev List* <rules-dev(a)lists.jboss.org>* *
*Cc: **Rich Halsey* <rich_halsey(a)bellsouth.net>* ; **James C.
Owen*<jco(a)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(a)redhat.com>* *
*To: **Rules Dev List* <rules-dev(a)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@gmail.com>*<kris.verlaenen(a)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(a)lists.jboss.org*
<rules-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6824
days inactive
6826
days old
7 comments
4 participants
participants (4)
-
Mark Proctor -
Mark Proctor -
Michael Neale -
Rich Halsey