普遍认为,基于 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 定义所包含的内容也要多,它是一种能够满足服务生命周期中所有相关参与者的需要的事物。
评论