究竟什么才是真正的规则引擎

可能很多人还不了解规则引擎是什么东西，或者不知道规则引擎究竟有什么用。我们都知道工作流引擎，也听说过JBoss下面有个Drools，或者我们知道 weblogic或者Oracle也有自己的Business Rule，我们可能还听说过ILOG被IBM收购了，如果我们研究微软的WWF，可能也知道其中有RuleSet等内容。国内的一些web快速开发平台，也提到了规则引擎。
在我们的印象中，我们感觉规则引擎就是解决业务逻辑层的实现问题的。因此我们理所当然的觉得工作流中的某个节点的逻辑处理，应该可以用规则引擎来解决，那么工作流本身的逻辑也应该可以由规则引擎来解决。另外我们也会觉得，平时项目当中的业务逻辑应该都可以用规则引擎来解决。
但是当我们在使用上述这些规则引擎，却发现很难和我们实际应用的业务逻辑层的业务逻辑实现相对应。
我们以JBoss的Drools为例，由于其规则引擎使用了匹配规则的方式来进行，因此在应用这些规则引擎时。首先需要将我们具体应用中的业务逻辑做抽象，抽象成一条条规则之后，再打包成一个规则包。一个规则包相当于一个智能块。当数据传递给这个智能块后，系统会以匹配的方式应用满足条件的逻辑处理。
当采用这种方式时，应该说逻辑更抽象了，在一个更高的层次加以抽象化的定义。但是也使得规则引擎的应用得到了很大的限制。
首先这种抽象本身需要一个复杂的分析过程，这需要有很强的分析设计能力。另外我们平时具体应用中的业务逻辑层，大量的逻辑都是对实际数据的处理，很多时候还是一个批量数据的处理，甚至有些逻辑需要的参数我们并不能定义在规则中，而是在数据库表中进行配置。因此我们常见的业务逻辑层的开发，并不能先设计出一个数据模型，然后再在此基础上抽象逻辑。
因此我们发现Drools等规则引擎很难用，根本不是我们所需要的那样。
我们研究规则引擎也有一段时间了。有时候我们发现自己做的规则引擎并不是一个规则引擎。因为我们和像Drools这些规则引擎有很大的差别。但我们确实解决了业务逻辑层的业务逻辑配置问题。应该说我们的更实用一些。但是我们却没法去实现JSR94标准。我们不光处理业务逻辑，还把所有业务逻辑层需要处理的操作全部采用规则配置的形式，包括数据库处理逻辑等。
因此我们有时候在想，究竟什么才是真正的规则引擎，我们这种方式肯定也是一种实现。业务JSR94标准应该改进一下了。