公共对象请求代理体系结构

定义

公共对象请求代理体系结构是一套由对象管理组织（OMG）发布的对象技术架构与规范，覆盖对象的使用、管理和互操作，并规定对象请求代理之间交换消息的方式^[1]。按照这一定义，符合规范的软件产品必须包含对象请求代理（ORB），使对象能够在分布式环境中透明地发送请求、接收响应^[2]。

这套规范由若干互补的部分组成：定义接口的接口定义语言、描述请求与参数的对象模型、支持对象生命周期管理的对象适配器，以及负责跨 ORB 通信的互操作协议^[3]。开放群组（The Open Group）曾以产品标准的形式对 CORBA 2.3 版本的必备组件作出规定，其中 ORB、接口定义语言、可移植对象适配器、动态调用接口、动态骨架接口、值类型语义、抽象接口语义和接口仓库均属必须具备的内容^[1]。

原理

系统的核心是对象请求代理，它是一个在分布式环境下按对象模型运作的软件总线，用来解析对象引用并建立应用对象之间的连接^[4]。客户程序并不直接与其他机器上的对象通信，而是通过本地存根向本机 ORB 发出调用；本机 ORB 再用 IIOP 把请求送往对方 ORB，由后者定位目标对象、执行操作并回传结果^[5]。对象注册、对象定位、对象激活、请求复用、错误处理、数据编组与请求分发等网络事务，均由 ORB 自动完成。

接口定义语言是保证语言中立性的关键环节：一个底层对象的方法与属性被汇集到单一接口描述中，该描述可编译为选定语言下的存根或骨架代码，各厂商的 ORB 都附带对应的编译器^[4]。接口定义语言只声明接口，不规定类或方法的具体实现，因此其定位是接口描述工具而非编程语言^[4]。

跨 ORB 通信依靠通用 ORB 间协议（GIOP）及其在 TCP/IP 上的具体实现 IIOP，二者构成互操作架构的框架^[1]。一次调用的链路可以概括为：

flowchart LR

A[客户端] --> B[客户端存根]

B --> C[本地 ORB]

C -->|IIOP| D[远端 ORB]

D --> E[对象适配器]

E --> F[服务对象实现]

F --> E --> D --> C --> B --> A

在 ORB 之上，规范还定义了对象服务与公共设施两个层次。对象服务为各类应用提供命名、事件、事务、通知、交易、生命周期和安全等基础能力，其中命名服务可依名字查出服务器中对象引用的位置，事务服务保证事务内的操作全部完成或全部回滚^[4]。公共设施分为面向通用领域的横向设施与面向电信、金融、医疗等专用领域的纵向设施^[4]。

发展历程

对象管理组织成立于 1989 年，早期致力于为面向对象开发工具和中间件奠定规范基础^[6]。1991 年 10 月，CORBA 1.0 发布，包含对象模型、接口定义语言，以及动态请求管理与调用、接口仓库的核心编程接口，并提供 C 语言的映射^[7]。1992 年 2 月的 1.1 版是首个广泛公开的版本，补充了基本对象适配器与内存管理接口^[7]。

1996 年 8 月的 2.0 版是一次较大幅度的修订，加入动态骨架接口、初始引用解析、GIOP 与 IIOP 互操作架构、分层安全与事务服务支持，并给出 C++ 和 Smalltalk 两种语言映射^[7]。此后 2.1 版增补安全 IIOP 与 SSL 上的 IIOP，以及 COBOL、Ada 映射；2.2 版引入服务端可移植性增强、与 DCOM 的互通和 IDL 到 Java 的映射；2.3 版于 1999 年 6 月发布^[7]。2.4 版则纳入消息规范、可互操作命名服务、通知服务、最小 CORBA 与实时 CORBA 等内容^[7]。

部件模型的工作启动于 1996 年的公共业务对象设施计划，因意见分歧而搁置，后由 CORBA 部件模型接替，其规范在 1999 年末发布，但因规模庞大、多数内容缺乏实现而影响有限。2012 年 10 月，OMG 发布 CORBA 3.3 测试版，其正式版本随后成为该规范的较新版本^[8]。相关规范同时以国际标准形式出现，即 ISO/IEC 19500 系列，分别对应接口、互操作与部件模型部分^[9]。

应用

CORBA 主要面向大中型企业的分布式应用，能够把不同厂商的计算机、从大型机到嵌入式终端的设备集成起来，被视为典型的中间件技术^[4]。它在电信与金融领域应用较广，例如电信管理网框架、综合网络管理系统、光传输设备监控系统等都有基于该规范的设计^[10]。

在轨道交通等工业场景中，自动售检票系统在分析 CORBA 技术特点后被用于构建信息共享平台，以缓解子系统之间的数据孤岛问题^[11]。由于规范独立于平台和开发语言，同一套分布式对象也可在 Java 环境中通过 RMI-IIOP 方式调用，企业级 Java 组件的远程客户机即借助该方式与服务端通信^[5]。

局限

规范规模庞大、复杂度高，编写一个并非简单的 CORBA 应用相当困难，许多接口设计繁复且不一致，开发者需自行处理大量细节。IIOP 使用非标准端口，通常难以穿越防火墙，客户端还需安装 ORB 环境，这限制了它在互联网范围的扩展^[10]。此外，线缆编码冗余较多而协议不支持压缩，广域网下性能不佳；规范对线程几乎未作规定，服务端异步分发亦不受支持，且缺少 C# 与 Visual Basic 的语言映射。

标准化过程本身也带来问题：规范由成员投票产生，部分参与者对技术细节了解有限；多个草案常被要求合并，导致特性堆叠与语义冲突；规范通过时不要求提供参考实现，因此出现过部分或完全无法实现的条款。厂商实现之间的差异还使应用在不同产品间迁移的成本偏高。

外部环境的变化同样削弱了它的地位：1990 年代中后期 Java 与万维网兴起，企业转向以浏览器、HTTP 和 EJB 构建电子商务基础设施，而 CORBA 未能与 Web 有效协作；随后基于 XML 的 Web 服务协议在普及度上超过了它。OMG 曾通过制定规范使 CORBA 应用与 WSDL、SOAP 之间交换数据，但其关注重心已转向建模类规范^[6]。

参见

• 对象管理组织 —— 制定并维护 CORBA 规范的国际标准化组织。

• 对象请求代理 —— CORBA 的核心组件，负责解析对象引用并在对象之间传递请求。

• 接口定义语言 —— 用于描述 CORBA 对象接口、实现语言无关性的描述语言。

• IIOP —— 在 TCP/IP 之上承载 ORB 间通信的互操作协议。

• Web 服务 —— 2000 年代后取代 CORBA 成为主流的跨平台远程调用技术路线。

• 中间件 —— CORBA 所属的软件类别，位于操作系统之上支撑分布式应用运行。