Douglas C. Schmidt
通信应用的开发者必须致力于应对在开发中反复出现的、与效率、可扩展性和健壮性相关的设计挑战。这些挑战常常独立于应用特有的需求。成功的开发者通过应用适当的模式和模式语言来解决这些挑战。但是，传统上，这些模式被锁在专家级开发者的头脑里、或是深埋在复杂的系统源码中。本论文的主要目的是描述一种作为面向对象通信软件基础的模式语言。除了描述该语言中的各种模式，论文还阐释了为什么了解模式间的关系及权衡可以帮助指导可复用通信构架和应用的构造。
通信软件是一组构造现代分布式系统及应用（比如Web服务、分布式对象、协作式应用，以及电子商务系统[1]）的服务和协议。构建、维护和增强高质量的通信软件是困难的。开发者必须对许多复杂问题有深入了解，比如服务的初始化和分布、并发控制、流控制、错误处理、事件循环集成，以及容错。在由有经验的软件开发者所创建的成功的通信应用中必定包藏着这些问题的有效解决方案。
将成功的通信软件解决方案的本质与特定实现的细节分离开来并非是不重要的。即使软件使用组织良好的面向对象（OO）构架和组件编写，要确定关键的角色和关系仍有可能是很困难的。而且，操作系统（OS）平台特性，比如多线程的有无；或是应用需求，比如最优努力 vs. 容错错误处理，常常是不同的。这些不同可能会掩盖在同一领域的不同应用的解决方案之间、其底层体系结构的共性。
捕捉成功的通信软件的核心共性是相当重要的，因为：
1. 它为负责增强和维护现有软件的程序员保存了重要的设计信息。这些信息常常只驻留在起初的开发者的头脑中。因此，如果没有明确地为这些设计信息编写文档，它们就有可能随时间而消逝，从而增大软件的熵，并降低软件的可维护性和质量。
2. 它有助于对正在构建新通信系统的开发者的设计选择进行指导。通过为它们的领域中常见的陷阱和缺陷编写文档，模式可以帮助开发者选择适当的体系结构、协议和平台特性，而不用将时间和努力浪费在（重新）实现低效或易错的解决方案上。
本论文的目的是通过例子来演示捕捉和传达成功的通信软件的本质的途径；在文中描述了用于构建应用级网关（gateway）的模式语言，该网关在分布在整个通信系统中的对端（peer）之间进行消息路由。模式所表示的是构建软件时所发生的问题的成功解决方案[2]。当相关模式被编织在一起，它们就构成了一种语言，有助于：
－ 为讨论软件开发问题定义词汇表；以及
－ 为这些问题的有序解决提供步骤。
通过确定通信软件开发中的基本挑战，研究和应用模式及模式语言可帮助开发者增强他们的解决方案的质量。这些挑战包括开发者之间的体系结构知识的交流；适应新的设计范式或体系结构风格；消除非功能性的压力，比如可复用性、可移植性和可扩展性；以及避开通常只能通过昂贵的“试－错”方法来学习的开发陷阱和缺陷[3]。
本论文根据模式语言来介绍应用级网关的OO体系结构和设计；该语言用于指导可复用和网关专用的构架及组件的构造。应用级网关对于可*性、性能和可扩展性有着严格的要求。因此，它们是介绍出现在大多数通信软件中的关键模式的结构、参与者和效果的极好样本。
本论文中描述的模式语言是在构建广泛的通信系统时揭示的，其中包括在线交易处理系统、电信交换管理系统[4]、电子医学成像系统[5]、并行通信子系统[6]、航空任务计算[7]，以及实时CORBA对象请求代理（ORB）[8]，等等。尽管这些应用中的特定需求不一样，其通信软件设计挑战却是相似的。因此，该模式语言含有专家的设计经验，可被广泛地复用于通信软件领域，其范围远远超出了在本论文描述的网关例子。
本论文的余下部分组织如下：1.2概述应用级网关的OO软件体系结构；1.3使用应用级网关作为例子，检查该模式语言中的模式，它们构成了可复用通信软件的基础；1.4对这些模式和文献中的其他模式进行比较；1.5给出结束语。
网关是使网络上相互协作的对端去耦合、并使它们进行交互、而又不直接相互依赖的中介者[2]。如图1-1所示，通过网关路由的消息含有封装在路由消息中的有效负载。图1-2演示应用级网关的软件体系结构中对象之间的结构、关联，以及内部和外部动力特性。该体系结构基于为多种研究和产品通信系统开发网关所积累的大量经验。在我们构建了许多网关应用之后，下面的事实变得清楚起来：它们的软件体系结构极大地独立于用于将消息路由给对端的协议。这样的认识使得图1-2中描述的组件已为其他的数千通信软件项目所复用[1]。能如此有系统地复用这些组件的能力源于两个因素：
1. 对通信软件领域中关键模式的动作和交互的理解。模式在比源码和OO设计模型（它所关注的是个体的对象和类）更高的水平上捕捉软件体系结构中的参与者的结构和动力特性。在本论文中描述的某些通信软件模式已经分别建立了文档[1]。尽管个体的模式描述捕捉了有价值的专家设计经验，然而复杂的通信软件系统常含有许多模式；理解这些模式之间的关系对于推动解决在构建通信软件时所产生的巨大挑战、以及相应的文档编写来说是必需的。因此，1.3根据一种用于通信软件的模式语言来描述这些模式之间的交互和关系。在该语言中的模式协同工作来解决通信软件领域里的复杂问题。
2. 对实现这些模式的OO构架的开发。识别在许多通信软件系统中普遍出现的模式有助于使可复用构架组件的开发成形。本论文所基于的网关系统使用ACE自适配通信环境构架[9]来实现，ACE提供了集成的可复用C++包装外观（wrapper fa?ade）和组件来完成常见的通信软件任务。这些任务包括事件多路分离、事件处理器分派、连接建立、路由、应用服务的动态配置，以及并发控制，等等。此外，ACE构架还含有1.3描述的模式实现。但是，这些模式比它们在ACE中的实现要丰富得多，并且已被其他许多通信系统所应用。
图1-1 对端和应用级网关的结构和动力特性
这一部分描述怎样复用和扩展多种ACE组件，以实现图1-2所示的通信网关中的应用无关的和应用特有的组件。在此综述之后，1.3检查在ACE组件之下的模式语言。
图1-2 OO网关软件体系结构
图1-2中的大多数组件都基于ACE组件，后者可被复用于其他通信系统中。唯一不能被广泛复用的组件是Supplier和Consumer Handler，它们实现的是与消息格式和网关的路由协议有关的应用特有的细节。网关中应用无关组件的行为概述如下：
进程间通信（IPC）组件：SOCK Stream、SOCK Connector和SOCK Acceptor组件封装Socket网络编程接口[9]。这些组件使用包装外观模式来实现[1]，该模式通过使开发者与低级、乏味和易错的Socket级编程屏蔽开来、简化了可移植通信软件的开发。此外，它们构成了下面描述的更高级的模式和ACE组件的基础。
事件多路分离组件：Reactor是基于1.3.3描述的反应堆模式的OO事件多路分离机制。它通过单一的多路分离点来在事件驱动的应用中引导外部的刺激。该设计允许单线程应用高效地在事件句柄之上等待、进行事件多路分离、并分派事件处理器。事件指示某件重要的事情已经发生，例如，新的连接或工作请求的到达。网关中主要的事件源是（1）连接事件，指示建立连接的请求，以及（2）数据事件，指示封装各种有效负载的路由消息，比如命令、状态消息和大块数据传输。
初始化和事件处理组件：在端点间建立连接涉及两种角色：（1）被动角色，在特定的地址上初始化通信端点，并被动地等待其他端点连接它，以及（2）主动角色，主动地发起连接到一或多个扮演被动角色的端点。Connector（连接器）和Acceptor（接受器）是分别为初始化网络服务而实现主动和被动角色的工厂[2]。这些组件实现1.3.5中描述的接受器－连接器模式。网关使用这些组件来与对端建立连接，并生成初始化了的Supplier和Consumer Handler。
为增加系统灵活性，连接可通过以下两种方式建立：
1. 从网关到对端，常常在网关最初启动时、为建立对端的初始系统配置而进行。
2. 从对端到网关，常常在系统运行后、无论何时有新对端想要发送或接收路由消息时进行。
在大型系统中，可能会有数打或数百对端连接到单个网关。因此，为加速初始化，网关的Connector可以异步地、而不是同步地发起所有连接。异步有助于在长延迟路径上（比如在卫星或长距陆基链路上构建的广域网（WAN））降低连接响应延迟。在Connector中包含的底层SOCK Connector[9]提供低级的异步连接机制。当SOCK Connector经由TCP连接两个Socket端点时，它生成SOCK Stream对象，并将其用于在对端和网关之间交换数据。
消息多路分离组件：Map Manger（映射管理器）高效地将外部id（比如对端路由地址）映射到内部id（比如Consumer Handler）。网关使用Map Manger来实现Routing Table（路由表），后者在内部处理发给网关的消息的多路分离和路由。Routing Table将对端发送的路由消息中包含的寻址信息映射到适当的Consumer Handler集。
消息排队组件：Message Queue（消息队列）[9]提供一种通用的排队机制，由网关用于在消息等待被路由给对端时、在Consumer Handler中对它们进行缓冲。可配置Message Queue来在单线程或多线程环境中高效而健壮地运行。当队列被实例化时，开发者可以选择所需的并发策略。在多线程环境中，Message Queue使用Monitor Object（管程对象）模式[1]来实现。
在图1-2中仅有两个组件（Supplier和Consumer Handler）是特有于网关应用的。这些组件实现1.3.6中描述的非阻塞缓冲式I/O（Non-blocking Buffered I/O）模式。Supplier和Consumer Handler驻留在网关中，在那里它们被用作路由消息的初始源和目的地的代理；这些消息会被发送给在网络上的主机。这两种网关特有组件的行为概述如下：
Supplier Handler：Supplier Handler负责将到来的消息路由给它们的目的地。当Reactor在连接的通信端点上检测到事件时，它就会通知Supplier Handler。在Supplier Handler从该端点上接收完整的路由消息之后，它查询Routing Table，以确定消息的Consumer Handler目的地集。随后它请求选中的Consumer Handler转发消息给适当的对端目的地。
Consumer Handler：Consumer Handler负责将路由消息可*地递送给它们的目的地。它实现了一种流控制机制，以缓冲由于暂时的网络拥塞或接收者缓冲区空间匮乏、不能立即发送而导致的路由消息的爆发。流控制是一种传输层机制，它确保源对端的数据发送速度不会超过目的对端缓冲和处理数据的能力。例如，如果目的对端的缓冲区空间耗尽，底层的TCP协议就会指示相关联网关的Consumer Handler停止发送消息，直到目的对端消耗了它现有的数据为止。
网关通过定制、实例化及组合上面描述的ACE组件，集成了应用特有和应用无关的组件。如图1-3所示，Supplier和Consumer Handler继承自共同的祖先：由Connector和Acceptor生成的ACE Svc Handler类。每个Svc Handler都是一个远地相连对端的本地代理[2]。它包含的SOCK Stream使得对端可以通过已连接的Socket句柄交换消息。
图1-3 Consumer和Supplier Handler继承层次
Consumer Handler是根据非阻塞缓冲式I/O模式来实现的。因而，它使用ACE Message Queue来串连未发送的消息，其顺序为这些消息在流控制机制允许时所必须遵循的递送顺序。在被流控制的连接重又开放后，ACE构架通知它的Consumer Handler，后者就开始通过发送消息给对端来排空Message Queue。
为提高可*性和性能，本论文中描述的网关利用了传输控制协议（TCP）。TCP为应用级网关提供了一种可*、有序、非重复的字节流服务。尽管TCP连接天生是双向的，从对端发送给网关的数据使用了与从网关发送给对端的数据不同的连接。以这样的方式分离输入连接和输出连接有若干优点：
－它简化了网关Routing Table的构造；
－它允许更为灵活的连接配置和并发策略；
－它增强了可*性，因为如果在一个连接上发生错误，Supplier和Consumer Handler可独立地重新连接。