松耦合系统通常是基于消息的系统，此时客户端和远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配。只要消息符合协商的架构，则客户端或服务的实现就可以根据需要进行更改，而不必担心会破坏对方。
简介
松耦合通讯机制提供了
紧耦合机制所没有的许多优点，并且它们有助于降低客户端和远程服务之间的依赖性。但是，紧耦合性通常可以提供性能好处，便于在客户端和服务之间进行更为紧密的集成。
最近，人们越来越热衷于比较应用程序交互的
松耦合方法和
紧耦合方法。
造成这个趋势的主要技术原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、发现和集成)等标准，
Web服务可以动态地发现和绑定到其他服务。
而主要业务原因是：
企业越来越需要灵活地处理业务流程的更改以及与合作伙伴的交互方式。松耦合系统的优点在于更新一个模块不会引起其它模块的改变。
传统上，业务流程是在企业范围，甚至在企业的不同业务单元内开发。这些活动在详细的实时信息的帮助下进行管理。跨多个业务单元或跨企业的流程必须更加灵活，以应对各种各样的需求。在这种情况下，可能出现更多的不确定性：参与者及其角色不断变化，所需的交互类型也不断变化。
在运营状况起伏不定的环境下，必须有一个松耦合架构，以降低整体复杂性和依赖性。松耦合使应用程序环境更敏捷，能更快地适应更改，并且降低了风险。除此之外，系统维护也更方便。在B2B领域，由于要求
业务实体之间独立交互，因此松耦合显得尤为重要。
业务合作伙伴之间的关系变化莫测，联合关系时而建立，时而又断绝，还需要在商业合作伙伴之间建立业务流程以满足市场的要求。两家公司在某一市场是合作伙伴，而在另一市场却可能是竞争对手。底层IT基础结构要适应这样的灵活性和独立性要求。
理想情况下，业务关系应当互不影响：在建立新型业务关系时，不对已有的业务关系造成影响。为一个业务合作伙伴提供的功能或许不应当供给另一个合作伙伴；与一个业务合作伙伴相关的更改不应对其他合作伙伴造成影响。一个商业合作伙伴不应为了等待一个同步响应，而阻塞另一个合作伙伴。IT系统的可用性也不应依赖于业务合作伙伴IT系统的技术可用性。
对比
所谓“耦合”，指将两个元素像链子一样连接在一起。
在软件领域，“耦合”一般指
软件组件之间的
依赖程度。那么，什么是依赖？各种依赖对
耦合度和松散度有多大影响？软件耦合可以发生在许多级别。必须区分生成时(编译时)依赖和运行时依赖。在分布环境中，为了确定系统的耦合程度，必须分析各个级别。表3-1简要介绍了这些级别，以及这些级别与
紧耦合-松耦合的关系。
表3-1 紧耦合与松耦合
下面将详细分析表3-1中的各项。
在研究分布系统的“耦合”问题时，与远程组件的连接方式可能是最重要的技术因素。
物理级别
在物理级别上，物理中介支持松耦合。MOM系统松散耦合，
消息队列扮演中介角色，解耦合消息的发送者和接收者。而RPC形式的应用程序紧密耦合，因为客户端和服务器直接交互，客户端要求服务器可用、可访问，以达到交互目的。
通信方式级别
如前所述，在“
通信方式”级别上，同步和异步通信对耦合级别的影响经常与
分布式组件的物理链接密切相关。异步通信通常与松耦合相关。不过，这要求底层中间件能以松耦合方式支持异步通信。以单向RPC为例：虽然客户端不等待服务器的应答，但单向RPC仍然
紧耦合，因为只有当客户端直接连接到服务器，而且服务器正在工作和运行时，客户端才能发送单向请求。这是说明各种
耦合度的极好例子：在适当MOM基础上建立的异步通信比异步单向RPC调用的耦合程度更低。
类型系统级别
再来研究
分布式应用程序的“
类型系统”级别的“
耦合性”。可以看到，类型系统越强，系统不同组件的依赖程度也越高。无论在应用程序开发阶段，还是在更改和重新配置运行的系统时，都是如此。前面分析过“接口语义”和“载荷语义”的差别。接口语义提供了显式的接口名、操作名和强类型参数。
因此，组件在这个级别上达到紧耦合的程度，因为每次更改接口时，需要考虑依赖的组件，影响会波及到整个应用程序。这样做的好处是：可以在编译时发现受影响的应用程序部分，使其适应和反映更改，避免不兼容的消息格式引起运行时异常。载荷语义的消息格式通常更灵活，故能降低组件的耦合级别。
有些情况下，可应用消息格式验证，如XML Schema验证。但是，这要求参与者之间有效管理的最新模式定义。注意，使用载荷语义并不能消除更改消息格式的问题：开发人员必须了解受更改影响的系统部分，确保在采用新格式时，这些部分能正常运行。很多情况下，这往往意味着问题从生成时转移到运行时。
交互模式的影响
以基于ORB的系统为例，该系统通常采用
面向对象的方式在复杂对象树中导航。客户端不仅需要了解各个对象的逻辑，还必须了解如何在对象间导航，从而导致了高
耦合性。RPC形式接口不支持这类复杂导航，但与分布对象系统相比，耦合程度降低了。基于MOM的系统一般采用更简单的交互模型，单个队列通常已足以作为客户端的输入点，服务器端
事务的所有输入在单个消息中提供。
在谈到这个问题时，需要考虑系统是基于RPC形式服务构建，还是基于队列和主题而构建。一般而言，主题和队列更灵活些，通过调整队列配置及关联方式，允许在运行时更方便地更改系统。大多数MOM系统强大的配置管理极大地降低了系统组件之间的耦合程度。
另一个重要因素是处理逻辑的所有权或控制。如果集中管理过程，则不同子过程和事务之间将紧密耦合。例如，数据库机制可用于确保不同子过程所拥有数据的参考完整性和总体一致性。在大型单片式系统(如ERP)中，经常能看到这种情况。如果业务流程高度分布(例如在B2B环境)，则不同子过程和
事务通常更独立，耦合程度更低。这时，必须接受一个现实：不存在全局定义的统一过程状态。同样，不同参与者拥有的数据可能不一致：一个系统已删除了一封订单，而另一个系统仍保存着清单。
最后，系统参与者互相定位的方式对系统的
耦合级别有显著影响。
静态绑定的服务
耦合性非常高，而
动态绑定的服务则松散耦合。在命名和
目录服务器中查找服务可以降低服务之间的耦合程度，客户端只需要了解待绑定服务的准确名称即可。UDDI等服务允许使用诸如“Find me the next printer on the second floor”等约束，更灵活地定位服务。注意，UDDI为
Web服务提供的动态服务发现并不是一个新概念，在此之前，CORBA命名服务等标准也支持服务发现。过去的经验证明，需要完全动态服务发现的应用程序数量少而又少。
在制定架构决策时，必须认真分析耦合级别的优缺点。一般而言，大企业使用的
OLTP(online transaction processing），在线事务处理)应用程序对松耦合的要求不高，这些应用程序在本质上是
紧耦合的。若超出一个企业或一个业务单元的范围，例如在B2B环境中，松耦合可能是惟一可选的解决方案。大多数情况下，利用松耦合来增加灵活性都会引来相应的代价：增加系统复杂度。为了运用更高级松耦合系统概念，开发工作会更繁重，对开发人员的技术要求也更高，还必须购买价格不菲的队列系统产品。但从长远看，如果经常调整耦合系统，则松耦合投资会引来丰厚回报。
测试
鉴于松耦合是SOA的基础，我觉得对于云计算也是这样，也许对于将松耦合分解成为很多基础模式，这会是个不错的主意，这些基础模式包括：位置独立性、通信独立性、安全独立性和实例独立性。
位置独立性引用了不管服务在哪里的概念，需要利用这个服务的其余组件在目录中发现它，并通过后期绑定流程利用它。当你利用服务持续地改变物理和逻辑位置时，迟早会用到，尤其是服务在组织外部，你可能还没有已交付的云资源。你的风险评估服务可能只是在周一提议上存在，而在周二在云端，这对你来说没什么不同。
动态探索是这个概念的关键所在，意味着调用组件可以按需定位服务新，不必紧密绑定服务。通常这些服务是私有的、共享的或者他们享有目录内的公共服务。
通信独立性意味着所有组件可以互相通信，不管他们在接口或者协议层怎样通信。因此，我们利用授权标准，像
Web服务，调解协议和接口区别。
安全独立性引入了调节安全模型之间和组件之间的不同的概念。这种方式实现起来有点困难，但是对于任何SOA是必须的。为了实现这种模式，你必须利用联合安全系统，该系统能够创建组件之间的信任，无论什么对于组件的是安全模型。这是若干联合安全标准背后的主要驱动力，这些标准的出现为了支持松耦合模型和web服务。
实例独立性意味着架构应该支持组件到组建的通信，这种通信使用同步和异步模型，在收到希求或者消息之前不需要其他组件在任何特定状态。因此，如果正确执行，所有服务应该能够异步地服务于任何请求组件，无论顺序是怎样的，也能够记住消息状态。