Drools Flow

Drools> Drools Flow

Drools流程

         DroolsFlow已命名为jbpm5,官网：http://www.jboss.org/jbpm

Rich Modelling Support(丰富的建模支持)

Rule Integrating(规则集成)

Unified API and Tooling(统一的API和工具)

Pluggable Work Items(可插拔的工作项目)

Human Tasks(人工任务)

Guvnor Integration(Guvnor 整合)

Debugging(调试)

Correlated Auditing(相关的审核)

Business Activity Monitoring(业务活动监控)

BPMN

Drools Flow And jBPM(Drools流程和jBPM)

Drools Flow提供工作流（业务）或者业务流程能力的Drools平台。业务流程或者工作流描述了一系列有序需要执行的步骤，使用流程图来直观描述。这儿使得他很容易描述一个复杂的组成任务。对描述基于状态，长时间运行的流程的进程是特别有用的。Drools Flow，可以使最终用户使用这些流程制定，执行和监控他们的业务逻辑。Drools Flow流程框架是很容易嵌入到任何java应用程序(如一个简单的java组件)，也可以独立运行在服务器环境中。

下面的章节中，是Drools流程框架的最重要特点：

Rich Modelling Support(丰富的建模支持)

         DroolsFlow提供啦必要的基石，终端用户可以简单滴拖放到画布上，构建自己的业务流程。这不仅包含标准的节点类型开始/结束节点，还有分支/合并节点(分支/同步),但还有更先进的等待状态，定时器，时间，复合节点。如下图：

底层的实现是基于一个通用流程框架，在相同的执行引擎中执行不同的建模方式。这一流程建模是基于一个简单的节点，连接和语境，可以很容易地将一个现有的流程语言添加到新的节点类型中，或者支持甚至完全不同的语言作为一个整体。基本框架提供啦通用的解决方案，非功能性的问题，如持久性，事务，事件等。例如，我们已经扩展Drools Flow,以支持特定的OSWorkFlow的节点，让一个简单的迁移路径，为现有的OSWorkflow的使用Drools Flow流程引擎。

Rule Integration(规则集成)

         流程和规则通常被认为是两个不同的模式来定义的业务逻辑。终端用户定义他们的应用程序时通常不想被迫进入一个范例，而是要选择最合适的每一个部分的逻辑范例。松散耦合的业务流程和业务规则引擎（也称为“决策服务”）可能会改善这种情况在某些情况下（而且在某些情况下，是一个很好的解决方案），但这方法不允许高级集成在流程和规则之间，并提出将这些产品的集成负担在终端用户上。

我们相信，允许终端用户能够将流程和规则无缝地结合起来，例如：

         a．流程调用的时候，可以定义规则，

         b.  (高层次的，特定域的)规则可以定义在这个流程中

         c.  在流程中（例如处理特殊的情况下），规则可以添加(或者重写)特定的行为

         d．任务分配，规则可以作为人工任务区分配

         e.  规则可以用来动态地改变行为的流程

         f.       非功能关注点可以从改流程中去掉，模块化的使用规则等等。

因此，你的业务流程变得更加适应变化。

Unified API and Tooling(统一的API和工具)

         在运行时集成流程和规则，还不够。终端用户的学习曲线必须竟可能低。如果流程和规则被视为两个完全不相同的资源，那么用户是负责学习，集成和管理两个不同的产品。然而，我们相信在一个以知识为向导的方式下，应用程序是面向过程的，或者以规则为向导。但终端用户可以简单滴选择二，不同的形式来表示自己的业务逻辑。所有的工具和接口，用户需要面临一个统一的环境，在整个知识生命周期中都支持整个想法。

例如：演示如何添加一个流程或者一个规则的知识库，实现完全一样的：

KnowledgeBuilderb = KnowledgeBuilderFactory.newKnowledgeBuilder();
b.add(ResourceFactory.newClassPathResource("MyProcess.rf"),ResourceType.DRF);
b.add(ResourceFactory.newClassPathResource("MyRules.drl"),ResourceType.DRL);

         同样，我们提供啦一个类似的API进行交互，在引擎运行时，听到引擎产生的时间等工具支持所有不同类型的知识（如流程，规则，决策表等）以类似的方式。

Pluggable Work Items(可插拔的工作项目)

         DroolsFlow在流程中，提供啦必要的积木，以各种方式结合任务，任务需要执行在特定的域中。特定域的语言是针对一个特定的应用领域的，因此能够提供结构密切相关用户视图解决的问题。这儿使得流程更容易理解和自我记录。Drools Flow，终端用户可以很容易地扩展节点，自定义面板，特定领域的工作项目，例如向下面所示，使用专门的节点在医疗保健方面的任务模式：护理，用药，通知等。

         这个例子显示了一些文件处理的自动化，找到了一些文件，日志和归档，复制和发送电子邮件之前，对他们进行验证。

这些可插拔的工作项目是：

         特定领域

         声明(什么，儿不是如何)

         高层次（无代码）

         定制的上下文(例如测试)

这些工作项目，他很容易集成到外部服务到业务流程中，是一个非常友好的方式。我们目前提供的默认实现任务，如：

         发送电子邮件

         查找文件

FTP

谷歌日历

即时通讯

REST服务

RSS订阅

建立档案

执行系统命令

转换数据

随着社会的帮助下，我们希望进一步扩展这组默认支持的服务。

HumanTask(人工任务)

         人工任务是业务流程的一个重要组成。随让流程中执行的一些工作，可以自动执行，但是许多任务还是需要人工的执行。Drools Flow支持在使用人工任务里面可以使用一种特殊的人工任务节点，来代表这个互动的流程。这个任务节点允许流程设计者自定义任务类型，角色，相关的数据等。

         由于这些人工任务节点时一个可插拔的工作项目(见上文)，他们更喜欢用户能够集成任意人工任务的解决方案（后台或者用户界面）。不过，我们会提供一个默认的实现基于WS-HumanTask规范。本规范描述了生命周期的任务以及如何进行交互的任务管理服务(查询任务，改变状态等)

Guvnor集成

         DroolsGuvnor提供了一个逻辑上集中的存储库来存储你的商业知识，和一个基于Web的环境，让企业用户查看和(在一定的限制内)，可能直接更新业务逻辑。

         流程可以上传到Guvnor和添加知识包（手动或者通过使用我们的Eclipse Guvnor工具，结合其他知识资源如：规则，决策表等），无论是手动，或者通过使用Eclipse Guvnor工具。这儿可以更容易地管理和访问你公司的业务逻辑(包含：历史，版本，动态更新的业务，等等)，就像管理业务人员一样。

Debugging(调试)

         DroolsEclipse IDE集成你的正常Eclipse 调试经验，专业的视图可以显示当前运行的流程实例和他们所处的状态。例如，下面的截图显示了突出的节点目前正在执行并等待完成的状态。

在执行和调试的过程中，这使得很容易找到你的应用流程是出入什么状态。请注意，在Drools IDE支持集成调试，这人意味着你将总是能够看到你的流程和规则之间的状态。

CorrelatedAuditing(相关审核)

         Drools Flow执行过程中所产生的时间，让我们可以创建一个审核日志包含必要的信息，弄清楚如何运行的。审核日志可以是一个简单的XML文件(在Drools IDE中，是基于tree的方式展示的)，或者存储在数据库中进一步处理。

更重要的是，审核功能不仅提供你的流程执行的信息，还可以是你的应用流程规则。终端用户不必尝试和手动将两个不同的日志文件（一个从流程引擎，一个是从规则引擎）关联，但是可以看到一体的综合性审核日志，显示在执行过程中发生的时间。

BusinessActivity Monitoring(业务活动监控)

         你需要积极地监控你的流程，以确保你可以检测到任何的异常情况呵突发事件，并尽快作出反应。业务活动监控（BAM）是基于这些事件的分析，将适时监控你的流程和尽可能地干预结合起来。Drools Flow可以让用户根据流程引擎生成的事件来自定义报表，并尽可能低在特定情况下使用事件处理规则（Drools Fusion），直接干预。

         在基于EclipseBIRT（商业智能报表管理工具）插件，用户可以创建报告，显示其他业务的关键绩效指标。很容易自定义自己的报告，使用预订的数据集包含所有流程历史信息的基础上的历史记录，记录在数据库中的所有运行时时间，和任何其他数据源，你可能将自己添加上。 Eclipse BIRT框架允许你自定义数据集，创建报表，包含图表，阅览报表，导出数据等，如下图所示：

BPMN

Bpmn(业务流程建模标注)是一种流行的商业用户使用的业务流程建模的工作流标记语言。BPMN是定义的术语，不同类型的节点，都是可视化的等。熟悉BPMN的人可能会发现它更容易滴实现可执行程序(可能是基于一个BPMN流程图)，采用了类似的可视化。因此，我们创建一个BPMN的皮肤，将Drools Flow映射到响应的BPMN可视化中来。

DroolsFlow and JBPM（Drools Flow 和jBPM）

         DroolsFlow是一个社区项目，jBPM是JBoss官方唯一的工作流产品。Drools Flow和jBPM是两个单独的项目。这个结果是流程集成的需要，一Drools 知识为向导的平台(在先进的集成流程和规则之间)，但是不能体现在jbpm项目中。Jbpm4和Drools Flow都是基于流程的框架，类似但是无关，都可以插拔的执行行为，jbpm是指PVM（流程虚拟机）。然而，到现在为止，无论是jbpm还是Drools Flow团队，已经同意在同一个方向发展。不过，我们相信Drools Flow提供了一组功能，不少于jBPMN项目。

Drools 5是一个完整的重新思考(儿不是重新实现)最多的是bottumup,一个新的公共API和所有的设计规则，流程和事件的同等性，没有确保没有功能被添加，是无缝的，统一的和正教的。因为流程，规则和事件被集成到相同的引擎中，可以很容易滴利用所有这儿三个规范。原因是根本不存在的多种API和部署方法，充其量只是负担，为用户提供更多的复杂性，在最坏的情况中两个不同的项目一期使用。

         传统的两种方式强制用户使用,一个是以流程为导向,一个是以规则为导向的方式.

获取的方式.在使用他们的工具是模型位经常出现混乱. Drools是一个远离以规则为中心，和以流程为中心，而是将中心转移到一行为建模为标准。通过更多的flexibability让用户去模拟他们想出现的问题。创建一个更加全面的软件开发方式（长期的全面的用于强制组成重要的整体和相互依存的重要性）.

         我们不相信仅仅以流程为中心，规则集成或者事件处理集成被认为或者将被添加后四项而不是一个基本的原则。这儿通常意味着该规则整合是一个无状态的规则，被调用到流程的节点中（所有的映射，编组和解组是一致性问题的结果）。面向过程的，也迫使用户学习重复的，不同的,API 和部署方式，将不提供一个工具链的声明周期的商业知识（例如，像一个统一的知识信息库与Drools Guvnor工具，或者提供重要的功能，例如相关的审核记录和报告）。

         基于这些和其他的特性，和足够的社会收容和需要，然而，我们希望Drools Flow采用jBoss产品。

译文：http://www.jboss.org/drools/drools-flow