近些年在一些与标准相关的活动中我们已经有了非常多的 SOA ， Web 服务 以及 REST 方面的文章和演示材料。大多数人都同意标准对于防止厂商锁定和保证异构实现间的互操作性是非常重要的。然而，最近 Steve Jones 提出了一个重要的问题，这个问题是标准该用在 SOA 生命周期中的何处？正如他所言，开发者和业务所有者们在（SOA）最开始需要标准的时候并未定义标准的做法让他很惊讶。对于技术标准（如 WS-*）而言，Steve 认为实在没有什么好的理由支持在开始时就不去定义标准。尽管这篇文章适用于很多技术，Steve 在文章的开头就集中在 REST 上，他说：
说“但这是 REST”（译者注：言外之意是这不是 SOA）并声称所有的事情将是动态的，这样的说法就是一种借口，而实际上只能说明你懒。
进而他向使用 REST 的开发者们阐述了这句话的含义。
- 认同你如何发布资源的规范，如何描述“GET”和“POST”是做什么的？ 2. 创建一些“服务”和资源的示范以及相关级别的文档供人们使用。
3. 认同围绕 Mocking/Proxying 的流程，使得人们能够在不需要等到最终解决方案完成之前就可以验证和测试他们的解决方案。
4. 认同对资源的测试流程以及你如何及时地确认这些资源符合了既定的系统需求。
Steve 通过一个个人的例子（去年，有些没脑子的人曾对我说，因为这是 REST，所以资源本身就是能够描述它的行为的规范）阐述了他对 REST 的观点，该观点相似于 Bill Burke 在的宣布 REST-* 时所提出的观点：
大部分关于 REST 的描述都是使用人类网络作为例子的，我这里的人类网络指的是浏览器和使用这些浏览器的人。在我看来基于机器的客户端与 REST 架构的交互，在（REST）初生时就有了。企业 IT 通常使用特定的中间件技术来实现他们的分布式应用。REST 的发明给我们带来重新审视企业 IT 开发与中间件如何交叉使用的机会。
因此，REST 中方法（标准）的缺失是那种仔细考虑并逐步迭代的方法形成的可能的原因之一，Steve 曾提到并且讨论过该方法。然而，如Steve 在本文中提出的，如果你选择了Web 服务作为实现方式，那么你就实在没有理由忽视过年10 年间发展出的那些标准。 WS-I Basic Profile 1.1 以及 SOAP 1.1 是必需，而 WSDL 的版本（1.1 还是 2.0）则取决于你的服务所使用的交互模式：
现在如果你需要回调，WSDL2.0 中提供了这种机制而且它具有很多技术优势。但是，当你要和不遵循 WS-I 的平台交互时，你会碰到一些很粗糙的 XML 编组和消息头冲突。你可以根据 WSDL2.0 去定义你本地的 WS-I 合规版本，但是大多数情况下你最好不要把资金浪费在寻找一种像样的设计和简单的方法之上——如针对某些特定的流程元素有标准的匹配的格式，通过传递要调用的服务名字就能通过某注册库解析出要进行回调的正确服务。
拿 WS-* 中的各种标准来说，Steve 认为只有少数几个才是核心的：WS-Security 和 WS-Reliable Messaging（大概 WS-Addresssing 是缺省的核心成员，因为现在 OASIS 正需要它）。如他所言，即便是对这些标准的选择还仅仅是第一步，因为在实施时，如果真正要做的话，同样重要的还有选择标准的版本。一些 Web 服务栈声称的合规性实际上是基于规范在标准化之前的发布，或者是面向旧标准的，这可能会致使它们益处甚少。最后，Steve 想对那些抱怨 HTTP 的性能的人说：
另一方面是认同 HTTP 是你的标准传输机制。严肃地说，现在已经是 2010 了，现在是人们该停止对“性能”的嘀咕并提出新的消息传输方式的时候了。如果你实拥有性能问题的话，那么你就要裁剪信息，使用二进制，然而 99.999% 的情况下这是没有意义的，并且，你最好不要用 HTTP 或 HTTPS。
总之，Steve 提出了一些重要的观点：标准很好，但是简单地提供口头的服务无益于 SOA 开发者和业务所有者。在 SOA 生命周期开始时就选择合适的标准是非常重要的第一步，而且这一步仍然被很多执行者所忽视，也因此带来了相应的问题。
暂无签名
腾讯云云原生提质增效实践精选集 2024
《2024腾讯云云原生提质增效实践精选集》出炉，5大热门技术领域，13个行业精选标杆案例，痛点到解决方案全...
评论