web 服务标准_了解所有这些疯狂的Web服务标准

web 服务标准

自从将SOAP和WSDL（Web服务描述语言）引入标准以促进异构系统之间的通信和数据交换以来，已经过去了八年。 从那时起，一系列的协议（统称为WS *）也被引入作为SOAP（在某些情况下为WSDL）的扩展，以促进特定的通信需求和场景。 WS *的类别非常广泛，并且已经达到了如此之高的标准数量，以至于尽管在许多平台上都实现了核心集，但是Web服务社区中的许多人对于应该关注哪些标准感到困惑，何时何地。 此外，随着每个标准遍历其开发，早期采用，批准和更新的生命周期，人们普遍担心互操作性。

通过这篇文章，我打算总结一下您最常听到的WS *协议，同时还要根据您在Web服务平台之间的实际实现来强调您今天将使用的最相关的标准（重点是Java和.NET）。 ），它们的采用和就绪程度，以及它们对与.NET的特定集成方案的适用性。 如果您不熟悉Web服务或WS *协议，或者在跟上该领域的变化步伐方面遇到困难，那么本文应该可以帮助您着手了解最多的协议，以及他们的目的。 我还将简要讨论围绕这些高级标准的互操作性阶段。

重访SOAP + WSDL

SOAP于1999年首次引入，这是一个简短的规范，描述了如何在应用程序之间格式化消息，并以XML为核心来促进互操作性。 如果您考虑一下，SOAP协议实际上仅描述消息的包装器：在何处放置标头，在何处放置消息有效负载，如何指示请求的意图（或“动作”）-基本要求使平台能够处理SOAP消息以执行工作。 很好，但是如果要将提取的标头和正文元素转换为特定于平台的运行时类型，则仍然需要理解它们。 那就是WSDL的来源。WSDL描述了可以访问服务的Url，该位置的受支持的操作（动作）以及XSD Schema描述的消息格式和相关类型定义。 当消息以SOAP为框架时，WSDL描述了特定于应用程序的消息传递需求。

事实证明，将WSDL（Web服务描述语言）与SOAP相结合，才真正提高了开发共享数据的系统的开发人员的生产率。 尽管早期存在许多互操作性问题，但今天，平台对SOAP和WSDL以及对类型的XML序列化的支持使在任何平台上开发和托管Web服务，生成描述消息传递需求的WSDL以及生成客户端代码成为可能。毫不费力地调用操作。 您可能会说“您让我在SOAP上了”，因为它解决了POX（“纯XML”）方法无法解决的问题-一种可通过编程发现的描述和工具，可帮助代码生成。

为什么选择WS *？

SOAP规范未定义消息头和主体元素的实际内容。 应用程序可以完全自定义所需的标头，以及主体应包含哪些数据以在特定操作中进行有意义的工作。 但是，在SOAP消息路由和寻址的业务实现之间共享某些共同的需求，处理大型消息有效负载，并在最前端提供安全可靠的通信。 这就是WS *协议出现的地方。

WS *指的是基于SOAP规范并在业界广泛支持下开发的似乎永远增长的标准协议集。 它们的目的是促进系统之间的通用消息传递需求。 例如，在某个时候，很明显，需要一种标准来发送用户名和密码凭证，因为其他地方的开发人员正在创建基本上执行相同操作的自定义SOAP标头。 因此，WS-Security诞生了。 这也是因为很快就知道需要一种规范来减少发送和处理二进制数据的开销，因此，在社区决定采用MTOM之前，出现了几种优化的二进制传输方式。 通过围绕这些场景和其他常见场景形成标准，供应商可以生产工具以促进围绕它们的开发-并提高开发人员的工作效率，而不仅仅是简单的消息交换。

图1：Web服务协议的核心类别。

图1说明了与Web服务相关的协议适用的一些主要类别。 这样组织起来，看起来并不那么令人生畏，但是当您扩展每个类别中的标准列表时，很容易有点不知所措。 在以下各节中，我将概述每个类别的关键标准的当前状态。 我将讨论它们的批准状态，主要目的和价值，以及它们在当今Java平台和WCF中的适用性。

注意：我将仅将WCF称为与此讨论相关的.NET平台，因为它是Microsoft的WS *实现。 在Java方面，WS *有许多实现，因此，出于本文的目的，我将在平台之间采用标准方面进行概括。

传输协议

当然，需要传输协议来促进消息传递。 SOAP协议绑定框架（ http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew ）描述了如何定义任何协议绑定来支持消息传输。 正式记录的两个绑定是：

• HTTP： http ： //www.w3.org/TR/2007/REC-soap12-part2-20070427/#soapinhttp
• SMTP： http ： //www.w3.org/TR/soap12-email

人们通常认为SOAP消息是通过HTTP或HTTPS传输的，这无疑是Java和.NET之间互操作性的最常见情况。 实际上，SOAP和WS *的性质使您可以通过任何协议公开服务，甚至可以不使用正式绑定中描述的服务，例如TCP，命名管道，UDP甚至自定义协议。 像Microsoft的Windows Communication Foundation（WCF）这样的平台通过这些协议和更多协议使用SOAP消息传递，因为该平台基于这种通用消息传递格式。 当然，通过非HTTP的实现是不可互操作的。

协议绑定描述了如何通过特定协议传输消息，包括如何将适当的寻址信息映射到协议头。 实际上，WS-Addressing从传输协议中删除了地址标头的耦合-描述了一种完全封装在消息有效负载中的寻址语义的替代方法。

至于对Web服务的传统平台支持，通常会在考虑互操作性时使用HTTP或HTTPS。

XML标准

XML和XSD Schema当然是SOAP，WSDL和WS *的核心-使记录消息需求成为可能。 XML数字签名和XML加密是与保护XML文档（或SOAP消息）的一部分有关的标准，因此WS-Security协议可以适当地利用它们。 关于最后一点的重要一点是，当引入WS-Security时，它并没有重新发明轮子来实现凭据和其他消息部分周围的消息安全性-它利用已经具有数字签名和加密库的规范来保护XML文档。

消息相关协议

有几种协议支持常规的消息传递功能-以SOAP作为总体消息格式开始。 当今，大多数平台都支持SOAP 1.1和SOAP 1.2格式-后者均基于文档文字消息格式（基于模式，而非编码）进行标准化。 SOAP 1.2通常是当今平台的默认设置。 但是，如果要公开必须与旧版客户端向后兼容的服务，则可能需要显式配置服务以使用SOAP 1.1序列化消息。

WS-Addressing：W3C建议，2005年8月

正如我之前提到的，WS- Addressing使寻址和路由与传输层分离。 这允许您以一致的方式通过任何协议跨多个跃点发送SOAP消息。 它还提供了一种标准方法来描述用于异步操作和发布/订阅模式的Web服务端点。 WS-Addressing是堆栈在顶部的许多其他WS *协议的核心依赖性。 当今，大多数平台都可以支持WS-Addressing协议-实际上，Web服务最经常支持带有WS-Addressing的SOAP 1.2。

通常，您不会看到地址标头，当您使用支持协议的平台公开或使用Web服务时，它们只会“发生”。 但是，由于某些平台还支持WS-Addressing的未批准版本，因此有时可能需要互操作性来配置您的客户端或服务以支持较旧的版本。

WS-Transfer：W3C提交，2006年9月

WS- Transfer通过SOAP消息传递支持针对资源的CRUD操作-将这些操作与HTTP动词分离，以提供与传输无关的REST实现。 我不会建议WS-Transfer作为HTTP上的RESTful架构的替代方案，因为寻址语义是完全不同的，但是此协议对于以资源访问为中心的服务很有用，而不是操作。 例如，如果您的服务专注于CRUD操作，则可以考虑将此规范作为Web服务产品的一部分来实施。

当今的WS- Transfer的大多数实现本质上都是专有的-即，规范本身不是任何Web服务平台的组成部分-但遵循该规范并实现自己的实现很容易。

WS-Enumeration：W3C提交，2006年3月

WS- Enumeration定义了一种协议，该协议用于遍历大型结果集，例如仅向前，只读游标进入数据集。 像WS-Transfer一样，该规范不是任何平台的组成部分，但是如果这种访问模式有意义，则易于实施该规范。

WS-EventNotification

WS- EventNotification描述了如何支持独立于传输协议的分布式事件和通知，如在发布和订阅方案中一样。 它正在进行中，代表了其他竞争规范的统一：WS- Notification和WS- Eventing 。 WS- 通知及相关标准（WS- BaseNotification之上 ，WS- BrokeredNotification和WS- 主题 ）成为认可的OASIS标准为2006年10月（的http://www.research.ibm.com/journal/sj/444/niblett。 html ）。 WS-Eventing于2006年3月成为W3C提交（ http://www.w3.org/Submission/WS-Eventing ），这是一种比WS- Notification更简单的通知基础结构方法。

这些标准的统一（在此讨论）说明，即使批准了一个规范（如OASIS的WS-Notification），仍可能朝着该标准的行业协议迈进，以便平台可以互操作。 只要有不时发生的针对特定目的的竞争性标准（有时会发生），它就会稀释跨平台供应商的实施，从而使互操作性变得困难。

直到WS-EventNotification达到（接近）批准的状态，通知才能实现广泛的互操作性。 但是，有一些采用适度采用的WS-Notification和WS-Eventing实现。

MTOM：W3C建议书，2005年1月

MTOM （消息传输优化机制）描述了如何以更有效的方式将二进制数据作为SOAP消息的一部分进行传输。 该规范代表了SwA （带有附件的SOAP）和DIME （直接Internet消息封装）的发展。 MIME编码是所有这些协议的基础-目标是消除与SOAP消息（XML信息集）中嵌入的base64编码二进制数据相关的膨胀和解析开销。 但是，MTOM通过利用XOP（XML二进制优化包装）来引用从SOAP信封中提取的二进制内容来建立在此之上，以便消息接收器可以将二进制数据重新构造到XML信息集的正确位置。 换句话说，二进制数据可以由SOAP主体中的特定元素引用，这通常意味着将其作为操作的参数进行评估。

SwA直到2004年6月才达到W3C注释状态，但是WS-I将此标准合并到了“基本附件配置文件”中，因此有许多平台可以实现此规范。 DIME也已在许多平台上实现，特别是Java平台，这些平台希望与.NET和不支持SwA的Web服务增强功能（WSE）（WCF之前的版本）实现互操作性。 如今，SwA和DIME都已过时，并且已经批准了两年的MTOM在这一点上得到了广泛的平台采用和成功的互操作性。

您不需要查看MTOM实现的详细信息，而只需在您选择的平台中配置客户端和服务以为可能包含二进制内容的消息启用协议。

安全协议

当WS *开始发展时，安全协议是最早跨平台稳定的协议之一。 最初的驱动程序是基于对凭据序列化方式进行标准化的需要，因此各个实现不必重新发明轮子。 快速出现了其他安全场景，这些场景特别与线路上的消息保护，安全会话和身份联合有关。

传输与邮件安全

为了在传输过程中保护消息，应该对消息进行数字签名以确保完整性，并对其进行加密以确保隐私。 这可以在传输级别或使用消息安全性来实现。 尽管并非所有采用安全协议的方案都利用消息安全性，但是这是一种建议的方法。 采用传输安全性时，仅点对点保护消息，如下所示：

相比之下，消息安全性在SOAP信封中传递凭据，并将OASIS SOAP消息安全性应用于签名和加密消息部分。 消息安全性的最重要方面之一是它使用可互操作的标准来保护消息传输，并且由于消息安全性可以保护消息而不依赖于传输，因此可以一直保护消息直至最终消息接收者（或目标应用程序） ）提供端到端的安全性，如下所示：

这样就可以在不暴露敏感信息的情况下，通过基于内容的路由器或管理中介（例如）传递消息。

人们总是认为使用消息安全性更为安全。 您需要问自己的问题是，是否有不必要的责任或风险与落入某种中介的消息相关，并且在传递给下游服务时不受保护。 通常，中介是下游服务信任域的一部分，但是其他消息路由也是可能的。

WS-Security：OASIS标准，2004年3月，2006年2月更新

WS-Security是一种开放格式，用于对消息部分进行签名和加密（利用XML数字签名和XML加密协议），以安全令牌的形式提供凭据，并在消息中安全地传递这些令牌。 该路线图始于2002年，但是2004年中期，OASIS批准了1.0版，并于2006年2月进行了更新（1.1版）。该组的核心标准包括WS-Security Core（SOAP消息安全性）和一些令牌配置文件，包括用户名令牌配置文件，X.509令牌配置文件，Kerberos令牌配置文件和SAML令牌配置文件。 令牌概要文件使跨平台以一致的方式对凭据进行序列化，这无疑是首先采用WS-Security的推动力之一。

鉴于WS-Security自2002年以来就已发展，因此解决了困扰该领域的早期采用者的大多数互操作性问题就不足为奇了。 例如，早期甚至在平台上传递简单的UserName令牌都是一个挑战。 现在，关于格式的协议已经存在了很长时间，以至于最新版本的Web服务平台已成功地就实现达成了协议。 规范的其他方面也存在相同类型的挑战，只是最终要解决最常见的情况。 今天，最常见的实现WS-Security的场景包括：

• UserName令牌而不是传输安全性 ：这可能是当今保护服务安全的最流行方法，因为许多人认为它可以满足其实现需求的“足够好的安全性”。
• 基于消息安全性的UserName令牌 ：在需要保护可能通过某种形式的中介（例如路由器）传递的消息的情况下使用此令牌 。 在这些情况下，邮件安全性可以减少责任-我认为应尽可能使用。
• 相互证书认证 ：这通常在业务伙伴方案中使用，该方案通过X.509证书代替用户名和密码来标识呼叫者。 在某些情况下，出于授权和审核跟踪的目的，使用X.509证书来证明原始伙伴，同时还提供UserName令牌来标识对服务进行呼叫的特定用户。

Kerberos令牌身份验证对于Intranet方案也很重要，但通常不用于暴露在防火墙外部的Web服务。 SAML在涉及联邦的场景中也非常常用，我将在稍后讨论。

您会发现Java和WCF平台在SSL和消息安全性进行签名和加密的情况下，对于WS-Security的这些常见场景具有很好的互操作性。

WS-SecureConversation：OASIS标准，2007年3月

WS- SecureConversation是描述减少减少多个呼叫交换的开销的安全会话的概念的规范。 通过使用WS-SecureConversation协议在调用方和服务之间进行初始交换来生成安全上下文令牌（SCT），并且该令牌用于认证后续消息交换（类似于SSL握手）。 在此交换期间生成的安全会话标识符也用于关联会话中的消息。

该协议是提高单发消息安全性性能的非常重要的标准，其中，每次呼叫都传递凭据，并为每个呼叫进行身份验证。 通过协商创建共享会话密钥，用于签名和加密消息的密钥大小会变小（使用对称密钥而不是非对称密钥），这也减少了处理开销。

尽管WS-SecureConversation直到最近才被批准，但已在多个Java平台和WCF中实现-因此，如今可以使用该协议实现互操作性。 话虽这么说，但如果今天想让您的Web服务吸引更多的用户，则应该公开带有WS-SecureConversation和不带有WS-SecureConversation的替代配置，以免限制可以与您的服务进行通信的客户端平台的数量。 引入会话对负载平衡也有影响，因为它暗示Web服务平台必须缓存安全会话标识符并将其与经过身份验证的调用者相关联。 平台缓存此信息的位置可以确定是否必须在安全会话中将呼叫者定向回同一台服务器。

WS-SecureConversation在OASIS委员会WS-SX下列出： http ://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx。

WS-Trust：OASIS标准，2007年3月

WS- Trust是一种可互操作的协议，支持安全令牌的发行，更新和交换。 如WS-SecureConversation协议所述，该协议用于发布安全上下文令牌，但它也是联合安全模型的关键。 在联合安全性模型中，WS-Trust支持身份验证或授权活动的委派，以使称为令牌发行者或安全令牌服务（STS）的集中式服务负责发行将被应用程序服务接受的安全令牌。 尽管理论上任何令牌格式都可以由STS发出，但是SAML令牌非常流行，因为它们是一种可互操作的XML令牌格式，可用于标识调用者，甚至描述其对应用程序功能的权利。

图2展示了一个简单的场景，其中应用程序服务请求调用者提供由特定的受信任STS发出的SAML令牌。 在这种情况下，向STS提供了UserName令牌，并返回了可用于向应用程序服务进行身份验证的SAML令牌。 WS-Trust Issue（）操作负责对调用方进行身份验证，如果成功，则生成可被应用程序服务使用的令牌。 令牌由STS进行数字签名，因此应用程序服务可以验证它来自受信任的来源，并且在途中未被篡改。 对于这种情况，通常应用程序服务和受信任的STS由同一组织拥有。

图2：使用WS-Trust的简单令牌发行场景 。

基于WS-Trust的联合身份模型使构建独立于特定凭证类型的调用授权的应用程序服务成为可能。 该服务没有在服务中包括为Internet合作伙伴认证UserName令牌和为内部用户认证Kerberos令牌的逻辑，而是在两种情况下都请求了受信任的SAML令牌，并将凭据支持和身份验证留给了受信任的STS。 如果STS以后增加了对不同凭据的支持，则对应用程序服务没有影响，因为它们继续依赖SAML令牌。 STS还可以请求SAML令牌，这些令牌描述经过身份验证的调用者在特定服务和操作的上下文中所拥有的权限，从而将授权委派给STS。

为了支持令牌发行，任何平台都可以通过遵循协议的准则来实现可互操作的WS-Trust端点-但是您不太可能从头开始构建自己的。 相反，要实现一个简单的令牌发行模型，您可以使用STS的一种社区实现（为Java或WCF平台编写），并对其进行修改以满足您的特定需求。 这将节省您大量的精力。 为了提高企业质量，您很可能会选择产品实现，例如Ping Identity的PingTrust或Microsoft的ADFS（Active Directory联合身份验证服务）-后者将在下一版本中支持基于Web服务的联合身份验证。 使用这两种方法，互操作性将取决于许多因素，包括WS-Trust实施，STS支持的用于身份验证的令牌格式以及STS可以发布的令牌格式。

WS-Trust当前列在OASIS委员会WS-SX下： http ://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx。

WS联合会：公开草案，2006年12月

WS-Federation是基于WS-Security，WS-SecureConversation和WS-Trust建立的规范，以支持跨信任域的身份联合，并支持映射身份以支持单点登录和注销。

WS-Federation有两个配置文件：

• 被动请求者配置文件 ：PingFederate和ADFS等产品当前支持此配置文件，以启用基于浏览器的单一登录（SSO）和身份联合。
• 活动请求者配置文件 ：PingTrust当前支持此配置文件，以后，ADFS也将支持此配置文件，以支持基于Web服务的身份联合。

WS-Federation解决了与SAML（安全性断言标记语言）2.0类似的问题，但可与其他WS *协议（例如与可靠消息传递和事务相关的协议）组成。 因此，当您希望将企业级联盟合并到解决方案中时，必须注意域中的参与者实现了哪些协议。 诸如PingFederate和PingTrust之类的产品均支持SAML 2.0和WS-Federation。 自由联盟支持SAML 2.0； ADFS和Windows Live ID仅支持WS联合身份验证。

WS-Federation的公共草案最近已被接受作为OASIS WSFED技术委员会的输入： http ://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsfed。 在这个委员会的领导下，SAML 2.0和WS-Federation标准希望融合。

可靠的通讯协议

可靠的消息传递协议旨在通过以下方式提高应用程序的可靠性：

• 可以保证消息能够一次准确有序地传递，而不会受到网络连接中短暂的干扰。
• 这些交付保证与特定协议无关，因此，例如HTTP协议的可靠性是可能的。
• 支持端到端可靠性，因此消息传递在多跳上是可靠的。
• 可靠性基于整个SOAP消息，而不仅仅是单个IP​​数据包。

图3展示了可靠消息传递如何跨平台工作的高级视图。 这个想法是，客户端（发起方）和服务（接收方）的平台都保留用于传出和传入消息的缓冲区，并且在“可靠会话”的持续时间内，等待消息回执的确认，然后再从缓冲区中删除消息。 在某些可配置的超时时间内未确认的消息会重新发送一些可配置的重试次数，以帮助克服网络连接中的间歇性打ic。

图3：可靠消息传递的高级视图。

WS-可靠性：OASIS标准，2004年11月

WS- Reliability协议早在许多其他WS *之前就已被OASIS批准。 它描述了如何实现可靠的消息传递，但不考虑事务，安全会话和其他WS *协议。 仍然有一些平台支持此规范。

WS-ReliableMessaging：OASIS标准，2004年11月

WS- ReliableMessaging协议比WS-Reliability具有更多的行业支持，并且确实考虑了WS *协议栈。 尽管尚未批准该规范，但许多平台都实现了该规范。 实际上，WS-RX OASIS小组委员会（ http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx ）将使这两个标准融合在一起以减少混淆。

尽管显然希望基于消息的可靠性是可取的，但是鉴于平台支持仍然是相当新的，因此对于广泛的支持，您将希望公开带有或不带有WS-ReliableMessaging支持的服务。 另外，像安全会话一样，可靠的消息传递意味着可能需要与缓存该会话的特定服务器机器具有亲和力的会话。

交易相关协议

WS-Coordination，WS-AtomicTransaction和WS-BusinessActivity是可互操作的协议，它们支持跨平台边界的分布式事务。 自2007年3月起，该协议集已被批准为OASIS标准。WS-Coordination定义了一种协议，用于在协调上下文中注册参与者，并将该协调上下文跨边界传递。 WS-AtomicTransaction和WS-BusinessActivity表示这种协调上下文的实现。 WS-AtomicTransaction促进了基于消息的两阶段提交（2PC）协议，而WS-BusinessActivity促进了可能涉及补偿交易的长期运行的交易。

少数平台已经支持带有WS-AtomicTransaction的WS-Coordination-使得可以跨平台，通过HTTP协议以及可能通过防火墙分布事务。

如今，当您拥有交易的所有参与者或与各方（平台除外）建立牢固的信任关系时，您更有可能考虑实施支持交易的服务。 要让您的服务加入一个鲜为人知的客户控制的交易中，会使您的服务面临参与不确定交易和资源锁定的风险。 在启用Internet的Web服务中启用事务支持之前，请仔细考虑。

这些交易协议在OASIS委员会WS-TX中列出： http ://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx。

元数据协议

如果没有一种方法来描述Web服务的需求-它的操作，其消息格式以及对WS *协议的支持-平台将不可能提供提高开发人员生产率并提高实现的整体一致性可靠性所必需的工具。 实际上，正是这种工具才真正使互操作性成为现实目标。 WSDL使无需WS *的应用程序消息传递成为可能。 WS-Policy和WS-MetadataExchange添加到WSDL中以支持WS *。

WS-Policy：W3C成员提交，2006年4月 。

WS-Policy描述了服务的扩展协议功能和要求，以及诸如MTOM，安全性，可靠的消息传递和事务之类的WS *功能。 另外，WS-Policy描述了如何将这些策略声明直接或作为WS-PolicyAttachment中描述的附件包括在WSDL文档中。 对于WS *，WS-Policy就是标准的SOAP消息传递。

WS-Policy背后的想法是，平台最终会将WS-Policy断言作为WSDL的一部分公开，以描述对WS *功能的支持。 因此，必须同意一组特定的策略声明，以描述每个功能。 已经存在一些这样的示例：

• WS-SecurityPolicy ：描述令牌，消息保护和服务支持的其他安全性功能，如本文档所述 。
• WS-ReliableMessaging策略 ： 本文档中描述了对服务的WS-ReliableMessaging功能支持。
• WS-AtomicTransaction的策略 ：描述了在WS-AtomicTransaction规范描述的服务，WS-AtomicTransaction的功能支持在这里 。

WS-Policy是一个可扩展的标准，如果您要为服务定义定制协议，它也允许创建定制断言。 关键是WS-Policy是可扩展的，并且可以用作描述应发现的所有WS *功能的基础。 WSDL中记录的所有内容（包括策略断言）都可以用于为客户端生成代码和配置-从而提高开发人员的生产力。 如今，WS-Policy尚未得到批准，并且平台之间还没有广泛支持WS-Policy。 WCF确实广泛使用此功能来促进元数据交换和代理生成，并且Sun的Tango之类的项目已证明与WCF产生的WS-Policy具有互操作性。

WS-MetadataExchange：公开草案，2006年8月

WS-MetadataExchange协议支持发现WSDL文档，WS-Policy设置以及与特定服务关联的消息和类型架构。 SvcUtil使用此协议从服务描述生成WSDL文档。 这使工具可以以编程方式发现需求以生成代理和配置，但也便于请求WSDL的特定部分，包括策略部分或操作详细信息。 该协议对其他WS *实现（例如与联合安全性相关的实现）很重要，例如，有时有时需要动态发现所需的凭据才能登录到STS。

WS *互操作性

从1999年首次引入SOAP到今天，我认为大多数人都可以同意，使用“普通SOAP”的平台之间的互操作性故事已经走了很长一段路。 通常来说（意味着“几乎所有时间”）都存在兼容性，因为已经解决了大多数常见问题，涉及一致地生成和解释WSDL，以及XML解析器通过模式描述的序列化类型的解释。

对于每个WS *协议，从早期采用和测试开始都有类似的发展。 最初发布； 供应商实施； 实现稳定。 尽管诸如MTOM，WS-Addressing和WS-Security之类的标准已在很大程度上达到了实现的稳定性，但其他最新的标准（如WS-Trust，WS-ReliableMessaging和WS-AtomicTransaction）仍处于供应商实施的早期阶段。

直到供应商的实现和工具处于开发人员不需要调整配置或XML来实现互操作性的程度时，才能达到广泛采用这一标准的目的，但是参与早期采用阶段的人员可以帮助实现这一目标。通过稳定现实用例。 历史已经证明，WS *工具最终可以工作到使开发人员可以生成服务并生成客户端代码的程度，而无需阅读每个65页的规范来理解所采用标准的XML。 它取决于您是否想要或非常需要使用WS *功能，是否愿意在批准标准之前以及在其早期实施中采用这些标准。

在本文中，我重点介绍了WS *协议，这些协议专门实现了跨平台边界的分布式消息传递-寻址，大消息支持，安全性，可靠的消息传递，事务和更相关的元数据交换。 希望您能对这些标准的目的有一个了解，并对它们的采用状况有一个高层次的了解。

翻译自: https://www.infoq.com/articles/ws-standards-wcf-bustamante/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

web 服务标准