企业级JavaBeansTM(EJBTM) 的CORBA 适配器到CORBA服务器的互操作性能比较
(来源：java.sun.com)
请大家发表对这篇文章的评论 
英文原文
Binu John, Vu Trang, Michael Vernik, Stacie Wolny and Sherry Yu
2002年1月
(by huihoo.com connect_freeman ,Changzheng Rao 翻译)
过去几年来，在建立基于CORBA的中间件上已经花费相当多的时间和精力。作为一项新技术，诸如JavaTM2，企业版（J2EETM），已经提供，也有了开始利用这些创新的软件解决方案。
在构建在J2EE平台上的新系统中，CORBA服务的杠杆作用显得越发重要。它显示出新的J2EE组件整合了CORBA服务将工作得更容易，诸如互操作的无缝性[1]。现在重要的问题是,互操作性的效率到底怎么样？在本文中，我们检视了含CORBA服务的J2EE组件在互操作方面的性能特性。
体系
典型的CORBA中间件是3层体系架构。CORBA客户和CORBA服务器进行通讯。服务显然是在数据库或其它遗留系统中扮演了一个通讯的角色。
图 1：CORBA 客户-服务体系。显然服务联结了数据库或遗留系统。
在图2中新体系中整合了J2EE组件。在这个系统中，J2EE组件在客户和服务器之间传接。客户已经从CORBA客户变成了RMI客户。客户与J2EE组件的通讯就是在与CORBA服务的通讯。J2EE组件是新的有效的客户端。J2EE组件有可能也和其它J2EE组件通讯。
图 2：含有J2EE组件的体系和客户对象有互操作性
EJB-CORBA互操作体系
体系通过角色2体现这点，J2EE组件与CORBA服务的互操作。
对我们而言有趣的J2EE组件是EJB。图3显示了EJB-CORBA对象互操作体系更多的概貌。客户与服务是通过EJB使用RMI/IIOP而不是使用IIOP进行通信。
图 3：EJB-CORBA 对象互操作体系
所有的CORBA通信被打包成称为适配器对象的辅助类。值得注意的是这个适配器仅仅是一个java bean而不是一个RMI-IIP的转换桥。
图3底下的盒显示了CosNaming服务。CORBA对象在实例化时,将自己绑定到命名服务中。适配器对象首先通过在命名服务中查找得到一个CORBA对象的引用。一旦适配器对象通过了服务器的引用了,它在CORBA服务对象上调用了商用算法。在服务上调用商用算法，适配器对象可以使用两种调用模式：静态调用接口或动态调用接口。
静态调用使用了为算法调用的客户桩。这个桩由IDL编译器产生。只要适配器调用用了算法调用的桩,对EJB来说桩就是可用了的。通常，这个桩和EJB一起打包。DII用的时候是无桩的只是动态绑定在服务对象上。
性能度量测试
端到端的J2EE-CORBA互操作体系的整体性能，如图3所示，依赖于客户和J2EE服务器之间的RMI/IIOP通讯开销，以及J2EE组件和CORBA服务器之间的CORBA通讯开销。本文主要讨论J2EE-CORBA之间的互操作部分。因此，我们的测试被设计成评测端到端体系中的该部分的性能。
我们执行了测试来衡量标准CORBA客户与在CORBA服务对象上EJB调用商用算法的性能。一个代理客户CORBA客户端基准的性能测试对于标准的CORBA客户或EJB来说对都是有效的。
我们评测了调用的响应时间性能。响应时间是算法调用和结果返回的所用的时间[2]。响应时间依赖于算法调用模式,因此，我们评测中包括了静态和动态调用的响应时间。
有几个其它的参量如数据分组影响到响应时间。包括诸如基本数据类型，联合数据类型，数据的流向和数据容量。然而，也显然有特别的代理实现，响应时间不用对数据类型和数据指向予以特别注意[3]。那也表明了结构的吞吐量低于简单数据类型[4]。我们开发了一个IDL，里面一个结构整合了几种基本数据类型。我们以数据容量测量了数据响应时间。我们没能测量到两个性能参数是类型队列的通过率和值类型。那两个变量常用来作为代理提供者基准和非用户基准[3]。
非常重要的是定义那些集合范围。测试意味着比较标准CORBA客户和EJB与CORBA服务互操作的性能。那不是用来比较ORB性能或应用服务性能。因此不能用来比较不同供应商的产品，那些ORB和应用服务提供商的名字不被披露。
测试结构
为了正确评做J2EE组件-CORB互操作的性能，测试结构使用了如图3中所见的结构。测试的控制由客户端处理，在下面将要提到运行测试应用。
所有的CORBA通讯功能性都压缩在适配对象中，使我们有状态的对话bean更容易和CORBA服务器进行通信。CORBA服务器绑定了名字服务,在J2EE组件都可以找到。
测试应用
性能的测试用例子应用来进行。样例应用是查询时用到的简单的目录应用。代码例子1显示了IDL。查询的结果包括了项目队列。查询变更时数据容量是不定的。查询结果也返回由服务器处理查询的时间。全部响应时间有方法的调用测量，这是在查询完的全部时间完成之后。CORBA通讯时间是通过全部响应时间减去在服务器中的时间来获得的。时间测量是用JAVA例行程序来进行的。当前毫秒时间。后来我们用了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服务器进行通讯。那是几个外部ORB也可以由EJB内开始初始化的办法。以下的样例代码显示了一种在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);
我们在2个不同的供应商（ORB1和ORB2）和3个不同的应用服务器ORB上运行测试。应用服务器中的2个使用了内建ORB来进行CORBA通信，而第三个应用服务器需要一个初始化的外部ORB（ORB1）。不同的ORB/应用服务器组合，以及相应的名称如下：
CC：孤立的CORBA 客户。有两个实例，一个使用ORB1 ，另一个使用ORB2。
ASIO：内建ORB应用服务器。有两个实例，一个使用ORB1 ，另一个使用ORB2。
ASRO：需要一个初始化的外部ORB（ORB1）来进行CORBA通信的应用服务器。有一个实例使用ORB1。
测试运行在拥有4个296MHz CPU和1GB内存，运行Solaris 8的Sun E450服务器上。CORBA客户/J2EE应用，和CORBA服务器运行在同一台机器上。Java的版本使用JDK 1.3.0_02。 所有应用服务器和Java应用的堆的大小都设置为128MB。
结果
对应不同的响应时间，我们采用了不同的数据大小进行测量。图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，当数据大小从100KB增加到300KB时，比率在0.83到0.94之间变动。采用外部ORB的应用服务器，与孤立的客户相比较，表现就差多了。当数据大小从100KB增加到300KB时，比率在1.59到2.97之间不等。采用内建ORB2的应用服务器的表现最好。当数据大小从100KB增加到300KB时，其比率的差别可以忽略不计。
测试在于利用目前市场上提供的应用服务器。因为我们不能访问任何一个应用服务器的权限，所以我们不能决定为什么某些应用服务器的表现要好于或者差于孤立的CORBA客户。
图10显示了采用ORB2的静态和动态调用下，对于不同的数据大小，其响应时间的差别。对于动态调用的响应时间要大于静态调用。考虑到创建一个请求，传送其参数和对数据进行排列的开销，这个结果是预料之中的 [5]。
图10：采用ORB2的静态和动态调用下，响应时间相对数据大小的关系
图11显示了在三种不同的数据大小下，对于不同的应用服务器和孤立的客户，动态调用的响应时间和静态调用的响应时间的比率。比率在最小值1.68和最大值2.65之间变动，均值为1.95。
图11：动态调用和静态调用的响应时间的比率
总结
J2EE组件与CORBA对象互操作良好。我们成功地在多应用服务器和多ORB上展示了这一点。
我们比较了端对端J2EE-CORBA互操作体系的J2EE-CORBA互操作部分的性能。其性能特性依赖于如何为CORBA互操作而配置应用服务器。使用内建ORB进行CORBA通信的应用服务器在调用CORBA服务器的方法这一方面的表现要优于孤立的CORBA客户。这些应用服务器的性能，正如与孤立的CORBA客户比较，在不同的有效载荷时区别不大。
在与孤立客户相比较时，需要外部ORB以初始化进行CORBA通信的应用服务器显示出较低的性能。与孤立客户相比较，应用服务器的性能随着有效载荷的大小的增加而下降。
对于我们使用的IDL，动态调用大约比静态调用慢两倍。动态调用提供相当的灵活性。但是，由于各种的实现动态调用而产生的开销，用户为此付出的代价是较低的性能。
总之，建立在J2EE上的新的组件能够无缝的与现有的CORBA体系互操作。通过使用为CORBA互操作性而恰当配置的J2EE服务器，这些J2EE-CORBA系统能够提供，与现存的与CORBA服务器直接通信的CORBA客户相比较而言，相当于并且在某些场合下更好的互操作性能。
参考
[1] MDE Enterprise Java Team, Sun Microsystems. eMobile Application Demonstrates End-to-End J2EE interoperability.
[2] Object Management Group. White paper on Benchmarking, Version 1.0, OMG document bench/99-12-01, 1999.
[3] Peter Tuma and Adam Buble. Technical Report on Open CORBA Benchmarking.
[4] Anirudha Gokhale and Douglas C. Schmidt. Measuring the Performance of Communication Middleware on High-Speed Networks.
[5] Anirudha Gokhale and Douglas C. Schmidt. The performance of the CORBA Dynamic Invocation Interface and Dynamic Skeleton Interface over High-Speed ATM Networks.