WfMC是啥
WfMC=Workflow Management Coalition.好象有人翻译成工作流管理委员会.有的称之为国际工作流管理委员会.俺不大了解,但好象加入该Coalition好象是要年费的.所以与其说是"委员会",不如称之为"联合会"。
是否符合WfMC标准需要WfMC确认,并不是谁都能声称自己符合WfMC的标准的.

什么是工作流:
工作流管理委员会(WfMC)把工作流定义为：工作流是一类能够完全或部分自动执行的业务过程。根据一系列规则，文档、信息、任务能够在不同的执行者之间传递、执行。完成正个过程所需要的参数有：
过程中每一单独步骤的定义，每一步骤由谁负责，每个活动需要的应用程序。定义一个工作流就是说明了处理过程是什么：由哪些活动、任务组成即流的结构。如何做：活动间的执行条件、规则，所交互的信息即控制流与信息流的定义，谁来做：人还是应用程序即角色定义，做得怎么样：对工作流的执行状态实施监控。(工作流管理与事务服务设计方案)

WfMC提出了一种工作流的参考模型(Workflow Reference Model)：目的就是把工作流分成5个模块,并定义这5个模块之间的接口的规范.这么做的意义是啥呢?应该不归我菜鸟来解释了.

模型包含5个模块：
1.过程定义(Process Definition)
2.特定的工作流系统(Workflow Enactment Service),其中包含一个或多个工作流引擎(Workflow Engine(s)),提供工作流API和交换(Workflow API and Interchange)
3.工作流客户端程序(Workflow Client Application)
4.激发的程序(Invoked Applications)
5.其它工作流系统(Other Workflow Enactment Service)
6.管理和监控工具(Aministration & Monitoring Tools)
其中包含5个接口(Interface)
1.工程定义工具接口(Process Definition Tools Interface)
工作流系统(Workflow Enactment Service)<=>过程定义(Process Definition)
2.客户端程序接口(Workflow Client Application Interface)
工作流系统(Workflow Enactment Service)<=>工作流客户端程序(Workflow Client Application)
3.激发程序接口(Invoked Application Interface)
工作流系统(Workflow Enactment Service)<=>激发的程序(Invoked Applications)
4.工作流系统间协同接口(Workflow Interoperability Interface)
工作流系统(Workflow Enactment Service)<=>其它工作流系统(Other Workflow Enactment Service)
5.管理和监控接口(Administration & Monitoring Tools Interface)
工作流系统(Workflow Enactment Service)<=>管理和监控工具(Aministration & Monitoring Tools)

XPDL：
5.流程定义交换概述(Overview of Process Definition Interchange)
流程定义的作用：
1。产生和控制流程实例的模版
2。仿真和预测
3。监控和分析
4。文档，可视化和知识库管理(?)
可能会包含子流程的定义
一个初始的流程定义最少要包含初始化和执行所需要的对象(objects)和属性(attributes)。流程实例将继承(inherit)这些对象和属性。
WfMC术语表中包含活动(activities), 流向(transitions), 工作流相关数据(workflow relevant data)和参与者(participants)等。
 
5.1流程定义交换的方法(Approaches to Process Definition Interchange)
这里使用XML作为交换的机制。XPDL提供一种交换标准，使用导入导出(import/export)的方法使得任意在内部用不同方式表示流程的系统得以互相交换流程(?)。
有很多不同的方法可以用来在不同系统间交换流程。在这些方法中都必须把流程表示成一致的格式。

6.元模型(Meta-Model)
元模型用以描述一个流程定义的最上层实体(the top-level entities)，实体的关系和属性(这些属性有的只是用以仿真或监控的目的，而不是为了运行(enactment))；它包含了把多个流程组织成流程模型(process models)和多个流程和流程模型间的公共定义数据(common definition data)。
 
6.1实体(Entities)

6.1.1工作流定义(Workflow Process Definition)
提供上下文环境(contextual information)，提供管理信息（如创建日期，作者等）或者用于执行(process execution)的信息（如初始值，执行优先级，期限，需要通知的人，仿真信息(simulation information)等）

6.1.2环节（Workflow Process Activity）
一个流程定义中包含多个环节，环节是流程中逻辑上独立的单元。环节代表使用多种资源处理的工作（参与者的任务）或/和应用程序（应用软件的职能）。其它信息包含是否自动开始/结束，当和其它环节发生资源冲突的时候的优先级。对流程相关数据(workflow relevant data items)的使用也必须指明。一个环节的范围是某个特定的流程。
一个环节可能是一个子流程(subflow)。这种情况下它包含了一个特定流程的执行，这个流程可能在同一个工作流服务器（workflow service）中运行，也可能在其它工作流服务器上运行（通过流程协同接口(process interoperability interface)）。子流程包含它自己的环节，内部流向，资源和应用程序分配(application assignments)，尽管这些可能是从同一个公共资源而来。输入参数和输出参数使得流程相关信息得以被在调用和被调用流程间交换（如果必要可以是返回参数）。
一个环节可能是一个块环节(block activity)。块环节包含一个环节组(activity set,)，或一堆环节和流向，一个环节组中的环节和流向共用内流程(containing process)的名字空间。
最后，一个空环节（dummy activity）不执行任何操作（因此没有相关资源和相关applications），仅用来在入流向(incoming transitions)和/或出流向(outgoing transitions)间进行流转(routing).

6.1.3流向信息.(Transition Information)
环节之间由流程控制条件相关联(流转条件(transition information).)).每个流向包含三个基本属性,源环节,目的环节和流向条件.从一个环节到另一个环节的流向可能是有条件的,也可能是不需要条件的.一个流程里面的多个流向可能产生串行的(sequential)或并行的(parallel)环节.分叉(split)或者合并(join)的相关信息在对应的环节之中,split as a form of “post activity” processing in the from-activity, join as a form of “pre-activity” processing in the to- activity.This approach allows the workflow control processing associated with process instance thread splitting and synchronization to be managed as part of the associated activity, and retains transitions as simple route assignment functions.{开始昏了}一个流向属于包含它和它的相关环节的流程.
其它更复杂的流向,不能用简单的函数来表达的,使用空环节来实现.结合使用基本的流向和空环节,任何复杂的流转结构都可以被实现.因为业内已经有好几种流向控制的途径,在XPDL中也有相应的几类,在本文稍后描述.

6.1.4流程参与者声明(Workflow Participant Declaration)
流程参与者声明描述在流程定义中各个环节的参与者(performer).The particular resources, which can be assigned to perform a specific activity, are specified as an attribute of the
activity, participant assignment, which links the activity to the set of resources (within the workflow participant
declaration) which may be allocated to it.{环节参与者是环节的一个属性...昏了}.流程参与者不一定是单独的个人,也可以是一组有相应资格或责任的人,或者机器的自动操作.元模型包含了一些简单的资源类型,这些类型可能在流程参与者声明中被定义.

6.1.5资源库(Resource Repository)(?)
资源库说明参与者可能是人员,程序,或者机器.在更复杂的情况下,参与者声明可能是一个资源库,它可能是参与人员的一个组织机构模型(Organizational Model).这份文档并没有定义或要求一个资源库.

6.1.6工作流应用程序声明(Workflow Application Declaration)
工作流应用程序声明描述了被工作流服务器调用的,用以支持各个环节的处理的IT应用程序或接口,这些程序和接口被定义为环节的一个属性.这些应用程序可能是行业工具,特定部门或企业的服务,或在工作流管理系统框架下的本地应用程序.工作流应用程序声明反映了工作流引擎和{应用程序或接口}的接口,包含需要传递的参数.

6.1.7工作流相关数据(Workflow Relevant Data)
工作流相关数据定义了在流程执行过程中创建和使用的数据.这些数据在工作流中被环节或者应用程序使用,并可能被用于传递持久的信息或者环节间的中间结果或/和用于判断流向流转或者分配参与者的的中间数据.工作流相关数据是特殊的类型(Workflow relevant data is of particular type.),XPDL定义了各种基本的和复杂的数据类型,(包含日期Date,字符串string,等).环节,被调用的应用程序(invoked applications)和/或流向条件会用到工作流相关数据.

6.1.8系统和环境数据(System and Environmental Data)
系统和环境数据由流程管理系统和本地系统环境管理,但会被工作流环节或工作流管理系统用于计算条件表达式,如同工作流相关数据一样.

6.1.9数据类型和表达式(Data Types and Expressions)
元模型(和相关的XPDL)假设有一些标准数据类型(string,reference,integer,float,date/time等),这些数据类型被用于工作流相关数据,系统和环境数据或参与者数据(participant data).用于条件判断的表达式将由这些数据类型组成.数据类型可以用XML schema或者引用外部资源中定义的类型来扩展.
 
 6.2流程和流程包(Processes and Packages)
从以上内容可知,流程模型包含的很多实体(entities)的范围超出了单个流程定义的范围.可能多个流程定义会引用到相同的流程参与者,工作流应用程序和工作流相关数据.元模型采取了使用公共流程定义库(common process definition repository)来包含这些实体和工作流定义.在这个库本身的范围内,为了提高传送流程定义数据的效率,引入了流程包的概念,流程包包含了一组工作数据实体(common data entities)和许多不同的流程定义,避免了在不同的流程定义中重复定义这些工作数据实体.
流程包包含了流程定义实体的许多公共属性如(作者,版本,状态等),包内的每个流程定义自动继承了所有这些公共属性,除非它们在流程定义中分别被重新指定.
 
在包中的一些实体的定义是全局的,能够被包中的所有流程定义(以及相关的环节和流向)引用,这些实体是:
-流程参与者声明
-工作流应用程序声明
-工作流相关数据
可以在流程包或者流程包包含的对象中使用被引用的外部流程包的最上层实体(The package reference allows the use within the package or its contained objects of references to top-level entities in the referenced external package:).{哈,没昏},这些最上层实体包括:
-子流程的流程ID
-流程参与者声明
-工作流应用程序声明
 
同一个库地址空间(repository address space)中的不同流程包的名称和标识的管理规定由提供商自己定义.{相同库,但不同包的名字空间的划分方法由工作流的开发者自己设计,好像是这意思}.推荐的查找方法是:
-流程id:先在同一个model中寻找(包含任何在不同服务器上运行的流程定义的引用),然后在任何被引用的外部model中查找
-流程参与者声明/工作流应用程序声明 :先在同一个model中查找,再在任何被引用的外部model中查找.
{这里model指的范围可能是流程包,有点像java import一个名字空间进来,怎么找一个类型一样}
 
工作流相关数据的命名在同一个流程包中必须是唯一的,在同一个包中,{在这份文档的当前版本},流程间参数的传递惯例是值传递(copy semantics).流程设计者(管理员)必须在流程定义/流程模型中确保名称和数据类型在调用子流程时的一致(和任何其它远程流程协调工作时的一致).

 6.3流程元模型(Process Meta-Model)
流程元模型定义了用于流程定义交换的一组基础的实体(entities)和属性(attributes)。对于每个流程定义，以下实体必须在流程范围内定义或从流程包中继承，或从其它包中引用：
-环节(Workflow Process Activity)
-流向(Transition Information)
-流程参与者(Workflow Participant Specification)
-工作流应用程序声明(Workflow Application Declaration)
-流程相关数据(Workflow Relevant Data)
这些实体的属性描述了流程的机制，它们将在本文后面被描述。

6.4流程包元模型(Package Meta-Model)
在一个模型定义(model definition.)中，多个流程定义是互相关联的。流程包包含了流程定义和相关的实体，而这些实体能被所有包内的流程使用(所有这些实体只要被定义一次)。流程包元模型包含了以下的实体：
-流程定义(Workflow Process Definition)
-流程参与者(Workflow Participant Specification)
-工作流应用程序声明(Workflow Application Declaration)
-流程相关数据(Workflow Relevant Data)
>

流程包的原模型指出了用于流程模型的交换和保存的实体和属性。它定义了各种不同的继承规则，来关联单独的流程定义和{流程参与者，工作流应用程序声明和工作流相关数据的定义}，这些定义(流程参与者...的定义)可能在单个流程定义中，也可能在流程包中。
流程包定义允许指定一些公共的流程定义属性，这些属性自动被应用于流程包中的每个流程定义。这些属性也可被但个流程所忽略.(如果这些属性在流程定义层被重新定义，那本地的属性值将覆盖全局的)
 
6.4.1流程库(Process Repository)
流程定义导入/导出接口被用于操作工作流管理系统的流程库。实现的方法是从这些流程库中导入导出包含XPDL的文件。这个接口在单独的流程和流程包两个等级上导入导出流程定义数据。
流程库和流程控制功能之间的接口由各个供应商(工作流实现者)自行决定，与本标准无关。但推荐把静态的流程库(for persistent, ongoing storage of process definition data)和动态的流程库(for managing changes to the process execution of extant process instances)区分开来(比如用版本控制)。
WfMC标准不包含流程定义库的具体内部实现结构。流程包的使用只是为了在导入导出过程中重用数据。在简单的流程库结构下(Where a simple process repository structure is used)。对流程定义层上的操作，被导入的流程库的共享信息会被复制到各个单独的流程定义中(并在导出过程中被类似地重新打包)。
 
6.4.1.1重新定义和范围(Redefinition and Scope)
因为有重新定义属性和元模型实体和对外部流程包的引用的可能，所以范围和层次的规则(principles of scope and hierarchy)被引入到了XPDL(和流程库)结构中。
(i)流程相关数据
流程相关数据的范围被直接相关的元模型实体定义并且不能被嵌套。它的标识符的可见性同样由该实体定义。{不知道有没搞错..费解}
(ii)属性
属性和外部属性的范围被直接相关的元模型实体定义并且可以被嵌套，例如可以在下一层被重新定义。例子：名字属性在各个实体定义中被重新定义。外部属性的标识符在特定实体和子实体可见，除非在子实体中重新定义了该标识符。
(iii)流程参与者和应用程序
流程参与者和应用程序的范围和可见性与外部属性相同。所有被(流程参与者和应用程序)使用的流程相关数据和外部属性的范围必须和使用者的范围一样，至少在同一个流程包内。
For a referenced external package entity that needs itself reference to entities and their identifiers defined in its external package clause the mechanism is started with the root in that package. That guarantees that no conflict takes place if the invoking process has an entity with the same id, which the definer of the referenced package cannot be aware of.
外部流程包的使用给流程设计者和管理者以很大的自由。一是可以在分开的模型中分别定义组织机构(参与者实体)和流程定义。另一个是可以添加一个新的流程定义共享原来的流程定义所用的模型而不需要重新提交整个环境信息。
 
6.5实体预览(Elements Overview)
下表展示了XPDL中定义的主要元素(elements)
-第一栏包含所有主要元素的属性。所有主要元素包含的属性有：id，name可能有Description和Extended Attributes。
-第二栏是特殊的属性
-The third group consists of elements that may contain references to other elements.
-Documentation and Icon elements ：被工作流引擎使用的描述信息
-第五栏包含了仿真和优化的信息
以后可能会添加别的元素和预定义属性

6.5.1供应商或用户扩展(Vendor or User specific Extensions)
尽管元模型和XPDL包含了大部分流程定义交换过程中需要的结构。但在特定环境下流程定义可能需要包含更多的信息(供应商或用户的特定信息)。供应商或用户应尽量使用标准的实体和属性。以下将描述扩展信息的标准方法，但这要求流程引擎提供相应的运行时支持。
 
6.5.1.1Extended Attributes
最主要的方法是使用Extended Attributes。Extended Attributes由供应商或用户在必要情况下自行定义，用以表达额外的信息。额外属性的运行时支持分别在两个系统中实现，而且双方要在对额外属性的导入导出上达成一致。
 
6.5.1.2. Extended parameter mapping
关于子流程的参数传递，由供应商自行决定，和WfMC无关

最后:faint...人家已经xpdl2.0了
 
好像n多概念不一样了。2005-10-3的版本，然道我就这么倒霉？
2.0的流程包(Package)里面添加了pools,message flows,associations & artifacts的概念。
 
泳道(Swimlanes)?
池(Pool){环节，流向(Sequence Flow (transitions))} Pool之间通过信息流(Message Flow)联系。白箱黑箱。background pool即默认的pool
 
通道(Lane)，进一步分割pool,属性被其中的环节继承
 
巨faint，人家已经有翻译好的。。1.0版本的，除了几个特殊名称的翻译不习惯外，读起来挺流畅的。
但不能理解的还是不能理解，好像翻译的人也没融会贯通。
就当学英语好了..郁闷。以后失业了可以试试粗浅的翻译。
 
工作流现在咋就这么流行呢？ http://www.cnitblog.com/Files/Raistlin/wfmc-zh.rar