神马文学网工作流理论总结 - 成都心情@北漂 - BlogJava
来源：百度文库 编辑：神马文学网 时间：2024/04/27 08:45:10
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
图2 WSCI层次
Web服务是才兴起的关键组件，提供松弛耦合和基于Web的计算体系。Web服务就是可以通过已有的基于Web的协议进行访问的自治领域，有着良好界定，而且基于标准的组件。按照标准划分出层次的"堆(stack)"主要目的是保证Web服务的语义和技术互用性。这个堆由W
对于WSCI 更详细的内容请参考W
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）和W
ebXML 体系规范定义：
1. 一种描述业务流程和关联信息模型的标准机制。
2. 一种注册和存储业务流程及信息元模型，便于共享和复用的机制。
3. 关于每个参与者的信息的发现包括：
* 他们所支持的业务流程。
* 他们提供支持的业务流程的业务服务接口。
* 各自业务服务接口所交换的业务消息。
* 传送，安全和编码协议所支持的技术配置。
4. 一种寄存先前出现的信息的机制，以便它能被发现和挽回。
5. 一个描述能由第3项以前，由每个参与者提供的信息组成的相互认可的业务契约的机制。(CPA)
6. 标准业务消息服务框架，它允许互操作，安全且可靠的在贸易双方交换消息。
7. 依照业务契约的约束，配置各自的消息服务的机制。
让我们先来了解一些概念。
注册表：一个中央服务器，它存储使ebXML 工作所需的各种数据。在这些信息中，“注册表”以XML 形式显示给用户的有：“商业过程和信息元模型”、“核心库”、“协作协议概要”以及“商业库”。基本上，当商家要与另一个商家建立ebXML 关系时，它向“注册表”发出请求，以查找合适的伙伴并查找有关处理那个伙伴的需求方面的信息。
业务流程：商家可以参与的活动（对于业务流程，商家通常需要一个或多个伙伴）。“业务流程”由“业务流程规范模式”(一种“W
协作协议概要(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规范、消息服务规范等。