精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-07-22
为监控程序和时间敏感程序编写规则 <o:p></o:p> 作者:Edson Tirelli <o:p></o:p> 在讨论完关于编写规则的抽象概念以后,我打算停一下,讨论一些真实的规则引擎用例以及怎样对这些用例编写规则。<o:p></o:p> 我发送了邮件到用户列表中询问大家喜欢更详细的讨论哪些用例,然后我开始收到一些反馈。在这篇文章中,我将讨论一个由Neil Goldman建议的主题,同时也是分享他对监控程序和时间敏感程序建立规则的一些想法。
监控应用
让我们从一个简单的例子开始讨论:假设用一个监控程序是为空调系统设置的,它必须保持温度在某一个范围之内。<o:p></o:p> 完成它的一个简单方法是使用规则引擎中有状态的working memory,它反射系统的状态并且规则针对状态的改变做出反应。上面例子中系统的状态是由传感器提供,因此将传感器模型作为Fact是最好的方法。规则将基于这些传感器Fact来做出决定。因此,你的规则可以是: 规则 代码
规则 代码
我们这里所说的是推论时间。如果用作推论的时间,显然需要将它看作fact模型。 " 你不要想规则条件读取操作系统的时钟作为匹配条件的一部分,因为当这些条件被评估时,你只能做很小的控制。系统时钟以一种非常高的频率进行变化,而规则引擎无法察觉这么小的如此高频率的变化。<o:p></o:p> 你希望你的规则可以对一个伪时钟具有敏感性,那
<o:p> </o:p>
<o:p> </o:p>
<o:p> </o:p> 要注意的时,上面所提及的问题,没有严格的限制要求定期将你的伪时钟与系统时钟同步,只要你拥有控制,何时和怎样更新伪时钟都可以。 现在我们从代码级别来了解一下所说的情况。假设你有一个任务计划应用程序,并且你想编写的规则将在计划的时间到达后运行你的任务,或者前一个必须的任务已经完成时。你的规则应当如下:
<o:p> </o:p> 你可能注意到在计划时间和当前时间比较时用了一个“<=”操作。这是因为通常无法保证你的规则正好在指定时间运行(除非运行在一个实时的平台),但是将在计划时间后尽早的执行。因此对时间的条件判断使用范围或一个起点来判断要比绝对值好。<o:p></o:p> 规则代码
监控程序也可以于无状态working memory一起工作,但是一个有状态的working memory通常对案例有更好的判断,就像上面描述那样。时间敏感的应用 时间敏感应用程序是根据时间进行推论或反应的应用。例如:账单应用,运行模拟的应用,任务计划等等。 在这样的应用中,规则将直接或间接的依赖于时间。在这里重点注意的是不要搞混将时间作为数据还是元数据应用到规则的区别。规则引擎通常有功能特性用来将时间作为元数据处理,比如允许特性指定一个规则的生效和失效时间。<o:p></o:p> java 代码
你的约束条件也会被作为fact的模型(上例中的TemperatureRange),用来帮助编写更灵活的规则,避免需要对值进行硬编码,并且允许单个规则对几个不同的条件进行反应。好了,我们已经从规则的方面来看你的问题,但是应用程序需要做什么呢?答案是:简单的保持更新传感器数据。可以通过几种办法完成,依赖于系统工作的方式,但最终通常使用查询和事件两种方式。如果你对ACS进行查询,代码如下:<o:p></o:p>上面是非常简单的规则,但是它们示范了这个概念。下面是利用天气传感器获得的数据建立对天气有更精密反应的规则模型: <o:p></o:p> 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
浏览 3121 次