鉴于松耦合是SOA的基础，我觉得对于云计算也是这样，也许对于将松耦合分解成为很多基础模式，这会是个不错的主意，这些基础模式包括：位置独立性、通信独立性、安全独立性和实例独立性。

　　位置独立性引用了不管服务在哪里的概念，需要利用这个服务的其余组件在目录中发现它，并通过后期绑定流程利用它。当你利用服务持续地改变物理和逻辑位置时，迟早会用到，尤其是服务在组织外部，你可能还没有已交付的云资源。你的风险评估服务可能只是在周一提议上存在，而在周二在云端，这对你来说没什么不同。

　　动态探索是这个概念的关键所在，意味着调用组件可以按需定位服务新，不必紧密绑定服务。通常这些服务是私有的、共享的或者他们享有目录内的公共服务。

　　通信独立性意味着所有组件可以互相通信，不管他们在接口或者协议层怎样通信。因此，我们利用授权标准，像Web服务，调解协议和接口区别。

　　安全独立性引入了调节安全模型之间和组件之间的不同的概念。这种方式实现起来有点困难，但是对于任何SOA是必须的。为了实现这种模式，你必须利用联合安全系统，该系统能够创建组件之间的信任，无论什么对于组件的是安全模型。这是若干联合安全标准背后的主要驱动力，这些标准的出现为了支持松耦合模型和web服务。

　　实例独立性意味着架构应该支持组件到组建的通信，这种通信使用同步和异步模型，在收到希求或者消息之前不需要其他组件在任何特定状态。因此，如果正确执行，所有服务应该能够异步地服务于任何请求组件，无论顺序是怎样的，也能够记住消息状态。

　　云计算解决方案内对于松耦合架构的需求实际不是个问题。如果你正确地利用云计算，除了一些极特殊的情况，你应该有一个松耦合架构。然而分析师和计划也是混合的一部分……理解你的需求以及架构的每个组件应该如何利用架构内的其他组件。让松耦合来帮助你吧！