松耦合的对比

松耦合的对比

所谓“耦合”，指将两个元素像链子一样连接在一起。在软件领域，“耦合”一般指软件组件之间的依赖程度。那么，什么是依赖？各种依赖对耦合度和松散度有多大影响？软件耦合可以发生在许多级别。必须区分生成时(编译时)依赖和运行时依赖。在分布环境中，为了确定系统的耦合程度，必须分析各个级别。表3-1简要介绍了这些级别，以及这些级别与紧耦合-松耦合的关系。
表3-1 紧耦合与松耦合 级 别 紧 耦 合 松 耦 合 物理耦合 需要直接的物理链接 物理中介 通信方式 同步 异步 类型系统 强类型系统（例如接口语义） 弱类型系统（例如载荷语义） 交互模式 以OO方式导航复杂对象树 以数据为中心，独立消息 过程逻辑的控制 集中控制处理逻辑 分布式逻辑组件 服务发现和绑定 静态绑定服务 动态绑定服务 平台依赖性 对操作系统和编程语言的依赖性高 独立于操作系统和编程语言 下面将详细分析表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环境中，松耦合可能是惟一可选的解决方案。大多数情况下，利用松耦合来增加灵活性都会引来相应的代价：增加系统复杂度。为了运用更高级松耦合系统概念，开发工作会更繁重，对开发人员的技术要求也更高，还必须购买价格不菲的队列系统产品。但从长远看，如果经常调整耦合系统，则松耦合投资会引来丰厚回报。
当今的企业应用程序环境混杂着多种不同技术和分布概念。一方面，这是由历史原因、各人偏好及收购和兼并造成的(甚至在同一个组织单元也存在多个冗余概念)；另一方面，企业中存在的各种补充概念和技术加重了复杂性。在一个企业中，不同类型的分布问题产生不同的需求，导致了不同解决方案共存的局面。
现代架构必须支持所有这些技术和概念。异质性(包括中间件的异质性)的存在是一个基本事实，我们无法阻止它，却可有效地管理它。另外，架构必须适应底层分布基础结构的不断变化。当今基础结构产品与企业应用程序的生命期大多不同，必须保护现有应用程序环境的资产，并能利用最新的基础结构产品。
通过本章的学习，您可了解到精心选择正确方法来集成两个分布式软件组件的必要性。您必须选择正确的通信基础结构、同步、调用语义和中介，并在“面向对象”和“以数据为中心”的接口之间做出选择。所有这些决策都会影响两个系统的耦合程度。