企业版JavaBeansTM （EJBTM）中 CORBA适配器与CORBA服务器互用性的性能评估

过去的几年中，在建立基于CORBA的中间件基础构件上投入了相当多的时间 和人力。当JavaTM 2企业版 （J2EETM）这样的新技术出现后，软件解 决方案开始利用这些创新。
用建立在J2EE平台上的新系统来提升现有的CORBA系 统，正变得越来越重要。已经证实可以很容易地将现有CORBA系统与新的J2EE组 件集成到一起，无缝地协同工作[1]。现在有一个重要的问题：这一互用性的效 率如何？在本文中，我们将检测J2EE组件与CORBA服务器之间互用性的性能特点。
体系结构
一个典型的CORBA中间件系统是一个3层结构。CORBA客户机与CORBA服务器通 讯。典型情况下，服务器与某个数据库或传统系统通讯，如图1所示。

图1： CORBA客户机－服务器体系结构 典型情况下，服务器连接到一 个数据库或传统系统。
与J2EE组件结合的新体系结构如图2所示。在这个系统中，J2EE组件被引入到 客户机和CORBA服务器之间。客户机从一个CORBA客户机转变成一个RMI客户机。 客户机与J2EE组件通讯，随后J2EE组件再与CORBA服务器通讯。J2EE组件等效于 新的CORBA客户机。J2EE组件还可能与其他J2EE组件通讯。

图2： J2EE组件与CORBA对象交互操作的体系结构。
EJB－CORBA互用的体系结构
在图2所示的体系结构中，J2EE组件与CORBA服务器协同工作。我们感兴趣的 J2EE组件是EJB。EJB位于客户机和CORBA服务器之间。图3显示了EJB－CORBA对象 互用体系结构更详细的视图。客户机使用RMI/IIOP与EJB通讯，而EJB使用IIOP 与CORBA服务器通讯。

图3： EJB－CORBA对象互用的体系结构
所有的CORBA通讯都封装在一个称为适配器对象的Java辅助器类中。 请注意，这个适配器对象通常是一个Java bean，而不是RMI－IIOP转换桥。
底部的方框显示的是Cos命名服务。CORBA对象在实例化时，把自己绑定 到命名服务。适配器对象首先在命名服务中查找该CORBA服务器对象，获得 它的引用。适配器对象获得指向服务器的引用后，就可以调用CORBA服务器 对象的业务方法了。为了调用服务器的业务方法，适配器对象可以使用两 种调用模型： Static Invocation Interface（SII，静态调用接口）或 Dynamic Invocation Interface（DII，动态调用接口）。
SII使用客户机存根来调用方法。存根由IDL编译器生成。因为适配器对 象使用存根来调用方法，所以EJB必须能访问存根。通常，存根与EJB封装 在一起。DII不使用存根，而在运行时与服务器对象进行绑定。
性能测量试验
端到端的J2EE－CORBA互用体系结构，如图3所示，其总体性能取决于客户机 与J2EE服务器之间的RMI/IIOP通讯开销和J2EE组件与CORBA服务器之间的CORBA 通讯开销。在本文中，我们把重点放在J2EE－CORBA的互用性部分。因此，我们 的试验设计成：评估端到端体系结构中这一部分的性能。
我们要通过试验测量单独的CORBA客户机与EJB在调用CORBA服务器对象的业务 方法时的性能，并做比较。性能测试等效于一个“代理用户”的客户端CORBA基 准测试，其中客户机是单独的CORBA客户机或EJB。
我们根据一次调用的响应时间来衡量性能。响应时间是指从发出方法调用到 返回数据到达之间经过的时间[2]。响应时间取 决于方法调用模型，所以我们对静态和动态调用分别测量响应时间。
还有几个其他因素会影响数据的汇集，从而影响响应时间。其中包括基本数 据类型、复杂数据类型、数据流向和数据大小的相关性。但是，已经证实对某 个具体的代理实现而言，典型情况下响应时间受数据类型和流向的影响并不明 显[3]。还已经证实，struct的 吞吐量要比简单数据类型的吞吐量低[4]。我 们开发了一个IDL，它在一个struct内组合了几个基本数据类型， 我们测量不同数据量之间的响应时间差异。我们没有测量的两个性能因素是传 送任意类型的序列和值类型与响应时间的相关性。这两个因素通常作为代理厂 商基准的一部分测量，而不是作为用户基准的一部分[3]。
定义这些试验的范围是非常重要的。试验的目的在于，对单独的CORBA客户 机和EJB在与CORBA服务器协同工作时的性能进行比较。它不是ORB性能或应用 程序服务器性能的比较。因为不是对来自不同厂商的产品进行比较，所以ORB 和应用程序服务器厂商的名字就不公开了。
测试框架
为了精确计算出J2EE组件与CORBA协同工作的性能，所用的测试框架是基于图3 所示的体系结构。试验的控制由客户机处理，它将运行下面一节中描述的测试应 用程序。所有CORBA通讯功能都封装在适配器对象中，以加快EJB与CORBA服务器之 间的响应速度，其中EJB是一个专属的会话bean。CORBA服务器绑定到命名服务， J2EE组件可能会查询这项服务。
测试应用程序
使用一个示范应用程序来进行性能测试。这个示范程序是一个简单的可供查 询的目录应用程序。代码范例1显示了IDL。查询的结果包括一个Items 序列。数据量因查询不同而有所差异。QueryResult还返回服务器 处理查询所耗的时间。方法调用的总响应时间可以认为是完成查询所花的总时间。 用总响应时间减去timeInServer就可以得到CORBA通讯的时间。 使用Java例程System.currentTimeMillis进行时间测量。因为我们 使用了Java虚拟机（JVM）的时钟，所以计时的最小单位是毫秒。在响应时间测量 中不包括初始化ORB和查找CORBA服务器对象的时间。
代码范例1： 用于目录应用程序的IDL
Struct Item {
long id;
string itemName;
string description;
double price;
};
typedef sequence ItemSeq;
struct QueryResult {
long long timeInServer;
ItemSeq items;
};
interface Catalog {
QueryResult queryCatalog (in string query);
};
CORBA的优点之一是其与编程语言的无关性。为了测试真正的互用性， 我们用C++编写了CORBA服务器。单独的CORBA客户机是用Java写的。测试 框架被设计为动态地加载适配器对象，这样同一个适配器对象就可以用于 单独客户机和EJB之间的对比测试。实现了两个不同的适配器对象，一个 用于静态调用，另一个用于动态调用。
正如前面所说的，EJB的所有CORBA通讯都通过适配器对象进行。适配 器对象则使用ORB来完成这些通讯。对于大多数应用程序服务器而言，适 配器对象可以直接初始化内置的ORB。但是，有些应用程序服务器可能需 要对个别ORB进行初始化，才能与CORBA服务器通讯。有几种方法可以在 EJB内初始化外部的ORB。下面的代码范例演示了从EJB内部对通过应用程 序服务器厂商认证的ORB进行初始化的一种方法。
代码范例2： 演示如何从EJB内部对外部ORB进行初始化的源代 码范例
// orb_implementation_class and orb_singleton_class
// are the names of the implementing classes.
String[] orbArgs = null;
java.util.Properties props = new java.util.Properties;
props.put ("org.omg.CORBA.ORBClass", orb_implementation_class);
props.put ("org.omg.CORBA.ORBSingletonClass", orb_singleton_class);
org.omg.CORBA.ORB.init (orbArgs, props);
我们在来自两家不同厂商的ORB（ORB1和ORB2）和三个不同的应用程序服 务器上运行这项测试。其中两个应用程序服务器使用内置的ORB进行CORBA通 讯，而第三个应用程序服务器需要对外部ORG（ORB1）进行初始化才能实现 CORBA互用性。下面给出了各种ORB/应用程序服务器的组合和它们的各自名称
CC： 单独的CORBA客户机。有两种情况，一种使用ORB1，另一种使用ORB2。
ASIO： 带内置ORB的应用程序服务器。有两种情况，一种使用ORB1，另一 种使用ORB2。
ASRO： 需要初始化外部ORB才能进行CORBA通讯的应用程序服务器。只有 使用ORB1的一种情况。
在Sun E450服务器上运行测试，配置是4 × 296 MHz的CPU，1 GB的内存， 运行的操作系统是Solaris 8。CORBA客户机/J2EE应用程序和CORBA服务器都 是在相同的机器上运行。Java版本为JDK 1.3.0_02。所有应用程序服务器和 Java应用程序的堆大小都设为128 MB。
结果
在不同配置下测量数据量对响应时间的影响。图4显示了使用ORB1进行静态 调用时响应时间与数据量的关系。和预料的一样，响应时间随着数据量的增长 而增长。在大多数情况下，内置ORB的应用程序服务器响应时间要比单独的 CORBA客户机略短。另一个需要初始化外部ORB的应用程序服务器，其响应时间 则明显长于单独的客户机。

图4： 使用ORB1进行静态调用时响应时间与数据量的关系
图5显示了使用ORB2进行静态调用时响应时间与数据量的关系。结果和前一 幅图非常相似。但是在这种情况下，应用程序服务器的性能明显优于单独的客户机。

图5： 使用ORB2进行静态调用时响应时间与数据量的关系
图6和图7显示了使用ORB1和ORB2进行动态调用时响应时间与数据量的关系。 对于ORB1和ORB2，动态调用的总趋势都与静态调用相同。

图6： 使用ORB1进行动态调用时响应时间与数据量的关系

图7： 使用ORB2进行动态调用时响应时间与数据量的关系
图8和图9显示了不同应用程序服务器与单独CORBA客户机在三种不同数据量下分 别进行静态和动态调用时响应时间的比值。

图8： 应用程序服务器与单独客户机的响应时间比（静态调用）

图9： 应用程序服务器与单独客户机的响应时间比（动态调用）
使用内置ORB进行CORBA通讯的应用程序服务器，性能要比单独的客户机好。对于 ORB1，当数据量从100 KB增加到300 KB时，比值从0.83变成0.94。需要初始化外部ORB 才能进行CORBA通讯的应用程序服务器，其性能要比单独的客户机差。当数据量从100 KB增加到300 KB时，比值从1.59变成2.27。使用内置ORB2的应用程序服务器，其性能 相对单独的客户机来说是最优的。当数据量从100 KB增加到300 KB时，比值的变化可 以忽略不计。
本测试是利用可从目前市场上购得的应用程序服务器进行的。因为我们没有任何 应用程序服务器的源代码，所以不能确定为什么它们的性能比单独的CORBA客户机好 或者差。
图10显示了使用ORB2进行静态和动态调用时，不同数据量下响应时间的变化。动 态调用的响应时间要比静态调用长。这是预料之中的，因为创建请求、给它填充参数 和编排数据都会增加开销[5]。

图10： 使用ORB2进行静态和动态调用时响应时间与数据量的关系
图11显示了不同应用程序服务器和单独客户机在三种不同数据量下， 动态调用与静态调用的响应时间比。比值从最小1.68到最大2.25不等，平均 值为1.95。

图11： 动态调用与静态调用的响应时间比
参考
MDE企业级Java小组，Sun微系统公司。 用eMobile应用程序演示端到端J2EE互用性。.
对象管理组。基准测试1.0版白皮书，OMG文档工作组/99-12-01，1999。.
Peter Tuma和Adam Buble。有关开放式CORBA基准测试的技术报告。.
Anirudha Gokhale和Douglas C. Schmidt。高速网络上通讯中间件的性能测量。.
Anirudha Gokhale and Douglas C. Schmidt。高速ATM网络上CORBA动态调用接口和动态基干接口的性能。.
总结
J2EE组件可以很容易地与CORBA对象协同工作。我们在多个应用程序和多 个ORB之间测试这一互用性时都获得了成功。
我们评估了端到端J2EE-CORBA互用性体系结构中，J2EE-CORBA互用性环 节的性能。性能特点取决于应用程序服务器如何对CORBA互用性进行配置。 使用内置ORB进行CORBA通讯的应用程序服务器，其性能要优于调用CORBA服 务器对象上方法的单独CORBA客户机。这些应用程序服务器的性能和单独的 客户机相比，在负载变化时差别并不大。
需要初始化外部ORB才能进行CORBA通讯的应用程序服务器，其性能要比 单独的客户机差。这种应用程序服务器的性能与单独客户机相比，当负载 量增加时会越来越差。
对于我们使用的IDL，动态调用比静态调用大约慢一倍。动态调用提供 了许多灵活性。但是，用户为这些灵活性付出的代价是较低的性能，因为 进行动态调用会增加各种开销。
总之，在J2EE平台上建立的新组件，可以无缝地与现有的CORBA基础构 件协同工作。通过使用为CORBA互用性进行了适当配置的J2EE服务器，这 些J2EE-CORBA系统可以提供CORBA互用性，其性能与CORBA客户机直接与 CORBA服务器通讯的现有系统相比不相上下，有时甚至更胜一筹。