Comparing RPC implementations: CORBA, Hessian, Burlap and SOAP.

Published 5-Oct-2004

Summary: This little test project compares convenience of use and performance of 4 RPC implementations: CORBA (that comes with j2sdk1.4.2_05), Hessian, Burlap and SOAP ( Axis 1.2 RC1).

Source code: Download it here.

This little test has been inspired by this post at TheServerSide.com . I decided to compare several RPC methods of communication between client and server.
1. I have started from CORBA implementation.

Even I did not use CORBA for awhile I quickly recovered from memory and CORBA spec(yes, it is readable and useful!) what needs to be in IDL.

1    module KGIRiaTest 
2    { 
3     
4      struct ContactVO{ 
5        string type; 
6        string value; 
7      }; 
8     
9     
10     struct UserVO{ 
11       string login; 
12       string fullName; 
13       sequence <ContactVO> contacts; 
14     }; 
15    
16     typedef sequence <UserVO> ListUserVO; 
17    
18     interface RiaServer 
19     { 
20       const string SERVER_NAME = "ria_server"; 
21       UserVO getUser( in string login); 
22       ListUserVO listUsers(); 
23     }; 
24   };

I would say that IDL looks refreshingly human friendly and it is kind of obvious what is defined there even for somebody, who never saw IDLs before. But lets describe what is there anyway, the IDL defines:

• couple of Value Objects ( or Data Transfer Objects ) #4 and #10
• and server interface ( #18) that has couple of methods ;
• server interface also defines SERVER_NAME constant to be used as default service name.

Now lets run idlj

7     <target name="idlc"> 
8       <mkdir dir="build/java_generated"/> 
9       <exec executable="idlj"> 
10        <arg line="-emitAll -fall -td build/java_generated  metadata/ria.idl"/> 
11      </exec> 
12    </target> 
13    

and generate whole bunch of Java classes

There are 3 types of classes: server side classes client side stub classes and common interface and VO classes In real life they would be packaged in two separate jars: one for server and another for client ( #3 of course would be packaged in both jars).

As we may see this is very simple process. Now lets create implementation of for our server. It is not difficult too: we just extend RiaServerPOA class that was conveniently prepared for us by idlj.

20 public class RiaServerImpl extends RiaServerPOA{

In the implementation we will simply return array of 13 Users, which we prepare upon class initialization.

Then we start naming service ( do not forget su - root on Unix because naming works on port 900 by default )

and start our CORBA service. Now we will write simple client CorbaImplTest, which will retrieve out Business Interface (RiaServerOperations)

That is it! As we can see dealing with CORBA is not that bad as painted by SOAP evangelists.

Now lets expose our server implementation with using Hessian and Burlap protocols. It is extremely simple, all we need is to extend (Hessian|Burlap)Servlet and implement our business interface like this:

17   public class RiaServerBurlap extends BurlapServlet implements RiaServerOperations{ 
18    
19       RiaServerImpl impl = new RiaServerImpl(); 
20    
21     public UserVO getUser(String login) { 
22       return impl.getUser( login ); 
23     } 
24    
25     public UserVO[] listUsers() { 
26       return impl.listUsers(); 
27     } 
28      
29   } 
30   

As we see we use the same implementation class as we use for CORBA server: it is POJO. Now lets configure web.xml and deploy our little web application on server:

Writing clients for Hessian and Burlap is just pure pleasure:

  
17     public static void main(String[] args) { 
18       try{ 
19         String url = "http://localhost:8080/protocol_compare/RiaServerBurlap"; 
20         BurlapProxyFactory factory = new BurlapProxyFactory(); 
21         RiaServerOperations riaServerOperations = (RiaServerOperations) factory.create(RiaServerOperations.class, url); 
22         TestingTimer.timeListUsers( "Burlap", riaServerOperations ); 
23       }catch( Exception e ){ 
24         e.printStackTrace(); 
25       } 
26    
27     } 
  

And finally lets try exposing the same POJO as SOAP with Axis. IMO it is less convenient environment to deal with: I cheated and manually inserted service description from service wsdd file into server-config.wsdd . Development steps with Axis are almost the same as with CORBA development, but they are not that polished yet and a bit less intuitive. Although once figured out and placed into build.xml file it works OK.

After deploying service we will use wsdl2java to generate SOAP client:

15 <target name="soapc" description="Generate SOAP client"> 16 <property name="axis_generated" value="build/axis_generated_java"/> 17 <mkdir dir="${axis_generated}"/> 18 <java classname="org.apache.axis.wsdl.WSDL2Java"> 19 <classpath> 20 <fileset dir="${home.axis}" includes="lib/**.jar"/> 21 <fileset dir="${home.j2ee}" includes="lib/**/*.jar"/> 22 </classpath> 23 24 <arg line="-o ${axis_generated} -p axis.client -s -a http://localhost:8080/protocol_compare/services/RiaServerImpl?wsdl"/> 25 </java> 26 </target>

And now we can run all our tests side by side:

This little test does not pretend to be a complete comparison of technologies. It is just a little exercise, feel free to repeat it and draw your conclusion.
IMO the test shows that:

• SOAP based solution is slowest and least convenient to develop with, but might be necessary to ensure interoperability.
• Hessian and Burlap protocols are refreshingly simple and convenient to work with and I recommend trying them out, probably as RMI, SOAP replacement for Java and Python clients;
• The whole SOAP story reminds me DOS/WIN vs Unix story. Unix is making its victorious return (MacOS-X, GNU-Linux) and CORBA will return some day because it sound technology that just makes sense. In the mean time I suggest keeping eye on CORBA and study its architecture and services.

 

Happy coding!