Web服务体系结构及其规范简介MicrosoftLearn

Envelope是SOAP消息的根元素，包含可选的Header元素和必需的Body元素。Header元素是一种通用机制，用于以分散的方式向SOAP消息添加功能。Header的每个子元素称为标头块，SOAP定义了几个已知属性，这些属性可用于指示谁应处理标头块(角色)，以及处理该标头是可选还是强制(必须了解)，如下所述。如果存在，Header元素始终是Envelope的第一个子元素。Body元素始终是Envelope的最后一个子元素，并且是“有效负载”的容器，用于邮件的最终接收者。SOAP本身没有定义内置标头块，并且只定义一个有效负载，这是用于报告错误的Fault元素。

所有Web服务消息都是充分利用XMLInfoset的SOAP消息。消息有效负载和协议标头采用同一模型这一事实可用于确保基础结构标头和应用程序正文的完整性。应用程序可以根据标头的内容和消息内的数据来路由消息。为XML数据模型开发的工具可用于检查和构造完整的消息。这些优势在DCOM、CORBA和RMI等体系结构中不可用，其中协议标头对应用程序而言基础结构详细信息不透明。

SOAP消息从发送方单向传输到接收方。可以将多个单向消息组合成更复杂的模式。例如，常用的模式是消息的同步请求/响应对。

发送或接收消息的任何软件代理称为SOAP节点。执行消息初始传输的节点称为原始发送方。使用和处理消息的最终节点称为最终接收方。处理原始发送方和最终接收方之间的消息的任何节点称为中间方。中介用于为单个消息的分布式处理建模。消息和最终接收方遍历的中间节点集合统称为消息路径。

SOAP信封的正文始终以最终接收方为目标。相比之下，SOAP标头可能针对中介或最终接收方。为了提供用于处理消息的安全且可版本控制的模型，SOAP定义了三个属性，用于控制中介和最终接收方如何处理给定标头块-角色、中继和mustUnderstand。角色属性用于标识标头块的目标节点。mustUnderstand属性指示如果未识别该节点，该节点是否可以忽略标头块。标记为mustUnderstand=“true”的标头块称为强制标头块。标记为mustUnderstand=“false”或没有mustUnderstand属性的标头块称为可选标头块。中继属性指示该节点是应转发无法识别的可选标头还是放弃它们。

每个SOAP节点都必须使用这三个属性来实现SOAP处理模型。以下步骤定义该模型：

SOAP处理模型旨在允许扩展性和版本控制。mustUnderstand属性控制引入新标头块是中断性变更还是非中断性变更。添加可选标头块(例如，标记为mustUnderstand=“false”)的标头是非中断性变更，因为任何SOAP节点都可以随时忽略它。添加强制标头块(例如，标记为mustUnderstand=“true”)的标头是一项中断性变更，因为只有知道标头块的语法和语义的SOAP节点才能处理消息。角色和中继属性使用mustUnderstand组合，以沿消息路径分布此处理模型。

SOAP提供的消息传送灵活性允许服务使用各种消息交换模式进行通信，从而满足分布式应用程序的要求。我们在体系结构的核心构建基块中利用了其中几个。事实证明，多种模式在分布式系统中特别有用。例如，远程过程调用的使用普及了同步请求/响应消息交换模式。当消息传送延迟不受控制时，需要异步消息传送。使用异步请求/响应模式时，显式消息关联变得是必需的。

广播传输普及了一对多消息传输。原始发送方通过仅发送收件人来将其消息强加于收件人，称为推送模型。虽然此模型在局域网中有效，但它不能很好地扩展到广域网，也不会为接收方提供调节消息流的选项。

当接收方显式请求来自源的消息时，将使用拉取模型。这使得消息流成为收件人的责任。拉取模式还可以与发布/订阅结合使用。它非常适合接收者可能间歇性地与源断开连接的情况。

SOAP独立于使用中的基础消息传送传输机制进行定义。它允许使用许多替代传输进行消息交换，并允许同步和异步消息传输和处理。

由于Web服务协议设计为完全独立于基础传输，因此选择适当的机制可以推迟到运行时。这使Web服务应用程序能够灵活地在发送消息时确定适当的传输。此外，当消息在节点之间路由时，基础传输可能会更改，同样，为每个跃点选择的机制可能会根据需要变化。

尽管具有一般传输独立性，但大多数第一代Web服务都使用HTTP进行通信，因为这是SOAP规范中包含的主要绑定之一。HTTP使用TCP作为其基础传输协议。但是，TCP的设计引入了处理开销，这并不总是必要的。几种应用程序协议模式更匹配用户数据报协议或UDP[UDP]的语义。这些模式对于设备和其他资源受限的系统特别有用。

UDP没有TCP的传递保证;它提供尽最大努力的数据报消息传送。实现它所需的资源也比TCP少。此外，UDP提供多强制转换功能，允许发送方同时将消息传输到多个收件人。将SOAP消息绑定到UDP的规范在SOAP-over-UDP[SOAP-UDP]中发布。

对于在此多传输世界中路由和寻址的消息，需要一种通用机制，以便在多个传输中传递关键消息属性。WS-Addressing规范为此定义了三组SOAP标头块。

Action标头块用于指示消息的预期处理。此标头块包含一个URI，最终收件人通常使用该URI来调度消息进行处理。

MessageID和RelatesTo标头块用于标识和关联消息。MessageID和RelatesTo标头使用简单的URI来唯一标识消息，通常这些URI是暂时性的UUID。

To/ReplyTo/FaultTo标头块用于标识要处理消息及其答复的代理。这些标头依赖于名为终结点引用的WS-Addressing定义的结构，该结构将正确处理SOAP消息所需的信息捆绑在一起。

终结点引用是WS寻址的最重要方面，因为它们支持更精细的寻址，而不仅仅是URI。它们在整个Web服务体系结构中广泛使用。终结点引用包含三个关键信息：基址，以及可选的引用属性和引用参数集。基址是用于标识终结点的URI，显示在针对该终结点的每个SOAP消息的To标头块中。引用属性和引用参数是任意XML元素的集合，用于通过为消息提供额外的路由或处理信息来补充基址。它们表示为文本标头元素。使用终结点引用为终结点构造消息时，发送方负责将所有引用属性和引用参数作为标头块包含。

引用属性和引用参数之间的区别在于它们与服务元数据的关系。Web服务的策略和协定仅基于其基址和引用属性。通常，基址和引用属性标识给定的已部署服务，引用参数用于标识该服务管理的特定资源。

引用属性和参数只是不透明的XML元素，预期仅由最终接收方处理。它们有助于确保可用于调度、路由、索引编制或其他发送方处理活动的信息包含在给定的消息中。虽然预计中介不会处理此信息，但某些中介（例如防火墙或网关服务）可能会使用某些参考属性或参数进行消息路由和/或处理。

具体而言，引用属性还有助于对共享通用URL和范围的WSDL实体集合进行寻址。WSDL是一种XML格式，用于将Web服务描述为对消息操作的一组终结点，它首先抽象地指定其实体，然后将其具体绑定到特定实例。具体而言，消息和操作是抽象定义的，然后绑定到具有网络传输和消息格式信息的终结点。因此，从WSDL的角度来看，当以不同的具体实体（如输入或输出消息、portType绑定、端口或使用通用URL的Web服务中的服务）为目标时，相应的终结点引用的引用属性应有所不同。元数据部分更详细地介绍了WSDL。

参考参数的两个使用示例是基础结构和应用程序级。引用参数的基础结构示例可以是发送到事务处理监视器的事务/登记ID。在书籍购买方案中，书籍的ISBN编号可以是引用参数的应用程序级示例。

所有Web服务交互都是通过交换SOAP消息来执行的，如上一部分所述。为了提供可靠的开发和操作环境，将使用计算机可读元数据描述服务。元数据可实现互操作性。Web服务元数据有多种用途。它用于描述服务可以支持的消息交换格式，以及服务的有效消息交换模式。元数据还用于描述服务的功能和要求。这种最后一种形式的元数据称为服务的策略。消息交换格式和消息交换模式以WSDL表示。策略使用WS-Policy表示。协定使用上述所有三种元数据表示。协定是一种抽象，可将应用程序与其所依赖的服务的内部实现细节隔离开来。

WSDL指定请求消息必须包含的内容，以及响应消息在明确表示法中的外观。WSDL文件用于描述消息格式的表示法基于XML架构。这意味着它既是编程语言中性的，也是基于标准的，这使得它适合描述可从各种平台和编程语言访问的服务接口。除了描述消息内容之外，WSDL还可以定义服务可用的位置以及用于与服务通信的通信协议。这意味着WSDL文件可以指定编写程序以与Web服务交互所需的基元素。有多种工具可用于读取WSDL文件并生成为Web服务生成语法正确的消息所需的代码。

虽然WSDL是一个很好的起点，但不足以描述Web服务的所有方面。WSDL只允许表示一个相当小的属性集。Web服务所需的更多详细信息的示例包括：

第一代Web服务必须使用专有协议在带外交换元数据。此问题通过WS-Policy[WS-Policy]得到解决。WS-Policy提供通用模型和语法来描述和传达Web服务的策略。它指定一组基本构造，可供其他Web服务规范使用和扩展，以描述广泛的服务要求和功能。WS-Policy引入了一种用于表达策略断言的简单且可扩展的语法，以及用于解释这些断言的处理模型。断言可以合并为逻辑替代项。

单个策略断言可以分组以形成策略替代项。策略是策略替代项的集合。为了促进互操作性，根据策略的XMLInfoset表示形式来定义策略。定义策略的精简窗体是为了在保持互操作性的同时减小策略文档的大小。

策略用于传达两个Web服务终结点之间交互的条件。满足策略中的断言通常会导致反映这些条件的行为。因此，策略断言评估是识别兼容行为的核心。仅当请求者满足要求或容纳与断言对应的功能时，请求者才支持策略断言（策略的构建基块）。通常，此确定使用特定于域的知识。当且仅当请求者支持替代项中的所有断言时，请求者才支持策略替代项。这是使用策略断言的结果机械地确定的。此外，当且仅当请求者支持策略中的至少一个替代项时，请求者才支持策略。一旦评估了政策替代方案，这一决定也是机械的。请注意，尽管策略替代项是互斥的，但一般情况下无法决定是否可以同时支持多个替代项。

为了以可互操作的形式传达策略，策略表达式是策略的XMLInfoset表示形式。普通窗体策略表达式是最直接的Infoset;等效的备用信息集允许通过多个构造紧凑地表达策略。策略表达式是策略的基本构建基块。两个运算符用于表示其断言：All和ExactlyOne。All运算符指定必须保留策略替代项集合中的所有断言才能满足策略断言。ExactlyOne运算符指定必须保留策略替代项集合中存在的断言之一才能满足策略断言。

WS-Policy和WS-PolicyAttachment的组合提高了以编程方式发现其他服务支持的策略和原因的能力。灵活地添加策略是对描述消息交互的WSDL信息的重要补充。

WSDL和WS-Policy都定义了元数据的格式，但没有指定获取或访问给定服务的元数据的机制。通常，可以使用各种技术发现服务元数据。为了使服务能够自描述，Web服务体系结构在WS-MetadataExchange[WS-MEX]中为元数据定义了基于SOAP的访问协议。GetMetadata操作用于检索在请求的终结点引用中找到的元数据。Get操作类似，但旨在检索元数据节中引用的元数据，并且将在存储它的终结点引用处检索。

使用WS-MEX交换的元数据可以描述为资源。资源定义为终结点引用可寻址的任何实体，其中实体可以提供自身的XML表示形式。资源构成了在Web服务中构建状态管理所需的基础。

什么是互操作性配置文件？

配置文件是一组准则，用于在核心协议之外使用Web服务规范。由于规范的常规用途设计，这些准则是必要的。在某些情况下，开发人员需要其他帮助来确定应使用哪些Web服务功能来满足特定要求。互操作性配置文件还解决了Web服务规范不够明确以确保所有实现以相同方式处理SOAP消息的领域中的歧义。

WS-I基本配置文件

第一个Web服务配置文件由WebServices-Interoperability组织(WS-I)[WS-I]发布。WS-I已敲定其第一个配置文件，其标题为基本配置文件1.0[WSI-BP10]。此配置文件主要提供有关SOAP1.1和WSDL1.0的可互操作使用的指导。

本部分介绍Web服务体系结构中用于为系统内服务联合提供消息完整性、身份验证和机密性、安全令牌交换、消息会话安全性、安全策略表达式和安全性的规范。提供这些功能的规范包括WS-Security、WS-Trust[WS_Trust]、WS-SecureConversation[WS-SecureConv]、WS-SecurityPolicy[WS-SecurityPolicy]和WS-Federation[WS_Federation]。

安全性是计算机系统的一个基本方面，尤其是由Web服务组成的系统。安全性必须可靠且有效。由于系统只能对消息格式和合法消息交换做出硬连线假设，因此必须基于明确、商定的机制和假设来构建安全性。安全基础结构还应足够灵活，以支持不同组织所需的各种安全策略。

当通信Web服务（例如安全套接字层(SSL)和传输层安全性(TLS)）之间提供安全传输时，可以简化安全解决方案的生成。通过安全传输，服务无需担心维护单个邮件的完整性和机密性：它们可以依赖于基础传输。但是，现有的传输级别安全性是一种仅限于点到点消息传递的解决方案。如果使用安全传输时存在中介，则初始发送方和最终接收方需要信任这些中介来帮助提供端到端安全性，因为每个跃点都是单独保护的。除了对所有中介的显式信任外，还必须考虑其他风险，例如消息的本地存储以及中介可能遭到入侵。

尽管Web服务的安全要求很复杂，但没有发明新的安全机制来满足基于SOAP的消息传送的需求。分布式系统安全的现有方法，如Kerberos票证、公钥加密技术、X.509[X509]证书等已证明已足够。只有将这些现有安全方法应用于SOAP才需要新机制。这些新的安全协议在设计时考虑到了扩展性，以便将来能够合并新方法。主要设计目标是为为SOAP和Web服务体系结构的其余部分设计的自描述安全属性提供机制。

使用各种方法来创建安全令牌。Web服务可能基于本地信息生成自定义安全令牌。或者，可以从专用服务（如X.509证书颁发机构或Kerberos域控制器）检索安全令牌。若要自动执行服务之间的通信，需要一种表达安全要求的机制。

附录C中所述的常见安全攻击包括系统威胁的基本分类，在选择Web服务安全功能时应仔细考虑这些威胁。

本部分的其余部分将探讨Web服务安全模型的应用。两个关键主题是保护通信和保护应用程序。不假定使用安全消息传输，也不需要安全Web服务。

消息级安全性是实现端到端安全性的关键构建基块。使用消息级安全性时，不需要传输级别安全性。消息级别安全性的要求包括消息完整性、消息身份验证和机密性。消息完整性可确保在没有检测的情况下无法更改消息。使用XML签名[XMLSIG]可确保可以检测到消息修改。

消息身份验证标识发送消息的主体。如果使用公钥加密，则可以确定主体的唯一标识。将公钥加密与受信任的源认证的密钥结合使用可提供此身份验证。但是，如果使用对称密钥加密，则情况并非如此-只能识别知道共享机密的主体组。

XML文档可以视为字符串字符。逐字符比较是关键的安全操作，例如XML签名。一个字符的差异是不同的结果。序列化是用于表示“网络上”对象的方法。例如，序列化用于创建SOAP消息的XML表示形式。消息处理软件会忽略不同序列化软件产生的任何inessentialtypographical变体，但会对安全软件产生重大影响。XML消息的Infoset表示形式可改善此问题。若要使XML签名正常工作，必须将消息转换为所有各方一致的XML表单。规范化是一个术语，用于描述用于生成非关键信息（例如换行符、制表符空格、属性顺序和结束标记样式）的一致视图的方法。签名包括规范化方法，用于使邮件收件人能够以与发件人一致的方式处理安全信息。服务使用的特定规范化方法是放置在WSDLportType绑定或WSDL端口上的有用策略断言。

WS-Security规范描述了目前使用的常见安全机制，但不排除将来添加新的安全机制。由于SOAP处理模型使用标头元素来做出处理决策，因此在确定要加密SOAP消息中的哪些元素时，必须非常小心。

Web服务设计人员必须了解消息的处理方式，才能确定要加密哪些元素以及要使用哪些加密算法。当特定标头元素需要由第三方或中介处理时，这些决策更为重要。如果这些参与方不了解相应的解密数据或加密XML元素时使用的约定，则它们将无法正常运行。此外，每个处理节点必须对消息中包含的安全信息有一个共同的了解。

加密标头中的XML元素的一个自然选择是将其完全加密，将原始元素替换为加密数据类型的元素。这种简单方法存在缺点。例如，中介很难确定哪些元素必须处理(使用mustUnderstand=“1”属性)修饰的元素。此外，由于元素类型发生更改，因此很难确定其原始类型。

另一种方法是将元素转换为一个元素，其中保留正确SOAP处理所需的所有密钥属性，并将原始元素加密并放置在可分辨的子元素中。此方法的优点是即使不知道如何解密元素的中介也能实现正确的处理。此方法的缺点是，它要求各方都理解用于表示原始元素的约定。虽然WS-Security目前没有提供有关此方法的指导，但我们预计将来的工作会这样做。首选备用方法，因为它允许正确处理所有SOAP标头元素。

WS-Security的配置文件规范中介绍了多种安全令牌。配置文件是为表示用户名、X.509证书和基于XML的安全令牌的令牌开发的。基于XML的安全令牌包括安全断言标记语言(SAML)[SAML]和eXtensiblerightsMarkupLanguage/RightsExpressionLanguage(REL)[REL]。Kerberos票证的使用规范也在开发中。

WS-I基本安全配置文件

WS-I发布的最新互操作性配置文件之一是基本安全配置文件(BSP)[WSI-BSP10]。此配置文件提供WS-Security和各种安全令牌的实现指南，例如用户名[WS-SecUsername]和X.509证书令牌[WS-SecX509]。它旨在与WS-I基本配置文件进行补充和撰写。

需要安全令牌才能提供端到端安全解决方案。这些安全令牌必须直接或间接地在消息处理参与方之间共享。每个参与方还必须确定是否可以信任断言凭据。这些信任关系基于安全令牌的交换和中转以及已建立的支持性信任策略。例如，中转令牌的受信任程度取决于系统管理员及其建立的信任关系。

提供安全令牌的服务可能非常多样化。这是Web服务首先使用每个基础安全技术的位置。为了提供统一的解决方案而不考虑安全技术，新协议设计用于信任域之间的安全令牌交换。

WS-Trust[WS-Trust]通过用于请求、颁发和中转安全令牌的协议补充WS-Security。具体而言，定义了用于获取、颁发、续订和验证安全令牌的操作。该规范的另一个功能是中转新信任关系的机制。网络和传输保护机制（如IPsec或TLS/SSL）可与WS-Trust结合使用，以满足不同的安全要求和方案。

为了解决在返回或颁发安全令牌之前需要双方之间进行一组交换的情况，为验证、协商和交换指定了机制。一种称为“质询”的特定交换形式为一方提供了一种机制，以证明其拥有与令牌关联的机密。其他类型的交换包括旧协议隧道。WS-Trust定义如何在这两个示例之外扩展其他令牌交换协议的规范。

某些消息身份验证和保密机制在计算上可能很昂贵。特别是，许多加密技术消耗大量处理能力。当单独保护消息时，这些成本通常是不可避免的。但是，当两个Web服务交换多条消息时，可以使用比WS-Security中定义的方法更高效、更可靠的消息机密性方法。保护消息会话时，应使用这些基于对称加密的机制。

WS-SecureConversation[WS-SecConv]基于共享机密（例如对称加密）定义两个通信方之间的安全上下文。安全上下文在会话的生存期内在各方之间共享。会话密钥派生自共享机密，用于解密会话中发送的各个消息。安全上下文在网络上表示为新的安全令牌类型(安全上下文令牌或SCT)。

定义了在安全会话的各方之间建立安全上下文的三种不同方法。首先，安全令牌服务可能会创建它们，发起方必须提取它才能传播它。其次，其中一个通信方创建安全上下文，并在消息中将其传播给另一方。第三，安全环境是通过协商和交换建立的。Web服务选择最适合其需求的方法。

安全上下文令牌表示或包含共享机密。此机密用于对消息进行签名和/或加密。使用共享机密时，参与方可能会选择要使用的不同密钥派生模式。例如，可以派生四个密钥，以便双方可以使用单独的密钥进行签名和加密。若要使密钥保持最新状态并保持高级别的安全性，应使用后续派生。最好使用此方法保护会话。WS-SecureConversation规范定义了一种机制，用于指示在给定消息中使用哪个派生。每个派生算法都使用URI进行标识。

Web服务联合安全体系结构中定义了两大类请求程序(消息发送方)：被动和智能(主动)。被动请求程序[WS-FedPassive]是仅使用HTTP且从不颁发安全令牌的服务。智能请求程序是一种能够发出包含安全令牌的消息的服务，如WS-Security和WS-Trust中所述的消息。传统的基于HTTP的Web浏览器是被动请求者的一个示例。已开发配置文件规范来定义这两种请求程序的行为。

本部分介绍用于在网络上查找Web服务并确定服务可用性的Web服务体系结构的功能组件：UDDI和WS-Discovery[WS-Discovery]。

Web服务发现是无需人工干预即可自动连接到服务的关键启用程序。Web服务发现方法反映了在计算机系统中查找信息的两种最常见方法：查找已知位置，或将请求广播到所有可用的侦听器。UDDI注册表充当目录，发现协议用于广播请求。

通用说明、发现和集成协议或UDDI指定用于查询和更新Web服务信息的公用目录的协议。目录包括有关服务提供商、它们托管的服务以及这些服务实现的协议的信息。该目录还提供将元数据添加到任何已注册信息的机制。

当Web服务信息存储在已知位置时，可以使用UDDI目录方法。找到目录后，可以发送一系列查询请求以获取所需的信息。UDDI目录位置通常是通过系统配置数据在带外获取的。

对于所有部署方案，UDDI目录包含有关Web服务及其托管位置的详细信息。UDDI目录条目有三个主要部分：服务提供商、提供的Web服务和与实现的绑定。其中每个部分都逐步提供有关Web服务的详细信息。

最一般的信息描述了服务提供程序。此信息不是针对Web服务软件，而是针对需要直接与服务负责人联系的开发人员或实施者。服务提供商信息包括姓名、地址、联系人和其他管理详细信息。所有UDDI条目都有多个用于多语言说明的元素。

可用Web服务的列表存储在服务提供程序条目中。这些服务可能会根据其预期用途进行组织：它们可分组到应用程序区域、地理位置或任何其他适当的方案中。存储在UDDI注册表中的服务信息仅包括服务的说明和指向它包含的Web服务实现的指针。也可以注册由其他提供程序托管的服务（称为“服务投影”）的链接。

UDDI服务提供程序条目的最后一部分是绑定到实现。此绑定将Web服务条目关联到确切的URI()，以标识服务的部署位置，指定要用于访问的协议，并包含对实现的确切协议的引用。

这些详细信息足以让开发人员编写调用Web服务的应用程序。详细协议定义通过名为类型模型(或tModel)的UDDI实体提供。在许多情况下，tModel引用描述SOAPWeb服务接口的WSDL文件，但tModels也足够灵活，可以描述几乎任何类型的资源。

对于在UDDI中注册的每个提供程序或服务，标准分类(（例如NAICS[NAICS]和较旧的SIC行业代码[SIC])或其他标识方案(（如EdgarCentralIndexKey)）可用于对信息进行分类并提高搜索准确性。作为任何实现的一部分，可用的分类和标识符方案集很容易扩展，因此可以对其进行自定义以支持任何特定的地理、行业或公司要求。

动态Web服务发现以不同的方式提供。动态发现的Web服务除了将信息存储在已知注册表中，还可以显式地宣布其到达和离开网络。WS-Discovery定义通过多播消息通知和发现Web服务的协议。

当Web服务连接到网络时，它会通过发送Hello消息来宣布其到达。在最简单的情况下，这些公告是使用多播协议通过网络发送的，我们称之为临时网络。此方法还可以最大程度地减少在网络上轮询的需求。为了限制网络流量并优化发现过程，系统可能包含发现代理。发现代理取代了使用已知服务位置发送多播消息的需要，将即席网络转换为托管网络。使用配置信息，可将代理服务的集合链接在一起，以便将发现服务扩展到服务器组，从一台计算机扩展到多台计算机。

由于发现代理本身是Web服务，因此它们可能会使用自己的特殊Hello消息来宣布其存在。然后，接收此消息的Web服务可以利用代理的服务，并且不再需要使用更嘈杂的一对多发现协议。

当服务离开网络时，WS-Discovery指定要发送到网络或发现代理的Bye消息。此消息通知网络上的其他服务离开的Web服务不再可用。

为了补充此服务公告和离开的基本方法，WS-Discovery定义了两个操作：探测和解析，用于在网络上查找Web服务。对于即席网络，探测消息将发送到多播组，与请求匹配的目标服务会将响应直接返回给请求者。对于使用发现代理的托管网络，探测消息改为单播到发现代理。当要按名称定位Web服务时，将使用Resolve消息。解析消息仅在多播模式下发送。解析类似于地址解析协议或ARP[ARP]，后者将IP地址转换为其相应的物理网络地址。

WS-Discovery规范还允许系统配置，在这些配置中，探测消息被发送到通过某些其他管理方式（例如，通过使用已知的DHCP记录）建立的发现代理。

动态查找服务的功能可启用Web服务管理引导。结合WS-Eventing[WS-Eventing]和其他协议，可以使用此动态发现基础结构生成更复杂的管理服务。

动态发现还会将Web服务体系结构扩展到设备，例如那些可能实现通用即插即用&(UPnP)协议的设备。这是使体系结构真正通用的重要一步。例如，借助WS-Discovery和WS-Eventing，打印机或存储介质等设备可以作为Web服务合并到系统中，而无需专门的工具或协议。

Web服务的设备配置文件规范

Web服务设备配置文件[WS-DP]规范提供有关应在资源受限的设备上实现Web服务体系结构规范系列的子集的指导。此配置文件尝试在可用的丰富功能与因资源限制而做出权衡时最重要的功能之间找到平衡。

本部分介绍Web服务体系结构的组件，这些组件提供可靠的消息传递、事务行为，以及提供Web服务集合之间的显式协调的功能。定义此功能的规范包括WS-ReliableMessaging、WS-Coordination[WS-Coord]、WS-AtomicTransaction[WS-AT]和WS-BusinessActivity。

当多个Web服务必须完成一个联合工作单元或在共同行为下运行时，必须就要使用的协议达成一致。Web服务之间的这种最小协调是不可避免的。还需要协调协议，以便能够确定并同意已达到共同目标。Web服务之间的每次交互都可以被视为一种协调。协议协调协议使体系结构更有可能让参与者服务成功完成他们共同设置的操作。Web服务体系结构设计为在遇到丢失消息的传输和服务发生故障时正常运行。

任何多方协调都可以通过根据需要连续加入更多参与者，从两方协调中建立起来。两方协调可能是自发的，也可能需要指定的协调人。常见的自发协调协议的一个示例是同步请求-响应消息传送模式。这是最简单的协议协调形式之一：对于每个工作请求，收件人Web服务必须先完成所有预期的工作，然后才能将任何数据返回给请求者。双方都遵循这种严格的模式，无需显式协调服务。“Three-Leg握手”部分提供了自发协调的第二个示例。WS-ReliableMessaging是一个非常通用的多消息自发协调的示例，将在下一部分中介绍。

许多条件可能会中断两个服务之间的消息交换。当使用HTTP1.0和SMTP[SMTP]等不可靠的传输协议进行传输或邮件交换跨越多个传输层连接时，尤其会出现此问题。消息可能会丢失、重复或重新排序，Web服务可能会失败并丢失易失状态。WS-ReliableMessaging是一种协议，可根据特定的传递保证特征实现消息的可靠传递。该规范定义了三种可以组合使用的不同保证：

至少一次和最多一次保证的组合可生成精确一次交付保证。由于Web服务体系结构采用与传输无关的设计，因此无论使用的通信传输或传输组合如何，都保证所有交付保证。使用WS-ReliableMessaging简化了系统开发，因为开发人员必须预见的潜在交付失败模式数量较少。

可靠消息传送不需要显式协调器。使用WS-ReliableMessaging时，参与者必须基于SOAP消息标头中发送的信息识别协议。作为组传输的消息集称为消息序列。消息序列可由发起方/发送方或Web服务建立，在建立双工关联时通常由两者建立。使用CreateSequence和CreateSequenceResponse消息显式建立序列。当所需的最终结果是将两个单向序列用作双工序列时，发起程序将提供Web服务要使用的序列。此序列的ID由发起程序包含在CreateSequence消息中。

WS-ReliableMessaging中定义了多个策略断言。这些策略断言是使用WS-Policy中定义的机制表示的。

可靠的消息传送协议简化了开发人员在各种传输保证下传输消息时必须编写的代码。相反，底层基础结构会验证消息是否已在终结点之间正确传输、重新传输消息并在必要时检测重复。应用程序不需要任何其他逻辑来处理消息重新传输、重复消息消除、消息重新排序或消息确认，可能需要这些逻辑才能提供传递保证。WS-ReliableMessaging的实现分布在发起方和服务之间。那些不可见的“在线”特征（如消息传递顺序）由WS-ReliableMessaging规范的实现提供。虽然由于传输丢失而导致的消息重新传输等特征由应用程序不为人知道的消息传送层处理，但其他端到端特征（如按顺序传递）需要消息传递基础结构和接收方应用程序进行协作。值得注意的是，当发送方预期“作为已发送”时，在接收方上提供消息排序“asreceived”是按顺序进行的错误实现。当发送方预期为“接收”时，在接收方上提供“作为已发送”的订单是按顺序正确实现的。

WS-Coordination规范定义了一个可扩展的协调框架，以支持需要显式协调器的方案。此协议引入了一个名为“协调上下文”的SOAP标头块，用于唯一标识要执行的联合工作。为了启动联合工作，Web服务将协调上下文发送到一个或多个目标服务。收到协调上下文会提醒收件人服务请求联合协作。协调上下文包含足够的信息，供请求收件人确定是否参与工作。协调上下文中包含的确切信息因请求的工作类型而异。

协调类型集是开放式的。只要参与联合工作的每个服务对所需行为有共同的了解，新类型就可以由实现定义。例如，原子事务是在Web服务体系结构中定义的几个初始基石协调类型之一。

如果理解并接受请求的协调类型，Web服务将使用WS-Coordination注册协议通知协调器并参与联合工作。协调上下文包括协调器终结点引用，以及可能选择的可能行为的标识符。注册操作指定参与的Web服务支持的行为。将注册消息发送到协调器后，Web服务将根据其订阅的协议参与工作。注册是协调框架中的关键操作。它允许不同Web服务的“连接在一起”，这些服务需要协调以执行联合工作单元。

WS-AtomicTransaction指定Web服务的传统ACID事务[Gray&Reuter]。在原子事务协调类型的上下文中，定义了三个协议：完成协议和两个Two-Phase提交协议的变体。完成协议用于启动提交处理。注册完成的Web服务能够在提交处理开始时告知指定的协调器。此协议还定义消息，用于将事务的最终结果传达给发起方。但是，该协议不要求协调器确保发起程序处理结果。相比之下，WS-AtomicTransaction中的其他行为需要协调器确保参与者处理协调消息。

Two-Phase提交(2PC)协议使所有已注册的参与者都做出共同的提交或中止决定，并确保所有参与者都被告知最终结果。如其名称所示，它使用两轮通知来完成事务。定义了此协议的两个变体：Volatile2PC和Durable2PC。这两个协议在网络上使用相同的消息，(对应于准备、提交和中止)的操作，但Volatile2PC没有持久性要求。易失性2PC协议将由管理易失资源的参与者使用，例如缓存管理器或窗口管理器。协调器在第一轮通知中联系这些参与者，不需要第二轮通知。

WS-AtomicTransaction中定义了多个策略断言。这些策略断言是使用WS-Policy中定义的机制表示的。

已证明在构建分布式系统时非常有用的一种模式是，使用事务持久队列提供存储和转发异步消息传送。在此模式中，在每个传输终结点上利用原子事务。在发送方，发送应用程序以原子事务方式将消息传送到持久队列，应用程序和队列管理器都使用WS-AtomicTransaction进行协调。仅当处理消息时没有错误时，它才会被视为已成功传递到队列。

类似地，从收件人队列中检索消息的应用程序使用原子事务执行此操作。这样，仅当没有处理错误时，才能从队列中删除消息。

WS-AtomicTransaction和WS-BusinessActivity都利用WS-Coordination来管理Web服务之间的协作。

Three-Leg握手

三条腿握手连接建立和拆解协议是不需要指定协调器服务的协调协议的一个示例。为了建立连接，发送方会向接收方发送请求。此请求建立会话。如果接受，接收方会通过确认消息积极响应此请求。发送方将第三条消息作为对确认的确认进行传输，验证双方是否知道另一方已建立会话。

拆解协议是类似的。其中一方向另一方发送会话拆解请求。收件人以对拆解邮件的确认进行响应。收到此确认后，发出拆解消息的一方将通过向确认发送确认来完成消息交换。

本部分介绍在Web服务体系结构中提供服务资源的枚举、其状态管理和事件通知的规范。它们基于WS-Enumeration[WS-Enum]、WS-Transfer[WS-Transfer]和WS-Eventing。

许多方案要求使用不止一个请求/响应消息对进行数据交换。需要这些较长数据交换的应用程序类型包括数据库查询、数据流式处理、信息遍历（如命名空间）和枚举列表。具体而言，枚举是通过在数据源和请求者之间建立会话来实现的。会话中的连续消息传输要检索的元素的集合。未对服务用于组织将生成的项的方法做出任何假设。预期在正常处理情况下，枚举将在会话结束前生成所有基础数据。

WS-Enumeration指定用于建立枚举会话和检索数据序列的协议。枚举协议允许数据源向使用服务提供会话抽象（称为枚举上下文）。此枚举上下文表示通过一系列数据项的逻辑游标。然后，请求者在一个或多个SOAP消息的跨度内使用此枚举上下文来请求数据。枚举的数据表示为XMLInfosets。该规范还允许数据源提供用于启动新枚举的自定义机制。由于枚举会话可能需要多个消息交换，因此必须保留会话状态。

有关迭代进度的状态信息可由数据源或使用服务在请求之间维护。WS-Enumeration允许数据源根据请求决定哪一方将负责维护下一个请求的状态。这种灵活性可实现多种优化。一个优化示例是允许服务器避免在调用之间保存任何游标状态。由于对于支持多个同时枚举的服务来说，消息延迟可能很大，因此不保留状态可能会显著节省必须维护的信息总量。资源受限的设备（如手机）上的服务实现可能根本无法维护任何状态信息。

WS-Transfer[WS-Transfer]中定义了管理通过Web服务访问的数据实体所需的基本操作。要了解WS-Transfer，需要引入两个新术语：工厂和资源。工厂是一种Web服务，可以从其XML表示形式创建资源。WS-Transfer引入了创建、更新、检索和删除资源的操作。应注意的是，资源的状态维护最多取决于宿主服务器的“最大努力”。当客户端收到服务器接受创建或更新资源的请求时，可以合理地期望该资源现在存在于确认的位置并具有已确认的表示形式，但这是不能保证的，即使在没有任何第三方的情况下也是如此。服务器可以更改资源的表示形式，可以完全删除资源，也可以恢复已删除的资源。这种缺乏保证与Web带来的松散耦合模型是一致的。如果需要，服务可能会提供Web服务体系结构不需要的其他保证。

WS-Transfer的创建、更新和删除操作扩展了WS-MetadataExchange中只读操作的功能。检索操作与WS-MetadataExchange中的Get操作完全相同。创建请求将发送到工厂。然后，工厂创建请求的资源并确定其初始表示形式。假定工厂不同于正在创建的资源。将为新资源分配一个服务确定的终结点引用，该引用在响应消息中返回。

Put操作通过提供替换表示形式来更新资源。可以使用WS-Transfer中的Get操作检索资源表示形式的一次性快照（与WS-MetadataExchange中的Get操作相同）。成功执行删除操作后，资源不再可通过终结点引用使用。这四个元数据管理操作构成了在Web服务中构建状态管理所需的基础。

在由相互通信的服务组成的系统中（可能使用异步消息传送），许多情况下，一个服务生成的信息对另一个服务感兴趣。由于缩放特性差，轮询通常不是获取此类信息的适当机制：通过网络发送的不必要的消息过多。相反，体系结构需要一种在事件发生时进行显式通知的机制。更重要的是要求在运行时动态完成源服务和使用者服务的绑定。Web服务体系结构通过轻型事件协议支持此功能。

WS-Eventing指定使以下四个实体能够交互的机制：订阅者、订阅管理器、事件源和事件接收器。这允许Web服务在充当订阅者时，注册对另一个Web服务提供的特定事件的兴趣，这些事件(事件源)。此注册称为订阅。WS-Eventing定义服务可以提供的操作，这些操作允许创建和管理订阅。当事件源确定某个事件已发生时，它将向订阅管理器提供该信息。然后，订阅管理器可以将事件传达给所有匹配的订阅。这类似于在传统的发布/订阅事件通知系统中发布主题。Web服务体系结构在定义、组织和发现主题的方式上提供了完全的灵活性;它提供一个通用基础结构，用于管理可在许多不同的应用程序领域利用的订阅。

事件代理可用于通过不同的源聚合或重新分发通知。代理还可以用作独立的订阅管理器。WS-Eventing支持这两种方法。代理可以在系统中扮演多个重要角色。可以组织主题以供某些类的应用程序使用。中转站可以充当通知聚合器，合并来自多个源的事件信息。它们还可以充当筛选器，接收的消息数超过了用于自身通知的消息数。部署可靠且可缩放的通知系统需要这种灵活性。

管理功能是要讨论的Web服务体系结构的最后一个方面。这些功能在WS-Management[WS-Management]规范中定义。

WS-Management基于体系结构的多个组件构建，提供所有系统管理解决方案所需的一组通用操作。这包括发现管理资源是否存在以及其中导航的功能。可以检索、设置、创建和删除单个管理资源，例如设置和动态值。可以枚举容器和集合的内容，例如大型表和日志。最后，定义事件订阅和特定的管理操作。在每个领域，WS-Management仅定义最低实现要求。

已采取谨慎措施，以便将一致的WS-Management实现部署到小型设备。同时，它已设计为纵向扩展到大型数据中心和分布式安装。此外，机制的定义独立于任何隐含的数据模型或系统运行状况模型。这种独立性支持将其应用于各种Web服务。

WS-Management要求使用带有特定附加信息的终结点引用托管资源。此信息包括提供资源访问权限的代理的URL、资源所属的资源类型的唯一标识符URI以及标识资源的零个或多个密钥。这些键假定为名称/值对。此信息到WS-Addressing终结点引用的映射如下所示：资源的URL映射到address属性，资源类型标识符映射到相应的XML命名空间)中名为ResourceURI的特定引用属性(，每个键映射到名为Key的引用参数，其属性名为Name。

对于使用WS-Transfer操作的数据访问，WS-Management指定另外三个限定符。可以使用SummaryPermitted标头和NoCache标头限定Get操作。SummaryPermitted限定符允许传输缩写表示形式（如果可用）。NoCache限定符需要传输新数据，不允许缓存信息。对于Put和Create操作，ReturnResource限定符要求服务返回资源的新表示形式。ReturnResource允许资源受限的Web服务在更新资源时不保留任何状态。

本文介绍Web服务体系结构的功能构建基块及其基本原则。每个构建基块都是根据协议规范定义的。我们期望本文中所述的功能范围和指导原则保持不变。但是，我们确实希望体系结构能够扩展以支持其他方案。能够适应创新是体系结构的基本优势。

体系结构的SOAP消息传送基础可确保广泛的覆盖范围。SOAP消息传送以独立于传输的方式支持异步和同步模式。没有更灵活的基础结构。为了加速Web服务体系结构的广泛采用，这些规范已与广泛的技术合作伙伴集合一起编写。与这些关键技术提供商合作可加快设备和支持在线协议的编程环境的部署。实现广泛覆盖、广泛采用和独立于规模的结构是我们三个核心目标。

我们努力确保体系结构可以在任何平台上以任何编程语言实现。体系结构的基于消息和基于协议的性质促进了这一点。如有必要，例如仅使用WS-Security实现消息完整性、保密性和身份验证，以及仅使用WS-Policy表达元数据，我们已限制各种技术方法以提高互操作性级别。理想情况下，只要实现忠实地遵循体系结构的协议规范，它们就能够与任何其他Web服务通信。真相在铁丝上。

最后但并非最不重要的一点，以下个人参与了Web服务体系结构的定义：(按字母顺序)TonyAndrews，BobAtkinson、KeithBallinger、DonBox、JohnBrezak、AllenBrown、LuisFelipeCabrera、ErikChristensen、GeorgeCopeland、MichaelCoulson、GiovanniDella-Libera、BrendanDixon、MikeDusche、ColleenEvans、MaxFeingold、HenrikFrystykNielsen、PraeritGarg，奥米米·加齐特、艾伦·盖勒、乔希·格雷、马丁·古金、德斯特里·胡德、埃菲姆·胡迪斯、托马斯·扬丘克JimJohnson、RyanJohnson、JohnJustice、GopalKakivaya、ChrisKaler、JohannesKlein、ScottKonersmann、BrianLaMacchia、DaveLangworthy、AndrewLayman、PaulLeach、AlLee、RodneyLimprecht、JoeLong、SteveLucco、JohnManferdelli、AshokMalhotra、JonathanMarsh、SteveMillet、AngelaMills、StefanPharies、斯科特·罗宾逊、约丹·罗斯科夫、苏杰伊·萨尼、杰夫·施利默、奥利弗·夏普、约翰·休克、亚瑟·肖胡德、丹·西蒙、杰夫·斯佩尔曼、基思·斯托比、萨蒂什·萨特、罗伯特·瓦贝、艾略特·温戈尔德、理查德·沃德、赫维·威尔逊、肯尼·沃尔夫和埃里克·辛达。

活动请求者-活动请求者是一个应用程序，(可能是Web浏览器)，能够发出Web服务消息，如WS-Security和WS-Trust中所述的消息。

身份验证-验证安全凭据的过程。

规范化-将XML文档转换为与各方一致的表单的过程。在对文档进行签名和解释签名时使用。

协调上下文-一组协调服务要执行的工作集的唯一标识符。

反序列化-从八进制流构造XMLInfoset的过程。它是用于从消息的线路格式创建消息的Infoset表示形式的方法。

摘要-摘要是八进制流的加密校验和。

域-安全域表示单个安全管理或信任单元。

持久两阶段提交-用于持久资源（如文件或数据库）上的事务的协议。

有效策略-对于给定策略主体，有效的策略是附加到包含策略主体的策略范围的策略的结果组合。

Exchange模式-用于服务之间的消息交换的模型。

工厂-工厂是一种Web服务，可以从XML表示形式创建资源。

标识映射-标识映射是一种在标识属性之间创建关系的方法。某些标识提供者可能会使用标识映射。

标识提供者(IP)—标识提供者是充当最终请求者的身份验证服务的实体。标识提供者还充当服务提供商的数据源身份验证服务，(这通常是安全令牌服务)的扩展。

消息-消息是可供服务发送或接收的完整数据单元。它是信息交换的自包含单元。消息始终包含SOAP信封，并且可能包含MTOM和/或传输协议标头中指定的其他MIME部分。

消息路径-在原始源和最终接收方之间遍历的SOAP节点集。

被动请求程序-被动请求程序是能够广泛支持的HTTP(（例如HTTP/1.1)）的HTTP浏览器。

策略-策略是策略替代项的集合。

策略替代项-策略替代项是策略断言的集合。

策略断言-策略断言表示特定于域的单个要求、功能、其他属性或行为。

策略表达式-策略表达式是策略的XMLInfoset表示形式，采用普通形式或等效的压缩形式。

主体-可以授予安全权限或对安全性或标识进行断言的任何系统实体。

协议组合-协议组合是能够组合协议，同时保持技术一致性，并且没有任何意外的功能副作用。

资源-资源定义为可由终结点引用寻址的任何实体，其中实体可以提供自身的XML表示形式。

安全上下文令牌-安全上下文令牌(SCT)是安全上下文抽象概念的线路表示形式，它允许上下文按URI命名并与[WS-Security]一起使用。

序列化-将XMLInfoset表示为八进制流的过程。它是用于为消息创建线路格式的方法。

服务-通过消息与其他实体交互的软件实体。请注意，服务不需要连接到网络。

签名-签名是使用加密算法计算并绑定到数据的值，以便数据的预期接收者可以使用签名来验证数据是否尚未更改并且源自消息的签名者，从而提供消息完整性和身份验证。可以使用对称或非对称密钥算法计算和验证签名。

注销-注销是主体指示他们不再使用其令牌的过程，域中的服务可以销毁主体的令牌缓存。

SOAP中介-SOAP中间体是SOAP处理节点，既不是原始消息发送方，也不是最终接收方。

对称密钥算法-一种加密算法，其中同一密钥用于加密和解密消息。

系统-实现特定功能的服务的集合。与分布式应用程序同义。

信任-信任表示一个实体愿意依赖第二个实体来执行一组操作和/或对一组主题和/或范围进行断言。

可变两阶段提交-用于易失性资源（如缓存或窗口管理器）上的事务的协议。

Web服务-Web服务是一种可重用的软件，它通过XML、SOAP和其他行业公认的标准通过网络交换消息。

XML文档可能包含11种类型的信息项。下面我们列出并定义SOAP允许提及其他项。SOAP允许的六个信息项是：

以下是根据这些轴组织的安全攻击类的简短非详尽列表，以及每个类的标准对策：

[ARP]

[HTML]

[HTTP]

[KERBEROS]

[MIME]

[REL]

[RFC1630]

[SAML]

[SMTP]

[TCPIP]

Internet协议。Ed.乔恩·波斯特尔1981年9月。国防高级研究项目局。

[TLS]

[UDP]

[X509]

[XSLT-20]

[XML-Infoset]

[XML-10]

[XMLENC]

[XML-Query]

[XML-Schema]

[XMLSIG]

[SOAP]

[SOAP-UDP]

[MTOM]

[UDDI]

[WSDL]

[WS-Addressing]

[WS-AT]

Web服务原子事务(WS-AtomicTransaction)。路易斯·费利佩·卡布雷拉，等人，2003年9月。BEA、IBM和Microsoft。

[WS-BA]

WebServicesBusinessActivityFramework(WS-BusinessActivity)。路易斯·费利佩·卡布雷拉，等人，2004年1月。BEA、IBM和Microsoft。

[WS-Coord]

Web服务协调(WS-Coordination)。路易斯·费利佩·卡布雷拉，等人，2003年9月。BEA、IBM和Microsoft。

[WS-Discovery]

[WS-Enum]

[WS-Eventing]

[WS-Federation]

[WS-FedActive]

[WS-FedPassive]

[WS-MEX]

[WS-Policy]

[WS-PA]

[WS-RM]

[WS-SecureConv]

[WS-Security]

[WS-SecurityPolicy]

[WS-SecUsername]

[WS-SecX509]

[WS-Transfer]

[WS-Trust]

[XOP]

[WSI-BP10]

[WSI-BSP10]

[WS-DP]

[NAICS]

[SIC]

[UBR]

[WS-I]

[灰色&路透社]

事务处理：概念和技术。吉姆·格雷和安德里亚斯·路透摩根-考夫曼，1993年。