【中间件技术】第二部分 CORBA规范与中间件(1) CORBA基本原理

简单介绍 CORBA应用程序的基本结构——对象管理体系结构、CORBA程序通信总线 ORB 的体系结构、CORBA对于可互操作性的支持，以及 CORBA 规范、与基于 CORBA 的中间件平台等内容。

---

2.1 对象管理体系结构

2.1.1 对象管理组织与其主要规范

在学习 CORBA之前，首先了解一下负责制定和发布 CORBA 规范的组织——对象管理组织 Object Management Group, OMG ，1989年成立的非盈利性联盟。从其名字可以看到，该组织所做的工作是和面向对象技术密切相关的，主要目标是：促进分布式系统开发中面向对象技术理论与实践的发展。OMG现在有成员 $800$ 多个，包括IBM、Sun、HP、西门子、爱立信等大型信息产品供应商；也包括像Oracle、BEA、Borland等知名软件开发商；同时还包括波音、花旗等最终用户和全球众多的高校与研究机构。

OMG的技术规范主要用来支持分布式、异类环境的软件开发项目。所谓异类是指：所开发的软件所运行的环境，可能包含不同的硬件平台（如不同厂商的PC机、工作站、小型机甚至Framework）、操作系统；开发时可能使用不同的程序设计语言、不同的网络通信协议进行交互。异类环境下分布式对象与其客户端之间的可互操作性，一直是分布式系统关注的一个重点。一种中间件或规范，要支持如此异类的环境是很不容易的，CORBA规范也是经过了多次更新与扩充，才达到了一个比较理想的程度。

OMG所制定和发布的规范，覆盖了从分析、设计到编码、部署、运行和管理的整个软件开发过程。这些规范是一种工业或行业标准。什么意思呢？就是这些规范不是某一个或几个厂商根据自己的产品所提出的，而是在整个行业中大家共同遵循的标准。比如，我们要基于 CORBA 开发一套应用系统，我们可以自由选择不同厂商的 CORBA 产品，我们开发好的系统也可以比较容易的从一个厂商的平台上，迁移到其他厂商的平台上。

OMG发布的最有影响力的两套规范，一个是统一建模语言 Unified Modeling Language, UML ，另一个就是通用对象请求代理体系结构 Common Object Request Broker Architecture, CORBA 。

• UML是一套面向对象分析与设计阶段的表示技术规范，为我们提供了一种可视化的方式，用来描述一个系统的分析与设计结果。Rational公司的 Rational Rose 是目前较为流行的UML软件工具，另外还有Borland收购的TogetherSoft公司的 Together 。Rational 公司和Rose工具相关的，有一整套软件开发规范 Rational Unified Process, RUP 。
• CORBA是一套面向分布式系统的中间件规范，基于CORBA 的中间件，为应用系统提供构件管理、构件互操作、公共服务等典型支持。具体的讲，CORBA又包含一系列单独的规范，比如核心的ORB体系结构、接口定义语言 IDL 、网络通信协议 GIOP 和 IIOP 、可移植对象适配器 POA 、CORBA 组件模型 CCM 等。每一个规范都对我们开发一个分布式系统的一个侧面作了标准化。比如，IDL 就规定了我们应该如何定义分布式对象的接口。

2.1.2 对象管理体系结构

CORBA 所基于的概念框架是对象管理体系结构 Object Management Architecture, OMA ，OMA 描述了「一个基于 CORBA 的应用系统」的基本结构与「构成系统的构件」的特性。由OMG发布的 Object Management Architecture Guide 是关于 OMA 的正式规范，该指南描述了OMG的技术目标与相关术语，并为所有 CORBA 规范提供了概念性的基础设施。指南的核心内容是对象模型与参考模型，其中对象模型定义了对象外部可见特征的、独立于具体实现的语义，参考模型则标识与刻划了组成 OMA 的组件、接口与协议。

2.1.2.1 OMA 参考模型

OMA 参考模型如图2-1所示，它描述了一个基于 CORBA 的应用系统的基本结构。从图中我们可以直观地看到，软件系统由很多个构件（对象）构成，这些对象都挂接到了一个类似总线的东西上；这些对象又被划分到不同的组中。图中方框加半圆的形状，表示被封装成对象的非面向对象实现。

在 OMA 参考模型中，ORB 为构成系统的各个构件提供了通信总线，为其提供互操作的基本支持；同时，构成系统的构件又被划分到了不同的组中，这是因为：在实际的系统中，除了最基本的通信设施外，构成系统的对象还有很多共性、可以加以提取并重用。比如，在几乎每一个系统中，都会有一些对象来实现命名服务，系统其他的对象利用「该对象提供的服务」来查找和定位对象；另外在很多系统中，还会有一些对象实现安全性控制、一些对象实现事务控制等功能；再有在很多系统中，都会有一些对象来提供打印功能、电子邮件功能等面向大多数领域的工具类的功能，以及一些特定领域内通用的功能。

CORBA 规范把这些对象的共性，按照其基础性分别抽象并标准化为对象服务、通用设施和领域接口，从而导致了对象组的划分。下面对 OMA 参考模型中各构成部分进行解释。

1. 对象请求代理

对象请求代理是 OMA 参考模型的核心，它提供了分布式对象之间「透明地发送请求或接收响应」的基本机制，独立于实现对象的特定平台与技术。客户程序无需知道如何与对象通讯、如何激活对象、对象如何实现、如何查找对象等。ORB 是基于分布式对象、构建应用程序的基础，它保证了在异类网络中对象的可移植性与可互操作性。

OMG的接口定义语言 Interface Definition Language, IDL ，为定义 CORBA 对象的接口提供了一种统一标准，用 IDL 定义的对象接口，是对象实现与客户程序之间的合约。IDL 是一种强类型的说明性语言，独立于任何程序设计语言。IDL 到程序设计语言的映射，支持开发者选择自己的程序设计语言来实现对象和发送请求。

OMG发布的 CORBA: Common Object Request Broker Architecture and Specification 是关于 ORB 体系结构的规范，定义了 ORB 组件的程序设计接口。OMG发布的 CORBA languages 是一系列独立的语言映射规范，包括Java、C++、Smalltalk、Ada、C、COBOL等语言。

2. 对象服务

对象服务是 CORBA 中通用性最强的一组公共服务，这些服务要么是利用分布式对象开发的、基于CORBA的应用程序的基础，要么为应用程序的可互操作性提供与具体应用领域无关的基础。

对象服务将「覆盖对象整个生存期的对象管理任务」标准化，例如：对象服务提供的功能包括了创建对象、对象访问控制、查找对象、维持对象间关系等。这种标准化可保证不同应用程序的一致性，并提高软件开发者的生产率。

OMG的对象服务统称 CORBA Services ，OMG发布的 CORBA Services: Common Object Services Specifications, COSS 是关于对象服务的一组规范，其中包括对象命名、事件、生存期、持久对象、事务、并发控制、关系、外表化、许可机制、查询、属性、安全性、时间、对象收集、交易对象等服务的规范。

3. 公共设施

公共设施的通用性比对象服务稍低，是可用于大多数应用领域的、面向终端用户的设施，包括分布式文档设施、打印设施、数据库设施、电子邮件设施等。公共设施提供的一系列通用的应用程序功能，可为特定的应用需求进行配置，公共设施的标准化使得通用操作具有统一性，并且终端用户可方便地选择自己的配置。

OMG的公共设施统称 CORBA facilities ，OMG发布的 CORBA Facilities: Common Facilities Architectures 是描述公共设施体系结构的规范。与对象服务规范一样，公共设施规范包括了一系列用OMG IDL表达的接口定义。

4. 领域接口

领域接口是 CORBA 中通用性最低的一组公共服务，仅在特定的应用领域具备一定的通用性，是与应用领域有关的接口，例如金融、医疗、制造业、电信、电子商务、运输等应用领域，领域内通用的功能如电信领域内的电话控制功能。图2-1中的领域接口表示为一组领域的接口，暗示了开发者可按照不同的应用领域来组织领域接口。

OMG正是按不同应用领域，组织与发布一系列领域接口规范。例如，OMG已发布了制造、医疗、金融、电信等行业的规范集 CORBA Manufacturing 、CORBA Med 、CORBA Finance 、CORBA telecoms 等。OMG正在进一步完善，并将陆续推出新的领域接口规范。

5. 应用程序接口

应用程序对象为终端用户执行该系统特定的任务，因为这部分不具有通用性，所以它不是OMG标准化的内容，而是构成整个 OMA 参考模型的最上层元素。一个典型的应用程序是由大量基本的对象类构建而成的，其中部分对象与具体应用有关，部分对象则来自领域接口、公共设施与对象服务。应用程序对象可通过继承机制重用现有的对象。

应用程序只需支持或使用与OMG一致的接口，即可加入到 OMA 中，这些程序本身未必要用面向对象风格来实现。图2-1的对象服务与应用程序接口，展示了现有的非面向对象软件可以嵌入在一些对象包装器中，从而融入 OMA 体系结构。

上述的对象服务、公共设施与领域接口，构成了 CORBA 中的公共服务集合，OMG对于这些公共服务的接口均进行了标准化，并且以 IDL 的形式定义出来。厂商实现一个 CORBA 中间件平台的时候，按照接口的约定去实现命名服务、安全性控制、事务控制、打印、电子邮件、电话控制等功能，可以采用任意的实现机制。程序员在程序中，也按照接口的约定来使用这些服务（服务是由一个一个的对象提供的），而不需要关心使用的那个厂商的平台，因为它们所实现的服务都提供了相同的接口。

2.1.2.2 OMA 对象模型

OMG在 Object Management Architecture Guide 中定义的对象模型描述了对象外部特征的标准语义，CORBA 系统中对象就是【中间件技术】第一部分 概述(1) 软件构件与中间件基本概念描述的分布式对象——构件。

在对象模型中，对象、类型、操作、属性、对象实现等语义，与Java、C++等面向对象程序设计语言十分相近。在该模型中，客户程序与对象实现之间的界面是对象的接口定义。对象接口采用接口定义语言 Interface Definition Language, IDL 定义。

请求是一个在特定时刻发生的事件，它携带的信息包括操作、提供服务的目标对象引用、$0$ 个或多个实际参数、以及一个可选的请求上下文 request context 等。对象引用是可以有效地指称一个对象的对象名字；请求上下文提供了可能影响请求执行的额外信息，这些信息通常与操作有关。

请求表 request form 用于发送请求，可多次求值与执行，请求表由 IDL 与特定语言的绑定来定义，另一种形式的请求表通过调用动态调用接口 DII 创建一个调用结构，往调用结构中添加参数后可发出调用。

在OMG的对象模型中，对象可以被创建或撤销。但从客户程序的角度看，没有专门机制用于创建或撤销对象，对象创建与撤销只是发出请求的结果，分布式对象的生命周期管理工作全部收缩到服务端。这样的好处是客户端的负担轻，客户端无需关心服务端分布式对象的生命周期特性，只是根据需要使用分布式对象。

---

2.2 对象请求代理结构

对象请求代理 Object Request Broker, ORB 是 OMA 的核心基础设施，CORBA 规范规定了 ORB 的标准体系结构。ORB 负责完成「查找请求的对象实现、让对象实现准备好接收请求、传递构成请求的数据等」完成远程调用时，底层通信任务所需的全部机制。

客户程序所看到的对象接口，完全独立于对象所处的位置、实现对象的程序设计语言、以及对象接口中未反映的其他特性。为调用远程对象实现的一个实例，客户程序必须首先获取一个对象引用（以后将知道有多种方式可获取对象引用）。客户程序发出远程调用的方式与本地调用相似，只不过调用的是远程对象实例的对象引用。其后，ORB 检查对象引用，如果发现目标对象是远程的，就将参数打包、并通过网络传递给远程对象所在的 ORB 。

ORB 提供的最基本功能是从客户程序向对象实现传递请求。在逻辑上，ORB 可理解为一个由 ORB 接口定义的服务集合，但在物理上，ORB 通常不必实现为一个单独的组件（例如进程或程序库）。ORB 内核 ORB Core 是 ORB 最关键的部分，负责请求的通信设施，每一个 ORB 产品供应商都有一个自己特有的 ORB 内核。图2-2展示了 ORB 体系结构的主要组成部分以及它们之间的关系。

从图2-2可以看到，ORB 采用了 Stub/Skeleton 结构来支持客户端与分布式对象的交互，其中客户程序桩和对象实现框架与 RMI 中的作用相同。但 ORB 的体系结构显然比 RMI 更复杂，因为它不仅提供了动态调用的方式，还支持用不同的程序设计语言实现对象。

1. 对象接口

客户程序所看到的对象接口，完全独立于对象所处的位置、实现对象的程序设计语言、以及对象接口中未反映的其他特性，这种独立性是通过 ORB 来保证的。IDL 根据可执行的操作以及操作的参数来定义对象的类型，并可映射到特定的编程语言或对象系统。为能在运行时充分利用对象接口定义的有关信息，还可将对象接口定义添加到接口库 Interface Repository 服务中，该服务允许运行时动态访问接口信息。IDL 与接口库具有同等的表达能力。

客户程序只能通过对象的接口定义，掌握对象的逻辑结构，并通过发送请求来影响对象的行为与状态。客户程序不必了解对象实现的具体实现方式，也不必知道该对象实现采用哪个对象适配器、以及需要用哪个 ORB 访问该对象实现。CORBA 通过对象接口，进一步延伸了传统程序设计语言的封装与信息隐藏概念。

对象实现可以用多种方式实现，例如独立的服务程序、程序库、每个方法的程序代码、被封装的应用程序、面向对象数据库等。通过使用附加的对象适配器，ORB 事实上可支持所有风格的对象实现。通常来说，对象实现不依赖于 ORB 或客户程序调用对象的方式，如果对象实现需要使用依赖于 ORB 的服务，则需要通过选择合适的对象适配器、获得服务的接口。

2. ORB 中的 Stub/Skeleton 结构

客户程序通过发送请求，调用由对象实现提供的服务。ORB 支持客户端与分布式对象通信的最基本方式是 Stub/Skeleton 结构。通过 Stub/Skeleton 结构完成调用的方式称为静态方式，对应客户端利用 Stub 发起调用的方式称为静态调用方式，服务端采用 Skeleton 分发请求的方式称为静态请求分派方式。

采用静态方式时，ORB 产品会提供一个 IDL 编译器，在编译 IDL 文件时会创建客户程序桩与服务端框架。如果 IDL 文件进行了修改，则必须重新用 IDL 编译器创建新的桩与框架。由于桩与框架在编译时创建，并且在运行时不再改变，因而这些接口又称作静态调用接口 Static Invocation Interface, SII 。

IDL 桩负责客户程序的实现语言与 ORB 内核之间的映射，IDL 框架负责服务程序的实现语言与 ORB 内核之间的映射，只要 ORB 支持某种语言的映射，客户程序或服务程序就可选择该语言作为实现语言，并且客户程序与服务程序可以使用不同的语言。使用静态接口的程序，开发者必须在程序编译之前就知道操作的名字、所有参数与返回值的类型，实际的操作名字、参数值和返回值是编写在应用程序的源代码中。

3. ORB 中的动态调用方式

除了上面提到的静态方式外，ORB 还支持客户端与分布式对象之间采用动态方式交互。客户端可以通过动态调用方式将请求发送给 ORB 内核，对应地，ORB也可以通过动态请求分派方式将请求传递给分布式对象。

客户端的动态调用方式使用动态调用接口 Dynamic Invocation Interface, DII 完成。从发送请求的功能上看，动态调用方式与静态调用方式具有完全相同的能力（即两者的调用语义相同），对象实现不能知道、也无需知道请求从客户端是如何发出的。DII 允许客户程序调用在编译客户程序时尚未确定对象接口的对象实现。客户程序使用 DII 时必须生成一个请求，其中包括对象引用、操作以及参数表。

DII 的这种动态特性，使得 DII 在某些应用场合更优于 SII ，例如：编写 CORBA 服务的浏览器、应用程序浏览器、转换协议的桥接、访问大量不同接口、应用程序的监控、通用对象测试程序等等。使用 DII 的应用程序，访问对象实现提供的服务时，不必包含由 IDL 编译器生成的桩，只需在运行时访问 ANY 对象。当然，使用 DII 会比 SII 更麻烦，程序员必须用 DII 接口指定操作和每个参数的类型与值，并且由程序员自己利用 CORBA 定义的类型码 typecode 作类型检查。DII 类似于Java语言的自省 introspection 机制。

DII 还提供了一种延迟同步调用，使得客户程序提交请求后不必等候答复。延迟同步调用与单向 one-way 操作相似，但延迟同步调用支持返回值和输出型参数（这时必须进行轮询）。CORBA 3.0 通过异步消息服务 Asynchronous Messaging Service ，同时支持静态的和动态的延迟同步调用。

ORB 将请求分派给对象实现也有两种方式：静态方式通过由 IDL 生成的框架，动态方式使用动态框架接口 Dynamic Skeleton Interface, DSI 。除了通过静态框架外，ORB 还可通过 DSI 查找合适的实现代码、传送参数，并将控制传给对象实现，对象实现执行请求，请求完成后控制与结果返回给客户程序。

虽然 DSI 比较复杂且性能不高，但 DSI 的动态特性使其在某些应用场合更优于静态分派请求，例如：开发服务端的桥接（协议转换器）、监控应用程序、解释性服务或由脚本驱动的服务等。下节还将看到，DSI 在实现对象的可互操作性时发挥的作用。使用 DSI 的应用程序提供服务时，不必包含由 IDL 编译创建的框架，因而这些服务支持更通用的请求，但需要更多的手工编程、并且必须检查类型的安全性。

ORB 屏蔽了客户端发送请求与服务端接收请求的不同方式：

• 从客户程序的角度看，使用 DSI 的对象实现、与使用 IDL 框架的对象实现行为相同，客户程序不必提供特别的处理去与使用 DSI 的对象实现通信；
• 同样对于服务端来说，客户端发起请求的方式也是透明的，对象实现框架的存在并不意味着一定要有客户程序桩，客户程序也可通过 DII 发送请求。

4. 对象适配器

在 ORB 中，服务端对象实现的框架并没有直接与 ORB 内核交互，而是由对象适配器 Object Adapter 充当了中介——在 CORBA 服务端程序中，对象适配器负责管理服务端的分布式对象。在 ORB 结构中，分布式对象与 ORB 内核之间的通信由对象适配器完成，对象适配器负责对象引用的生成与解释、方法调用、交互的安全性、对象实现的激活与冻结、将对象引用映射到相应的对象实现、对象实现的注册等。为满足特定系统的需要，供应商会提供不同的专用对象适配器。对象实现可选择使用哪种对象适配器，这取决于对象实现所需的服务。

---

2.3 CORBA中的可互操作性

对可互操作性的良好支持是 CORBA 解决的重点问题之一，也是 CORBA 的主要优势所在。除了同一平台上的可互操作性之外，当前有许多商品化和免费的 ORB 产品，每一种产品都试图满足它们的操作环境的特定需求，因而产生了不同 ORB 之间可互操作的需要。此外，有些分布式应用系统并不是 CORBA 兼容的，例如DCE、DCOM等，这些系统与 CORBA 的可互操作需求也在不断增长。

影响对象之间可互操作性的因素，不仅仅是实现方面的差异，还包括安全性方面的严格限制、或需要提供正在开发产品的受保护测试环境等原因。为了提供一个完全可互操作的环境，必须将这些差别都考虑进去。

2.3.1 ORB 域和桥接

在 CORBA 中支持互操作的基本方式是划分域 domain 并通过域之间的桥接来实现。域支持开发人员根据自己的实现因素或管理原因，将对象划分为不同的集合，不同域的对象之间需要桥接机制才可彼此交互。用于实现互操作的桥接机制必须足够灵活，既可适用于协议翻译量少、而传输性能比较重要的情况（例如，位于同一个 ORB 上两个不同的域），也可适用于性能不太重要、但需要访问不同 ORB 的情况。

实现可互操作性的方法，通常可分为直接桥接和间接桥接两种方式。

• 采用直接桥接方式时，需交互的元素直接转换为两个域的内部表示，这种桥接方式具有较快的传输速度，但在分布式计算中缺乏通用性。
• 采用间接桥接方式时，需交互的元素在域的内部表示形式与「各个域一致认可的另一种表示形式」之间相互转换，这种一致认可的中间表示形式要么是一种标准（例如OMG的 IIOP ），要么是双方的私下协议。如果中间表示是某一运行环境的内部表示（如TCP/IP），则称为全桥 full bridge ；否则如果一个 ORB 运行环境不同于公共协议，则称该 ORB 为半桥 half bridge 。

桥接既可在一个 ORB 的内部实现（例如，只是连接两个管理领域的边界），也可在更高层次实现。在 ORB 内部实现的桥接称为内联桥 in-line bridge ，否则称为请求层桥 request-level bridge 。实现内联桥时，既可要求 ORB 提供某种附加的服务，也可引入额外的桩和框架代码。

请求层桥的工作方式大致如下：

• 客户程序的 ORB 将桥与服务程序的 ORB 看作对象实现的一部分，并通过 DSI 向该对象发送请求（注意 DSI 无需在编译时知道对象的规格明）；
• DSI 与桥协作，将请求转换为服务程序的 ORB 能够理解的形式，并通过服务程序的 ORB 的 DII 调用被转换的结果；
• 如果请求有返回结果，也是通过类似的路径返回。

实际上，桥为了完成其功能、不得不了解对象的有关信息，因而要么必须访问接口库，要么只能是一个与特定接口有关的桥。

2.3.2 GIOP, IIOP 与 ESIOP

为了桥接正常工作，必须制订传输请求的统一标准，规定传输底层的数据表示方法与消息格式，由OMG定义的通用 ORB 间协议 General Inter-ORB Protocol, GIOP 负责完成这一功能。GIOP 专门用于满足 ORB 与 ORB 之间交互的需要，并设计成可在任何传输协议的上层工作，只要这些协议满足最小的假设集。当然，用不同传输协议实现的 GIOP 版本不必直接兼容，但它们能够交互、会更加有效。

除了定义通用的传输语法外，OMG还规定了如何以TCP/IP协议为基础实现 GIOP 协议，这一更具体的标准称为因特网 ORB 间协议 Internet Inter-ORB Protocol, IIOP 。GIOP 与 IIOP 之间的关系就好象 IDL 与Java、C++等具体语言之间的映射关系。由于TCP/IP是独立于供应商的最流行传输协议，IIOP 为 ORB 提供了开放式的（OMG术语为 out of the box ）可互操作性。此外，IIOP 还可作为半桥的中间层，除了提供可互操作性的功能之外，供应商还可用于 ORB 间的消息传递。

IIOP 是 ORB 之间的通信协议，虽然也可用于实现 ORB 内部的消息传递，但并不是 CORBA 的硬性规定。一个特定的 ORB 产品可能支持多种通信协议，但声称与 CORBA 2.0 兼容的 ORB 产品至少必须支持 IIOP 。

CORBA规范还提供了一套特定环境 ORB 间协议 Environment-Specific Inter-ORB Protocols, ESIOP ，这些协议可用于特定环境（诸如DCE、DCOM、无线网络等系统）的可互操作性。与 IIOP 相比，ESIOP 可针对于特定环境进行优化。

2.3.3 CORBA 对可互操作性的支持

CORBA 的目标是支持多个层次的可互操作性，CORBA 规范经过多次改进与发展才达到这一目标。在可互操作性方面，CORBA 的支持主要包括如下几个层次：

1. 不同平台（如操作系统）与语言之间的可互操作性：这是早期的 CORBA 版本强调解决的主要问题，解决方法包括：制定 IDL 标准以及 IDL 到程序设计语言的映射。这使得使用「同一供应商的 ORB 产品」开发的客户程序与服务程序之间可以交互，但使用「不同供应商的 ORB 产品」开发的客户程序与服务程序则未必是可互操作的。
2. 不同厂商 ORB 产品之间的可互操作性：CORBA 2.0 版引入了 GIOP 和 IIOP ，从而实现了不同供应商的 ORB 产品之间的可互操作性，所有供应商的 ORB 产品如果与 CORBA 2.0 兼容，则彼此之间可互操作。
3. 不同体系结构之间的可互操作性：更完善的可互操作性还应包括不同体系结构之间的可互操作，例如一个 CORBA 对象可通过协议桥接操作一个 DCOM 对象，OMG通过引入 ESIOP 来解决这一问题。但 ESIOP 只能解决 CORBA 与特定体系结构（如DCOM）之间的互操作，并不能通过一套 ESIOP 解决所有的问题。

---

2.4 CORBA规范与 CORBA产品

OMG本身不开发或发布任何软件、或实现任何规范，它只是将OMG成员的信息需求 RFI 与建议需求 RFP 汇集为规范。CORBA 规范是一套开放式的规范，OMG的成员或非成员公司，均可免费实现符合 CORBA 规范的 ORB 产品。

2.4.1 CORBA 规范

CORBA 这一名词既用于专指关于 ORB 体系结构的规范，也泛指OMG基于 OMA 参考模型发布的一系列规范集。由于OMG需要不断改进与完善 CORBA 体系结构，因而为 CORBA 规范编制了完整的版本号。仅当对体系结构作重大改变时，OMG才增加 CORBA 规范的主版本号，所以有时也以主版本号代指 CORBA 的新特征，例如 CORBA 2 指 ORB 之间的可互操作性和基于TCP/IP协议的 IIOP ，而正式发布最新版本 CORBA 3 则指 CORBA 的组件模型。

为更好掌握 CORBA 的改进历程与发展趋势，并理解 ORB 产品供应商对 CORBA 规范各种新特性的支持，必要了解 CORBA 规范各主要版本的发布时间和主要改进内容。

1. 1991年12月正式发布 CORBA 1.1 ，定义了接口定义语言 IDL 的标准、以及 ORB 的应用程序设计接口 API ，使客户程序与对象实现可在 ORB 的具体实现中彼此交互。
2. 1995年7月正式发布 CORBA 2.0 ，定义了不同供应商的 ORB 之间的可互操作性。
3. 1997年9月修订的 CORBA 2.1 增加了 CORBA 与 Microsoft 的分布式计算模型 COM 的可互操作性。
4. 1998年2月修订的 CORBA 2.2 引入可移植对象适配器 POA ，取代原有的基本对象适配器 BOA ，并增加了 IDL 到 Java 语言的映射标准。OMA 参考模型中的领域接口也是从该版本开始引入，表明 CORBA 规范已从 ORB 内部运行方式扩展到 CORBA 技术应用。
5. 1998年12月修订了 CORBA 2.3 ，将要使用的实验环境 VisiBroker for Java 4.0 完全遵循了该版本。
6. 2000年11月修订的 CORBA 2.4.1 是OMG正式发布 CORBA 规范的最新版本。CORBA 2.4 新增了三个规范：CORBA 消息规范 CORBA Messaging（由服务质量 QoS 、异步方法调用和可互操作的路由接口组成，异步方法调用使 CORBA 的消息传递方式包括了同步、延迟同步、单向和异步四种方式，服务质量可用于根据应用需求、管理与选择不同的底层传输方式）；极小化 CORBA 规范 MinimumCORBA（将 CORBA 裁剪为适合仅有有限资源的系统）；实时 CORBA 规范 Real-Time CORBA（对 CORBA 进行扩充，将 ORB 作为实时系统的一个部件）。此外，该版本还对可互操作的命名服务、通知服务等规范进行了修改。
7. 2002年8月正式发布 CORBA 3.0 。鉴于组件技术在面向对象技术中扮演着越来越重要的角色，3.0版本的最大改进是为 CORBA 引入了 CORBA 组件模型 CORBA Component Mode, CCM 。CORBA 组件模型参照 Sun Microsystems 的 Enterprise JavaBeans, EJB ，为开发即插即用的 CORBA 对象提供了基本架构，程序员可用 CORBA 脚本语言 CORBA Scripting Language, CSL 合成 CORBA 组件。CORBA 组件模型将会给客户端和服务端的可伸缩性带来有力支持。此外，CORBA 3.0 更好地集成了Java、因特网和DCE遗留系统，允许在 IIOP 上使用 RMI ，并支持 IIOP 穿越防火墙。

2.4.2 CORBA 产品

尽管OMG不断改进与完善 CORBA 规范，但每一版本保持了较好的向后兼容性，因而
CORBA 规范相当成熟与稳定，并且拥有大量产品，在企业计算与因特网计算领域拥有庞大
的市场。基于 CORBA 的软件适用于因特网应用与企业计算，特殊版本的 CORBA 还可运行在实时系统、嵌入式系统与容错系统。

由于 CORBA 规范独立于软件供应商，在不同供应商的 ORB 产品上运行的程序之间具
有较好的可互操作性。当前市场上有许多 CORBA 产品可供用户选择，其中一些是商品化的，一些是免费的，许多商品化商品也提供了免费的试用期。但这些产品在对 CORBA 规范的支持程度、对 CORBA 对象服务的支持程度、其他附加特征等方面有很大差异。

1. Orbix

IONA技术公司的 Orbix 是一个可靠的商品化 CORBA 产品，其主要版本是 Orbix 6 ，分为标准版 Orbix Standard 、企业版 Orbix Enterprise 和大型主机版 Orbix Mainframe 三个版本，早期广泛使用的版本包括 Orbix 3 等。Orbix 完全遵循 CORBA 规范，支持Java、C++、COBOL、PL/I等多种语言，可运行在Windows、Linux、Solaris和HP-UX等多种平台，实现了 CORBA 与 COM 的桥接，并提供命名、安全性、事务、交易对象、事件、通知等多种对象服务。

全球的相当一部分电话呼叫，都是通过IONA的企业 CORBA 产品处理的。全球最大的金融机构的三个总部，都在其最关键的IT系统中使用了 Orbix 。Orbix 为全球规模最大、要求最高的面向服务的体系结构 SOA 提供了基础结构。

Orbix 是IONA利用基于标准的解决方案、解决高端企业集成问题的主要手段之一，在一些全球最大规模的集成系统中，在考虑到极高的性能、可用性、安全性和系统管理以及一流的 24x7 技术支持时，很多企业选择了基于 Orbix 实现。

2. VisiBroker

Borland公司是当前商品化 ORB 产品的主要供应商之一，其产品 VisiBroker 目前支持支持Java、C++以及C#等语言，可在Windows、Linux、Solaris、HP-UX和AIX等平台运行，目前最新版本为7.0。新版本 VisiBroker 完全遵循 CORBA 2.6 规范，同时支持实时 CORBA 规范，支持 SOA 架构与 .NET 应用的互操作。

作为一个 ORB 平台，VisiBroker 支持可移植对象适配器、值类型、RMI/IIOP 、具有集群和容错特性的命名服务、属性管理、服务质量、拦截器等，并扩充了位置服务、对象包装器等功能。

VisiBroker 的应用非常广泛，除了作为独立的 ORB 平台外，VisiBroker 还其短小精悍而被嵌入在其他产品之中，例如Netscape Communicator浏览器嵌入了 VisiBroker 产品后，Applet可向 CORBA 对象发出请求而不必须下载相关的 ORB 类。

3. TAO

TAO 是由美国华盛顿大学分布式对象计算研究小组开发的著名免费 ORB 产品，采用代码公开开发模式。TAO 支持C++语言，提供命名、事件、交易对象、生存期、属性、并发性等对象服务。TAO 目前支持 CORBA 2.6 ，其特色是包括了支持实时 CORBA 的显式绑定
与可移植同步器。

4. OmniORB

OmniORB 是由AT&T剑桥实验室开发的一个免费 ORB 产品，该产品的第 $4$ 版完全遵循 CORBA 2.6 规范，支持C++，提供命名、属性等对象服务，主要特色是具有较高的性能。
OmniORB 自1997年开始成为GNU公开许可证 GNU Public Licence 的免费软件。

5. ORBit

ORBit 是一个遵循 CORBA 2.4 规范的 ORB 产品，支持C、C++、Lisp、Python、Ruby等语言绑定。运行 POA, DII, SII 等特性。

关于这些产品的详细信息可浏览表2-1提供的站点。

2.4.3 CORBA 小结

1. CORBA 的优势

CORBA 提供了一个工业标准、而不是一个软件产品。不同供应商的竞争，导致市场上存在大量高质量的、完全遵循 CORBA 的产品。共同遵循的 CORBA 标准，为应用系统提供了较好的可移植性（注意：应用程序在不同 CORBA 产品之间并不是 $100\%$ 可移植）。

CORBA 的最大特点在于，提供了在异类分布式环境中对象之间高度的可互操作性，这种高度可互操作性，使得运行于异类环境的分布式对象之间可以方便地通信，异类环境包括不同供应商的不同硬件平台、操作系统、网络系统、程序设计语言或其他特性。CORBA 应用程序客户可运行在小至手持无线设备或嵌入式系统，大至大型计算机的平台。CORBA 支持多种现有的程序设计语言，并且支持在单个分布式应用程序中混合使用这些语言。这一特性导致了 CORBA 在诸如电信领域等典型领域内，得到了非常广泛的应用，电信领域内部的异构问题非常突出，而 CORBA 对于可互操作性提供了良好的支持，因此 CORBA 技术在电信智能网、电信网管系统中应用很广泛。

CORBA 的另一优势是提供了灵活的服务端模型（在第5章详细讨论）与丰富的系统级服务，这一特性的典型应用是「开发有效管理大量服务端对象的大型系统」。CORBA 的可伸缩性与容错性，使得许多大型网站后台都应用了 CORBA 技术。

由于 CORBA 是相对早期提出的规范，因此新的规范在提出时借鉴了很多 CORBA 规范的成功之处，可以在Java企业版等中间件规范中看到 CORBA 成功技术的影子。

2. CORBA 的问题

作为一种支持分布式系统开发的中间件规范，由于规范制定与修定的周期较长（再加上厂商实现的周期情况会更糟）等诸多因素，CORBA 在一些现代分布式系统新需求方面，并没有及时提供足够的支持，尤其是现在「基于Web的分布式系统开发」需要的人机界面（如动态页面技术等）支持、持久化支持、更强大的构件自动化管理支持（CORBA 3.0 中提出的 CORBA 组件模型 CCM 具备这类特性，但提出较晚，因此厂商实现的进度很难满足实际应用的需求）等，这使得基于 CORBA 开发分布式系统时、有时不能获得全面的支持，尤其在开发典型的以数据库为核心 database-backened 的Web信息系统时，这种情况尤为突出，这在某种程度上限制了 CORBA 的进一步应用，相比之下，Java EE与.NET对于这类系统的支持更为全面。

综上所述，CORBA 目前比较适合「对于互操作要求较高、基于异类环境的分布式系统开发」，这类系统的核心特征是系统核心业务逻辑构件之间（而不是界面构件与业务逻辑构件之间、或业务逻辑构件与数据库之间）频繁的跨越网络交互是系统需要解决的主要问题之一；另外，CORBA 灵活的服务端模型与丰富的系统级服务，也使得 CORBA 中间件成为支撑分布式系统中间层开发的有力候选者之一。

相比之下，由于在人机界面支持、持久化支持等方面的欠缺，CORBA 中间件在支撑「以数据库为核心的Web信息系统开发」时，显得支撑不够全面，而Java EE或.NET中间件的优势更为明显。

---

思考与练习

2-1 结合OMA参考模型，说明 CORBA 规范如何向应用系统提供互操作与公共服务的支持？
2-2 请说明 CORBA 规范对可互操作性支持具体情况，并针对可互操作性的每个侧面简要解释 CORBA 规范是如何做到的。
2-3* 结合 CORBA 规范的主要特点，说明 CORBA 中间件适合什么类型的分布式系统开发