最近几年,在很多的产品中越来越重视业务规则引擎的实现。比如IBM目前主推的一些产品线中,单独针对业务规则进行了强化。但是在实际的项目应用中,却发现究竟哪些应用,或者那些规则适合采用业务规则引擎来进行实现,而其他的一些规则适合采用工作流引擎或者报表引擎来进行实现。
这个问题,其实和不同规则引擎的适用面有关。一般的规则引擎,最适合是那些数据结构确定的业务规则的处理。特别是这些规则是非常雷同的,可以说是平级的,然后反复的对同一批数据进行匹配处理。比如电信计费规则,是针对用户的使用数据,有很多同级的套餐规则,然后将这些数据,用所有的套餐规则算一遍。这些套餐规则,基本都是平级的,偶尔有些具有先后顺序的,也只是采用一些标记来进行控制。
就这类业务规则引擎来说,规则引擎的应用还是非常单一的。如果规则非常少,或者说和数据结构的关系比较紧密,就不适合采用规则引擎来做。这类业务规则,可以在工作流引擎中,有些直接就采用sql语句等解决,或者说采用脚本语言来进行解决。因为规则引擎的应用反而显得非常累赘。
业务规则引擎经过扩展功能后,需要加上对数据结构的变更支持,特别是支持数据库结构的变更。这样的话,业务规则引擎就不仅仅只是对数据处理逻辑的实现,而且是数据层的处理实现。
这类业务规则引擎,就可以将绝大部分的项目中需要用到的后台逻辑采用业务规则引擎来进行实现。如此一来工作流引擎的压力就会大大减少,其只需要处理表单、流程控制等,其他的一概都可以交给规则引擎来进行实现。工作流就只需要处理流程相关的一些数据结构,即使一些业务数据,也只需要事先传给工作流实例就行了,而不需要再去考虑业务相关的其他一些数据结构等。
在此类业务规则引擎的