1.            工作流历史

工作流技术发端于 1970 年代中期办公自动化领域的研究工作，但工作流思想的出现还应该更早， 1968 年 Fritz Nordsieck 就已经清楚地表达了利用信息技术实现工作流程自动化的想法。 1970 年代与工作流有关的研究工作包括：宾夕法尼亚大学沃顿学院的 Michael D. Zisman 开发的原型系统 SCOOP ，施乐帕洛阿尔托研究中心的 Clarence A. Ellis 和 Gary J. Nutt 等人开发的 OfficeTalk 系列试验系统，还有 Anatol Holt 和 Paul Cashman 开发的 ARPANET 上的“监控软件故障报告”程序。 SCOOP, Officetalk 和 Anatol Holt 开发的系统都采用 Petri 网的某种变体进行流程建模。其中 SCOOP 和 Officetalk 系统，不但标志着工作流技术的开始，而且也是最早的办公自动化系统。

1970 年代人们对工作流技术充满着强烈乐观情绪，研究者普遍相信新技术可以带来办公效率的巨大改善，然而这种期望最终还是落空了。人们观察到这样一种现象，一个成功的组织往往会在适当的时候创造性的打破标准的办公流程；而工作流技术的引入使得人们只能死板的遵守固定的流程，最终导致办公效率低和人们对技术的反感。 1970 年代工作流技术失败的技术原因则包括：在办公室使用个人计算机尚未被社会接受，网络技术还不普遍，开发者还不了解群件技术的需求与缺陷。

含有工作流特征的商用系统的开发始于 1983 年至 1985 年间，早期的商用系统主要来自于图像处理领域和电子邮件领域。图像处理许多时候需要流转和跟踪图像，工作流恰好迎合这种需求；增强的电子邮件系统也采用了工作流的思想，把原来点对点的邮件流转改进为依照某种流程来流转。在这些早期的工作流系统中只有少数获得了成功。

进入 1990 年代以后，相关的技术条件逐渐成熟，工作流系统的开发与研究进入了一个新的热潮。据调查，截至 1995 年共有 200 多种软件声称支持工作流管理或者拥有工作流特征。工作流技术被应用于电讯业、软件工程、制造业、金融业、银行业、科学试验、卫生保健领域、航运业和办公自动化领域。

2.            工作流概念

2.1 工作流概念

工作流是针对工作中具有固定程序的常规活动而提出的一个概念。通过将工作活动分解成定义良好的任务、角色、规则和过程来进行执行和监控，达到提高生产组织水平和工作效率的目的。工作流技术为企业更好地实现经营目标提供了先进的手段。工作流管理系统（ workflow management systems , WFMS ）是以规格化的流程描述作为输入的软件组件，它维护流程的运行状态，并在人和应用之间分派活动。在此，我们先定义一些基本的术语：流程定义（ process definition ）和流程实例（ process instance ）。一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。工作流管理系统还处于技术发展曲线上的初级阶段。目前，工作流中使用了过多的概念。在这个领域中的大量规范和工具没有一个是相似的，他们之间主要的分歧在于如何阐述流程中的步骤。

在介绍工作流时有一个话题必须包括，那就是工作流和业务流程管理（ BPM ）的关系。术语 “ 工作流 ” 通常描述人与计算机系统的一系列相关交互。在开发人员中，工作流经常被提及。有时，工作流的意思是指一些不同的 UI 界面。业务流程管理的范围比较广，相比之下工作流多半局限于技术领域。业务流程管理还从管理人员的角度涉及了非技术问题，比如分析、组织的效率。

2.2 工作流管理系统概念

    工作流管理系统是以规格化的流程描述作为输入的软件组件，它维护流程的运行状态，并在人和应用之间分派活动，推进工作流实例的执行，并监控工作流的运行状态。

工作流管理系统可以描述不同覆盖范围和不同时间跨度的经营过程，根据经营过程以及组成活动的复杂程度，工作流管理系统可以采取多种实施方式，在不同实施方式中，所应用的信息技术、通信技术和支撑系统结构会有很大的差别，工作流管理系统的实际运行环境也可以在一个工作组内部，也可以在全企业所有业务部门。

    工作流管理系统在实际系统中的应用一般分为三个阶段：即模型建立阶段、模型实例化阶段和模型执行阶段。在模型建立阶段，通过利用工作流建模工具，完成企业经营过程模型的建立，将企业的实际经营过程转化为计算机可处理的工作流模型。模型实例化阶段完成为每个过程设定运行所需的参数，并分配每个活动执行所需要的资源，模型执行阶段完成经营过程的执行，在这一过程中，重要的任务是完成人机交互和应用的执行。

3.            工作流应用目标领域

使用工作流管理系统的目的之一是作为企业应用系统集成（ EAI ）的平台。在当前大部分企业级 IT 架构中，各种各样的异构应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（ EAI ）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流管理系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流管理系统和专门系统是相互补充的。工作流管理系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流管理系统的第一种使用方式就是：结合所有的专门应用，使用工作流管理系统构建一个 EAI 平台。

工作流管理系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流管理系统都有一个方便的机制，来生成执行任务的表单。对于专注于 ISO 或者 CMM 认证的组织，采用这种方式使用工作流管理系统能够显著提高生产率。不用将过程用文字的形式写在纸上，工作流管理系统使你通过流程定义建模实现过程的自动化（如使用基于 Web 的应用）。

工作流管理系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。

4.            工作流规范

    在工作流管理系统概念的基础上，演进出很多标准，总体上可分为基于标准 XML 文档的和基于 Web 服务技术的两种规范。

4.1 基于标准XML文档的规范

4.1.1 概述

此类规范最大的特点就是基于纯 XML 技术。其中包括：

WfMC 的 XPDL ， WfMC 发布的工作流管理系统参考模型提出了五类接口，有关过程模型的定义则构成了接口一（ XPDL ）的核心内容。 XPDL 是至今工作流领域最为重要的一个标准 , 目前大多数工作流引擎是依据该标准设计开发的。

BPML （ Business Process Modeling Language ）， BPML 是 BPMI （ Business Process Management Initiative ）组织发布的规范。 WfMC 和 BPMI 在 2002 年 6 月 26 日宣布将合作制定业务流程和工作流标准，即采用 BPML 来描述工作流过程，同时采用 XPDL 所定义的工作流模型。 BPML 规范为表达业务流程和支持实体提供一个抽象模型。 BPML 为表达抽象和执行流程定义了一种正式模型，该模型代表了企业业务流程的面貌，包含了不断变化的复杂行为，事务和数据管理，合作，异常捕获，操作语义。 BPML 为了能够持久化和通过异种系统进行定义交换以及使用建模工具，提供了 XML Schema 形式的语法。

在 WfMC 所定义的一系列规范基础上， OMG （ Object Management Group ）联合这些规范发布了 Workflow Management Facility 规范，该规范定义了如何将工作流向 CORBA 转换。

4.1.2 WFMC

该领域的代表规范就是工作流管理联盟（ Workflow Management Coalition ， WfMC ）发布的。 1993 年， WfMC 的成立标志着工作流技术开始进入相对成熟的阶段。为了实现不同工作流产品之间的互操作， WfMC 在工作流管理系统的相关术语、体系结构及应用编程接口等方面制定了一系列标准。 WfMC 给出的工作流定义是：工作流是指整个或部分经营过程在计算机支持下的全自动或半自动化。在实际情况中可以更广泛地把凡是由计算机软件系统（工作流管理系统）控制其执行的过程都称为工作流。

 

图1 1994年11月 WfMC发布工作流管理系统参考模型

 

 

Work Flow Enactment Service 这个组件就是我们平常说的工作流机或工作流引擎，主要功能是读取工作流定义、根据工作流定义驱动工作流的流转。

Process Definition(1) 在流程定义、建模工具、工作流引擎之间定义标准接口。使流程开发人员能够部署流程定义。流程定义表示一种形式上的业务流程描述，由各种活动以及相互之间的网状关系组成，标识了流程的开始和终止，并且包含个体行为的信息，比如各个参与者、与 IT 相关的应用程序和数据，等等。该接口采用的标准是 XPDL （ Xml Process Definition Language ）。

Workflow Client Application(2) 工作流引擎的客户端程序。该程序由用户结合业务需求而开发，用它来驱动工作流。客户端程序通过该接口与引擎交互。一般的工作流引擎用户不需要懂引擎的实现，只要知道怎么实现客户端程序就可以了。

Invoked Application(3)   通过普通代理软件调用该接口，允许调用工作流引擎之外的功能。

Other Work Flow Enactment Services(4)  与其他工作流引擎协作的接口。

Administration and Monitoring Tools(5)   管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。

 

详细说明 WfMC 参考模型

 

    接口 1 早期的规范为 WPDL （ Workflow Process Definition Language ）。后来，这一接口的规范变更为 XPDL 。 XPDL 是至今工作流领域最为重要的一个标准，目前大多数工作流引擎是依据该标准设计开发的。 XPDL 利用 XML 作为流程定义相互转换机制，在流程定义元模型中， XPDL 语法直接与定义在其中的对象、属性相关联。元模型描述了流程定义所需要的上层实体，以及它们的关系和属性。对于 XPDL 基本元素更加详细的介绍请参考 WFMC-TC-1025 FINAL Draft 。

 

    接口 2&3 规范为 WAPI （ Workflow Application Programming Interfaces ）。通过在 WFM 产品中支持这些接口，便于实现需要访问 WFM 工作流引擎功能（工作流服务）的前端应用程序。此类应用程序的实现，可由 WFM 开发人员或 ISVs （独立软件开发商）完成。实现这些 API 调用，还有利于工作流应用程序使用该通用的 API 接口操作不同的工作流引擎。这些 API 调用，允许 WFM 开发人员使用一个单一的最终用户接口和功能集合，而不用考虑已有的各种 WFM 工作流产品。 WAPI 调用可用各种语言实现。最初的联盟规范将适用于 ’C’ 语言。该 API 采用 CALLS 的形式。在特定的 WFM 产品实现中，对 CALLS 的底层实现不做任何假设。 WAPI 调用用于运行时（ run-time ），就是说，当流程正在执行或将要执行时。它们通常被用于工作流应用程序（如工作表处理器和协同操作的应用程序等），当某一 WFM 引擎需要在 API 函数上下文内与其它 WFM 产品的工作流引擎交互时，它们也可用于 WFM 引擎。通过其函数集， WAPI 提供了一组由工作流定制服务（ Workflow Enactment Service ）提供的工作流服务。 WAPI 不假设任何特定的用户接口，更确切地说，它特别地假定了支持工作流的应用程序用户接口。该应用程序使用这些服务，提供其自己的用户接口，实现这些接口，依赖于实现它的应用程序开发环境工具。 WFM 引擎的功能大致分为以下几类：

l        WAPI 连接功能

l        WAPI 工作流定义功能

l        WAPI 过程控制功能

l        WAPI 活动控制功能

l        WAPI 过程状态功能

l        WAPI 活动状态功能

l        WAPI 工作表功能

l        WAPI 管理功能

对于 WAPI 更加详细的介绍请参考 WFMC-TC-1009 V 2.0 。另外，可同时参考 WFMC-TC-1013 V 1.4 ，该文档为符合 WAPI 的命名规则提供了方针和解决办法，该文档也包含 'C' 语言的通用头文件。

接口 4 规范为 Wf-XML 2.0 。有必要在流程引擎中集成跨越 Internet 和 Intranet 并能相互作用的标准协议。一个流程引擎，一个异步服务的特殊类型（被称为 Asynchronous Services Access Protocol (ASAP) ），一组描述服务运行步骤的活动，就这样出现了。最后暴露这些步骤，允许服务调用者具有额外对那种服务状态的了解能力。提出 ASAP 的主要目的在于通过 SOAP 提供一种控制和监视异步 Web 服务的基本能力，并传递编码为 XML 格式的结构信息。控制异步 Web 服务包括构建服务，安装服务，启动服务，结束服务，通知异常，通知服务的结束并获得服务的结果。监视 Web 服务包括检查当前服务状态和该服务的历史执行状态。外部程序调用最基本的流程的开始和监视只能通过 ASAP 。 ASAP 已经建立了连接异步服务的标准协议，无论他们是否是像流程引擎那样实现。 Wf-XML 提供一种方法把面向过程工具融入进通用的引用框架。现在流程定义工具就可以已一种标准方式来获取或更新流程定义了。流程监视工具也一样能跟踪流程实例了，也可以跟踪子流程链接和更低一层的子流程。对于 Wf-XML 2.0 更加详细的介绍请参考 Wf-XML 2.0 Draft 。

接口 5 规范为 CWAD （ Common Workflow Audit Data ）。通过在工作流产品中支持这一规范，就能在不同的工作流产品中提供一致的审计数据分析。在初始化和执行一个流程实例时，会发生许多影响业务的事件，包括 WAPI 时间，内部 WFM 引擎操作和其他系统以及应用程序函数。有了 CWAD 信息，业务就能确定已经在工作流管理中发生了什么操作。我们希望审计信息被利用到分析和追溯状态信息中。另外审计数据可被用作执行操作的证据。工作流分析工具将希望信息以一致的格式表现，描述全部事件，在一套规定的标准内发生 ... 例如，运行“ x ”流程用了多久时间，在一个给定的流程实例内进行了哪些活动？表现出的审计数据将会绑定很细节的内容。对于 CWAD 更加详细的介绍请参考 WFMC-TC-1015 V1.1 。

 

    其他基于标准 XML 定义的标准发展很弱，在这里不作介绍了。

 

4.2 基于 Web 服务技术的规范

4.2.1 概述

Web 应用的巨大成功和不断发展，使其渗透到商业领域和个人生活的各个方面。人们只要使用浏览器，就可以享受到各种各样的服务，例如网上购物，网上交易，网络游戏，预定车票，网上聊天和交友等等。与此同时，由于 Web 技术所带来的优势（统一的客户端和较好的维护性），使一些传统的应用纷纷转型到基于 B/S 架构的瘦客户端应用程序，这是因为它能够避免花在桌面应用程序发布上的高成本，也能够很好的解决客户和服务器之间的通信问题。在客户端和服务器之间的通信，一个完美的解决方案是使用 HTTP 协议来通信。这是因为任何运行 Web 浏览器的机器都使用 HTTP 协议，可以很好地透过防火墙进行通信。

许多商业程序还面临另一个问题，那就是与其他程序的互操作性。目前有很多商业数据仍然在大型主机上以非关系文件（ VSAM ）的形式存放， 并由 COBOL 语言编写的大型机程序访问。而且，还有很多商业程序使用 C++ 、 JAVA 、 VB 和其 他各种各样的语言编写。现在初了最简单的程序之外，所有的程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。在以前，没有一个应用 程序通信标准是独立于平台、组建模型和编程语言的。只有通过 Web 服务、客户端和服务器才能够自由的用 HTTP 进行通信，不论两个程序的平台和编程语言是什么。 Web 服务技术完全基于标准的技术，只有基于标准，所有的开放厂商才能有相同的标准，才能够在各自的平台上开发出具有跨平台互操作能力的软件产品和解决方案。

经过近几年的发展， Web 服务的概念渐渐深入人心，随着社会的发展， Web 服务将越来越流行。基于 Web 服务的工作流规范将推动 Web 服务进入一个全新的阶段。

4.2.2 WSCI

2002 年 6 月 26 日 BEA 、 Intalio 、 SAP 和 Sun 在美国发布了基于 XML 的 Web 服务协作接口 WSCI （ Web Services Choreography Interface ）。 WSCI 描述了在特殊流程中通过 Web 服务实现消息流的交流，并描述了集合性信息在互动的 Web 服务间的交流，提出了一种涉及到多种 Web 服务的复杂流程的全球观点。当今的服务描述语言对于简单的获取信息是足够的，例如股市报价，但它们没有提供充足的动作细节，来描述服务作为一个大型的、更全面的协作的一部分所扮演的角色。 WSCI 的关键优势之一在于，它通过描述 Web 服务如何在大型的、全面的业务流程中应用，从而在业务流程管理与 Web 服务之间架起了桥梁。这些业务流程可以只是一个公司内的，也可以是跨越多个公司的。

 

                                             
                                                 图 2 WSCI 层次

 

Web 服务是才兴起的关键组件，提供松弛耦合和基于 Web 的计算体系。 Web 服务就是可以通过已有的基于 Web 的协议进行访问的自治领域，有着良好界定，而且基于标准的组件。按照标准划分出层次的 " 堆 (stack)" 主要目的是保证 Web 服务的语义和技术互用性。这个堆由 W3C 开发，仍然处于初级阶段，目前正在被重新构建；为了使真实的 Web 服务协作成为可能，还需要多个附加层。平行的，其他标准为业务流程和协作构建一种严密的语义和互用性。可以预见，这两个堆将在中间见面（ meet in the middle ）。尽管仍需要为总体框架在一种有效的方式里发生， WSCI 提供第一步连结这两个堆。 WSCI 在自下而上的堆里是一个主要参加者，但可以预见，这会在协作区域的更高一级别层次出现和集成。

对于 WSCI 更详细的内容请参考 W3C （ World Wide Web Consortium ）的 WSCI 1.0 。

4.2.3 ebXML

ebXML 是一个规范集，这些规范共同实现了模块化电子商务框架。 ebXML 的构想是实现一个全球电子市场，其中，不同规模和不同地区的企业可以通过交换基于 XML 的消息来合作和进行商业活动。 ebXML 是一项倡议，其参与者与认可者包括几百家大公司和团体。 ebXML 的直接赞助者是 OASIS （ Organization for the Advancement of Structured Information Standards ）和 UN/CEFACT （ United Nations Centre for Trade Facilitation and Electronic Business ）。许多标准团体也参与其中，包括 NIST （ National Institute of Standards and Technology ）和 W3C 。

ebXML 体系规范定义：

1.        一种描述业务流程和关联信息模型的标准机制。

2.        一种注册和存储业务流程及信息元模型，便于共享和复用的机制。

3.        关于每个参与者的信息的发现包括：

      * 他们所支持的业务流程。

      * 他们提供支持的业务流程的业务服务接口。

      * 各自业务服务接口所交换的业务消息。

      * 传送，安全和编码协议所支持的技术配置。

4.        一种寄存先前出现的信息的机制，以便它能被发现和挽回。

5.        一个描述能由第 3 项以前，由每个参与者提供的信息组成的相互认可的业务契约的机制。 (CPA)

6.        标准业务消息服务框架，它允许互操作，安全且可靠的在贸易双方交换消息。

7.        依照业务契约的约束，配置各自的消息服务的机制。

让我们先来了解一些概念。

注册表 ：一个中央服务器，它存储使 ebXML 工作所需的各种数据。在这些信息中，“注册表”以 XML 形式显示给用户的有：“商业过程和信息元模型”、“核心库”、“协作协议概要”以及“商业库”。基本上，当商家要与另一个商家建立 ebXML 关系时，它向“注册表”发出请求，以查找合适的伙伴并查找有关处理那个伙伴的需求方面的信息。

业务流程 ：商家可以参与的活动（对于业务流程，商家通常需要一个或多个伙伴）。“业务流程”由“业务流程规范模式” ( 一种“ W3C XML 模式”和一个 DTD ）正式描述，但也可以用 UML 建模。

协作协议概要 (CPP) ：由希望参与 ebXML 事务的商家用“注册表”归档的概要。 CPP 将指定商家的某些“商业过程”，以及它支持的某些“商业服务接口”。

业务服务接口 ：商家可以执行其“业务流程”中必需的事务的方式。 “业务服务接口”还包括商家所支持的“业务消息”种类以及传递这些消息可能采用的协议。

业务消息 ：作为商业事务一部分进行通信的实际信息。一条消息将包含多层。在外层，必须使用实际的通信协议（例如 HTTP 或 SMTP ）。 SOAP 是 ebXML 推荐的消息“酬载”信封。其它层可以处理加密或认证。

核心库 ：可以在更大的 ebXML 元素中使用的标准“部件”集。例如，“业务流程”可以引用“核心流程”。“核心库”由 ebXML 发起者本身提出，而更大的元素可能由特定厂家或商家提出。

协作协议协定 (CPA) ：本质上是两个或多个商家之间的契约，它可以从各自公司的 CPP 中自动获取。如果一个 CPP 说：“我可以做 X ”，则 CPA 会说“我们将一起做 X 。”

 

 

图 3 ebXML 工作流程

 

上图中，公司 A 已经知道在互联网上可访问一个 ebXML 注册表（第 1 步）。接着，公司 A 在复查 ebXML 注册表的内容后，决定构建和部署适合自己的 ebXML 应用（第 2 步）。客户端软件开发不是 ebXML 参与者的必要先决条件。适合 ebXML 的应用和组件是很容易通过商业途径获得，比如收缩包装膜这样的方案。公司 A 接着提交自己的业务描述信息（包括实现的详情和参考链接）到 ebXML 注册表（第 3 步）。业务描述被提交到 ebXML 注册表，来说明该企业的 ebXML 能力和限制条件，以及它的支持的业务脚本。这些业务脚本是 XML 版本的业务流程和关联信息包（比如营业税计算）。在接受确认后，业务脚本的形式和用法就是正确的了，一个认可被发送到公司 A （第 3 步）。公司 B 在 ebXML 注册表上发现了由公司 A 提供的业务脚本（第 4 步）。接着，公司 B 发送一个请求到 公司 A ，他们使用 ebXML 共同参与业务脚本（第 5 步）。公司 B 从 ebXML 获得收缩包装膜方案。在参与该脚本的公司 B 直接提交被提议的业务协定到公司 A 相应的 ebXML 软件接口之前。这个被提议的业务协定要概述双方达成的业务脚本和详细协议。该这个业务协定还包含了属于将用于事务发生的要求的信息，偶然作出的计划，以及与安全相关的必备条件（第 5 步）。公司 A 随即接受该业务协定。最后，公司 A 和 B 现在准备从事使用 ebXML 的电子商务。

ebXML 规范集还包含了：业务流程计划规范、注册表信息模型、注册表协议规范、 EbXML 需求规范、 CPP 和 CPA 规范、消息服务规范等。



请注意！引用、转贴本文应注明原作者：Rosen Jiang 以及出处： http://www.blogjava.net/rosen