工作流管理联盟（WFMC）提出了一个工作流参考模型，约定了工作流系统的体系结构、应用接口及特性，主要目的是为了实现工作流技术的标准化和开放性。下面简要介绍系统中的各个部分，并对参考模型中的五类接口进行描述。 1． 工作流管理系统中的各种数据 [color=rgb(49, 148, 20 ]工作流控制数据（Workflow Control Data）工作流执行服务/工作流机通过内部的工作流控制数据来辨别单个过程或活动实例的状态。这些数据由工作流执行服务/工作流机控制。用户、应用程序或其它的工作流机/工作流执行服务不能对其进行直接读写操作，它们可以通过向工作流执行服务/工作流机发送消息来获得工作流控制数据的内容。 [color=rgb(49, 148, 20]工作流相关数据（Workflow Relevant Data）工作流管理系统通过工作流相关数据来确定过程实例状态转换的条件，并选择下一个执行的活动。这些数据可以被工作流应用程序访问并修改。因此，工作流管理软件应该在活动实例之间传递工作流相关数据。 [color=rgb(49, 148, 20]工作流应用数据（Workflow Application Data）这种数据指那些由应用程序操作的数据。它们是针对应用程序的，工作流管理系统无法对它们进行访问。 2． 工作流模型和工作流建模工具 [color=rgb(49, 148, 20]工作流模型过程模型包含了工作流执行服务运行该过程的所有必需的信息，包括它启动和结束的条件、组成的活动、活动间导航的准则、参与其中的用户、需要激活的应用程序的指针、需要用到的工作流相关数据的定义等等。 在工作流的建模期间需要参考组织/角色模型来获得有关组织结构和组织内角色的信息。过程定义指定完成某项活动的组织实体或角色，而不是定义具体人员。工作流执行服务负责在[color=rgb(49, 148, 20]工作流运行环境内将组织实体或角色映射为特定的人员。 [color=rgb(49, 148, 20]工作流建模工具它主要用于分析、建模、描述并记录经营过程。它应输出一个能被工作流机动态解释的过程定义。不同的工作流产品其建模工具输出的格式是不同的，参考模型中的接口1不仅使工作流的定义阶段和运行阶段分离，使用户可以分别选择建模工具和执行产品，还可以使不同的工作流产品合作为一个过程定义的执行提供运行服务环境。 工作流管理联盟针对工作流建模做了两方面的工作： （1） 建立了一个元模型（process meta model）：它用于描述一个过程模型内各个对象、它们之间的关系及它们的属性，有利于多个工作流产品之间交换模型信息。 （2） 定义了一套可以在工作流管理系统之间及在管理系统与建模工具之间交互过程模型定义的API接口。 图1为工作流管理联盟定义的过程元模型。 3． 工作流执行服务 工作流执行服务由一个或多个工作流机组成（在分布环境下，由多个工作流机组成），提供了过程实例执行的运行环境，主要完成以下功能： （1） 解释流程定义，生成过程实例，并管理其实施过程。 （2） 依据过程定义和工作流相关数据为过程实例的导航提供进入和退出的条件、并行或串行执行活动的信息、用户信息或所需激活的应用程序的信息等等。 （3） 与外部资源交互完成各项活动。 （4） 维护工作流控制数据和工作流相关数据（这些数据包括不同过程和活动实例的内部状态信息、工作流机用于协调和恢复的各种检查数据和恢复/重起信息等），并向用户传递必要的相关数据。
在分布式的工作流执行服务中，多个工作流机协调工作，推进[color=rgb(49, 148, 20]工作流机实例的执行。每一个工作流机控制过程执行的一部分，并使用相关的资源和应用工具。这种执行服务需要共同的命名和管理范围，便于过程定义和用户/应用名称一致。分布式的工作流系统采用特定的协议来同步各工作流机，并传递相应的控制信息。在一个同构的工作流执行服务中这些协议是因厂家而异的。当选用不同的工作流系统产品时，各工作流机之间需要一个标准来进行转换。它应包括以下几个方面的内容： （1） 一个共同的命名机制； （2） 支持共同的过程定义对象和属性； （3） 能够传递相应的工作流相关数据，并控制过程实例的生成； （4） 能够在异构的工作流机间传递过程、子过程及活动； （5） 支持共同的管理职能。 4． 工作流机 [color=rgb(49, 148, 20]工作流机是一个为工作流实例的执行提供运行环境的软件服务或“引擎”。它主要提供以下功能： （1） 对过程定义进行解释； （2） 控制过程实例的生成、激活、挂起、终止等； （3） 控制活动实例间的转换，包括串行或并行操作、工作流相关数据的解释等； （4） 支持用户操作的界面； （5） 维护工作流控制数据和工作流相关数据，在应用或用户间传递工作流相关数据； （6） 提供一用于激活外部应用程序和访问工作流相关数据的界面； （7） 提供控制、管理和监督的功能。 [color=rgb(49, 148, 20]工作流机的一个重要功能就是控制实例和活动实例的状态转换。工作流管理联盟的参考模型中为过程实例的运行状态和活动实例的状态进行了定义，并给出了状态转换的条件。图2和图3分别描述了过程实例和活动实例各个状态之间的转换。 过程实例包括以下几种运行状态： 初始（inactived）：一个过程实例已经生成，但该过程实例并没有满足开始执行的条件； 准备运行（running）：该过程实例已经开始执行，但是还不满足开始执行第一个活动并生成一个任务项的条件；
运行中（active）：一个或多个活动已经开始执行（也就是已经生成一个工作项并分配给了合适的活动实例） 挂起(suspended)：该过程实例正在运行，但处于静止状态，除非有一个“重启”的命令使该过程实例回到准备运行状态，否则所有的活动都不会执行； 结束(completed)：该过程实例满足结束的条件，工作流管理系统将执行过程实例结束后的操作（如统计），并删除该过程实例； 终止（terminated）：该过程实例在正常结束前被迫终止，工作流管理系统将执行补救措施，并删除该过程实例。
活动的运行状态包括： 未开始（inactive）：该活动实例已经生成但还没有被激活（例如活动开始条件没有满足）； 运行中（active）：该活动实例已经被激活了； 挂起（suspended）：该活动实例处于静止状态； 结束（completed）：该活动已经执行完毕，工作流管理系统将进行活动结束后的导航工作，激活下一个符合启动条件的活动实例。 5． 客户端应用 这种方式适合于需要人员参与的活动。这种情况下，工作流机通过任务项列表管理器来进行控制。工作流管理联盟提供了四种可能的通过任务项列表来实现工作流客户工作流机之间的通讯方式，如图4所示。其中一种支持集中式的结构，另外三种适合分布情况下的工作流系统。 （1） 基于主机方式的模型（Hust Based Model）：这种方式适合于集中的情况。此时，客户端应用程序、任务项列表管理器、任务项列表和工作流机都列在中央的主服务器上，用户通过模拟一个终端用户来获得任务项列表； （2） 共享的文件库模型（Shared Filestore Model）：在这种情形下，客户应用程序和任务列表管理器位于用户的工作站上，而工作流位于中央服务器上。任务项列表位于一个客户应用和工作流机都能够达到的共享的文件系统中。 （3） 电子邮件模型（Electronic Mail Model）：这里，客户应用和任务项列表管理器位于用户的工作站上，工作流机位于中央主机上。所有的通讯都使用电子邮件。此时，任务项列表一般位于客户端； （4） 过程调用或信息传递模型（Procedure Callor Message Passing Model）：这时，客户应用程序和任务项列表管理器位于用户的工作站上，任务项列表和工作流机位于服务器端。用户通过RPC或者其它的消息传递机制来获得任务项列表。
6． 由工作流机直接调用的应用程序 这种情况适合于不需要人员参与的活动。在简单的情况下，工作流机通过过程模型中定义的活动的信息、应用程序的类型和需要的数据来激活应用程序。被激活的应用程序可以和工作流机位于一台计算机上，可以位于相同的运行平台上，也可以位于网络可以到达的不同平台上。模型定义提供了有关应用程序的类型、地址等充分信息，便于工作流机激活该程序并执行相应的动作。 7． 工作流执行服务之间的互操作性 工作流联盟的目标之一就是规定一个标准使得不同厂商提供的工作流产品能够协调工作，整个系统能够无缝地在各个产品之间传递任务项。工作流管理联盟在互操作性上的工作主要集中在提供了一系列互操作的情景，从简单的任务传递到传输整个工作流过程模型和工作流参考数据。尽管有可能考虑那些很复杂的情形（如不同厂商提供的工作流机共同协作实现工作流执行服务，这在目前还不可能实现，因为它要求所有的工作流机都能够解释过程模型，共享一套工作流控制数据，并在异构的工作流机环境下共享过程实例状态。）但就目前来说，比较切合实际的目标是在不同的工作流执行服务间传递过程的部分内容，支持其实例的运行。 8． 系统管理和监控工具 该工具能够对工作流在整个组织内的流动状况进行监控，并提供一系列的管理功能，如有关安全性、对过程的控制和授权操作等方面的管理。主要功能包括以下几个方面： （1） 建立、设置和优化组成[color=rgb(49, 148, 20]工作流管理系统的各个软件； （2） 对过程模型进行实例化； （3） 将过程模型中的角色实例化； （4） 将运行中的过程实例、活动实例和数据分发到各个工作流机中； （5） 启动、挂起、恢复和终止过程实例； （6） 管理正在执行的过程实例并对正常或异常退出的过程的历史数据进行统计和分析。 9． 工作流参考模型中的五类接口 工作流联盟给出了五类接口： （1） 接口1：工作流服务和工作流建模工具； （2） 接口2：工作流服务和客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用和工作流服务之间的功能访问方式； （3） 接口3：工作流机和直接调用的应用程序之间的接口； （4） 接口4：工作流管理系统之间的互操作接口； （5） 接口5：工作流服务和工作流管理工具之间的接口。 其中，接口1为在不同物理或电子介质之间传递过程定义的信息提供了交互的形式和API调用；接口2定义了通信建立、工作流定义操作等功能；接口3激活应用程序的API函数应覆盖的几个方面的功能；接口4完成工作流执行服务之间需要提供大量的WAPI来实现互操作，无论是在两个工作流执行服务之间的直接调用还是通过网关函数；接口5主要实现对工作流的管理和监视。
| 
免费注册
发表于 2018-11-12 20:27