RMI-IIOP

互联网内部对象请求代理协议（IIOP）是一个实现互操作性的协议，它使得由不同语言编写的分布式程序在因特网中可以实现彼此的交流沟通。它是行业战略性标准，也即公用对象请求代理程序结构（Common Object Request Broker Architecture，CORBA）中至关重要的一个部分。采用公用对象请求代理程序结构（CORBA）中的互联网内部对象请求代理协议（IIOP），企业将能够将自己编写的程序和其他公司的程序进行交流，不论这个程序是不是已经写出来了，或者在那个地方写的，这都无关紧要。公用对象请求代理程序结构（CORBA）和互联网内部对象请求代理协议（IIOP）正在面临着微软公司推出的分布式COM（DCOM）协议的竞争。（不过，微软公司和提出CORBA协议的对象管理组织已经达成意向，他们将共同努力创建一种桥梁性的软件，使得在CORBA协议和DCOM协议背景下编写的程序可以实现彼此的无限沟通。）　　CORBA和IIOP协议假定在计算机的客户端/服务器端模式中，客户端的程序总是提出各种请求，服务器端的程序则处于等待和接受客户端请求的状态。在编写程序的时候，常常需要用到一个叫做通用ORB间协议（GIOP）的界面。通用ORB间协议（GIOP）可以实现网络传输层之间的映射，而IIOP就是其中最重要的映射之一，它应用传输控制协议（TCP）借助因特网的传输层来传递请求或者接收答复。　　如果客户端需要在网络中传送一个程序命令，就必须提供为程序提供一个目标地址。这个地址就是交换可互操作对象引用（IOR）。应用IIOP协议，目标地址由服务器端口数据和IP地址共同构成。

1997 年，IBM 和 Sun Microsystems 启动了一项旨在促进 Java 作为企业开发技术的发展的合作计划。两家公司特别着力于如何将 Java 用作服务器端语言，生成可以结合进现有体系结构的企业级代码。所需要的就是一种远程传输技术，它兼有 Java 的 RMI（Remote Method Invocation，远程方法调用）较少的资源占用量和更成熟的 CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）技术的健壮性。出于这一需要，RMI-IIOP 问世了，它帮助将 Java 语言推向了目前服务器端企业开发的主流语言的领先地位。

在本文中，我将简要介绍 RMI-IIOP，目标是使您能开始在企业开发解决方案中使用这一技术。要解释 RMI-IIOP 究竟是什么，我认为提供一些关于 CORBA 和 RMI 的信息是重要的，这些信息您在各个技术的典型介绍中可能找不到。如果您对 CORBA 或 RMI 的基础知识不熟悉，我建议您在往下读之前先阅读一些介绍性信息。，那里挑选了一些文章和教程。

在我具体讨论 RMI-IIOP 之前，我们将先看一下 CORBA 和 RMI 用来对请求进行数据编入的机制。CORBA 将是我们的主要示例，因为 RMI-IIOP 数据编入是建立在 CORBA 传输协议（IIOP）的基础上的。我们将回顾一下该传输协议和 ORB（object request broker，对象请求代理）在网络上发送请求、定位远程对象和传输对象方面的基本功能。

远程对象传输

对 CORBA 请求进行数据编入是通过使用 IIOP 协议做到的。简言之，IIOP 将以标准化格式构造的任何 IDL（Interface Definition Language，接口定义语言）的元素表示为一系列字节。那就假设有一个 Java 客户机正在将一个 CORBA 请求分派到 C++ 服务器吧。客户机应用程序以 Java 接口的形式拥有远程对象的引用，并调用该接口的一个操作。本质上是，接口调用它对该操作的相应实现，这个实现将位于存根（stub）（存根是您将已经用 idlj 从 IDL 生成了的）。

存根把方法调用分派到 ORB 中，ORB 由两部分组成：客户机 ORB 和服务器 ORB。客户机 ORB 的职责是对请求进行数据编入，放到网络上，传往特定位置。服务器 ORB 的职责是侦听从网络上传下来的请求，并将这些请求转换成语言实现能够理解的方法调用。要了解对 CORBA ORB 的角色的更深入讨论

存根分派了方法调用之后，客户机 ORB 将请求和所有参数转换成标准化字节格式，在这种情况中是 IIOP。接着，请求通过导线被发送到服务器 ORB，服务器 ORB 应该正在侦听传入请求。服务器端 ORB 将读进数据的字节并将请求转换成对 C++ 服务器实现有意义的东西。C++ 服务器方法将执行它的功能（即调用所请求的方法）并使用相同的机制通过 IIOP 将结果返回给客户机。

RMI 以类似的方式处理请求，但是它使用 JRMP（Java Remote Messaging Protocol，Java 远程消息传递协议）作为其传输协议。当然，RMI 传输还涉及 Java 对象的序列化。

远程对象定位

CORBA 使用 CosNaming 命名服务定位远程对象。CosNaming 为名称服务器保存对 CORBA 服务器进程的绑定（或引用）提供了一个框架。当 CORBA 客户机向名称服务发送 CosNaming 请求，请求给定名称的服务器进程时，名称服务返回该进程的 可互操作对象引用（interoperable object reference（IOR））。接着，客户机使用该 IOR 直接与服务器进程通信。

IOR 包含关于服务器进程的信息，例如服务器进程的位置。CosNaming 服务的缺点之一是，IOR 对人类而言是难以看懂的 ― 至少对我们这些没有电子大脑的人来说是这样。相反地，RMI 对用户则要友好一些。它使用运行在 JNDI 之上的 注册中心（与命名服务极为相似）来定位远程对象。RMI 注册中心使用 Java Reference 对象（它由若干个 RefAddr 对象组成）来识别和定位远程对象。这些 Java 对象比 IOR 对用户更加友好。

不久前，COBRA 将可互操作命名服务（Interoperable Naming Service（INS））结合进了它的对象-定位（object-location）模式。INS 在 CosNaming 上运行，使用人类可以阅读的 URL 作它的对象位置。INS 不使用命名服务；相反地，它将调用直接发送到指定的 URL。

 

RMI 对 CORBA

那么，哪一个更好呢：是 CORBA 还是 RMI？答案取决于您想做什么。CORBA 是一个运行在业界标准的第三或第四代协议上的、经过试验和测试的大体系结构。如果考虑到 CORBA 提供的所有附件（例如：事务处理、安全拦截器、事件通道，还有更多）的话，则 CORBA 看来是企业应用程序的解决方案。CORBA 的最大缺点是它很复杂。要熟练使用 CORBA，开发者通常要经历陡峭的培训曲线。

相反地，RMI 相当容易学习。创建一个客户机／服务器实现，绑定到注册中心和远程对象，使用 RMI 调用和／或接收请求都相当简单。RMI 的资源占用量也比 CORBA 小得多，因为 JRMP 是开销比 IIOP 小得多的协议。但是，RMI 缺乏 CORBA 的工业级的附件，而且是纯基于 Java 的机制。那么，我们真正需要的就是 RMI 的灵活性和易用性以及 CORBA 的企业就绪性，对吗？那就开始讨论 RMI-IIOP 吧。

RMI-IIOP 概览

RMI-IIOP 让您仅需极少修改就可以在 IIOP 上运行 RMI 调用。借助于 RMI-IIOP，您可以编写简单易懂的 Java 代码，同时使用 CORBA 提供的丰富的企业功能套件。而且，代码的灵活性足够大，可以运行在 RMI 或IIOP 上。这意味着，您的代码可以在纯 Java 环境中运行（当小的资源占用量和灵活性很关键时），或者对代码作少量修改后集成到现有的 CORBA 基础架构中。

RMI-IIOP 很强大的功能之一是，它让您编写纯 Java 客户机／服务器实现而不丧失 RMI 类序列化的灵活性。RMI-IIOP 通过覆盖 Java 序列化并在导线上将 Java 类转换成 IIOP 做到这一点。在另一端，Java 类被作为 IIOP 从导线上读下来，接着创建这个类的一个新实例（使用反射），类的所有成员的值都完整无缺 ― 瞧：这就是 IIOP 上的 Java 序列化！

为了让 RMI-IIOP 实现透明的对象定位，ORB 供应商历史上曾经使用 Java CosNaming 服务提供者（或用外行人的话说，是 插件）。该插件在 JNDI API 之下工作，访问 CORBA 命名服务。尽管我没有在这里花篇幅来说明原因，但这种命名解决方案并不理想。其结果是，许多供应商 ― 尤其是应用服务器供应商 ― 为 RMI-IIOP 开发了专门的对象定位机制。

RMI-IIOP 也支持作为 Java CosNaming 服务的一个扩展的 INS。因为我相信 INS 将确定对象定位的未来方向，所以我们在本文将讨论的代码示例使用 INS。

自己动手构建 RMI-IIOP

说得够多了，让我们来编写代码吧！在以下几部分中，我们将构建一个简单的、基于 Java 的客户机／服务器 RMI-IIOP 应用程序。这个应用程序由三个部分组成：RMI 接口、服务器应用程序和客户机应用程序。示例以在 IIOP 之上的 Java 序列化为特色，所以您可以看到 Java 类如何被客户机实例化，如何传递到服务器，由服务器更改，然后将所有修改完整地回传到客户机。