普遍认为，基于 SOAP 的 Web 服务的主要复杂点之一是使用 Web 服务描述语言（WSDL）进行服务接口的描述。 William Vambenepe 指出 WSDL 的另一问题是，WSDL 和随之诞生的 stub 生成工具创建的分布式应用程序之间是紧密耦合的。人们开始意识到的是服务描述的问题，而不是如何改进它。
……所以，他们完全抛弃服务描述的想法。在当今 API 的时代，从描述应用程序契约的角度看，我们没有比 15 年前好到哪里去。这是个悲剧。
Vambenepe 在博文中探讨了支持其观点的两个（关于服务描述的）重大误区。
-
试图为服务寻找到真正的服务描述。Vambenepe 认为，找不到这样的服务描述。 > 对服务描述进行优化，使之满足特定的需求而不是自动着重于语法校验，这绝对是很好的。服务契约的所有客户并一定使用相同的服务描述。对于不同用户和 / 或用途，完全可以使用不同的服务描述。
尽管 Vambenepe 在其博文中谈论的主要是既定服务的不同格式，但是他的观点却有着更广的意义。作为技术人员，在很长一段时间内，我们所关注的只是面向开发人员的服务描述（API 定义），往往忽视了业务分析员的需要，而对于某个服务是否适用于特定的企业解决方案，做此决定的人却是业务分析员。通常， 除了“传统的”API 描述（服务描述）之外，他们还需要服务的其他相关信息，例如：
- 该服务提供哪些业务功能？
- 该服务有哪些限制？
- 该服务能够支持的 SLA？
- 服务请求者必须满足那些要求才能正确地调用服务？
- 特定的执行结果在何种条件下产生？
-
自动基于服务描述进行消息校验。Vambenepe 指出，有了服务描述并不意味着一定要对消息进行校验： > 服务描述还有许多其他用途，但都被忽视了，原因是人们过多关注在语法校验和 stub 生成之上。
博文中列出的服务描述的其他用途有：
- 用于附着策略和 SLA。Vambenepe 解释： > WSDL 常常用于……附着策略和 SLA。若为了该目的，你就不一定需要 XSD 消息定义……你需要的只是一种途径来标识策略和 SLA 所附着的操作。我们 可以使用一种比 WSDL 更简单的描述语言来完成该任务。但是，如果你全盘抛弃了描述语言的各个方面，这就好比把婴儿（对服务处理的请求进行分类，即操作 ）和洗澡水（语法校验机制）一起倒掉。
- 治理 / 版本控制。发现服务定义变更的能力： > 服务描述文档的一个好处是，你能知晓服务定义的变更。即便你将获取的信息降低到一个简单值（如，在我上次查看后有无变更？是 / 否） ，它仍然也是有价值的。如果你能对（服务）描述文档进行检查，进而找到那些请求受到变更的影响，那就更好了。并且，还能知道变更是否是向后兼容（backward-compatible）的。
规范的服务描述无疑是重要的。而且，WSDL 的缺点不应成为全盘抛弃它的原因。如果服务描述的下一版本能够超越今天的 WSDL 或 Web 应用描述语言（WADL）——“机器可读的”服务描述，那当然很好。服务包含的内容比 API 多得多，它是建立解决方案的基本成分。所以，服务描述比 API 定义所包含的内容也要多，它是一种能够满足服务生命周期中所有相关参与者的需要的事物。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论