Over the past few years, a considerable amount of time and effort has been spent on building CORBA-based middleware infrastructures. As new technologies, such as Java^TM 2, Enterprise Edition (J2EE^TM), become available, software solutions are beginning to utilize these innovations.

It has become increasingly important to leverage the existing CORBA systems with new systems built on top of the J2EE platform. It has been shown that integrating the existing CORBA systems with new J2EE components can be done with ease, as well as interoperate seamlessly^[1]. Now the important question is, how efficient is this interoperability? In this paper, we examine the performance characteristics of the J2EE component-CORBA server interoperability.

Architecture

A typical CORBA middleware system has a 3-tier architecture. The CORBA client communicates with a CORBA server. The server typically communicates with either a database or a legacy system as shown in Figure 1.

Figure 1: CORBA client-server architecture. Typically the server is connected to either a database or a legacy system.

The new architecture incorporating J2EE components is shown in Figure 2. In this system, the J2EE components are introduced between the client and the CORBA server. The client changes from a CORBA client to an RMI client. The client communicates to the J2EE component which in turn communicates to the CORBA server. The J2EE components are in effect the new CORBA clients. The J2EE components may also communicate to other J2EE components.

Figure 2: Architecture with J2EE components interoperating with CORBA objects.

EJB-CORBA Interoperability Architecture

In the architecture shown in Figure 2, the J2EE component interoperates with the CORBA server. The J2EE component of interest to us is the EJB. The EJB sits between the client and the CORBA server. Figure 3 shows a more detailed view of the EJB-CORBA object interoperability architecture. The client communicates to the EJB using RMI/IIOP whereas the EJB communicates to the CORBA server using IIOP.

Figure 3: EJB-CORBA object interoperability architecture

All the CORBA communications are encapsulated in a Java helper class called the adapter object. It should be noted that this adapter object is just a Java bean and not a RMI-IIOP conversion bridge.

The box at the bottom shows the CosNaming service. The CORBA object, at instantiation, binds itself to the naming service. The adapter object first obtains a reference to the CORBA server object by looking it up in the naming service. Once the adapter object obtains a reference to the server, it can invoke business methods on the CORBA server object. For invoking business methods on the server, the adapter object can use two invocation models: the Static Invocation Interface (SII) or the Dynamic Invocation Interface (DII).

SII uses a client stub for the invocation of the method. The stubs are generated by the IDL compiler. Since the adapter object uses the stub for method invocations, the stubs should be accessible to the EJB. Usually, the stubs are packaged along with the EJB. DII uses stubless runtime binding with the server object.

Performance Measurement Tests

The overall performance of the end-to-end J2EE-CORBA interoperability architecture, as shown in Figure 3, depends on both the RMI/IIOP communication overhead between the client and the J2EE server and the CORBA communication overhead between the J2EE component and the CORBA server. In this paper we concentrate on the J2EE-CORBA interoperability part. Hence, our tests were designed to evaluate the performance of that portion of the end-to-end architecture.

We carried out tests to measure the performance of standalone CORBA clients versus EJBs invoking business methods on a CORBA server object. The performance test is in effect a 'broker user' client side CORBA benchmark with the client being either a standalone CORBA client or an EJB.

We measured performance in terms of response time for an invocation. Response time is the time elapsed between the start of a method invocation and the arrival of the return data^[2]. The response time depends on the method invocation model, therefore we measured the response times for both static and dynamic invocations.

There are several other parameters that influence the marshalling of the data and hence the response time. These include the dependencies on the basic data types, the complex data types, the direction of data flow and the size of the data. However, it has been shown that for a specific broker implementation, the response times typically do not vary significantly with the type and the direction of the data^[3]. It has also been shown that the throughput for struct is lower than that for simple data types^[4] . We developed an IDL that incorporated several basic data types inside a struct and we measured the variation of the response time with the data size. Two performance factors that we did not measure are the dependence of response time on passing sequences of Any type and the value types. These two factors are usually measured as part of the broker vendor benchmark and not the user benchmark^[3].

It is very important to define the scope of these tests. The tests are meant to compare the performance of standalone CORBA clients versus EJBs interoperating with the CORBA server. It is NOT a comparison of the ORB performance or application server performance. Since this is not a comparison of products from different vendors, the names of both the ORB and the application server vendors are not disclosed.

Testing Framework

To accurately evaluate the performance of J2EE Component-CORBA interoperability, the testing framework used was based on the architecture shown in Figure 3. Control of the test is handled by the client, which runs the test application described in the following section. All of the CORBA communication functionalities are encapsulated in the adapter object, facilitating the correspondence between our EJB, which is a stateful session bean, and the CORBA server. The CORBA server binds to the naming service, which may then be looked up by the J2EE component.

Test Application

The performance tests were carried out using a sample application. The sample application is a simple catalog application that can be queried. Code Sample 1 shows the IDL. The result of the query contains a sequence of Items. The data size was varied by changing the query. The QueryResult also returns the time taken by the server to process the query. The overall response time for the invocation of the method is measured as the total time taken for the query to be completed. The CORBA communication time is obtained by subtracting the timeInServer from the overall response time. The timing measurements were carried out using the Java routine System.currentTimeMillis. Since we use the Java virtual machine (JVM¹) clock, the resolution of the time measurement is milliseconds. The time taken to initialize the ORB and to look up the CORBA server object were not included in the response time measurement.

Code Sample 1: IDL for the catalog application

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);

};

One of the advantages of CORBA is its programming language independence. In order to test true interoperability, we wrote the CORBA server in C++. The standalone CORBA client was written in Java. The testing framework is designed to load the adapter object dynamically, so that the same adapter object can be used for comparison tests between the standalone client and the EJB. Two different adapter objects were implemented, one for static invocation and the other for dynamic invocation.

As mentioned before, the EJB uses the adapter object for all CORBA communications. The adapter object in turn uses an ORB to carry out these communications. For most application servers, the adapter object can initialize the built-in ORB directly. However, some application servers may need a separate ORB to be initialized to communicate with the CORBA server. There are several ways in which the external ORB can be initialized within the EJB. The code sample below shows one way of initializing an application server vendor certified ORB from within the EJB.

Code Sample 2: Source code sample showing how to initialize an external ORB from within an EJB

// 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);

We ran the tests on ORBs from two different vendors (ORB1 and ORB2) and three different application servers. Two of the application servers used built-in ORBs for CORBA communication, whereas the third application server needed an external ORB (ORB1) to be initialized for the CORBA interoperability. The different ORB/application server combinations and their respective names are given below

• CC: Stand alone CORBA client. There are two instances, one using ORB1 and the other using ORB2.
  
  
• ASIO: Application server with built-in ORB. There are two instances, one using ORB1 and the other using ORB2.
  
  
• ASRO: Application server which requires an external ORB to be initialized for CORBA communication. There is one instance using ORB1.

The tests were run on a Sun E450 server with 4 X 296 MHz CPU and 1 GB of RAM running Solaris 8. Both the CORBA client/J2EE application and the CORBA server were running on the same machine. The Java version was JDK 1.3.0_02. The heap sizes of all the application servers and the java applications were set to 128 MB.

Results

The variation in response time with data size was measured for different configurations. Figures 4 shows the response time versus data size for static invocation using ORB1. As expected the response time increases with data size. For the most part, the application server with the built-in ORB has a slightly lower response time than the standalone CORBA client. The response time for the other application server which needed the initialization of an external ORB is significantly higher than the standalone client.

Figure 4: Response time versus data size for static invocation using ORB1

Figure 5 shows the response time versus data size for the static invocation using ORB2. The results are very similar to those in the previous graph. In this case however, the application server performs significantly better than the standalone client.

Figure 5: Response time versus data size for static invocation using ORB2

Figures 6 and 7 show the response time versus data size for the dynamic invocation using ORB1 and ORB2. The general trend for the dynamic invocation is the same as that for the static invocation for both ORB 1 and ORB2.

Figure 6: Response time versus data size for dynamic invocation using ORB1

Figure 7: Response time versus data size for dynamic invocation using ORB2

Figures 8 and 9 show the ratio of the response time for the different application servers to that of the standalone CORBA client at three different data sizes for static and dynamic invocations respectively.

Figure 8: Ratio of response times of the application servers to that of the standalone client (static invocation)

Figure 9: Ratio of response times of the application servers to that of the standalone client (dynamic invocation)

Application servers that use built-in ORBs for CORBA communications perform better than standalone clients. For ORB1, the ratio changes from 0.83 to 0.94 as the data size is increased from 100 KB to 300 KB. The application server which needed an external ORB to be initialized for CORBA communication, performed poorly with respect to the standalone client. The ratio varied from 1.59 to 2.27 as the data size is increased from 100 KB to 300 KB. The application server using built-in ORB2 performed the best compared to the standalone client. The variation in the ratio was negligible as the data size was increased from 100 KB to 300 KB.

The tests were carried out utilizing application servers currently available in the market. Since we did not have access to the source code of any of the application servers, we were unable to determine why some performed better or worse than the standalone CORBA clients.

Figure 10 shows the variation of response times with data size for both static and dynamic invocations using ORB2. The response time for the dynamic invocation is greater than that for the static invocation. This is as expected because of the overhead of creating a request, populating it with parameters and marshalling the data^[5].

Figure 10: Response time versus data size for static and dynamic invocations using ORB2

Figure 11 shows the ratio of response times for dynamic invocations to that of static invocations for the different application servers and standalone clients at three different data sizes. The ratio varies from a minimum of 1.68 to a maximum of 2.25 with an average of 1.95.

Figure 11: Ratio of response times of dynamic to static invocations

Summary

J2EE components interoperate easily with CORBA objects. We were successful in showing this interoperability on multiple application servers and multiple ORBs.

We evaluated the performance of the J2EE-CORBA interoperability portion of the end-to-end J2EE-CORBA interoperability architecture. The performance characteristics depend on how the application servers are configured for CORBA interoperability. Application servers that use their built-in ORB for CORBA communications performed better than standalone CORBA clients in invoking methods on the CORBA server object. The performance of these application servers, as compared to standalone clients, does not vary much with the payload size.

The application server that required an external ORB to be initialized for CORBA communications showed lower performance when compared to standalone clients. The performance of the application server as compared to the standalone client deteriorated as the pay load size increased.

For the IDL that we worked with, dynamic invocations were approximately twice as slow as static invocations. Dynamic invocations provide a lot of flexibility. However, the penalty that the user pays for this flexibility is lower performance due to the various overheads involved in making the dynamic invocation.

In conclusion, new components built on top of the J2EE platform can interoperate seamlessly with the existing CORBA infrastructure. By using J2EE servers that are configured appropriately for CORBA interoperability, these J2EE-CORBA systems can provide CORBA interoperability performance comparable to and in some cases better than the existing systems of CORBA clients communicating directly to the CORBA servers.

References

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.