兵马未动粮草先行 SOA落地首先定义标准

近些年在一些与标准相关的活动中我们已经有了非常多的SOA，Web服务 以及REST方面的文章和演示材料。大多数人都同意标准对于防止厂商锁定和保证异构实现间的互操作性是非常重要的。然而，最近Steve Jones提出了一个重要的问题，这个问题是标准该用在SOA生命周期中的何处？正如他所言，开发者和业务所有者们在（SOA）最开始需要标准的时候并未定义标准的做法让他很惊讶。对于技术标准（如WS-*）而言，Steve认为实在没有什么好的理由支持在开始时就不去定义标准。尽管这篇文章适用于很多技术，Steve在文章的开头就集中在REST上，他说：

说“但这是REST”（译者注：言外之意是这不是SOA）并声称所有的事情将是动态的，这样的说法就是一种借口，而实际上只能说明你懒。

进而他向使用REST的开发者们阐述了这句话的含义。

1. 认同你如何发布资源的规范，如何描述“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生命周期开始时就选择合适的标准是非常重要的第一步，而且这一步仍然被很多执行者所忽视，也因此带来了相应的问题。

来源：INFOQ

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友