Quartz Job Scheduling Framework［翻译］第十四章. 工作流中使用 Quartz (第二部分)

三. OSWorkflow 快速入门

像 Quartz 一样，OSWorkflow 是一个完全由 Java 构建的开源项目，而且也是 OpenSymphony 家族项目的成员。还有许多的工作流项目，商业的或是开源的。OSworkflow 在设计上与 Quartz 有很多相似性，所以把这两个框架进行集成不用太费我们的心思。

OSWorkflow 工作在有限状态机的原则之上。一个工作流由一系列状态组成，包括一个开始状态和一个或多个结束状态。从某一状态迁移到另一状态，需要发生一次转换。实际上从某一特定状态可能会有多种转换，你也可以在同一时间从某一状态发生多种转换。选择什么转换依赖于环境，对状态的输入，和一些我们将在后面讨论的条件信息。

·Workflow 描述文件

OSWorkflow 的一个关键组件是工作流描述器，有时候也叫做工作流定义；我们在这儿会交替的用这两个述语。工作流描述器定义了某一特定工作流的所有方面。这个描述器实现为一个 XML 文件，框架包含了一个 DTD 用于验证。你用用 OSWorkflow 工作的多数时间将会涉及到理解描述器文件的布局与规则。你可以在 http://www.opensymphony.com/osworkflow/workflow_2_7.dtd 查看 2.7 版的 DTD 文件。

·OSWorkflow 的概念

为有助于讲解，我们创建一个假想的工作流并在本章的后续部分中使用。创建好后，这个工作流将扫描某个目录来查找文件。在医学领域中，这些可能是来自于客户或病人信息的电子单据。

假如检查时存在任何文件，这个工作流程就读取他们并存储信息到数据库中。工作流的最后一步是产生一个电子邮件，记载了插入到数据库中的记录的数量。你可以想像一下，假如我们正运行着一个全球范围的业务，我们会期望文件会在白天或黑夜的任何时间丢过来。那就是为什么在调度器方面 Quartz 是如此的完美。

我们想用 Quartz 和 OSWorkflow 构建一个系统，用它来定期的检查这些文件，当接收到一个或多个文件时，通过一个指定的工作流来处理收到的文件。图 14.1 显示了我们想用的工作流。

你能从图 14.1 中的工作流中看出，由几个步骤组成了工作流本身。开发一套可在许多不同工作流中重用的步骤是个很好的想法。让我们看看这个示例工作流的一些定义和说明。

首先，一个工作流描述符(定义) 文件具体以下格式：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE workflow PUBLIC
  "-//OpenSymphony Group//DTD OSWorkflow 2.7//EN"
  "http://www.opensymphony.com/osworkflow/workflow_2_7.dtd">

<workflow>
  <initial-actions>
    ...
  </initial-actions>

  <steps>
    ...
  </steps>
</workflow>

我们现来浏览工作流重要的部分。

·工作流步骤

一个工作流由一些状态和步骤构成。每个步骤由你给它指定一个名字。在 OSWorkflow 中，由某一步骤和另一步骤的转换是一个动作的结果。下面的 XML 片断描绘了一个步骤：

<step id="1" name="Read Files">
 <actions>
  <action id="1" name="Read the records from the files" auto="true">

  <results>
   ...
  </results>
  </action>

 </actions>
</step>

·工作流动作

简而言之，任何工作流引擎的目标都是使工作流从开始进行到结束。那意味着我们需要一种方式来转换工作流从某一步骤到另一步骤。在 OSWorkflow 中，动作就是用来决定选用哪一个转换路径，因此，也决定了要转换到的步骤。在工作流中一个单一的步骤可以有多条路径(或者叫转换) 可基于动作的结果来执行。有几方面因素有助于决定工作流应采取哪个路径，包括外部事件和来自用户的输入。工作流动作使用条件和函数去确定动作的结果，进而要采取的转换。每个动作必须有至少一个无条件的结果和零个或多少有条件的结果。这有助于确保一个工作流总是能从一个步骤进行转换，甚至是不存在有条件的结果时也能导致一个转换。通常，一个动作会从一个步骤产生单个转换。我们在后面要讨论到，这不完全对，因为在从在步骤上发生多个转换时可以导致一个分支。最后，这些多重转换必须归并回一条路径上。下面的 XML 片断提供了一个工作流动作元素的例子：

<action id="1" name="Start Workflow">
 <results>
  <unconditional-result old-status="Finished" status="Queued" step="1"/>
 </results>
</action>

叫做初始化动作(initial actions) 特殊类型的动作通过指示第一个步骤执行来启动一个工作流。这儿是一个 initial-actions 元素的例子：

<initial-actions>
 <action id="1" name="Start Workflow">
  <results>
    <unconditional-result old-status="Finished"
      status="Queued" step="1" />

  </results>
 </action>
</initial-actions>

·动作结果

动作结果告诉工作流下一步要做什么任务。OSWorkflow 提供了有条件的无条件的两种结果。一个结果可以用多个条件元素，由它们计算出 true 或 false。计算为 true 的结果元素中的第一个条件会得到执行并决定了下个步骤。假如只有一个无条件的结果或者不存在为 true 的有条件结果，那么这个无条件的结果会得到执行。

存在三种工作流结果元素类型，不论它们是有条件的还是无条件的：

    ·转换到单一步骤

    ·分支到两个或多个步骤

    ·合并多个步骤到单一步骤上

你要组合使用它们来构建你的工作流。

·工作流函数

在 OSWorkflow 中，多数它的强大和灵活之处体现在函数和条件的使用上。函数是在从某一步骤到另一步骤转换期间能执行的逻辑；这是可以做大部分工作的地方，尤其是对于我们的 Quartz + OSWorkflow 集成应用上来说。OSWorkflow 包括调用 EJB 方法的函数，使用 Java 消息服务(Java Message Service，JMS) 的函数，发送电子邮件的函数，还有更多。函数还支持了我们感兴趣的方面是它能调用一个普通的 Java 类。

OSWorkflow 包括了函数的接口 com.opensymphony.workflow.FunctionProvider. 所有我们必须做的是创建一个实现 FunctionProvider 接口的 Java 类，它只包含一个方法：

public void execute(java.util.Map transientVars,
                    java.util.Map args,
                    com.opensymphony.module.propertyset.PropertySet ps)
            throws WorkflowException;

创建好了 FunctionProvider 类之后，我们要像如下这样设置函数到工作流中：

<function type="class">
  <arg name="class.name">
    org.cavaness.quartzbook.chapter14.ReadFileFunction
  </arg>
</function>

当工作流来到了这个步骤和定义了函数的动作时，它就会呼叫我们的 Java 类，并调用函数的 execute() 方法。这真的是很强大的，因为你能易的集成新的或遗留的系统到你的工作流中。

·自动动作

假如你构建这样一个工作流，你希望它的步骤在没有用户输入时自动转换，你可以在某个动作上使用 auto 属性来强制发生动作。这意味着工作流一旦启动后，就会缘着它的步骤自动运行，而不用等待一个外部事件来引发它的转换。[译者 Unmi 注：原文似乎未把某些个别的自动化动作与完全自动化的工作流分清。]

·工作GUI 设计器

我们这里没有使用 GUI 设计器，但还值的一提的是 OSWorkflow 团队已创建了一个图形化的工作来建立和编辑工作流定义。这个工具是一个客客户端的，可使用 Sun 的 Java Web Start 技术来运行。图 14.2 显示了这个 GUI 工具加载了示例工作流的截图。

[看全尺寸图]