业务流程（business process）是现实世界中的一种活动，它由一系列在逻辑上相关的任务（tasks）组成，若根据恰当的顺序和正确的业务规则（business rules）来执行这些任务，便可产生业务效果——比如“从下订单到收款”、“订单兑现”和“保险索赔处理”等都是典型的业务流程。

业务流程管理（Business Process Management，BPM）是一套软件系统、工具和方法的统称，它关注机构如何识别、建模、开发、部署和管理上述业务流程。业务流程也包括IT系统与人类的交互（除非是IT系统已完全实现自动化的情况，这样的话，业务流程则仅包含IT系统）。早已有各种BPM方案在使用了，从最初的工作流系统（workflow systems），到现在的Web服务编制（Web services orchestration），都在此列。

BPM技术可以以SOA为基础，利用SOA在架构上的成果，更好地进行业务流程自动化。投资基于Web服务的SOA的重要原因之一就是：Web服务有利于轻而易举地完成BPM的目标。

BPM系统的目标是协助达到“业务流程与期望业务结果的一致”，并确保IT系统能够支持这些业务流程。BPM系统令业务用户（business user）可以在图形化的界面下，以便于IT部门实现的方式为业务流程建模。所有IT系统都是以某种形式来支持和实现业务流程的。而BPM的独特之处在于，它显式地将业务流程逻辑（business process logic）从其他的应用程序代码中分离出来，这与其他形式的系统开发构成了鲜明的对比：在那些系统中，业务流程逻辑是深嵌在应用程序代码中的。

将业务流程逻辑从其他的应用程序代码中分离出来，有利于提高生产力、降低运营成本和增加机动性。如果能够正确实现业务流程逻辑与其他的应用程序代码的分离（比如，将BPM作为SOA与Web服务的消费者），机构将能更快地对不断变化的市场环境作出响应，以把握获取竞争优势的机会。如果能够根据业务流程的图形化描述生成一个可执行的流程规约，那么效率可以得到进一步提高。

Business Operational Changes

业务运营的改变

各种业务（businesses）由于进入业务的原因不同而具有特殊的运营特征（operational characteristics）。举个例子来说，一家比萨店有“30分钟内送达”的承诺。要确保做到这一点，就必须考虑到各种运营特征，比如烘烤比萨的时间、取订单的时间以及规定区域内的运送时间等。显然，运送是一种需要依靠人来进行、不能完全自动化的操作，但是流程中的许多其他部分是可被自动化的，比如可以在收到Web预定后自动提醒将物料运送至比萨餐馆，然后利用机器进行比萨的制作。就理想上来说，你希望尽可能在更多方面提高运营效率，保持最少的 IT系统花费。基于SOA的基础设施能够帮助你实现这一点。

BPM有助于简化“如何将‘解决不同业务问题的Web服务 ’组合起来执行”这一难题。如果把服务（service）看成IT系统与业务功能（比如处理订单）的对应，那么BPM层可被看成一种将多个服务联合为一个可以完成一定功能（比如验证订单、对客户的信用历史进行检查、计算库存量是否能够满足订单、最终运送订单和发送发票等）的流程流（process flow）。通过执行由应用层代码组成的流程流（process flow），业务流程将更易于针对新的应用特征与功能（比如供货商、库存管理或运送过程的变化等）作出变化与更新。

图1-11所显示的是一种用于自动化订单处理的流程流（process flow），该流程流以订单的录入为起点。第一步是接受订单文档，检查安全凭证，并向发送者提供“文档已收到”的确认。

图1-11 处理订单的业务流程流

通常，流程引擎（process engine）会保存输入文档，以便在后续步骤中使用。在文档经过验证之后，其位置（或者在数据库中，或者文件系统中）的引用（reference）将被发送给下一步骤，以便可以随时监测现有库存是否能够满足订单所需的产品数量。如果现有库存量足够的话，在流程流（process flow）的下一步将确认并接受订单，并通知客户订单可被满足。该确认通知可以用Email也可以用Web服务消息发送。

此时，客户可以再一次确认订单，以确认报价及运送时间。如果客户不进行再次确认，流程（process）将被取消，并进入“取消订单”步骤（主要是清除前面业务流程的工作，也可能包括一些补偿事务操作（compensating transactions）以取消为该订单预留的库存量，并取消相应的递送安排）。如果客户再次确认的话，下一步将是准备发货。收到发货确认后，流程流（process flow）将进入到最后一步，即将发票发送给客户。

通常流程流（process flows）由多个独立的任务（tasks）组成，其中每个任务都是一个Web服务。流程流会根据一项任务的执行结果来选择不同的分支以继续执行。可以在流程流的分支处进行错误处理。例如，如果一种产品在某一供货商处缺货的话，那么流

程流会进入这样一个分支：它向其他供货商发送Web服务请求，看它是否有足够的库存。如果所有可用的供货商都缺货，流程流将返回一个错误。

市场和制度的不断变化，要求机构具有相当的灵活性（flexibility）。为IT经理、架构师及开发人员提供一种通用的、基于服务的（services-based）解决方案，将有利于实现机构的灵活性，并易于实现生产力的提高。尤其是在为业务流程管理（BPM）奠定了SOA的基础之后，企业便可集中精力于更高层次的问题（比如设计最佳的业务流程，而不是关心应用实现的技术细节）。

对某些应用而言，核心的Web服务规范就已经足够了；但对另一些应用来说，缺少补充Web服务规范中的某些特性将有所妨碍。比如，有些公司希望它们发布的Web服务具有相当的安全性，并要求只接受通过可靠的消息保证机制发送的订单。

在定义核心的Web服务规范时，已经预留了扩展点（比如SOAP报头），以备添加补充特性的需求。

Standardization
标准化
各种Web服务规范正在通过不同的方式（比如，通过一小群厂商，或者通过被正式授权的技术委员会）走向标准化。从一般的经验来看，很多规范都是先从一小群厂商共

同努力开始，然后被提交给标准化组织以寻求被进一步接受。由Microsoft、IBM以及它们各自的合作伙伴制订的那些规范，往往能够获得较大的市场牵引力。 Microsoft和IBM是Web服务规范运动的事实领袖它们已经定义或帮助定义了所有主要的Web服务规范。在本书编写之时，一些“WS-*”规范仍处于个别机构的控制之下，但是我们希望它们将来能被提交给标准化组织。

目前活跃在Web服务领域的标准化组织有：

l W3C（World Wide Web Consortium，万维网联盟）。致力于Web标准（如HTTP、HTML及XML等）的制定。W3C是SOAP、WSDL、WS- Choreography、WS-Addressing、WS-Policy、XML Encryption和XML Signature的大本营。

l OASIS（Organization for the Advancement of Structured Information Standards，结构化信息标准促进组织）。成立之初致力于促进SGML（Structured Generic Markup Language）[6]间的互操作性，自1998年开始使用现在的OASIS这个名称[7]，以强调其对XML的关注。目前，OASIS主要推动的规范有UDDI、WS-Security、WS-BPEL、WS-Composite Application Framework、WS-Notification、WS-Reliability、Web Services Policy Language（Extensible Access Control Markup Language TC的一部分）（本书将会介绍以上规范）以及Web Services for Remote Portlets、Web Services Distributed Management和Web Services Resource Framework（WSRF）等。

l WS-I（Web Services Interoperability，Web服务互操作组织）。创建于2002年，专门致力于确保各种Web服务实现的互操作性。WS-I发起了若干工作组（working groups）以解决Web服务规范之间的不兼容性。WS-I提出了一些称作概要（profile）的规范（这些规范为其他规范提供了公共的解释），并为Web服务厂商提供了用以确保符合WS-I规范的测试工具。

l IETF（Internet Engineering Task Force，因特网工程任务组）——负责定义和维护基本的Internet规范，如TCP/IP、SSL/TLS等。这些规范与Web服务的关系不是那么直接。TCP/IP是用于HTTP传输的最常见的通信协议，Web服务中会用到基本的IETF安全机制。IETF与W3C共同协作进行XML Signature规范的制订。

l JCP（Java Community Process，Java社团过程）——由Sun公司创建，致力于促进Java的普及并控制其发展。JCP主导着多个Java Specification Requests（JSRs），JSRs为Web服务定义各种Java APIs，例如用于SOAP Java绑定的JAX-RPC、用于XML数据绑定的JAX-B以及用于WSDL的Java APIs等。

l OMG（Object Management Group，对象管理组织）——最初致力于创建和促进CORBA（Common Object Request Broker Architecture，通用对象请求代理体系结构）规范，OMG主导着定义WSDL到C++以及CORBA到WSDL的映射的规范。

Web服务的标准化进程自SOAP 1.1规范于2000年年中提交给W3C开始拉开序幕。之后，带附件的SOAP（SOAP with Attachmens）、XKMS、WSDL等也被提交给W3C。与此同时，一个非公开组织提出了UDDI，而后UDDI被提交给OASIS。其他提交给 OASIS的主要规范包括：WS-Security、WS-BPEL、WS-CAF及WS-Notification等。最近，WS- Addressing和WS-Policy也被提交给了W3C，这表明W3C又恢复了成为多数主要规范的大本营的势头。

ebXML系列规范也出自OASIS，这些规范与Web服务规范栈有很大程度的重合。Web服务和ebXML都用到了SOAP，但除此以外，它们的规范栈别无相似之处。ebXML有自己的注册库（registry）和自己的Web服务编制（orchestration）语言。

[B][/B]
Standardization and Intellectual Property Rights
标准化与知识产权
Web服务的标准化面临着一个困难，即没有哪个单独的标准化组织真正处于明显的

领导地位。W3C、OASIS、WS-I、IETF和 OMG等瓜分了Web服务规范的制订。这样的话，规范何以成为一个被采纳的标准？如果有人能为此提出一种有效的解决办法，无疑他将会成为百万富翁。市场的接受和采纳将最终导致差异，这表明：在厂商的投入程度和赢得用户方面，经济因素是至关重要的。Web服务厂商们常常先在小规模的团队中非正式地启动规范制订工作，以快速完成规范的制订，然后自行发布规范，接着再将规范提交给某个标准化组织。Microsoft的SOAP 1.1就是这样炮制出来的，其他厂商（诸如BEA、HP、IBM、IONA、Oracle、SAP、Sun、Tibco和WebMethods等）也都通过这种方式推出了很多规范。然而，在向标准化组织提交规范的时候，这种规范制定方式存在的一个重要问题就突显出来了。具体来说就是：必需要解决知识产权相关的问题（包括版权和专利等）。这是规范制定过程中的重要步骤，即使标准化组织未对被提交的规范做多少改动。规范只有被提交给某个开放的标准化组织，并且解决了知识产权问题（至少在公开声明上看起来是这样），这个规范才有可能被真正地广泛采纳。不经过这一步，非最初参与规范制订的软件厂商们将难以获知规范的变动，这会令它们在产品（如果是基于该规范的话）中的投入作废，并且还要面对可能产生的知识产权许可费（使用费或其他形式的费用）的问题。

Specification Composability

规范的可组合性

前面提到过，SOAP和WSDL规范在设计时就预留了扩展点，以备添加补充特性的需求。多个补充规范可以在一个SOAP报头（SOAP header）中组合。下面是一个例子：

<S:Header>

<wsse:Security>

...

</wsse:Security>

<wsrm:Sequence>

...

</wsrm:Sequence>

</S:Header>

在这个例子中，SOAP报头中增加了对安全性（security）和可靠性（reliability）的扩展。安全性报头（security header）中一般包含安全令牌（security token）（可用于确保消息来自受信源（trusted source））等信息。可靠性报头（reliability header）中通常包含一个消息ID和顺序号，用以确保消息（或一组消息）被可靠地收到[[8]]。

可以注意到，上面的示例代码中为安全性和可靠性报头分别使用了不同的命名空间（namespace）[[9]]：wsse: 和wsrm: 。这样做，是为了避免可能产生的命名冲突。在一个XML文档中，不允许同一名称的元素或属性具有两种类型，而SOAP消息是一个XML文档，因此必须遵从这一规定。命名空间前缀（namespace prefixes）为元素名称（element names）和属性名称（attribute names）提供了唯一的限定符（unique qualifier），因此避免了名称冲突。命名空间保证了各种对SOAP报头的扩展不会相互影响。

增加补充特性不一定需要对现有Web服务进行修改——更确切地说，在许多情况下，可以把补充特性加入到SOAP报头（SOAP header）中，而不必修改SOAP主体（SOAP body）。不过，对执行环境和映射层（mapping layers）的修改可能是必要的。当然，在对SOAP报头进行扩展时，必须确定执行环境是否支持、以及如何支持该扩展；否则，对SOAP报头的扩展将不起作用。

对Web服务的扩展增加了执行环境中SOAP处理器（SOAP processors）的职责。在生成SOAP消息的过程中，可以利用与WSDL契约（WSDL contracts）关联的策略断言（policy assertions）来确定是否要在SOAP报头中加入某些信息，以帮助执行环境选用恰当的传输协议或约定诸如事务协调（transaction coordination）之类的特性。

如图1-12所示，为Web服务调用增添各种补充特性的结果，是增加了在发出消息

之前和收到消息之后的额外处理。后面章节中将对这些补充特性作更详细的介绍。这些补充特性可能会与某个业务流程引擎的需求相关，而且还可能需要注册库（registry）的支持。

图1-12 为SOAP增加补充特性

Composibility and Complexity

可组合性与复杂性

可以想象，补充的Web服务规范之间的可组合性（composability），令它们可以逐渐使用或发现新的概念与特性。作为Web服务规范开发的事实领袖，IBM和Microsoft显然希望避免 Web服务规范过于庞杂。Web服务的价值很大程度上来自于其相对简单性。CORBA就是因为过于复杂和难于使用，而常受到批评。当然，CORBA比它之前的技术

要简单一些，但相对于Web服务来说，则仍显得复杂。复杂性（complexity）的解决办法在于：需要具有足够本领来有效地利用技术的人。而IT成本的最大部分在于人力方面，因此复杂性通常意味着需要更大的项目开支。为了让Web服务遵守承诺，IBM和Microsoft希望在为基本的Web服务规范增添复杂特性时，能够保持其简单性。有人认为Web服务就是用于支持聚合各种新特性的，因此可以扩展现有的应用，而不必修改它。然而，这只是一个未经验证的断言，因为完全实现了各种补充规范的产品尚未问世，而且还根本不清楚是不是在产品中将以同样的方式来实现这些补充特性。另外，还没有一个完整定义了这些补充特性如何共同工作的Web服务架构。还有，如果你收到了一个SOAP消息，其中包含有安全性、可靠性及事务性等报头，你会先处理哪一个？安全性报头，还是可靠性报头？或者事务性报头？确实没人知道。如果觉得这些过于复杂，人们可以回过头来使用XML over HTTP这种最简单的方式，并对这些扩展进行手工编码（hand code）。

Metadata Management

元数据管理

Web服务中的元数据（metadata）是关于Web服务的描述信息，这些描述信息用于构造消息主体（body）（包括数据类型和结构）和报头（header），服务请求者需要根据这些描述来调用服务。服务提供者发布元数据（metadata）；服务请求者发现元数据，并据此构造可被服务提供者正确处理的消息。

在进行服务调用时，不仅要发送数据类型和数据结构，还要发送关于补充服务质量的信息，比如安全性、可靠性、事务性等信息（如果有的话）。如果消息中缺少某些这类信息，消息处理可能会失败。

元数据规范包括：

l XML Schema——用于定义消息中的数据类型与数据结构，用于表达策略信息。

l WSDL[10]——用于将消息和消息交换模式（Message Exchange Patterns，MEPs）与服务名称及网络地址相关联。

l WS-Addressing——用于包含与端点相关的端点寻址属性（endpoint addressing properties）和端点引用属性（endpoint reference properties）。许多其他补充规范需要WS-Addressing来支持定义通信模式中的端点寻址与端点引用属性。

l WS-Policy——用于将服务质量（quality of service）需求与WSDL的定义相关联。WS-Policy是一个包含安全性、可靠性、事务性等策略断言的框架（framework）。

l WS-MetadataExchange——用于查询和发现与Web服务关联的元数据，包括获取WSDL文件及相关WS-Policy定义的能力。

基于Web服务的SOA在服务绑定（service binding）上与基于J2EE或CORBA的SOA有所不同。Web服务是通过服务发现（可以是动态的），而不是通过引用指针或名称进行绑定的。如果服务请求者能够理解服务提供者给出的WSDL及相关联的策略文件，那么服务请求者便可动态生成SOAP消息，以执行提供者的服务。所以，各种元数据规范，对于基于Web服务的SOA的正确执行来说，是至关重要的。

寻址（Addressing）
寻址（Addressing）是补充的Web服务规范的重要需求之一，因为Web上不存在Web服务端点地址（endpoint address）的目录。在几乎所有的消息交换模式（MEPs）中（除去那些最简单的），SOAP消息中都必须包含端点地址信息。WS- Addressing取代了之前提出的WS-Routing和WS-Referral。

如果没有寻址方案，在服务提供者收到你发送的Web服务请求时，一般只知道一个地址，即请求者的返回地址，而该地址是仅在当前会话（session）期间有效的。回复过

程中一旦发生错误，将无法进行重试——基本上，一旦发生通信错误，请求者的地址就丢失了。

并且，也没有一种用于指定“除请求者地址以外的其他返回地址”的好方案。最终的结果是，无法为复杂的消息交换模式（MEPs）或多传输（multi-transport）[[11]]定义地址规划（address schemes）或标识端点地址（endpoint addresses）。

策略（Policy）
策略（policy）在表达Web服务的补充特性时是必要的。有了策略，请求者便可对Web服务的安全性、事务性及可靠性作出规定，而不是仅在WSDL文档中提出关于消息的数据需求。

服务提供者可以用一组机器可读的（machine- readable）的断言（assertion）来表达策略,并向服务请求者提出：必须符合这些断言才能调用其服务。服务是否对安全性有要求？是否支持事务性？对于运行时间长而且复杂的交互，断定它是否支持事务、或者事务能否跨越多个Web服务是非常重要的。

WS-Policy对于实现补充特性的互操作来说是必要的，因为策略断言是请求者唯一能够用以确定“提供者是否要求某些或全部补充特性”的方式。以安全性为例，各个服务提供者支持的安全令牌（security token）种类（比如X.509或Kerberos等）会有所不同。WS-Security是一种能够携带任何令牌类型的开放框架。但是，如果提供者没有声明它所期望的令牌类型，请求者便无法确信提供者的要求是什么。

服务请求者在决定要调用提供者的服务时，确定提供者是否支持可靠性或事务性也是很重要的。比如，也许你想知道提供者的服务是否支持在提交失败后重试，以及是否会在成功接受消息后发送确认消息。最后，你可能还想知道是否要向服务提供者发送一个事务上下文（transaction context），以便提供者的服务加入事务。

获取元数据（Acquiring Metadata）
请求者将用WS-MetadataExchange或其他类似机制，直接查询WSDL及其相联的策略文件，以获取它所需要的元数据（metadata）。WS-MetadataExchange使用了WS- Addressing中的一个叫做“活动（action）”的特性来访问服务提供者发布的元数据。WS-MetadataExchange用于提供关于 Web服务描述的任何信息——在大多数应用中，它基本上可以代替UDDI了。

开发者是否使用UDDI是不一定的。补充Web服务规范之间的互操作，需要相关的元数据管理机制的支持，而公共的UDDI没有提供这样的机制，而且请求者可能需要WS-MetadataExchange来确保它们拥有与提供者进行补充特性的互操作所需的信息。

Security

安全性

在Web服务规范栈的每一层都涉及安全性（security）问题，安全性需要利用各种机制来预防分布式计算过程中的各种挑战与威胁。在某些特定威胁或多种威胁组合的情况下，需要将这些机制加以组合才能得以预防。在Web服务和SOA中，评估是否需要在网络层、消息层以及对消息中数据进行保护是特别重要的。

基本的安全性保护是建立在加密（encryption）、认证（authentication）和授权（authorization）机制之上的，而且通常还要进行问题跟踪的详细记录。业界已在WS- Security这一规范框架上取得了一致，虽然仍有一些工作正在进行之中。

WS-Security用于为Web服务消息提供端到端（end-to-end）的消息层安全性。常见的基于HTTP的安全机制（比如SSL）仅为传输层提供点对点（point-to-point）的保护。有时通过使用其他传输映射（比如CORBA的IIOP或WebSphere MQ等）也可以获得额外的安全性；但是正如其余的补充特性那样，Web服务安全规范是针对HTTP这一缺省

的、用于大多数情况的传输协议而制订的，它可以很容易地应用于其他传输协议。

WS-Security报头（headers）可以包含像 Kerberos票据（tickets）和X.509证书（certificates）这样的强身份认证（strong authentication）格式，也能使用XML Encryption和XML Signature技术对消息内容作进一步保护。尽管用于安全断言标记语言（Security Assertion Markup Language，SAML）的WS-Security授权概要（authorization profile）还在开发之中，SAML仍可独立用于授权信息的交换中。

IBM、Microsoft及Verisign等公司另外提出了一些对WS-Security作进一步扩展和补充的规范，比如：

l WS-SecurityPolicy——通过定义安全断言（security assertions）对Web服务的需求作详细描述，以供服务请求者参照。

l WS-Trust——定义如何通过从受信源（trusted sources）处获取必要的安全令牌（security tokens）（例如Kerberos票据），对安全系统建立整体的信任。

l WS-SecureConversation——定义如何为一个安全会话（secure session）建立和维护持久的上下文，以便对Web服务进行多次调用、而不必每次都进行大开销的身份认证。

l WS-Federation——定义如何创建跨越多个安全区域（security domains）的联合会话（federated session），以便在经过单次身份认证后即可使用部署在多个安全区域内的Web服务。

由于Web服务都是XML应用，而XML自身存在着安全问题（XML是以人类可读的文本在Internet上发送的），因此，用基于XML的安全技术来保护装入SOAP消息之前和之后的XML数据也是很重要的。这些技术包括：

l XML Encryption——通过使用各种受支持的加密算法，来提供部分或全部XML文档的机密性（confidentiality），以确保文档内容不会被窃听或被未授权的人读取。

l XML Signature——通过使用各种加密和签名机制来提供完整性（integrity），以确保服务提供者能够确定文档有没有在传输过程中被修改，并确保文档被收到且只收到一次。

XML Encryption和XML Signature既用于保护Web服务的元数据，也用于保护Web服务的数据。

Reliability and Messaging

可靠性与消息传递

消息传递（messaging）包括SOAP以及它的各种消息交换模式（Message Exchange Patterns，MEPs）。在高级的消息传递方面，尚无统一的规范集合被业界认可，这里就不介绍了。而可靠性与消息通知方面的各个规范，本质上工作方式相同，因此这里将二者混合起来进行介绍。

一般来说，可靠的消息传递（reliable messaging）是保证一个或多个消息被收到正确次数的机制。可靠的消息传递规范包括：

l WS-Reliability

l WS-ReliableMessaging（由IBM和Microsoft等制订）

可靠的消息传递用于确保SOAP消息（SOAP messages）可以在不可靠的网络（比如基于HTTP的Internet）上进行可靠的递送。

可靠的消息传递是一种用于进行有保证的递送（guaranteed delivery）、无重复的、消息次序正确的SOAP消息交换协议。可靠的消息传递的原理是：为一组消息设定相同的ID，根据消息号将消息编组，并依据顺序号进行排序。

有了可靠的消息传递，便可自动从某些传输层的错误状态中恢复；如果没有可靠的消息传递，应用必须自己解决这类问题。可靠的消息传递还支持在Internet上衔接两种不同的私有消息传递协议。

在一般的消息传递领域也有一些扩展的消息交换模式（MEPs）规范，比如事件通知（event notification）、事件发布/订阅（event publish/subscribe）等，它们基本上扩展了Web服务的异步消息传递能力。这类规范包括：

l WS-Eventing

l WS-Notification

通知（notification）通过一个常被称作消息代理（message broker）或事件代理（event broker）的媒介（intermediary）进行消息递送。订阅者（subscriber）确定它们希望收到消息的通道（channels）或感兴趣的消息主题（topics），发布者（publisher）将发送消息到订阅者正在侦听的通道或主题。通知（notification）是一种可用来进行广播和发布/订阅的消息传递机制。

Transactions

事务

事务（transctions）指的是：对持久数据（persistent data）的多个操作，要么全部完成，要么什么都不做，就像处理订单或资金转移那样。事务处理技术中最重要的一个方面是：在遇到操作系统或硬件故障之后，将应用恢复到某个已知状态的能力。例如：如果在一次资金转移操作完成（即借记操作和贷记操作都已完成）前发生了一个错误，事务应确保银行账户的余额状态与该资金转移操作开始之前一样。

有些Web服务应用可能只需要下层执行环境的事务处理能力，比如应用服务器和数据库所提供的事务性。而另一些Web 服务应用则要将多个Web服务调用（Web service invocations）及SOAP报头中的事务上下文（transactional context）组成为一个更大的事务性单元（transactional unit），以便进行跨越多个执行环境的事务协调。

Web服务事务规范扩展了事务协调器（transaction coordinator）的概念，为Web服务修改了通用的两阶段提交协议（two-phase commit protocol），并为更加松耦合的Web服务及编制流（orchestration flows）定义了扩展的事务协议。目前大多数执行环境（比如J2EE、.NET框架、CORBA等）中都有事务协调器。Web服务规范为这些（及其他）协

调器定义了扩展，以便用于基于补偿的（compensation-based）协议和衔接不同软件领域的协调器间（coordinator-coordinator）协议。

协调（coordination）是一种为合成的Web服务应用确定一致的、预定义结果的通用机制。协调器模型（coordinator model）包括两个主要阶段：第一阶段为获取阶段，参与合成的Web服务各自向协调器登记一个特定的协议（比如两阶段的提交、补偿或业务流程等）；在第二阶段，当参与合成的各个服务分别执行结束后，协调器启动约定好的协议来完成事务。如果发生错误，协调器应启动恢复协议（recovery procotol）（如果有的话）。

Web服务的事务规范包括：

l BEA、IBM和Microsoft提出的WS-Transactions规范系列：

? WS-AtomicTransactions——为短期执行的业务流程定义了两种两阶段提交协议（two-phase commit protocol，2PC）：易失的两阶段提交（Volatile 2PC）和持久的两阶段提交（Durable 2PC）。

? WS-BusinessActivity——为长期执行的业务流程定义了基于试验提交和基于补偿（compensation-based）的撤销协议。

? WS-Coordination——定义了用于上述两个可挂接的协议（pluggable protocol）的协调器。

l OASIS的WS-Composite Application Framework（WS-CAF）：

? WS-Context——定义了一个独立的、用于一般上下文（即用于非事务协议上下文，如安全、设备、网络ID或数据库及文件ID等）的上下文管理系统。

? WS-CoordinationFramework——为基本的上下文规范和WS-TransactionManagement中的可挂接事务协议（pluggable transaction protocol）定义协调器。

? WS-TransactionManagement——定义了三个可挂接到WS-CoordinationFramework中的事务协议：ACID，Long-Running Actions（LRA）和业务流程管理（BPM）。

上述两个规范系列都以一种支持挂接的协调器为中心。它们都定义了原子事务（即两阶段提交）和基于补偿的事务。WS-CAF将上下文管理作为单独的规范，并增加了一个专门用于业务流程管理（BPM）的事务协议。

Orchestration

Web服务编制

Web服务最终将被发布用于给定IT环境中的大多数软件系统和应用，并要跨越多个组织的IT环境。在具有异常处理、分支和并行执行的长期运行的（long-running）业务流程流中，可以用编制引擎（orchestration engine）创建较复杂的交互模式，而不是令Web服务用SOAP和WSDL支持下的一种或多种消息交换模式（MEPs）进行彼此调用。但是要实现这一点，编制引擎必须保持上下文，并提供多个服务之间的关联机制。

可以将Web服务编制本身作为Web服务来发布，通过它提供封装一组其他Web服务的接口。通过使用MEPs的组合以及编制机制，整套应用可以由不同封装层次的（从封装单个软件模块的，到封装复杂的Web服务流的）Web服务建立起来。

业界已经对OASIS的Web服务编制规范WS-BPEL 取得了一致的认同。WS-BPEL（Web Services Business Process Execution Language，Web服务业务流程执行语言）假定Web服务是用WSDL与策略断言定义的。

通常，一个流程流因某个XML文档的到达而启动。所以，在对流程流的入口点进行建模时，往往采用面向文档式的Web服务（document-oriented Web services style）。通常，流程流中的各个任务需要取文档中的不同部分加以操作（比如检查不同供货商的库存量）。这意味着，流程流中的各个步骤可以通过组合请求 /响应（request/response）与面向文档的Web服务来实现。

WS-BPEL规范与其他扩展规范的不同之处在于，它所定义的是一种可执行的语言，而且能够与各种促使业务流程自动化的软件系统相兼容。Web服务编制，通过说明性的（declarative）方式（而不是编程的方式）表达了进行Web服务合成的需求；而其他的Web服务规范，则大多是用XML来表示现有各种对SOAP报头进行扩展的分布式计算功能及特性。

W3C的Web服务编排定义语言（Web Services Choreography Definition Language，WS-CDL）是Web服务编制领域的另一个规范。编排（choreography）被定义为在多个外部交易伙伴之间建立形式化关系。 WS-CDL与WS-BPEL的区别之一是，前者不要求所有被集成的端点（endpoints）都有Web服务基础设施（infrastructure）。

Strategic Value of Orchestration

Web服务编制的战略价值

有人说，Web服务编制即Web服务获取战略价值的所在。 Web服务有其内在价值，因为开发人员可以相对轻松地解决不同类型软件间的互操作问题。Web服务编制可以各种不同的方式使用：从创建合成服务，到创建成熟的业务流程管理。为BPM使用Web服务编制显然是较困难的，因为它要求对企业的业务流程有较深入的理解。总之，人们总期望能够在编制层找到解决困难问题（比如数据类型与结构的不兼容，数据的语义匹配，及关联多个Web服务的执行结果等）的解决方案。要证明这些问题是否能够在编制层得到解决、自动化业务流程管理是否正是各机构所想要或需要在部门和企业级配置的，还需要时间来证明。

我们已经看到，目的并不是SOA本身，而只是起点——它是通向更优的IT环境的一套规划与指导；它是一种基础设施的规划，这种基础设施不但可以确保IT与业务一致，而且可以通过资产（assets）的重用、快速应用开发及多渠道服务减少开销。

Web服务的核心标准已经取得了初步成功，下一步是要定义各种补充的特性与功能，以支持越来越多的应用种类。

面向服务（service orientation），提供了一种与面向对象不同的思考角度与方式。从面向过程的计算到面向对象的计算是一个意义重大的转变，到SOA的转变也同样具有重大意义。服务并不是要取代其他技术，而是一种补充技术。它尤其适合于解决多种执行环境（比如面向对象的、面向过程的及其他系统）间的互操作性。