[笔记]Loose Couple Dimensions，松耦合的维度

在Infoq的文章SOA的十大原则 ，专门提到了松耦合。松耦合是老生常谈了，不过这篇文章则用了好几个维度来描述：

时间 ：当参与者在时间上是松耦合时，它们不需要在同一时间启动并进行通讯。这要求两者之间采用某种缓冲或队列机制，尽管这种机制与松耦合无关。当参与的一方向另一方发送消息时，交互的继续不依赖于逻辑上或物理上能否立即返回应答消息。

在互联网时代，这个需求逐渐明显，因为我们已经习惯了各种网络应用，例如我自己深度依赖Gmail, Google Docs。然而一旦断网，就只能干瞪眼。幸好Google推出Gear ，成功将互联网应用与浏览器松耦合，极大的扩充了互联网应用的可用性。

另外在企业应用中，同一时段会收到不同类型的用户请求。如果某些请求的及时性要求不迫切的话，将其置入队列中，就能在在保证业务功能完整的情况下，无需其他投资而提高了应用的性能。

位置 ：如果一方参与者查询与之通信的另一方参与者的地址，另一方的地址可以透明地进行变更，不需要重新编程、重新配置或者甚至不需要通信伙伴的重新启动。这意味着查找（lookup）过程采用某种目录或地址来存储服务终端的地址。

这里提到不需要“重新配置”，在企业应用中我觉得需要商榷。因为这的确就以为需要一个目录服务，而且目录服务本身的位置永远不能改变。而应用每次访问服务之前都要执行一次查找动作是否值得呢？我可以倾向于可以重新配置，但是要做到动态配置，即无需重启应用。

类型 ：同静态与动态，弱类型与强类型这些编程的概念类似，参与者既可以全部依赖也可以部分依赖文档结构来实现它的功能。

在ESB的项目中这倒是比较常见，我们使用的是Oracle Service Bus ，一般采用xml作为交换格式。既然实际格式是文本，那么两边应用的具体类型就无所谓了，例如字符串“2009-03-06 21:24:20”，在服务端是日期类型，而在客户端是字符类型。

版本 ：参与者可以依赖服务接口的特定版本，也可以兼容某个范围内的版本。所需匹配的版本越确切，参与者在这个方面上的松耦合性就越差。一个好的原则是遵循 Postel法则 （译 者注：Postel’s Law——“Be liberal in what you accept, and conservative in what you send.”）：服务提供者应尽可能兼容许多不同的版本，这将使它更加健壮（可能甚至需要容错），服务使用者应尽可能遵循精确的语法和文档类型。这将增加 整个系统的稳定性和灵活性。

在SOA的首期项目，根本没有所谓的“版本”问题，而随着项目的渐渐演变，版本问题就渐渐暴露出来了。尽管基于Oracle Service Bus 的丰富特性可以应付一些版本问题，但还是服务接口的初始设计其决定作用。我觉得解决“版本”问题，SOA的十大原则 提到的“面向文档”是一个很好的工具，因为面向文档能够灵活应对接口的变化。

这里的Postel’s Law——“Be liberal in what you accept, and conservative in what you send " ，中文意思应该就是我们常常说的“严以待己，宽以待人 ”。服务端的程序设计必须严格遵循相应的架构规范、设计模式和最佳实践，但是就要允许客户端以各种古灵精怪、不合逻辑的方式进行交互，这样的服务端就会更将强壮，而版本变化则不在话下了。

基数 ：服务消费者和提供者可能是1对1的关系，尤其是在请求或响应交互发生时，或队列被明确使用的情况下。在别的情况下，服务使用者（在这种情况下，称作“消息发送者”或“事件源”更为合理）可能既不知道也不关心有多少人接受了消息。

这段文字有点不容易读，我理解为交互双方是一对一，或者一对多的关系。现在一般都是通过“主题队列”的订阅机制来实现一对多的关系。

查找 ：参与者打算调用服务时，既可以依赖服务提供者的物理名或逻辑名，也可以先通过一组功能描述来执行查找（lookup）操作。这意味着存在一个注册表和（或）仓库，对存储其中的使用者需求和提供者能力进行直接或间接的匹配。

这段话讲的不够直白，我的理解就是如果应用要使用一个天气预报的服务，那么应用可以首先到某个地方查找能够提供天气预报能力的服务，然后使用它。说实话， 我还从来没有看过能够在“运行时”做到这一点的，曾经有一些SOA的项目标书提到这个特性，除了让销售多买一些Repository Server外，就不曾在项目实施中出现过了。

对于将使用者需求和提供者能力进行直接或间接的匹配 ，我认为只是应该在“设计时”进行，而且当企业部署了上百个服务后是很有必要的。不过我这里着重的是企业应用，不晓得互联网应用中有否在运行时进行功能查找的真实案例。

接口 ：参与者可能要绑定到一个特定的服务接口或是支持一个通用的接口。如果使用通用接口，所有该接口的使用者都能与所有该接口的提供者进行交互。尽管可能乍看起来这有些笨拙，但单一通用（统一）接口的原则就是WWW架构的核心

通用接口的确是WWW的核心，不同产商的浏览器可以自如的和不同产商的Web服务器进行交互，这就是通用接口带来的奇迹。不过我对通用接口的理解还不够深 刻，这几天在看一些关于REST的争论也常常提到统一接口的问题，需要做进一步了解。我对如何在企业应用中的采用单一通用接口比较感兴趣。

---------------------------感想分割线 ---------------------------

其实松耦合真的是老生常谈，但这种多维度的分析还是让人眼前一亮的。将问题进行分解，然后分别描述是一种简单而有效的方法。在讨论问题的时候，容易泛泛而谈没有重点，或者紧紧揪住某个细节陷入其中，这个时候，如果有人说“这个问题嘛，应该分成几个方面来看，…… ”，这个人往往会被大家佩服。

其实也是，当我们开始试图从多个角度看待一个问题时，就更加能够看清问题的真相，找到相应的解决方法，而如果能够做到麦肯锡所倡导的“相互独立，完全穷尽 ”就更加完美了。