本文首先从工作流建模语言的历史讲起，然后涉及众多时下流行的建模语言以及规范，对这些规范所要解决的问题、相互间的关系做了简单阐述，给出工作流技术堆栈图，以及WFMC参考图。作为工作流入门文章不错。

　　浅谈众多工作流规范
 
　　提纲

　　本问首先从工作流建模语言的历史讲起，然后涉及众多时下流行的建模语言以及规范，对这些规范所要解决的问题、相互间的关系做了简单阐述，给出工作流技术堆栈图，以及WFMC参考图。作为工作流入门文章不错。

　　什么是工作流？

　　简单说来，工作流就是要在正确的时间点将相应的工作分发给对应的人员去做，然后周而复使地进行。工作流是以人为中心的。

　　工作流开发的简短历史

　　工作流有悠久的历史。其实，只要人活着并一起工作来完成一个普通的任务就存在一个工作的流—或叫作工作流，它从一个人传递给另一个人。

　　但注意，工作流并不仅仅就是一个工作的流动而已。其还包括相应的规则集、角色以及职责，工作流将根据它们来进行流动和传递。换句话来说，可以说工作流就是流程。

　　“古老”的工作流由监管者进行管理，并分配任务且监测执行的性能；而一般职员则将工作从一个人流转到另一个人；而工作流的发布者（制定者）则跟踪问题并处理异常确保工作流程可以顺利地执行下去。

　　早期来说，人们通过一套规则和指令来进行工作流的通讯。刚开始是靠口头语，后来靠文字用语，最后靠更权威的书面出版。随着这些规则和指令的日益增长，以及组织任务的复杂化，人们面临的风险也在复杂度方面增长。

　　人们发现工作流的表述方式直接影响了工作流的发展。从口头语到文字用语的“进化”尤其重要，它有利于规则在更大范围内人群中散布，利于人们对复杂任务的理解。它有利于团队信息共享，并能基于此共享力来创建更特别和复杂的工作流程。

　　尽管如此，但工作流的使用还是遭受同样的基本限制，也就是说用于组织内部进行通讯、散发以及例证工作流规则、指令、信息的媒介，其具有静态性、被动性等特性。结果，工作流在处理以下情况时仍然很差劲：

　　1、非常规或异常环境
　　2、组织结构或配置发生变化
　　3、不稳定、易变或其他原因发生信息的改变
　　4、在狭义或广义工作环境中步骤的改变

　　一旦工作流发布后，这些限制影响人们在工作流流程上工作以及开发工作流流程的能力。

　　一旦发布后，工作流流程就会变得如绝对无错的至理名言一样从未修改或挑战。这样将导致期望值与现实值的差距。而这种差距只有等到识别出所出现的问题并想矫正它才并察觉：这就造成了行动的滞后。然而，这个问题通常大到组织无法在失败前带来任何有效的改变。小的方面讲，一般组织破产；大的方面讲，组织需要昂贵的重组以及服务外包。

　　动态工作流

　　随着动态适配的媒介技术的出现（比如数字计算），被动的记录这个基本限制解除。加以正确的使用，此新技术可以让持续地修订工作流流程成为可能，允许它们在废除前修改。

　　所以，这是第一次，自从它们被记录下来的时候，改变正在运行中的业务流程成为可能，创建动态工作流流程，以解决记录媒介的被动特性问题。同时，也是第一次，使得可以先于流程发布实施预先的“假设会怎么样”测试以及“负载均衡”成为可能。这些动态工作流流程使得持续调优流程从而跟踪用户需求整个过程成为可能。

　　这种实时地动态改变工作流流程描述了组织中步骤的改变。

　　还有一个额外的好处是关于价格。动态工作流流程的一个隐含信息就是其需要一个更系统化的方法论，从而相应地隐射出或开发出这些流程。现在不再是简单地任由流程未定义或隐式定义，它们必须显式地隐射并记录。

　　要隐射并记录动态流程需要一个可描述性的建模语言，且人和机器都能理解此语言。这里就自然引入了流程建模。
 
　　工作流技术团体

　　从技术上来谈，工作流并不是新东西。一些国际团体很久以前已经成立，并帮助共享创新技术以及理念。结果导致开放、安全的工作流技术的发展以及相应成型的系统。这些团体包括以下列举的：

　　以上给出了工作流相关技术的一个清晰描述，从简单的信息存储到完整的集成业务管理。以上所有的内容都有一个共同点：它们在工作流相关技术领域都非常重要，其中一些在信息管理标准和技术方面也很重要。
 
　　工作流建模语言

　　了隐射并记录工作流流程，需要一个相应的描述性流程建模语言，以便可以被人和机器理解。

　　一些语言存在是为了建模的目的，一些更通用，有些则特殊。一般建模的情况下，BPMN的标识用于业务用户，而UML主要用于软件开发者。

　　UML严格来说，是一套软件系统开发的建模语言，现在已经变成了工业标准。其灵活性以及简单性也可以将其用于描述工作流和业务流程。

　　UML加上XML,CORBA以及.NET或Java形成了OMG的模型驱动架构的一个集成部分。尽管关于UML的使用有许多的争议，但事实上，此语言还是很容易使用的。UML划分为若干部分，提供给用户12种不同的图，其中只有3到4种真正用于描述业务流程。UML是分层的，这样可以使得先在一个抽象级上定义业务流程，然后进一步具体化、再具体化直到用户满意为止。最后就是UML是人以及机器都很好理解的语言，先在已经有很多基于UML的工具为模型的开发提供了相对易用的GUI接口。

　　在工作流相关的建模语言中，出现了2种重要的标准，那就是WPDL（或其XML形式的XPDL，其来自WFMC标准组织）和BPML（来自BPMI标准组织）。

　　现在WFMC和BPMI都在考虑将其各自语言合并为一个统一语言（如同Booch和OMT语言合并为UML一样），或为两种语言开发一个标准的影射。这个还有待后续的情况发展了。

　　作为工作流相关语言，XPDL和BPML都提供了一个超越通用建模语言（如UML）的重要的优势。它们都能用于工作流建模系统以及运行时工作流系统，在系统间进行移动时而不需要附加额外的转换工作。

　　另外，现在已经开始出现了XPDL和UML之间的“桥梁”，所以使得用XPDL建模工作流然后转换为UML，以便用于系统开发，反之亦然。

　　最后，第三个工作流相关建模语言，BPEL（BPEL4WS）也出现了。其由microsoft的XLANG和IBM的WSFL合并而来。

　　这三种定义语言（XPDL、BPML以及BPEL）因为它们支持与工作流产品的交互所以对业务用户也非常重要，但并不就意味着可以直接用于业务用户群。而对于业务用户群体，开发出了BPMN。此语言图形化、易学并且易用。值得注意的是，其已经被WFMC和BPMI采纳为一个流程标准了。

　　一个知名的组织，OMG当前也在开发一种业务流程建模语言—EDOC，尽管其并不被认为会商业运作。

　　说了这么多，下面给出一张各种与工作流相关的标准如何互相支持的图
      
　　不管哪个语言用于建模和描述流程，有一点是肯定的：在业务流程模型的创建中为业务用户提供的支持是不需要编程开发者或编码的其他中间人。

　　具体以上介绍的建模语言后续会有专题学习心得。

　　工作流和面向服务架构

　　下图给出企业级工作流技术栈

　　展现层

　　栈最上方，流程定义这边，BPMN和UML用于捕获业务流程以及关键的流程对象。这两种建模语言分别用于建模流程和业务用例和业务对象。栈最上方，流程执行这边，有多种web页面描述语言：JSP、ASP和xHTML等。这些Web页面描述语言使得使用web浏览器跨Internet与工作流引擎进行交互成为可能。

　　流程层

　　XPDL

　　XPDL是一种描述流程的元语言。其并是由开发者或用户直接操作的，而是间接地由用户通过工作流系统利用下层XPDL流程描述所对应的BPMN标记语言建模产生的流程描述语言（这里其实讲明白了BPMN和XPDL如何协同工作的）。使用XPDL有一些优势，其中包括用完全不同的流程描述语言（如BPEL、BPXL和BPQL）所表征的流程描述提供一个单一文件。

　　BPEL

　　BPEL是一种用于描述Web service的编排的流程描述语言。与XPDL相比，BPEL不能直接被人操作，而是通过上层的BPMN语言来进行操作的。其实在这里来粗步比较来说，BPEL更关注机器软件之间的交互，而相对会淡化与人的交互接口，而XPDL则是为工作流相关语言制定，同时WMFC组织给出的接口图中有一个interface2是与人专门交互数据的，自然对人的交互作用考虑得比BPEL多。

　　BPQL

　　BPQL是用于监控流程的查询语言，是BPMI组织所给出的管理与监控接口规范。

　　BPXL

　　BPXL则用于BPEL扩展。

　　总归，流程层通过流程执行的BPEL,XPDL，外加流程监控管理的BPQL以及相应的扩展机制BPXL完成流程层的任务。

　　注意：图中用虚线表示的意义是正在制定中的规范。

　　流程支持层

　　Web-service

　　内部关键的三个协议SOAP、WSDL以及UDDI。

　　其实这里还有一个现在比较流行的SCA和SDO规范，对于支持流程提供服务也是起到了很重要的作用。

　　其他的数据访问、虚拟机平台技术在这里就不详细讲了。

　　工作流系统架构

　　工作流系统从一开始就要跨功能、跨业务、跨组织机构。这么一个庞大的系统，必须有一个良好设计的架构。

　　如下是由WFMC给出的工作流参考模型

　　下图则为参考模型之构件接口图

　　原文出处：http://gocom.primeton.com/blog10872_19935.htm