[转载] Web services 世界的业务过程和工作流

<abstract-extended></abstract-extended>首先，我们需要考虑一个问题。想想那个造出第一个轮子的洞穴人。第一个轮子是创造、发明、是值得庆祝的理由。而制造第二个、第三个、第四个、第五个等轮子的制作则只是劳动。从穴居时代，到亨利福特开始通过装配线生产福特汽车，直到今日，我们一直都在想办法来更好地、更快地、更可靠地，同时花费更少的金钱来完成工作。对于达到这些目标，业务流程是一种非常好的方法。本文将讨论业务流程、它们与现今的工作流和 Web 服务的关系，还有我们面临的挑战。

业务流程：是的，它们值得投资

业务流程可以被定义为一个具有各种不同功能的活动相连的一组有相互关系的任务。业务流程有起点和终点，而且它们都是可重复的。这个定义并不能反映出产生一个有用的业务流程所需的思考、明确性、细节和付出的时间。有用的业务流程为企业创造并节省金钱。

更重要的是，为企业创建业务流程的价值在于那些流程所代表的智力资产。企业生产出的配件有价值，这无可非议；此外，如何制造这些配件的知识也同样有价值。您可以在业务流程中获取这些知识、添加新的知识并予以改进。配件制作流程的作用域是很重要的，因为执行所有这些步骤将确保合格的配件；步骤多了或少了或与此不同将使得成本增加或质量降低，甚至两种结果都有。

定义业务流程并对其作出文档所花费的时间和努力是完全值得的。只让配件制造主任了解企业的配件制造知识，然后让他每晚走出工厂大门，这就有危险了。只要定义了配件制造业务流程，配件制造工人可以随时来去，而且任何配件制造工人都可以随时取代另一个人的工作，这是因为工厂里的所有配件制造工人都理解并遵循业务流程。我们可以学习、改变、评估然后再次改变配件制造业务流程，因为该流程对于每个人都是可见的，而非局限于配件制造主任。

工作流：谁？什么？何时？

工作流软件并不创建业务流程，但是，当您在设计业务流程定义和添加要求的业务规则定义时，把工作流应用到业务流程时当然集中了该流程的细节。工作流可以被看作是业务流程中的 谁？什么？何时？这几个问题的答案的实现。

谁？

谁是业务流程流所涉及的参与者？他们担任什么角色？他们是如何被组织的？分组是灵活而动态的？还是更为固定而静态的？不仅是人，更多实体可以成为工作流参与者。组织、应用程序、员工、Web 服务和其他工作流可以是谁这个问题的答案。把参与者抽象为角色将使一个工作流更为健壮。举例来说，您不必冒着在工作流中产生瓶颈的危险来指定员工 A 或员工 B 必须做某项任务，或者忍受每次有人调任或晋级时都必须修改特定员工名单时令人头痛的维护工作，您可以允许任何具有管理员（Supervisor）角色的人来执行该任务，这样会减小产生瓶颈的风险，还能降低维护成本。

什么？

参与者要做哪些工作？他们如何来做他们的工作？他们要批准什么事情吗？他们执行事务吗？他们创建文档吗？跟踪库存吗？向供应商询价吗？开展商业活动吗？把信息传递给其他参与者吗？有些工作流是完全自动的，而有些则由必须通过人来执行的手工任务组成。更为常见的是，工作流是这两种类型的结合。例如，向供应商询价可以是一组由人来执行的人工任务之一，但也可以变为一个对 Web 服务的编程调用，该服务根据供应商和向其提供的物品信息返回价格。

何时？

参与者如何知道工作何时开始？工作何时完成？参与者以什么顺序进行他们的任务？他们是以串行还是平行方式工作？如果只是有时工作，那么是在什么情况下？每个任务要持续多长时间？是否有确定的截止期限？如果任务没有成功完成，是否要重新再来？当一个业务流程中包含目前由人仅在白天完成的任务，而对这些任务的检查结果是把它们变为自动地、在任何时间执行，这样人就被解脱出来，可以去完成其他任务，而后来变为自动执行任务不必等待某人去执行。

您了解工作流语言吗？

现在，让我们来了解一些常见的工作流术语（请参见表 1），大部分取自 WfMC 的工作流参考模型（Workflow Reference Model）（请参见参考资料来获取更多信息）。

表 1：工作流术语和定义

工作流	很简单，它就是工作从开始到完成的过程。工作流由流程逻辑和路线规则组成。流程逻辑定义了任务的顺序和必须遵循的路线规则，还有截止期限以及由工作流引擎实现的其他业务规则。
流程定义	一个图形流程定义或流程图，代表工作流的流程逻辑元素以及各元素之间的关系。
流程实例	一个流程实例，通常称为工作，是一个流程定义的运行实例。
工作流管理系统	一个软件应用程序，它存储流程定义并通过其工作流引擎组件来根据这些流程定义运行工作。工作流引擎是运行时执行模块。
流程定义工具	一个用来创建和更改流程定义的软件工具。该工具可以是一个业务流程管理软件的组件、一个独立的应用程序或者一个工作流管理系统的组件。流程定义工具提供了重用已存储工作流元素甚至所有子流程的能力，这使工作流应用程序开发者生产力更高，因为他们在构建工作流并在工作流中集成其他应用程序时避免了再次发明这些轮子（应用程序）。
参与者	以下类型之一：资源集、特定资源、组织单元、角色（一个人在组织内部的作用）、人或系统（自动代理）。它可以回答业务流程中“谁？”这个问题。
活动	组成流程定义中的一个逻辑步骤的任务。可以是自动的或人工的。自动指在流程操作过程中定义脚本和触发器的能力。流程定义中的特定活动可以作为无人参与的任务来运行，自动化可以在手工或人力驱动的任务中执行业务规则。常见的一种自动活动就是截止期限管理，如果某个工作项在预定的截止期限之前未能完成，该管理可以自动发送一条提醒消息或触发一个延期程序。
活动所有者	活动所有者是有权宣布一个活动结束，然后推进工作到流程中的下一个活动的参与者。
工作所有者	工作所有者是有权整体控制流程实例执行过程的参与者。
工作项	代表流程实例中活动的参与者将要执行的工作。

工作流的根

软件中的工作流方向来源于两个起源不同的观点： 基于人的业务流程和 基于规则的自动化流程；两者之间的互补性一直在增强。

基于人的工作流软件的根在工作组工具（workgroup tool）和群件（groupware）中。在工作组工具应用程序（办公室套件，如 Lotus SmartSuite、Microsoft Office 和 Star Office，还有一些更为专用的工具，如 Autodesk 和 Autocad）中，小组协作和隐式工作流一直就是明显的特征。群件是旨在让小组或群体中的人能更容易地协作并帮助他们使工作流更为平稳而高效的软件。对于从工作组工具和群件发展而来并且现在正显式地捕获和管理着工作流的基于人的工作流软件，其未来在于增强 Web 服务功能，同时增强 JSP 和 portlet 支持，从而使它们朝越来越集成到 Java 环境中的方向发展。

如 Web 应用程序编制（Web application orchestration）中所述，在规则引擎应用程序和静态的、一步一步的、基于规则的生产和制造流程中均可以见到工作流自动化应用程序的根。这种工作流现在也在朝支持基于人的工作流的方向发展。

两种观点的融合意味着工作流软件具有灵活地处理各种不可预料的情形的能力是非常重要的。Web 服务工作流的编制和编排是目前正在进行的标准定义工作的重要部分。

我们在这里仍然可以看到两种观点。编制将顺序和节拍分别强制施加在一组 Web 服务及其输出上，从而产生期望的流程结果，这正如一个音乐指挥者把顺序和节拍分别强制施加在一组演奏者和他们奏出的音乐上，从而产生期望的音乐效果。演奏者奏出的音乐中如果有走调或错误将使指挥者很不高兴，但这不会改变演奏过程的顺序和节拍。Web 服务的编制反映了工作流的自动化根。

相对比，从同样的比喻角度而言，编排比编制更为复杂，编排定义的是处理一组 Web 服务之间的各种不可预测的交互的行为。一群舞蹈者和一个交响乐团的演奏者都以相互合作的方式各司其职地演出，与此同时，舞蹈者按编藕玫亩髟谖杼ㄉ显硕舜说纳硖寤嵯嗷ビ跋臁Ｄ掣鑫璧刚叨鞯谋湫位虺龃砘嵋鹌渌璧刚叩亩鞣⑸谋洌饨幼啪突岣谋湮璧副硌荼旧怼eb 服务的编排反映了工作流的基于人的根。

工作流和企业应用程序集成

工作流软件应该完成以下四个主要功能（这些功能是企业应用程序集成（Enterprise Application Integration，EAI）的一部分）：充当垂直应用程序的组件；与应用程序集成软件很好地一起工作；成为协作应用程序的"粘合剂"；适应 Web 服务体系结构。

作为垂直应用程序的组件（用于诸如银行业和保险业这样的企业行业），工作流应用程序应该通过跨组织共享的直观的图形工具来增强开发和业务范围之间的交互。对于像制造业这样的行业，工作流应用程序应该增强生产的灵活性并使生产系统负载均衡。在流程和组织发生改变时，工作流应用程序应该能够很容易更新工作流。最后一点，但并非最不重要的是，工作流应用程序应该通过对业务流程进行标准化和监督帮助企业遵守政府和组织条例。

为了 与应用程序集成软件API 很好地合作，工作流应用程序应该提供灵活的 Java 支持，这种支持将使工作流应用程序能够与 Web 应用程序和其他 IT 应用程序集成，同时应该支持与现有企业应用程序的集成。举例来说，工作流应用程序应该能够支持外部主机工作流系统中嵌入的工作流。

从前面提到的两种观点来看， 工作流应用程序应该成为合作应用程序的“粘合剂”。合作应用程序通常指由其他需要执行任务的应用程序／Web 服务构建的应用程序以及管理所有的交互作用和数据流的应用程序。合作应用程序也可以指基于人的业务流程的自动化和流水线化，这样工作流的相关人员作为个人来说生产力更高，而在小组中显得更为重要。

工作流应用程序应该适用于 Web 服务结构体系。工作流可以作为 Web 服务来提供。举例来说，工作流 Web 服务可以被提交报价请求的外部供应商调用。创建请求后，工作流应用程序可以自动创建并添加以前存储在文档管理系统中与提交者建立的合约的链接，然后根据这些以前的合约以及目前市场情况生成一些推荐报价，再把提交发送到合适的人（们）。当要去满足该请求的人收到提交时，他能够得到作出一个有充分信息根据的决定所需的一切信息，知道应该向供应商提供什么样的报价。工作流也可以控制一组构成应用程序的 Web 服务流。

让您的工作流调用我的工作流

在一个由 Web 服务构建而成的合作应用程序里，应用程序中的业务流程的确是一组任务，这些任务的参与者是 Web 服务，而工作流控制极为重要，完全不同的工作流之间的交互也不可避免。然而，在您的工作流可以调用我的工作流并被其理解（互操作）之前，我们需要一个标准去描述公共流程、组合、专用工作流和其他常见的工作流构件。尽管现在已经有了一些被提议的工作流标准，但这种工作流互操作性还未被人们确定。人们编写了其他一些这种建议和文档。表 2显示了近年来产生的各种工作流规范和定义。在本文末尾也有一个关于这些标准的参考资料列表。

表 2：工作流规范

Wf-XML	工作流管理联盟（Workflow Management Coalition，WfMC）中的 Wf-XML 和工作流参考模型（Workflow Reference Model）：Wf-XML 是一种基于 XML 的工作流互操作性信息的编码。工作流参考模型是一种底层工作流系统体系结构的描述。目前 Wf-XML 没有与 SOAP 和 WSDL 绑定。
WSFL	IBM Web 服务流语言（IBM Web Services Flow Language）：指定了 Web 服务组合的两种类型 1）一个被认为是流模型（flowModel）的可执行业务流程，和 2）一个被认为是统一模型（globalModel）的业务合作。与 SOAP、UDDI 和 WSDL 兼容。
XLANG	Microsoft 的 XLANG：用于 BizTalk 的业务模型语言，该语言是可运行 EAI 的 .NET 组件。BizTalk 编制（BizTalk Orchestration）是工作流引擎，BizTalk 编制设计器（BizTalk Orchestration Designer）是基于 XLANG 的可视化业务流程模型工具。
BPEL4WS	用于 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services）是用于 Web 服务编制、工作流和组合的 WSFL 和 XLANG 的协作合并。该语言还尚未被提交到 IT 标准组织。
ebXML BPSS	电子商务过渡工作组（eBusiness Transition Working Group）继承了业务流程规范方案（Business Process Specification Schema（BPSS））的 ebXML 层中的工作流对话和编制，ebXML 定义了许多基于 XML 的电子商务的协议和层。
WSCI	Sun/BEA/Intalio/SAP 联盟的 Web 服务编排接口（Web Services Choreography Interface）“是一种基于 XML 的接口描述语言，该语言描述了参与和其他服务的编排交互作用的 Web 服务所交换的信息流。”
WSCL	W3C 的 Web 服务对话语言（W3C's Web Services Conversation Language）：Hewlett-Packard 向 W3C 的提交，该提交允许定义 Web 服务的抽象接口（也就是，Web 服务支持的企业级对话或公共流程），以及交换的 XML 文档及其文档的排序。
PIPs	RosettaNet 的伙伴接口流程（Partner Interface Process ）：定义了贸易伙伴与指定的系统到系统（system-to-system)的基于 XML 的对话之间的业务流程。许多 PIP 被用来定义各种伙伴情况。
JDF	CIP4 的工作定义格式（Job Definition Format）是一种即将使用的用于图形艺术（Graphics Arts）工业的工作流工业标准，该标准用于简化不同应用程序和系统之间的信息交换。

我们到了这种程度吗？

为何存在这么多被提议的工作流标准？有些标准之间是直接竞争的关系，的确如此，但很多标准是从工作流那种类似于洋葱的层中的其他标准开始定义，而这些标准在层的边缘融合在一起。基本流程的定义与流程之间如何合作的定义融合在一起。该定义的边界与编制等融合在一起。考虑混合自动和人工活动的所有可能...那么，这是一个很复杂的洋葱。

“工作流标准”是一个矛盾修饰法吗？
矛盾修饰法是一个各部分看上去彼此抵触的短语。“标准”一词表明了共性、简化，并且是一个构建其他人可以理解的有用的东西的基础。工作流通常是复杂而多样的。当我们开始把工作流排列在一起时，复杂性和可能的变化将变得庞大。

把可能把"工作流"浓缩为一个公共的"标准"或一系列标准吗？同时这些标准要足够复杂才能有效。很多人这么想并且现在正在从事这方面的工作。该标准将不会如某些人所希望的那样完整；没有标准会是这样（这就是标准的扩展发明的原因）。也许那将是绊脚石；我们现在需要让工作流标准充分地成长发展。

我们正在等待广泛传播的 Web 服务实现...

目前普遍使用的成熟而完善的业务流程管理产生了可以转换为复杂而完善的工作流的业务流程。工作流行为和互操作性的标准化试图一次性让所有方面标准化，但对于整个过程来说已经晚了。也许标准的主体和它们的成员应该将力量集中在完成基础的、核心的工作流标准，而不应被外层过多地分散力量。标准工作应该由中心"流"出来。

参考资料

您可以参阅本文在 developerWorks 全球站点上的英文原文.
从 Workflow Management Coalition（WfMC）标准 Web 页面开始。
在这篇 developerWorks 的文章 Introducing the Web Services Flow Language来了解关于 WSFL 的更多内容。（ developerWorks，2001 年 6 月）
关于 BPEL4WS，请直接阅读由两位作者合著的系列文章，从 Business Process with BPEL4WS：Understanding BPEL4WS，Part 1开始。（ developerWorks，2002 年 8 月）
了解关于 IBM 的 WebSphere MQ Workflow。
如果要了解很好的编排和编制的标准流程的更新，请参见 Stuart J. Johnson 的 Web Services Wars Take Artistic Turn一文。
请查看关于 IBM WebSphere Business Integration的信息。
看看波兰（Poland）的一个团队如何处理动态工作流参与者任务（dynamic workflow participant assignment）。
工作流管理联盟（Workflow Management Coalition，WfMC）中的 Wf-XML 和工作流参考模型（Workflow Reference Model）是一种基于 XML 工作流的互操作性信息的编
查看关于 IBM Holosofx的信息，它使用了用来标识、集成和管理实时相关企业数据的连续业务流程管理（Continuous Business Process Management）软件，从而交付了一个完整的集成行业解决方案。
IBM Web 服务流语言（Web Services Flow Language）是 BPEL4WS 规范的先驱。
Microsoft 的 XLANG是一种用于 BizTalk 的业务模型语言。
Web 服务业务流程执行语言（Business Process Execution Language for Web Services）是 WSFL 和 XLANG 用于 Web 服务编制、工作流和组合的协作合并。 BPWS4J是 IBM alphaWorks 的 Web 服务业务流程执行语言 Java 运行时平台，该语言支持并且验证 BPEL4WS 文档。
eBusiness Transition Working Group提出了工作流对话和编制的定义，并作为 ebXML协议堆栈的部分。
Sun/BEA/Intalio/SAP 联盟的 Web 服务编排接口（Web Services Choreography Interface）是另一个编排规范。
W3C 的 Web 服务会话语言（Web Services Conversation Language）是 Hewlett-Packard 的提交，该提交也关注 XML 文档交换和排序。
RosettaNet 的伙伴接口流程（Partner Interface Process）定义了交易伙伴之间的业务流程。
CIP4 的工作定义格式是一个即将使用的图形艺术工业的工作流规范。

关于作者
Margie S. Virdell 是一名位于德克萨斯州奥斯汀的 IBM Developer Relations Technical Consulting 的电子商务设计师，为 IBM 商业伙伴提供教育、授权和咨询。她从德克萨斯州威尔克丝-巴里的 Midwestern State University 获得历史学士学位和计算机科学硕士学位，并且在 IBM 工作了 15 年，她大部分时间都花在软件开发上。当她不在思考电子商务的下一步时，她通常更多地学习超大黑洞和超级火山。您可以通过 virdell@us.ibm.com联系 Margie。

分享到：