I don't know about myths, but I agree that having business people maintain rules is not a slam dunk.
I think expecting business folks to have the patience and anal retentive attention to detail required to do IT's job is a fantasy. It's been in play ever since 3G languages (graphical approaches to programming) have been offered as a way to get secretaries to write code so the programmers could all be fired.
I'd point out that as the size of the rule set increases, the possibility of ensuring that it's correct and self-consistent goes down. If your rules set has thousands of rules it'll be hard to test.
Speaking of which, combinatorial explosion of combinations will make it hard to test a rules engine.
Rules engines are terrific technology, but be careful.
Actually, having used drools heavily, I disagree with you on your point about users having the ability to do stuff easily, I think it's relatively trivial to provide users with a simple interface to generate powerful rules dynamically.
One I would definitely add to the list is:
Myth: Rules engines are slow!
Not so, again, I've pushed even thousands of events per second through drools quite easily.
Another which I absolutely loathed was:
Myth: It's too heavy weight and complex to use.
Nonsense, the syntax is trivial and with a few lines of java, you can do some really funky stuff! Sorry if this appears to be a rant, had months of this crap at a previous employer as I wad trying to introduce this tech!
Myths... 1/ Business users can: author rules deploy them test them run them Whithout the help of IT... I have delivered a training for a client who was actually thinking that it was true because the salesman said so... ah ah ah they made my day/mounth/year !!!
Can you seriously think about a company who will take the risk to deploy a service in the back of the IT team?? no way! You need security as well to prevent me writing a rule stating: if the name of the client is "Damien" then 100% discount - groovy baby!
The architecture of a project cannot be done by non-technical users
2/ You can manage rule project easily without having to worry about anything. There is limit of number of rules you can deal with. In theory one could have as many rules as they want but this is not entirely correct. JRules stop synchronizing rules between Eclipse and RTS from around 3,000 rules. It will take forever if you have a project with 100,000 rules all in RETE. Building the tree will take a long time. Even in Sequential mode it takes a long time to proceed.
You cannot use a rule repository like the folder "My Documents" and just keep on adding rules.
3/ Business users can write all kind of rules without any training. Different things: a/ order of conditions may impact performance. b/ some rules are complex and need a good understanding of the language c/ the algorithm used can impact the result of the execution d/ a single badly written rule can multiply the execution time by n. I worked on a project where only 1 rule was responsible for some random timeouts. e/ Some complex problem can be express in one rule. This problem is solve in one rule and has one result: There are four Golfers standing at a tea, in a line from left to right. - The golfer to the Fred’s immediate right is wearing blue pants - Joe is second in line - Bob is wearing plaid pants - Tom isn’t in position one or four, and he isn’t wearing the orange pants
BTW: This is an JBoss example.
How can a business user do this?
4/ Rule engine can do backward chaining I think JBoss say they can but I am not sure about this. Blaze and JRules cannot.
5/ One doesn't need any programme language to write rules. Correct, but you will need some to execute the rules. Except if you are using a simple XSD as Object Model. But your Decision Service will not do that much clever thing.
6/ It is slower than JAVA Of course but by using BRMS you are externalizing the business logic so it has a cost. Exactly like when you externalize data. The database call has a cost. I have sent 5,000 objects into the working memory of JRules with a project containing 4 dummy rules which were calling each other... Performance test purpose Result: 19 Millions rules executed in 75 seconds. Do your maths... it is not that slow.
7/ You can do anything in a rule Do not make database call in a rule (especially in the conditions). Using Rete, in theory, a rule could "test" the condition to find matching result in the memory thousands of time. No one want to call a database that much in an application.
发布评论
评论（3）
我不知道有哪些神话，但我同意让商界人士遵守规则并不是一劳永逸的事情。
我认为期望业务人员拥有完成 IT 工作所需的耐心和对细节的高度关注是一种幻想。自从 3G 语言（图形化编程方法）作为一种让秘书编写代码以便程序员都可以被解雇的方式被提供以来，它就一直在发挥作用。
我想指出的是，随着规则集规模的增加，确保其正确性和自洽性的可能性就会下降。如果您的规则集有数千条规则，则很难测试。
说到这里，组合的组合爆炸将使测试规则引擎变得困难。
规则引擎是很棒的技术，但要小心。
I don't know about myths, but I agree that having business people maintain rules is not a slam dunk.
I think expecting business folks to have the patience and anal retentive attention to detail required to do IT's job is a fantasy. It's been in play ever since 3G languages (graphical approaches to programming) have been offered as a way to get secretaries to write code so the programmers could all be fired.
I'd point out that as the size of the rule set increases, the possibility of ensuring that it's correct and self-consistent goes down. If your rules set has thousands of rules it'll be hard to test.
Speaking of which, combinatorial explosion of combinations will make it hard to test a rules engine.
Rules engines are terrific technology, but be careful.
实际上，在大量使用drools之后，我不同意你关于用户有能力轻松完成任务的观点，我认为为用户提供一个简单的界面来动态生成强大的规则相对来说是微不足道的。
我肯定会添加到列表中的一个是：
事实并非如此，我再次很容易地将每秒数千个事件推入流口水。
另一个我绝对讨厌的是：
废话，语法很简单，用几行java，你就可以做一些非常时髦的事情！抱歉，如果这看起来像是咆哮，当我试图介绍这项技术时，我在前任雇主那里经历了几个月的废话！
Actually, having used drools heavily, I disagree with you on your point about users having the ability to do stuff easily, I think it's relatively trivial to provide users with a simple interface to generate powerful rules dynamically.
One I would definitely add to the list is:
Not so, again, I've pushed even thousands of events per second through drools quite easily.
Another which I absolutely loathed was:
Nonsense, the syntax is trivial and with a few lines of java, you can do some really funky stuff! Sorry if this appears to be a rant, had months of this crap at a previous employer as I wad trying to introduce this tech!
神话...
1/ 企业用户可以：
作者规则
部署它们
测试它们
运行它们
在没有 IT 帮助的情况下...我为一位客户提供了培训，他实际上认为这是真的，因为推销员是这么说的...啊啊啊他们让我度过了一天/一个月/一年！
你能认真考虑一下有一家公司会冒着风险在IT团队后面部署一个服务吗？没办法！
你也需要安全来防止我写一条规则：
如果客户的名字是“Damien”，则 100% 折扣 - 绝妙宝贝！
项目的架构不是非技术人员可以完成的
2/ 您可以轻松管理规则项目，无需担心任何事情。
您可以处理的规则数量是有限的。理论上，人们可以拥有任意数量的规则，但这并不完全正确。
JRules 停止在 Eclipse 和 RTS 之间同步大约 3,000 条规则。
如果您的项目有 100,000 条规则，全部都在 RETE 中，那么这将需要很长时间。建造这棵树需要很长时间。即使在顺序模式下，也需要很长时间才能进行。
您不能使用像“我的文档”文件夹这样的规则存储库并继续添加规则。
3/ 业务用户无需任何培训即可编写各种规则。
不同的东西：
a/ 条件的顺序可能会影响性能。
b/ 有些规则很复杂，需要对语言有很好的理解
c/ 使用的算法会影响执行结果
d/ 一条写得不好的规则会使执行时间增加 n 倍。
我参与的项目中只有 1 条规则导致一些随机超时。
e/ 一些复杂的问题可以用一条规则来表达。
这个问题可以用一条规则解决，并有一个结果：
<我>
有四名高尔夫球手站在茶边，从左到右排成一排。
- Fred 右边的高尔夫球手穿着蓝色裤子
- 乔排在第二位
- 鲍勃穿着格子裤
- 汤姆不在位置一或位置四，而且他没有穿橙色裤子
顺便说一句：这是一个 JBoss 示例。
企业用户如何才能做到这一点？
4/ 规则引擎可以进行反向链接
我认为 JBoss 说他们可以，但我对此不确定。 Blaze 和 JRules 不能。
5/ 不需要任何程序语言来编写规则。
正确，但您需要一些来执行规则。除非您使用简单的 XSD 作为对象模型。但你的决策服务不会做那么聪明的事情。
6/它比JAVA慢
当然，但是通过使用 BRMS，您将业务逻辑外部化，因此它会产生成本。
就像外部化数据一样。数据库调用是有成本的。
我已将 5,000 个对象发送到 JRules 的工作内存中，其中包含 4 个相互调用的虚拟规则的项目...性能测试目的
结果：75 秒内执行了 1900 万条规则。算算算……没那么慢。
7/ 你可以在规则中做任何事情
不要在规则中（尤其是在条件中）进行数据库调用。理论上，使用 Rete，规则可以“测试”条件以在内存中查找匹配结果数千次。
没有人愿意在应用程序中调用数据库那么多。
希望有帮助
Myths...
1/ Business users can:
author rules
deploy them
test them
run them
Whithout the help of IT... I have delivered a training for a client who was actually thinking that it was true because the salesman said so... ah ah ah they made my day/mounth/year !!!
Can you seriously think about a company who will take the risk to deploy a service in the back of the IT team?? no way!
You need security as well to prevent me writing a rule stating:
if the name of the client is "Damien" then 100% discount - groovy baby!
The architecture of a project cannot be done by non-technical users
2/ You can manage rule project easily without having to worry about anything.
There is limit of number of rules you can deal with. In theory one could have as many rules as they want but this is not entirely correct.
JRules stop synchronizing rules between Eclipse and RTS from around 3,000 rules.
It will take forever if you have a project with 100,000 rules all in RETE. Building the tree will take a long time. Even in Sequential mode it takes a long time to proceed.
You cannot use a rule repository like the folder "My Documents" and just keep on adding rules.
3/ Business users can write all kind of rules without any training.
Different things:
a/ order of conditions may impact performance.
b/ some rules are complex and need a good understanding of the language
c/ the algorithm used can impact the result of the execution
d/ a single badly written rule can multiply the execution time by n.
I worked on a project where only 1 rule was responsible for some random timeouts.
e/ Some complex problem can be express in one rule.
This problem is solve in one rule and has one result:
There are four Golfers standing at a tea, in a line from left to right.
- The golfer to the Fred’s immediate right is wearing blue pants
- Joe is second in line
- Bob is wearing plaid pants
- Tom isn’t in position one or four, and he isn’t wearing the orange pants
BTW: This is an JBoss example.
How can a business user do this?
4/ Rule engine can do backward chaining
I think JBoss say they can but I am not sure about this. Blaze and JRules cannot.
5/ One doesn't need any programme language to write rules.
Correct, but you will need some to execute the rules. Except if you are using a simple XSD as Object Model. But your Decision Service will not do that much clever thing.
6/ It is slower than JAVA
Of course but by using BRMS you are externalizing the business logic so it has a cost.
Exactly like when you externalize data. The database call has a cost.
I have sent 5,000 objects into the working memory of JRules with a project containing 4 dummy rules which were calling each other... Performance test purpose
Result: 19 Millions rules executed in 75 seconds. Do your maths... it is not that slow.
7/ You can do anything in a rule
Do not make database call in a rule (especially in the conditions). Using Rete, in theory, a rule could "test" the condition to find matching result in the memory thousands of time.
No one want to call a database that much in an application.
Hope it helps