Are distributed objects fast enough? - SOA

Matjaz B. Juric, Ales Zivkovic, Ivan Rozman

Are distributed objects fast enough? Java is becoming important for building real world, mission critical applications. Although Java is still not a perfect language, it is becoming more mature every day. We all know the advantages of Java, especially the “write once, run anywhere” approach, but we are also aware of the disadvantages. Performance issue is the most common reason for Java rarely use today. In spite of that, there are many large companies claiming they are developing their crucial business applications in Java. Modern applications are not monolithic programs, they are built of objects. Therefor developers need a “glue” for bringing all the pieces together and combine them into a functional application. Object location independence is an advantage that gives developers the ability to structure the application into multiple tiers. For building distributed applications in Java it is natural to choose Remote Method Invocation (RMI), but there is another possibility - CORBA. CORBA is a valuable alternative to RMI. We could describe CORBA as a superset of RMI, although both technologies are not compatible yet. Both CORBA and RMI allow remote method invocation independently of location, however CORBA is more than just an object request broker. It offers programming language independence and a rich set of object services and common facilities all the way to the business objects. There are multiple factors that can affect the decision. One of them is certainly the performance. To get an overview about the performance of RMI and CORBA we have done several measurements and experiments to simulate real world scenarios. We hope that the founding of our work will help you to get a clearer picture about both distributed object models.

Testing method The goal was to measure the overhead which was introduced into method invocation by CORBA and RMI. Therefore we have developed several testing patterns and methods with different basic data types of parameters and return values. As a basis for performed tests we used an ATM (Automatic Teller Machine) application, developed for demonstration purposes for one of our banks. The invocation time was measured for six methods with different return types. The main idea was to investigate the influence of data types on performance. The significant code with methods and corresponding classes is shown in Listing 1. As you can see all the methods return just a value. We chose this approach to minimize the influence of time needed to execute the methods.

… public class Atm { … private long number; private boolean working=true; … final public boolean Working() { return working; } final public long getAtmNo() { return number; } } … public class Card { … private int number; … final public int getNumber() { return number; } } … public class Account { … private String type; private float balance=0f; private double limit; … final public float getBalance() { return balance; } final public String getType() return type; }

{

final public double getLimit() { return limit; } } …

Listing 1: Methods, used for performance measurement

The methods were invoked from an applet which had a panel for displaying results and a button for start. Time was measured with System.currentTimeMillis() method. It has returned time in milliseconds. To achieve more accurate results methods were invoked several times. In Listing 2 the skeleton of testing applet is shown.

… boolean is_working=false; my_account.setBalance((float)50f); for(int j=0;j