Douglas C. Schmidt
接受器－连接器设计模式（Acceptor-Connector）使分布式系统中的连接建立及服务初始化与一旦服务初始化后所执行的处理去耦合。这样的去耦合通过三种组件来完成：acceptor、connector和service handler（服务处理器）。连接器主动地建立到远地接受器组件的连接，并初始化服务处理器来处理在连接上交换的数据。同样地，接受器被动地等待来自远地连接器的连接请求，在这样的请求到达时建立连接，并初始化服务处理器来处理在连接上交换的数据。随后已初始化的服务处理器执行应用特有的处理，并通过连接器和接受器组件建立的连接来进行通信。
图9-1 面向连接的应用级网关的物理体系
为演示接受器－连接器模式，考虑图9-1中所示的多服务、应用级Gateway（网关）。通常，Gateway使分布式系统中的协作组件去耦合，并允许它们在无需互相直接依赖的情况下进行交互。图9-1中的这个Gateway在不同的服务端点间路由数据，这些端点运行在用于监视和控制人造卫星群的远地Peer（对端）上。每个Peer中的服务经由Gateway发送和接收若干类型的数据,比如状态信息、大块数据和命令。一般而言，Peer可以分布在局域网和广域网中。
该Gateway是一个路由器，负责协调它的Peer之间的通信。从Gateway的角度来看，它为之路由数据的Peer服务仅由其应用级通信协议来进行区分，这些协议可能会使用不同的帧格式和有效负载类型。
Gateway在它的Peer之间使用面向连接的TCP/IP协议[11]来传输数据。在我们的示例网络配置中，每个服务都与一个连接端点绑定在一起；该端点由IP主机地址和TCP端口号指定。端口号唯一地标识服务的类型。为每种类型的服务/端口维护单独的连接增强了路由策略的灵活性，并提供了更为健壮的错误处理，如果网络连接意外关闭的话。
在我们的分布式应用中，Gateway和Peer必须能改变它们的连接角色，以支持不同的使用情况。特别地，或是可以主动地发起连接，或是可以被动地等待连接请求。例如，在一种配置中，Gateway可以主动地发起到远地Peer的连接，以便路由数据给它们。在另一种配置中，Gateway可以被动地接收来自Peer的连接请求，后者随即经由Gateway路由数据给另外的Peer。同样地，在一种使用情况下，Peer可以是主动的连接发起者，而在另一种使用情况下则是被动的连接接受者。
由于我们的分布式应用的天性，预先指定连接建立和服务初始化角色、并将它们硬编码进Gateway和Peer组件的传统设计太不灵活。这样的设计过度地将连接建立、服务初始化和服务处理组件耦合在一起。这样的紧耦合使得独立于通信角色改变连接角色变得很困难。
分布式系统中利用面向连接协议来在服务端点间进行通信的客户/服务器应用。
分布式应用常常含有复杂的代码，执行连接建立和服务初始化。一般而言，分布式应用中在服务端点间交换的数据的处理极大地独立于配置问题，比如（1）是哪一个端点发起连接，也就是，连接角色vs.通信角色，以及（2）连接管理协议 vs. 网络编程API。下面对这些问题进行概述：
- 连接角色 vs.通信角色：连接建立角色天然地不对称，也就是，被动的服务端点进行等待，而主动的服务端点发起连接。但是，一旦连接建立，通信角色和连接角色可以是互不相关的。因而，数据可以任意的服从服务通信协议的方式在服务端点间进行传输。常用的通信协议包括点对点、请求－响应和单路流。
- 连接管理协议 vs.网络编程API：不同的网络编程接口，比如socket或TLI，提供不同的API来使用多种连接管理协议建立连接。但是，不管用于建立连接的协议是什么，数据可以使用统一的消息传递操作来在端点间进行传输，例如，send/recv调用。
一般而言，用于连接建立和服务初始化的策略变动的频度要远小于应用服务实现和通信协议。因而，使这些方面去耦合、以使它们能独立地变化，对于开发和维护分布式应用来说是必要的。对于将连接及初始化协议与通信协议分离的问题，下面一些压力会对解决方案产生影响：
- 应该容易增加新类型的服务、新的服务实现和新的通信协议，而又不影响现有的连接建立和服务初始化软件。例如，可能有必要扩展Gateway，以与运行在IPX/SPX通信协议、而不是TCP/IP之上的目录服务进行互操作。
- 应该有可能使下面的两种角色去耦合：（1）连接角色，也就是，哪一个进程发起连接 vs. 接受连接，以及（2）通信角色，也就是，哪一个服务端点是客户或服务器。通常，“客户”和“服务器”之间的区分指的是通信角色，它们可以与连接角色不相关。例如，在发起到被动服务器的连接时，客户常常扮演主动角色。但是，这些连接角色可以反转过来。例如，扮演主动通信角色的客户可以被动地等待另一个进程对其进行连接。9.2中的例子演示了后一种使用情况。
- 应该有可能编写可以移植到许多OS平台上的通信软件，以最大化可用性和市场占有率。许多低级网络编程API的语义只是有着表面的不同，而语法却互不兼容，因而难以使用低级API，比如socket和TLI，来编写可移植应用。
- 应该有可能将程序员与低级网络编程API（像socket或TLI）类型安全性的缺乏屏蔽开来。例如，连接建立代码应完全地与后续的数据传输代码去耦合，以确保端点被正确地使用。没有这种强去耦，服务可能会错误地在被动模式的传输端点工厂上读写数据，而后者仅应被用于接受连接。
- 应该有可能通过使用像异步连接建立这样的OS特性来降低连接响应延迟。例如，有大量对端的应用可能需要异步、并发地建立许多连接。高效和可伸缩的连接建立对于运行在高响应延迟的WAN上的应用来说特别重要。
- 应该可以尽可能多地复用通用的连接建立和服务初始化软件，以有效利用先前的开发成果。
对于分布式应用提供的每个服务，使用接受器－连接器模式来使连接建立及服务初始化与由服务的两个端点在连接和初始化之后执行的后续处理去耦合。
引入两个工厂，生成已连接和初始化的服务处理器，用于实现应用的服务。第一个工厂，称为接受器，创建并初始化传输端点，被动地在特定地址上侦听来自远地连接器的连接请求。第二个工厂，连接器，主动地发起到远地接受器的连接。接受器和连接器都初始化相应的服务处理器，处理在连接上交换的数据。一旦服务处理器被连接和初始化，它们就执行应用特有的处理，一般不再与接受器和连接器进行交互。
在图9-2中通过Booch类图[2]演示了接受器－连接器模式中的参与者的结构。
服务处理器（Service Handler）：Service Handler实现应用服务，通常扮演客户角色、服务器角色，或同时扮演这两种角色。它提供挂钩方法，由Acceptor或Connector调用，以在连接建立时启用应用服务。此外，Service Handler还提供数据模式传输端点，其中封装了一个I/O句柄，比如socket。一旦连接和初始化后，该端点被Service Handler用于与和其相连的对端交换数据。
接受器（Acceptor）：Acceptor是一个工厂，实现用于被动地建立连接并初始化与其相关联的Service Handler的策略。此外，Acceptor包含有被动模式的传输端点工厂，它创建新的数据模式端点，由Service Handler用于在相连的对端间传输数据。通过将传输端点工厂绑定到网络地址，比如Acceptor在其上侦听的TCP端口号，Acceptor的open方法对该工厂进行初始化。
一旦初始化后，被动模式的传输端点工厂侦听来自对端的连接请求。当连接请求到达时，Acceptor创建Service Handler，并使用它的传输端点工厂来将新连接接受进Service Handler中。
连接器（Connector）：Connector是一个工厂，实现用于主动地建立连接并初始化与其相关联的Service Handler的策略。它提供方法，由其发起到远地Acceptor的连接。同样地，它还提供另一个方法，完成对Service Handler的启用；该处理器的连接是被同步或异步地发起的。Connector使用两个分开的方法来透明地支持异步连接建立。
图9-2 Acceptor-Connector模式的参与者的结构
当连接建立时，Acceptor和Connector都通过调用Service Handler的启用挂钩方法来将其启用。一旦Service Handler被Acceptor或Connector工厂完全初始化，它通常就不再与这些组件进行交互了。
分派器（Dispatcher）：为Acceptor，Dispatcher将在一或多个传输端点上接收到的连接请求多路分离给适当的Acceptor。Dispatcher允许多个Acceptor向其登记，以侦听同时在不同端口上从不同对端而来的连接。
为Connector，Dispatcher处理异步发起的连接的完成。在这种情况下，当异步连接被建立时，Dispatcher回调Connector。Dispatcher允许多个Service Handler通过一个Connector来异步地发起和完成它们的连接。注意对于同步连接建立，Dispatcher并不是必需的，因为发起连接的线程控制也完成服务服务处理器的启用。
Dispatcher通常使用事件多路分离模式来实现，这些模式由反应堆（Reactor）[3]或前摄器（Proactor）[4]来提供，它们分别处理同步和异步的多路分离。同样地，Dispatcher也可以使用主动对象（Active Object）模式[5]来实现为单独的线程或进程。
下面的部分描述接受器－连接器模式中Acceptor和Connector组件所执行的协作。我们检查三种规范的情况：Acceptor、异步的Connector和同步的Connector。
图9-3演示Acceptor和Service Handler之间的协作。这些协作被划分为三个阶段：
- 端点初始化阶段：为被动地初始化连接，应用调用Acceptor的open方法。该方法创建被动模式的传输端点，将其绑定到网络地址，例如，本地主机的IP地址和TCP端口号，并随后侦听来自对端Connector的连接请求。其次，open方法将Acceptor对象登记到Dispatcher，以使分派器能够在连接事件到达时回调Acceptor。最后，应用发起Dispatcher的事件循环，等待连接请求从对端Connector到来。
- 服务初始化阶段：当连接请求到达时，Dispatcher回调Acceptor的accept方法。该方法装配以下活动所必需的资源：（1）创建新的Service Handler，（2）使用它的被动模式传输端点工厂来将连接接受进该处理器的数据模式传输端点中，以及（3）通过调用Service Handler的open挂钩将其启用。Service Handler的open挂钩可以执行服务特有的初始化，比如分配锁、派生线程、打开日志文件，和/或将该Service Handler登记到Dispatcher。
- 服务处理阶段：在连接被动地建立和Service Handler被初始化后，服务处理阶段开始了。在此阶段，应用级通信协议，比如HTTP或IIOP，被用于在本地Service Handler和与其相连的远地Peer之间、经由前者的peer_stream_端点交换数据。当交换完成，可关闭连接和Service Handler，并释放资源。
图9-3 Acceptor参与者之间的协作
Connector组件可以使用两种常用方案来初始化它的Service Handler：同步的和异步的。同步的服务初始化对于以下情形来说是有用的：
- 如果建立连接的延迟非常低，例如，经由回路设备与在同一主机上的服务器建立连接；或是
- 如果有多个线程控制可用，并且使用不同的线程来同步地连接每个Service Handler有足够的效率；或是
- 如果服务必须以固定顺序初始化，而客户不到连接建立不能执行其他有用的工作。
同样地，异步服务初始化在相反的情形中是有用的：
- 如果连接延迟很高，并且有许多对端需要连接，例如，在高延迟WAN之上建立大量连接；或是
- 如果仅有单个线程控制可用，例如，如果OS平台不提供应用级线程；或是
- 如果服务被初始化的顺序不重要，或如果客户应用必须在建立连接的同时执行另外的工作，比如刷新GUI。
同步的Connector情况中的参与者之间的协作可被划分为以下三个阶段：
- 连接发起阶段：为在Service Handler和它的远地Peer之间发起连接，应用调用Connector的connect方法。该方法阻塞调用线程的线程控制、直到连接同步完成，以主动地建立连接。
- 服务初始化阶段：在连接完成后，Connector的connect方法调用complete方法来启用Service Handler。complete方法通过调用Service_Handler的open挂钩方法来完成启用；open方法执行服务特有的初始化。
- 服务处理阶段：此阶段与Service Handler被Acceptor创建后所执行的服务处理阶段相类似。特别地，一旦Service Handler被启用，它使用与和其相连接的远地Service Handler交换的数据来执行应用特有的服务处理。
同步服务初始化的协作如图9-4所示。在此方案中，Connector将连接发起和服务初始化阶段结合进单一的阻塞操作中。在此情况中，只为每个线程控制中的每次connect调用建立一个连接。
图9-4 用于同步连接的Connector参与者之间的协作
异步的Connector中的参与者之间的协作可被划分为以下三个阶段：
- 连接发起阶段：为在Service Handler和其远地Peer之间发起一个连接，应用调用Connector的connect方法。就如同同步方案，Connector主动地建立连接。但是，在连接异步完成的同时，它不会阻塞调用者的线程控制。相反，它将Service Handler的传输端点（我们在此例中将其称为peer_stream_）登记到Dispatcher，并将控制返回给它的调用者。
- 服务初始化阶段：在连接异步完成后，Dispatcher回调Connector的complete方法。该方法通过调用Service Handler的open挂钩来将其启用。这个open挂钩执行服务特有的初始化。
- 服务处理阶段：此阶段与前面描述的其他服务处理阶段相类似。一旦Service Handler被启用，它使用与和其相连接的远地Service Handler交换的数据来执行应用特有的服务处理。
图9-5演示这三个阶段的使用异步连接建立的协作。在异步方案中，注意连接发起阶段被暂时与服务初始化阶段分离开来。这样的去耦合使得多个连接发起（经由connect）和完成（经由complete）能够在各自的线程控制中并行地进行。
图9-5 用于异步连接的Connector参与者之间的协作