ACE应用-第3章 应用模式语言开发可扩展ORB中间件

　

Douglas C. Schmidt     Chris Cleeland

　

　

　

　

有四种趋势正在塑造商业软件开发的未来。首先，软件工业正在从“从零开始”的应用编程迁移到使用可复用组件来集成应用[1]。其次，分布式技术提供远地方法调用和/或面向消息的中间件来简化应用协作，软件开发者对这样的技术有着巨大的需求。第三，业界正在努力定义标准的软件基础组织构架、以允许应用在异种环境间无缝地协同工作 [2]。最后，下一代分布式应用，比如视频点播、电话会议以及航空控制系统，要求保证响应时间、带宽和可*性的服务质量(QoS) [3]。

顺应这些趋势的一种关键软件技术是分布式对象计算（DOC）中间件。DOC中间件便利了在异种分布式环境中本地和远地应用组件的协作。它的目标是消除开发和发展分布式应用和服务的许多麻烦、易错和不可移植的方面。特别地，DOC中间件使得一些常见的网络编程任务得以自动化，比如对象定位、实现启动（也就是，服务器和对象启用）、封装不同体系结构的字节序和参数类型大小的差异（也就是，参数整编）、容错，以及安全。对象请求代理（ORB）是DOC中间件的心脏，比如CORBA[4]、DCOM[5]，以及JAVA RMI[6]。

本论文描述我们怎样应用模式语言来开发和发展可动态配置、比静态配置的中间件要更容易扩展的ORB中间件。一般而言，通过将相关解决方案族应用于标准的软件开发问题，模式语言有助于减少软件概念和组件的持续的重新发送和发明[7]。例如，要为常见通信软件体系结构中的参与者之间的角色和关系编写文档，模式语言是十分有用的[8]。本论文中介绍的模式语言是在[9]中介绍的模式语言的一般化，并已被成功地用于构建灵活、高效、事件驱动和并发的通信软件，包括ORB中间件。

为使我们的讨论更集中，本论文介绍了一项个案研究，演示我们怎样将此模式语言应用于开发The ACE ORB（TAO）[10]。TAO是可自由使用、高度可扩展的ORB，它瞄准的是有实时QoS需求的应用，包括航空任务计算[11]、多媒体应用[12]，以及分布式交互模拟[13]。可扩展设计是TAO的新颖之处，它的ORB在模式语言的指导下，能够进行动态定制、以满足和适应特定应用的QoS需求和网络/终端系统特性。

本论文的余下部分组织如下：3.2给出CORBA和TAO的综述；3.3说明使用动态配置的动机，并描述一种模式语言，用以应对在开发可扩展ORB时所面临的关键设计挑战； 3.3.5评价并量化模式语言对ORB中间件的贡献；3.4给出结束语。

　

　

这一部分概述CORBA参考模型，并描述TAO提供给高性能和实时应用的增强特性。

　

　

CORBA对象请求代理（ORB）[14]允许客户调用分布式对象上的操作，而不用关心以下问题：

　

对象位置：CORBA对象可以与客户共驻一处，或是分布在远地服务器上，而不会影响它的实现或使用。

　

编程语言：CORBA支持的语言包括C、C++、Java、Ada95、COBOL，以及Smalltalk，等等。

　

OS平台：CORBA运行在许多平台上，包括Win32、UNIX、MVS，以及实时嵌入式系统，比如VxWorks、Chorus和LynxOS。

　

通信协议和互连：CORBA可在以下通信协议和互连上运行：TCP/IP、IPX/SPX、FDDI、ATM、Ethernet、Fast Ethernet、嵌入式系统底板，以及共享内存。

　

硬件：CORBA使应用和源于硬件多样性的副作用（比如不同的存储方案和数据类型大小/范围）屏蔽开来。

　

图3-1演示CORBA参考模型中的组件，它们相互进行协作来提供上面概述的可移植性、互操作性和透明性。

　

　

图3-1 CORBA参考模型中的组件

　

CORBA参考模型中的每个组件概述如下：

　

客户（Client）：客户是一种获取对象的引用、在其上调用操作以执行应用任务的角色（role）。对象可以在远地、或与客户共驻一处。客户可以像访问本地对象那样访问远地对象，也就是，使用object->operation(args)。图3-1显示下面描述的底层ORB组件怎样将远地操作请求从客户透明地传送给对象。

　

对象（Object）：在CORBA中，对象是OMG接口定义语言（IDL）接口的的实例。各个对象被对象引用（object reference）所标识，对象引用与一或多个路径相关联，通过这些路径客户可以访问服务器上的对象。对象ID将对象与它的实现（称为仆人，servant）相关联，它在对象适配器（Object Adapter）的范围内是唯一的。在对象的生存期内，有一或多个仆人与其关联，以实现它的接口。

　

仆人（Servant）：此组件实现由OMG IDL接口定义的操作。在面向对象（OO）语言（比如C++和Java）中，仆人使用一或多个类实例来实现。在非OO语言（比如C）中，仆人通常使用函数和结构来实现。客户从不与仆人直接交互，而总是通过对象引用所标识的对象来进行。以对象作为RefinedAbstraction、仆人作为ConcreteImplementor，对象和它的仆人共同构成了桥接（Bridge）模式[15]的一种实现。

　

ORB核心（ORB Core）：当客户调用对象上的操作时，ORB核心负责将请求递送给对象；如果有任何响应，就将其返回给客户。ORB核心是作为链接进客户和服务器应用的运行时库来实现的。对于远地执行的对象、遵循CORBA的ORB核心通过General Inter-ORB Protocol（GIOP）的一种版本（比如运行在TCP传输协议之上的Internet Inter-ORB Protocol，IIOP）来进行通信。此外，还可以定义定制的Environment-Specific Inter-ORB Protocol（ESIOP）。

　

ORB接口（ORB Interface）：ORB是可通过多种方式（例如，通过一或多个进程或一组库）实现的抽象。为使应用与实现细节去耦合，CORBA规范定义了ORB的接口。该ORB接口提供标准的操作来初始化和关闭ORB、将对象引用转换为字符串或反向转换，以及为通过动态调用接口（dynamic invocation interface，DII）发送的请求创建参数表。

　

OML IDL Stub和Skeleton：IDL Stub和Skeleton分别被用作客户及仆人与ORB之间的“胶水”。Stub实现代理（Proxy）模式[15]，并提供强类型的静态调用接口（SII）；该接口将应用参数整编（marshal）为通用的消息级表示。相反，Skeleton实现适配器（Adapter）模式[15]，并将消息级表示“去整编”为对应用来说有意义的有类型参数。

　

IDL编译器（IDL Compiler）：IDL编译器将OMG IDL定义转换为自动生成的Stub和Skeleton；其源码采用某种应用编程语言，比如C++或Java。除了提供编程语言透明性，IDL编译器还消除了常见的网络编程错误来源，并可以进行自动的编译器优化[17]。

　

动态调用接口（DII）：DII允许用户在运行时生成请求，对于不具有所访问接口的编译时知识的应用来说这是有用的。DII还允许客户发出缓召的同步调用（deferred synchronous call），使请求与两路（two-way）操作的响应部分去耦合，从而避免客户会阻塞到仆人响应为止。CORBA SII Stub同时支持同步和异步两路操作，也就是，请求/响应操作；以及单路操作，也就是，“只请求”操作。

　

动态Skeleton接口（DSI）：DSI是客户的DII在服务器端的对应物。DSI允许ORB将请求递送给仆人，而这些仆人不具有所实现的IDL接口的编译时知识。发出请求的客户不需要知道服务器ORB是使用静态Skeleton还是动态Skeleton。同样地，服务器也不需要知道客户是使用DII还是SII来调用请求的。

　

对象适配器（Object Adapter）：对象适配器是使仆人与对象相关联的合成组件，它创建对象引用、将到来的请求多路分离给仆人，并与IDL Skeleton协作，以分派仆人上适当的操作upcall。对象适配器使得ORB能够支持各种类型的具有类似需求的仆人。这样的设计产生了更小更简单的ORB，可以支持广泛的对象粒度、生存期、策略、实现风格和其他特性。

　

接口仓库（Interface Repository）：接口仓库提供关于IDL接口的运行时信息。使用这些信息，程序有可能遇到在程序编译时其接口还属未知的对象，并且仍然能够确定在该对象上的合法操作，并使用DII来发出调用。此外，接口仓库还提供公共区域来存储与CORBA对象的接口相关联的其他信息，比如Stub和Skeleton的类型库。

　

实现仓库（Implementation Repository）：实现仓库[18]包含的信息允许ORB启用服务器来对仆人进行处理。实现仓库中的大多数信息都是特定于某种ORB或OS环境的。此外，实现仓库还提供了公共区域来存储与服务器相关联的信息，比如管理控制、资源分配、安全，以及启用模式。

　

　

TAO是高性能实时ORB终端系统，其应用目标是具有确定性和可统计QoS需求、以及最优努力（best-effort）需求的应用。TAO的ORB终端系统含有图3-2中所示的网络接口、OS、通信协议，以及遵循CORBA的中间件组件和服务。TAO支持标准的CORBA参考模型[14]和实时CORBA规范[19]，并且，它还具有一些增强特性，可用于确保高性能及实时应用的高效、可预测和可伸缩的QoS行为。此外，TAO也可以很好地适用于一般的分布式应用。下面，我们概述图3-2中所示的TAO组件的特性。

　

　

图3-2 TAO实时ORB终端系统中的组件

　

优化的IDL Stub和Skeleton：IDL Stub和Skeleton分别执行应用操作参数的整编和去整编。TAO的IDL编译器生成的Stub/Skeleton可以有选择地使用高度优化编译的和/或解释式的（去）整编[20]。这样的灵活性允许应用开发者有选择地对时间和空间需求进行权衡，这对于高性能、实时、和/或嵌入式分布系统来说是至关紧要的。

　

实时对象适配器（Real-time Object Adapter）：对象适配器使仆人与ORB相关联，并将到来的请求多路分离给仆人。TAO的实时对象适配器使用理想哈希[21]和主动式多路分离[22]优化来在恒定的O（1）时间内分派仆人操作，而不管IDL接口中定义的活动连接、仆人及操作的数目。

　

运行时调度器（Run-time Scheduler）：TAO的运行时调度器[19]将应用QoS需求（比如限定端到端响应时间以及满足定时调度最后期限）映射到ORB终端/网络资源（比如CPU、内存、网络连接，以及存储设备）。TAO的运行时调度器同时支持静态[10]和动态的[23]实时调度策略。

　

实时ORB核心（Real-time ORB Core）：ORB核心将客户请求递送给对象适配器，并将响应（如果有的话）返回给客户。TAO的实时ORB核心[24]使用多线程、占先式、基于优先级的连接和并发体系结构[20]来提供高效和可预测的CORBA协议引擎。TAO的ORB核心允许将定制的协议插入ORB，而不会影响标准的CORBA应用编程模型[25]。

　

实时I/O子系统（Real-time I/O subsystem）：TAO的实时I/O（RIO）子系统[26]把对CORBA的支持扩展进OS中。RIO分配优先级给实时I/O线程，以实施应用组件和ORB终端系统资源的可调度性。在与高级硬件集成时（比如下面描述的高速网络接口），RIO可以（1）及早在优先级化的内核线程上执行I/O事件的多路分离，以避免基于线程的优先级调换，以及（2）维护清晰的优先级流，以避免基于包的优先级调换。TAO还可以高效地，并尽可能地在缺乏高级QoS特性的传统I/O子系统上可预测地运行。

　

高速网络接口（High-speed network interface）：“菊花链”（daisy-chained）网络接口是TAO的I/O子系统的核心，它含有一或多个ATM端口互连控制器（APIC）芯片[27]。APIC被设计用于维持2.4 Gbps的双向合计数据率，使用零复制缓冲优化来避免在终端层之间复制数据。TAO还运行在传统的实时互连上，比如VME底板和多处理器共享内存环境；以及TCP/IP上。

　

TAO内部情况（TAO internals）：TAO的开发使用了称为ACE[28]的较低级中间件。ACE实现通信软件的核心并发和分布模式[8]，并且提供可复用的C++包装外观和构架组件来支持高性能实时应用和像TAO这样的较高级中间件的QoS需求。ACE和TAO运行在广泛的OS平台上，包括Win32、大多数版本的UNIX，以及实时操作系统，比如Sun/Chorus ClassiX、LynxOS和VxWorks。

　

为加速实现我们的项目目标，并避免重新发明已有的组件，我们在SunSoft IIOP之上对TAO进行开发。SunSoft IIOP是可自由使用的Internet Inter-ORB Protocol（IIOP）版本1.0的C++参考实现。尽管SunSoft IIOP提供了CORBA ORB的核心特性，它还是有以下局限：

　

缺乏标准的ORB特性：尽管SunSoft IIOP提供了ORB核心、IIOP 1.0协议引擎，以及DII和DSI实现，它还缺乏IDL编译器、接口仓库和实现仓库，以及可移植对象适配器（Portable Object Adapter，POA）。TAO实现了所有这些遗漏的特性，并提供了更新的CORBA特性：异步方法调用[29]、实时CORBA[19]特性[30]，以及容错CORBA特性[31, 32]。

　

缺乏IIOP优化：由于大量的整编/去整编开销、数据复制，以及很高的函数调用开销，SunSoft IIOP在高速网络上执行得很糟糕。因此，我们应用了一系列优化法则模式[22]，显著地改善了它的性能[33]。指导我们的优化法则包括：（1）为常见情况进行优化，（2）消除不必要的浪费，（3）用高效的专用方法来替换通用方法，（4）如果可能，预先计算值，（5）存储冗余状态，以加速昂贵的操作，（6）在层与层间传递信息，以及（7）为处理器缓存亲缘性进行优化。

　

本论文并不讨论TAO怎样解决上面概述的SunSoft IIOP的局限，[10, 20]对它们进行了详细讨论。相反，我们关注TAO怎样在使用模式保留它的QoS能力的同时、实现克服了以下SunSoft IIOP局限的ORB：

　

缺乏可移植性：像大多数通信软件应用一样，SunSoft IIOP是直接使用低级网络和OS API（比如socket、select和POSIX Pthreads）编写的。这些API不仅麻烦而易错，它们还不能跨平台移植，例如，许多操作系统都缺乏Pthreads支持。3.3.3.1演示我们怎样使用包装外观（Wrapper Fa?ade）模式[15]来改善TAO的可移植性。

　

缺乏可配置性：像许多ORB和其他中间件一样，SunSoft IIOP是被静态配置的，这使得不直接修改源码、就难以对其进行扩展。这违背了TAO的一个关键设计目标：对不同应用需求和系统环境的动态适配。3.3.3.7和3.3.3.8解释我们是怎样使用抽象工厂（Abstract Factory）[15]、策略（Strategy）[15]和组件配置器（Component Configurator）[8]模式来为不同的使用情况简化TAO的配置的。

　

缺乏软件内聚性：像许多应用一样，SunSoft IIOP专门解决特定的问题，也就是，实现ORB核心和IIOP协议引擎。它使用紧耦合的、特定的、且将关键ORB设计决策硬编码的实现来完成这一工作。3.3.3.7和3.3.3.6阐释我们怎样使用抽象工厂和策略来减少不必要的耦合，并在将SunSoft IIOP发展为TAO时增加内聚性。

　

　

使用ORB中间件的一个关键动机是将复杂、较低级的分布式系统基础构造任务从应用开发者处转移到ORB开发者那里。ORB开发者负责实现可复用的中间件组件，由它们来处理连接管理、进程间通信、并发、传输端点多路分离、调度、分派、（去）整编，以及错误处理。这些组件通常被编译进运行时ORB库中、与使用ORB组件的应用对象链接，并在一或多个OS进程中执行。

尽管这样的事务分离可以简化应用开发，它还有可能会产生不灵活和低效的应用及中间件体系结构。其主要原因是许多传统ORB都是由ORB开发者在编译时和链接时静态配置的，而不是由应用开发者在安装时或运行时动态配置的。静态配置的ORB有以下缺点[28]：

　

不灵活性：静态配置的ORB将各个组件的实现与内部ORB组件的配置紧密地耦合在一起，也就是，哪些组件一起工作以及它们怎样一起工作。结果，对静态配置的ORB进行扩展需要修改已有源码。在商业的非开放源码的ORB中，应用开发者可能无法获得这些代码。

即使源码可用，扩展静态配置的ORB还需要重新编译和链接。而且，任何目前正在执行的ORB及其相关对象都必须关闭并重启。这样的静态重配置过程对于某些应用领域并不很适用，比如需要7 * 24可用性的电信呼叫处理[34]。

　

低效率：静态配置的ORB在空间和时间两方面都可能是低效的。如果不必要的组件总是被静态地配置进ORB中，就可能会产生空间的低效率。这可能会增加ORB的内存占用，迫使应用为它们不需要的特性付出空间代价。对于嵌入式系统，比如蜂窝电话或电信中继线卡[35]，过大的内存占用是特别成问题的。

时间低效则可能来自限制ORB使用静态配置的算法或数据结构来处理关键任务，从而使得应用开发者难以定制ORB来处理新的使用情况。例如，实时航空控制系统[11]常常可以离线地实例化它们的所有仆人。这些系统可以从这样的ORB中获益：它使用理想哈希或主动式多路分离[36]来将到来的请求多路分离给仆人。因而，对于关键任务系统来说，被静态配置以使用通用的、“一劳永逸”的多路分离策略（比如动态哈希）的ORB的执行可能会很糟糕。

　

理论上，上面描述的静态配置的缺点是内在于ORB的，不应该直接影响应用开发者。但是实际上，应用开发者会不可避免地受到影响，因为ORB中间件的质量、可移植性、可用性，以及性能都被降低了。因此，改善ORB可扩展性的有效方式是开发可进行静态和动态配置的ORB中间件。

通过动态配置，开发者可以有选择性地集成关键ORB策略（比如连接管理、通信、并发、多路分离、调度，以及分派）的定制实现。这样的设计使得ORB开发者能够集中关注ORB组件的功能，而不用过早地使自己陷入这些组件的的特定配置。而且，动态配置还使得应用开发者和ORB开发者能够在系统生存期的后期（也就是，在安装时或运行时）改变设计决策。

　

　

图3-3 ORB可扩展性维度

　

图3-3演示以下ORB可扩展性的关键维度：

　

下面，我们沿着上面概述的每一维度描述用于增强TAO的可扩展性的模式语言。

　

　

这一部分使用TAO作为个案研究，演示通过降低组件间的耦合来帮助应用和ORB开发者构建、维护和扩展通信软件的模式语言。图3-4显示该模式语言中我们用于为TAO开发可扩展ORB体系结构的模式。详细地描述每一模式、或讨论TAO中使用的所有模式已超出了本论文的范围。相反，我们聚焦于关键模式是怎样改善实时ORB中间件的可扩展性和性能的。[9, 15]中的参考文献有对这些模式的全面描述，[8]解释这些模式是怎样被编织在一起来构成模式语言的。

　

　

图3-4 将模式语言应用于TAO

　

下面概述这一语言中的模式的意图和使用：

　

包装外观（Wrapper Fa?ade）[8]：该模式将现有非OO API所提供的功能和数据封装在更为简洁、健壮、可移植、可维护和内聚的OO类接口中。TAO使用此模式来避开OS专有的系统调用（比如Socket API或POSIX线程）的麻烦、不可移植，以及非类型安全的编程。

　

反应堆（Reactor）[8]：该模式构造事件驱动的应用、特别是服务器，它们从多个客户那里并发地接收请求，但依次对它们进行处理。当I/O事件在OS中发生时，TAO使用此模式来同步地通知ORB特有的处理器。反应堆模式驱动TAO的ORB核心中的主事件循环，接受连接并接收/发送客户请求/响应。

　

接受器－连接器（Acceptor-Connector）[8]：该模式使连接建立及服务初始化与服务处理去耦合。TAO在服务器和客户上的ORB核心中使用此模式，以被动和主动地建立独立于底层传输机制的GIOP连接。

　

领导者/跟随者（Leader/Followers）[8]：该模式提供一种高效的并发模型，在其中多个线程轮流享有一组事件源，以检测、多路分离、分派和处理发生在事件源上的服务请求。TAO使用此模式来便利多种并发策略的使用；这些策略可在运行时被灵活地配置进ORB核心。

　

线程专有存储（Thread-Specific Storage）[8]：该模式允许多个线程使用“逻辑上全局”的访问点来获取相对于线程来说的局部对象，而又不会为每次访问对象带来锁定开销。TAO使用此模式来使实时应用的锁竞争和优先级调换最小化。

　

策略（Strategy）[15]：该模式提供的抽象用于从若干候选算法中进行选择，并将其包装进对象中。在整个软件体系结构中，TAO大量地使用此模式来为并发、通信、调度和多路分离配置自定义ORB策略。

　

抽象工厂（Abstract Factory）[15]：该模式提供单一组件来构造多个相关对象。TAO使用此模式来将它的成打的策略对象合并进一些可管理的抽象工厂中，这些工厂可一起被方便而一致地重配置进客户和服务器中。TAO组件使用这些工厂来访问相关策略，而不用明确地指定它们的子类名。

　

组件配置器（Component Configurator）[8]：该模式允许应用在运行时链接它的组件实现，或解除其链接，而不必修改、重编译或静态重链接此应用。它还支持将组件重配置进不同的进程中，而不必关闭和重启运行中的进程。TAO使用此模式来动态地替换抽象工厂实现，以在运行时定制ORB的特性。

　

组成此模式语言的模式的使用并不局限于ORB或通信中间件。它们已被应用于其他许多通信软件领域中，包括电信呼叫处理和交换、航空航班控制系统、多媒体电话会议，以及分布式交互模拟，等等。

TAG: 开发 ACE应用 可扩展 ORB 中间件