松耦合的介绍
最近，人们越来越热衷于比较应用程序交互的松耦合方法和紧耦合方法。造成这个趋势的主要技术原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、发现和集成)等标准，Web服务可以动态地发现和绑定到其他服务。而主要业务原因是：企业越来越需要灵活地处理业务流程的更改以及与合作伙伴的交互方式。
传统上，业务流程是在企业范围，甚至在企业的不同业务单元内开发。这些活动在详细的实时信息的帮助下进行管理。跨多个业务单元或跨企业的流程必须更加灵活，以应对各种各样的需求。在这种情况下，可能出现更多的不确定性：参与者及其角色不断变化，所需的交互类型也不断变化。
在运营状况起伏不定的环境下，必须有一个松耦合架构，以降低整体复杂性和依赖性。松耦合使应用程序环境更敏捷，能更快地适应更改，并且降低了风险。除此之外，系统维护也更方便。在B2B领域，由于要求业务实体之间独立交互，因此松耦合显得尤为重要。业务合作伙伴之间的关系变化莫测，联合关系时而建立，时而又断绝，还需要在商业合作伙伴之间建立业务流程以满足市场的要求。两家公司在某一市场是合作伙伴，而在另一市场却可能是竞争对手。底层IT基础结构要适应这样的灵活性和独立性要求。理想情况下，业务关系应当互不影响：在建立新型业务关系时，不对已有的业务关系造成影响。为一个业务合作伙伴提供的功能或许不应当供给另一个合作伙伴；与一个业务合作伙伴相关的更改不应对其他合作伙伴造成影响。一个商业合作伙伴不应为了等待一个同步响应，而阻塞另一个合作伙伴。IT系统的可用性也不应依赖于业务合作伙伴IT系统的技术可用性。
所谓“耦合”，指将两个元素像链子一样连接在一起。在软件领域，“耦合”一般指软件组件之间的依赖程度。那么，什么是依赖？各种依赖对耦合度和松散度有多大影响？软件耦合可以发生在许多级别。必须区分生成时(编译时)依赖和运行时依赖。在分布环境中，为了确定系统的耦合程度，必须分析各个级别。表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环境中，松耦合可能是惟一可选的解决方案。大多数情况下，利用松耦合来增加灵活性都会引来相应的代价：增加系统复杂度。为了运用更高级松耦合系统概念，开发工作会更繁重，对开发人员的技术要求也更高，还必须购买价格不菲的队列系统产品。但从长远看，如果经常调整耦合系统，则松耦合投资会引来丰厚回报。
当今的企业应用程序环境混杂着多种不同技术和分布概念。一方面，这是由历史原因、各人偏好及收购和兼并造成的(甚至在同一个组织单元也存在多个冗余概念)；另一方面，企业中存在的各种补充概念和技术加重了复杂性。在一个企业中，不同类型的分布问题产生不同的需求，导致了不同解决方案共存的局面。
现代架构必须支持所有这些技术和概念。异质性(包括中间件的异质性)的存在是一个基本事实，我们无法阻止它，却可有效地管理它。另外，架构必须适应底层分布基础结构的不断变化。当今基础结构产品与企业应用程序的生命期大多不同，必须保护现有应用程序环境的资产，并能利用最新的基础结构产品。
通过本章的学习，您可了解到精心选择正确方法来集成两个分布式软件组件的必要性。您必须选择正确的通信基础结构、同步、调用语义和中介，并在“面向对象”和“以数据为中心”的接口之间做出选择。所有这些决策都会影响两个系统的耦合程度。