为何在Drools中使用MVEL

 

为何在Drools中使用MVEL

作者： Mark Proctor

我目前正在努力工作以实现插件式的语言系统，它与Drools2.0中的语义模块有些类似。使用这种系统，人们可以用任何他们喜欢的语言来编写Drl语言实现，可以用这种语言建立他们的断言、返回值、Eval和推论。我们将支持两种语言实现：Java和MVEL（http://mvel.codehaus.org/）。当然大家问的第一个问题会是为什么选择MVEL而不是Groovy，Jython等等，我将原因列举如下：

• 反射/字节码（JIT）编译和执行模式
  • 对于大型系统，我们需要避免产生过多的字节码，但是对于性能敏感区域字节码仍然是一个选择
• 快速反射模式
  • 我们最开始使用自己的语言JFDI，它被设计成一个简单并且快速的基于反射的语言，核心是所有的工作在编译时已经完成，运行时只是一系列的反射调用。这一设计已经完全在MVEL中实现，因此它的反射性能非常好。而其它语言放弃反射模式使用字节码来获得合理的性能。
• 插件式转换器
  • 字典式转换太慢，MVEL可以通过提供的转换器直接解决这个问题，这样我们可以用数组提升性能。
• 规模
  • MVEL 当前小于 350K
• 自定义的语言扩展
  • MVEL扩展了语言，通过特殊代码块嵌入以支持对规则友好的构建。因此我可以将“modify (person) ( age += 1, location = "london" )”作为一个事务模块看待，这样我可以在整个模块的前后运行拦截机制。这使得宏的应用更为简单，我们可以定义我们自己的关键字并将它扩展到MVEL代码中。
• 静态类型/推断类型或者动态模式
  • 变量可以被无类型化并完全动态进行
  • 变量可以是静态类型或者类型能够被推断，支持Casting
  • 对于类型模式可以选择验证器，不允许动态变量并且确认所有类型和方法调用都是正确的，这有助于：
    • 编制时间校验器
    • 代码补完
    • 重构
• 支持可配置的语言特性
  • 语言特性可以被关闭
  • 我们不想在“then”部分强制使用流结构，没有‘if’‘switch’等等。规则应该是宣告式的，‘何时做那件事’而不是‘何时可能做那件事’

MVEL遵从BSF（脚本语言框架），不久也将会支持EL（JSP 2.0 表达式标准实现）。MVEL已经是EL的超集，但是它仍然不支持一些深奥的特性如用不同的方式表达等式

补充一点：MVEL对比OGNL在某些情况下有10倍以上的性能提升

 

愚昧的问一下,Drools规则里的动作可以有返回值吗

要看你对返回值的期待是什么，如果指的是应用程序获得规则引擎执行后的结果。那可以通过Query命令从Working Memory中查询。另外被设置到规则引擎中的对象其实保留的是引用，也就是说，引擎对对象的修改将同时反映到应用的对象中。这也是一种返回值的方式。