WfXML-R：基于REST的流程整合

作者 Gavin Terrill 译者 徐涵 发布于 2008年6月5日

领域

架构 & 设计,

企业架构

主题

架构 ,

SOA ,

业务流程管理 ,

REST

标签

GData ,

Atom

Patrice Cappelaere最近宣布，WfXML-R——一种为WF-XML 2.0提供REST式绑定的提议——已经得到了工作流管理联盟（Workflow Management Coalition，WfMC）的接纳。

WfXML-R旨在围绕WfMC的参考模型里的5个接口建立规范：

• 接口1：在流程定义（process definition）与建模工具和工作流引擎之间定义一个标准接口。

• 接口2：为客户端应用向工作流引擎请求服务（为了控制流程行进、活动及工作项目等）定义APIs。

• 接口3：为APIs定义一个标准接口，以便工作流引擎可以通过公共代理软件来调用各种各样的应用。

• 接口4：定义工作流互操作模型以及相应的支撑标准。

• 接口5：定义监测和控制功能。

目前在0.4版中，WfXML-R考虑了对以下用例（use cases）的支持：

• 远程应用需要发现并从服务器获取一个可用工作流、定义及其他可用资源的列表。
• 远程应用需要能够启动（和停止）一个流程实例（process instance）。
• 远程应用需要：
  • 确定流程实例的当前状态
  • 确定当前所等待流程里的活动
• 远程应用需要能够创建、更新并删除工作流及定义。
• 远程应用需要能够启动和停止流程引擎，或者创建/删除一个新引擎。
• 远程应用需要能够查看历史与日志。
• 远程应用搜索特定资源。

目前，已确定的REST资源包括：

WfXML-R REST资源

/workflows	该资源是工作流分析师最初创建的主要容器。该资源包含名称信息、作者以及其他跟工作流相关的元数据。它指向定义（definitions）及实例（instances）等其他资源。
/definitions	对于一个特定的工作流，可以有一个或多个流程定义（process definitions）被指定、载入引擎和版本化。要为工作流规定要执行的各项活动，就必须要有流程定义。流程定义本质上就是流程实例的工厂（factory）。
/processes	流程实例（process instances）执行实际的工作。它包含区分不同流程的上下文信息。一个流程实例资源只能被使用一次：它被创建，然后被启动，它可以被暂定、继续、终止。如果一切正常的话，它最终将结束。
/activities	流程实例（process instance）可以在任意时刻进入“等待某个外部活动完成”的状态。该活动（activity）代表该流程里的等待点（wait-point）。流程（process）可以等待某个人与之交互，也可以等待流程里某个自动化步骤的结果。该活动提供流程所等待事物（比方说任务承担者）的信息，以及关于“已经等待了多久”、“愿意等待多久” 的详细信息。这样的话，该活动担当的是那个远程流程的一个观察者。该活动可以提供它所等待的远程流程实例的URL。
/traces	在执行一个特定流程的过程中，系统可以收集历史信息或有关序列路径、各个活动后的输入/输出、时间戳等追踪信息。
/participants	参与者执行具体的活动（activities）。他们可以是人，也可以是其他Web服务。
/workitems	人可以成为一个工作流里的参与者，也可以被分配任务（或活动）去执行。这些请求可以在“仓库”里排队，以便用户获取和执行。这些请求就是工作项目（workitems）。
/engine	引擎本身也许是最有访问价值的资源了。远程应用可能想查看并修改某些引擎属性。管理员可能会创建或删除一个新的引擎资源，或者获取一个运行着的引擎的列表。
/errors	引擎维护着一个运行时错误的列表，用户可以获取该列表。

WfXML-R利用了Atom发布协议（Atom Publishing Protocol）、Atom 1.0聚合格式（Atom 1.0 Syndication Format）、GData、OpenSearch及OCG发布-订阅（OCG Publish-Subscribe）等现有的标准与协议。

查看英文原文：WfXML-R: REST based process integration

• 更早的 >