Drools团队也推出工作流了-Drools Flow特性介绍

Drools团队在其Drools rule的基础上也推出了工作流项目-Drools Flow，Drools被JBoss收购后，现在与jBPM应该说是同一个爹妈养的了，那么Drools团队为什么执意又开发一个工作流项目呢？这个 Drools Flow又有那些新的特性或吸引人的地方呢？下面是笔者翻译的Drools官方首页（http://www.jboss.org/drools/drools-flow.html ）上的关于Drools Flow的特性介绍，以飨读者，有翻译的不当之处还望大家批评指正。

ps:TMD,他们官方网页上竟然也有很多错误单词 ,还有一些语句真TMD的难翻译，是偶水平的问题？

 

丰富的建模支持
规则集成
统一标准的API和工具
可插入式的工作项
人工任务
Guvnor集成
调试
相关审计
业务活动监控
业务流程建模标注
Drools Flow和jBPM

Drools Flow为Drools平台提供了工作流或者（业务）流程能力。一个业务流程或者工作流使用一个流程图表描述了一系列需要执行的步骤的顺序。这使得它更容易来描述一个各种不同任务的复杂组合。流程在描述基于状态的，长时间运行的过程时特别有用。Drools Flow允许最终用户使用这些流程来指定，执行和监控（一部分）他们的业务逻辑。Drools Flow流程框架可以很容易地嵌入到任何的Java应用中（作为一个简单的Java组件）或者能够以一个服务器环境的模式独立运行。

在以下的章节中，我们将要强调Drools Flow框架的的最重要的特性。
丰富的建模支持
Drools Flow提供了必要的构建区块，使得最终用户通过在他们的画板上简单地拖拽来构建他们的业务流程。这不仅包含标准的节点类型例如开始/结束节点或者分裂/会聚节点（对应于分支/t同步），而且包含合并了等待状态，计时器，事件，组合节点等的更高级的节点。每个不同的节点类型都在下面的Drools Flow手册中进行了详细的解释。

下面的实现是基于一个统一的流程框架来实现的，这个流程框架支持在同一个执行引擎上执行不同的流程模型。流程模型是基于简单节点，连接和上下文的，这使得它容易地作为一个整体将新的节点类型引入已经存在的流程语言，甚至完全不同的语言。下面的框架为非功能性的关注例如持久化，事务，事件等提供了一般的解决方案。例如，我们已经扩展了Drools Flow来支持特定的OSWorkflow的节点，为已经存在的OSWorkflow用户提供一个到Drools Flow流程引擎的简单的迁移路径。
规则集成
当谈到定义业务逻辑时，流程和规则通常作为两个不同的范式被关联在一起。那些正在定义他们应用中的业务逻辑的最终用户通常不愿意被强制使用一种范式，而是想为他们逻辑的每一个部分选择最适合的范式。业务流程和业务规则引擎的松耦合或许可以在某些案例中改进这种情况，但是这种途径不允许流程和规则之间进行更高级的交互，然后将这个责任推给了集成这些产品的最终用户。
我们认为最终用户应该被允许可以无缝地结合流程和规则。这意味着：
?    规则可以定义哪些流程被调用
?    （高级别的，领域特定的）规则可以指定那些流程中的决策
?    规则可以增大（或者覆盖）流程中的特定行为(例如处理异常的事例)
?    分配规则可以用来给（人工的）任务指定执行者
?    规则可以用来动态地更改流程的行为
?    非功能性的关注点可以从流程和现代化的使用规则中被移除
?    等
结论是，你的业务流程变得更适应改变。
统一标准的API和工具
能够在运行期的引擎中集成流程和规则是无论如何也不够的。最终用户的学习曲线必须是尽可能地低。如果流程和规则被当作是完全不同的资产，那么用户负责学习，集成和管理两个不同的产品。我们仍然认为在一个面向知识的途径中，应用程序不是面向流程或者面向规则的，但是用户可以在不同的范式中选择，用以表现他们的业务逻辑。用户面临的所有的工具和接口，支持一个统一的环境的概念贯穿于整个的知识生命周期。
例如，下面的代码片段展示了怎样给一个知识基础增加一个流程或规则是完全相同的：
KnowledgeBuilder b = KnowledgeBuilderFactory.newKnowledgeBuilder();
b.add(ResourceFactory.newClassPathResource("MyProcess.rf"), ResourceType.DRF);
b.add(ResourceFactory.newClassPathResource("MyRules.drl"), ResourceType.DRL);
同样，我们提供了一个类似的API与运行期引擎进行交互，监听由引擎产生的事件等。工具以一个类似的方式支持所有不同类型的知识（例如流程，规则，决策表等）。
可插入式的工作项
Drools Flow提供了必要的构建模块以不同的方式将任务组合为一个流程，需要被执行的任务通常是领域特定的。领域特定语言定位于一个特定的应用领域，因此能够提供与用户试图解决的问题很相近的基础结构。这使得流程能够被更容易地理解并且自动文档化。Drools Flow允许用户通过定制可以很容易地扩展节点的调色板，领域特定的工作项，如下图所示，是利用在医疗领域的环境中的特定节点来建模护理任务，处方，通知等。

 这个示例也展示了一些文件的自动处理：文件查找，日志并且在归档，复制和发邮件之前验证它们。
 
这些可插入式的工作项是：
?    领域特定
?    声明性的（什么，不是怎样）
?    高层级（不是编码）
?    对于上下文的定制（例如，测试）
这些工作项可以使它很容易地，以一个非常友好的方式集成外部的服务到你的业务流程中。我们目前为这些任务提供了默认的实现：
?    发送邮件
?    文件查找
?    FTP
?    Google 日历
?    即时消息
?    REST服务
?    REST feeds
?    创建归档
?    执行系统命令
?    数据转化
通过社区的帮助，我们希望进一步地扩展这些默认的支持服务。
人工任务
业务流程的一个重要的方面就是人工任务管理。而一个流程中的某些工作可以被自动地执行，另一些任务需要与人工的参与者协同执行。Drools Flow通过一个特定的人工任务节点支持流程内部的人工任务的使用，这个人工任务节点代理这个交互。这个节点允许流程设计者来定义任务类型，参与者，与这个任务相关的数据等。
既然这个人工任务节点作为一个可插入式的工作项（参考上面）来实现，因此用户可以集成任何他们想要的人工任务管理解决方案（后端的 与/或 用户接口）。我们基于WS-HumanTask规范提供了一个默认的实现。这个规范描述了任务的生命周期和怎样与任务管理服务（查询任务，改变状态等）做交互。
Guvnor（Guvnor是Drools的另一个开源项目，是一个管理大量规则的中央知识仓库-译者注）集成
Drools Guvnor提供了一个（以逻辑为中心的）仓库用来存储你的业务知识，还有一个基于web的环境，允许业务用户来查看和（在一定的约束下）有可能直接地更新业务逻辑。
流程可以被上传到Guvnor，并且可以手动地，或者使用我们的Eclipse Guvnor工具增加一个知识包（与其它的知识资产相结合，例如规则，决策表等等）。这使得管理你公司的业务逻辑更加的容易，同时也更容易被业务用户所理解。

 (click to enlarge)
调试
Drools Eclipse IDE通过特定的视图扩展了你通常的Eclipse调试体验，这些视图展示了当前正在运行的流程实例和它们所处的状态。例如，下面的图展示了一个流程中高亮的节点是正在执行并且等待被完成。
 
这使得它容易在执行期的任何点上发现你的应用的状态，并且调试你的流程以防看到不期望的结果。注意，Drools IDE支持集成调试，这意味着你总是可以同步地看到你的所有的流程和规则的状态。
相关审计
Drools Flow在流程执行的过程中生成事件，这允许我们创建一个包含必要信息的审计日志来计算出在运行期将要发生的事情。这个审计日志可以是一个简单的XML文件（如下所示，可以在Drools IDE中以一个树形方式可视化地看到），或者存储到一个数据库中（为了进一步的处理）。

更重要的是，这些审计特性不仅提供了关于你的流程执行的信息，而且也包含你的应用中的规则。终端用户不必去尝试手工地收集两个日志文件（一个来自于流程引擎，另一个来自于规则引擎），而是可以看到一个集成的审计日志，展示出在执行期发生的事件。
业务活动监控
你需要积极地监控你的流程来确保你能尽可能早地探测到任何的异常和对不期望事件的影响。基于对那些事件的监控，业务活动监控可以实时监控你的业务流程和直接干预（甚至可能自动地）的可能性。Drools Flow允许用户基于流程引擎生成的事件来定义报表，并且使用事件处理规则（Drools Fusion）在特定的条件下进行有可能地直接干预。
基于Eclipse BIRT(业务职能报表工具)，用户能够创建报表用来展示他们业务的关键绩效指标。使用包含所有流程历史信息（基于在数据库中记录了所有的运行期事件的一个历史记录器）和任何你可能想要加入的其它数据源的预定义数据集，你可以容易地定义你自己的报表。Eclipse BIRT框架允许你定义数据集，创建报表，包含图表，报表预览，用web页导出它们等。下面的屏幕截图展示了一个图表的示例。
 
(click to enlarge)
BPMN（业务流程建模标注）
BPMN(业务流程建模标注)是一个被业务用户用来建模业务流程而广泛使用的工作流标注语言。BPMN定义了术语，不同的节点类型，以及这些节点怎样被可视化，等等。那些熟悉BPMN的人或许发现使用一个相似的可视化工具可以很容易实现一个可执行的流程（可能基于一个BPMN的流程框图）。因此我们创建了一个BPMN的皮肤用来将Drools Flow的概念匹配到等同的BPMN可视化视图上。
 
(click to enlarge)
Drools Flow 和jBPM
Drools Flow是一个社区项目。jBPM仍旧是JBoss的唯一的官方工作流产品。Drools Flow和jBPM是两个独立的项目。这是由于在Drools内部面向知识的平台（和在流程与规则之间的高级集成）中流程集成的需求而导致的结果，而这个需求没有被jBPM提供。jBPM4和Drools Flow都是基于一个具有可插拔的执行行为的流程框架的，在jBPM中指的是PVM（流程虚拟机）。然而，直到现在为止，jBPM和Drools Flow都没有能够达成一个统一的合并方式。然而，我们确信Drools Flow提供了一些至少可与jBPM项目相比的特性。
Drools 5是一个完全从底层重构的（不是重新实现），具有一些新的公共API和与规则，流程，作为一等公民的事件一起设计的任何特性，在没有确信是无缝的，统一的和正交的之前没有添加任何新的特性。因为流程、规则和事件被集成到一个引擎中，所有这三个范式都可以方便地利用公共的特性（当你增加一个特性到某一个范式时，它也同样可以被其它的范式所访问）。没有理由为了多个api和部署办法，这些api和部署办法至多会在复杂性上加重用户的负担，最坏的情况下是当两个不同的项目一起使用时引入不匹配。
使用两个不同提供商的产品时，传统的方式是强制用户以面向流程或者面向规则的办法来工作，这种方式恰好成为了妨碍，在他们应该使用哪一种工具来建模哪一部分时通常很混乱。Drools是从以规则为中心或者流程为中心改变为一个更接近于行为建模的项目，这种行为建模对于用户来建模他们想要的问题具有更大的灵活性，对于软件开发创建了一个更全面的方法（此处的术语，“全面的”用来强调整体的和它的各部分相互依存的重要性）。
我们并不认为在以流程为中心的方式内部，仅有规则集成或者事件处理集成没有被考虑或者在事后被添加进来，而不是从一开始就作为一个基本的原则添加进来。这通常意味着对于一个被一个流程节点（具有所有的匹配，编组，取消编组和作为结果的一致性问题）调用的无状态的规则会话来说，规则集成是有限的。以流程为中心的方式同时也强制用户学习重复的，而不是不同的，api和部署方法，也不会提供一个用于支持业务知识（例如作为Drools核心的，一个统一的知识仓库和管理工具，或者提供重要的特性，例如相关的审计日志和报表）的生命周期的工具链。
基于这些原因和其它的有区别的特性，并且具有足够的社区认可和需求，我们仍然希望Drools Flow作为一个JBoss产品而被采纳。

评论

2 楼 ltian 2010-04-19  

这篇好文章收藏了，谢谢你的工作！

1 楼 ltian 2010-04-19  

我感觉不仅仅是工作流定义中的一些流程传递的规则需要规则的支持，权限也可以看成规则的一个子集。当然人类越来越认识到事务的本质的时候，事情就会变得越来越简单。