(工作流)商务过程管理系统与规则引擎携手并肩而来。过程定义语言(例如 XPDL , Colored Petri Nets , Pi-Workflow 或者 jPDL )用来在相对粗级别的抽象层次来描述一个过程。规则用来在工作流的上下文基础之上实现决策,例如决定谁来负责一个项目,当一个活动完成时应该通知谁,或者当一个活动拖延了应该做什么。
今天, JBoss Drools 团队的 Mark Proctor 和 Kris Verlaenen 发表了一篇文章:对使用工作流和规则进行声明式编程的看法。文章以 Mark 描述的工作引擎的下一个主要优势为开端:
当 前规则引擎业界的“惯用伎俩”是关注于无状态的决策服务,分离的工作流引擎在某些时候调出分离的无状态的规则引擎来辅助决策工作 —— 在经过了 30 年的研究与开发后,这是我们能够提供的最好的方案。数百万英镑的许可证无非是从一些工作流引擎的一个无状态 web service 调用而得到的美化的电子表格。不是贬低这个模型,实际上这个模型是非常有用的,但是规则引擎与工作流引擎在这种级别的集成最多只是表面上 的,而我们需要统一这些模型,使得这个模型达到更高的层次。
这篇文章是基于 jBPM 团队以前发表的一篇论文,该论文中的说法是"过程虚拟机(Process Virtual Machine)" (PVM)。概括地说,对于工作流来说PVM 就像对于Java 来说的字节码 —— 是一个独立于过程定义语言的过程执行引擎。Kris 介绍了 PVM+ 与规则引擎集成并与过程执行环境一起提供如下的优点:
- 可以在过程定义中对规则建模
- 可以在规则和过程之间共享数据(包括结构定义)
- 统一审计
- 简化了管理功能
- 规则和过程的实例可以通过共享的上下文并行的对变化作出反应
PVM+ 是以过程为中心的 DSLs 的基础。Kris 例举了现有的 jBPM 语言 jPDL,与我们最近介绍的 PageFlow (在 web 页面中指定控制流的工作流语言)和 RuleFlow (一种处理有大量规则的流程的工作流语言) 一同作为样例实现语言。
Kris 探讨了“工作条目处理器”的作用,它是负责执行处理实例的。Kris 对于依赖上下文采用不同的处理器的想法很感兴趣。这种方法可以用来克服一个由来已久的对基于规则和工作流的开发的批评——即难以测试:
一个工作流在它的生命周期的不同阶段会有不同的行为。例如,对于测试,处理器可以仅仅是简单的测试工作流的执行是否被记录了。在仿真时,做一些对某些应该被执行的工作条目的可视化工作,使得人们可以仿真完成 / 放弃这些工作条目。
查看英文原文: Unified Rules Engine and Processes - - - - - -
译者简介: 曹云飞,西安交通大学计算机软件硕士。现就职于 Ethos ,热衷于新技术的钻研,软件架构与敏捷开发,目前从事 Home Control 方面的工作。参与 InfoQ 中文站内容建设,请邮件至 china-editorial[at]infoq.com 。
评论 2 条评论