In-depth investigation of CORBA vs. SOAP

 

 

1.  Overview

 

What is SOAP?

 

SOAP (Simple Object Access Protocol) is a proposed standard for linking Internet applications running on different platforms, using XML messages. SOAP is designed to connect together programs running on different machines, without regard to what OS/CPU is on each. It’s basically remote procedure calls (RPC) implemented via HTTP with XML content.

 

 

 

What is CORBA?

 

CORBA is an acronym for Common Object Request Broker Architecture. It is a standard architecture for developing distributed object oriented applications conforming to the Object Management Architecture (OMA).CORBA is an object bus enabling the client to invoke methods on remote objects from the same or another vendor at the server independent of the language the objects have been written in, operating systems, and their location. The interaction between client and server is mediated by object request brokers (ORBs) on both the client and server sides, communicating typically via IIOP (Internet Inter-ORB Protocol). The capabilities of CORBA objects (operations or methods) are defined using the Interface Definition Language (IDL).

 

 

CORBA is a distributed object standard, SOAP is a communication standard. A better comparison would be CORBA and Web services. Both standards use standard communications mechanisms, CORBA uses IIOP (Internet Inter ORB Protocol), and Web services uses SOAP. Both have interface definition languages, CORBA’s is IDL (interface definition language), and in the world of Web services it’s WSDL (Web Services Definition Language). A key difference between CORBA and the Web service technologies (UDDI/WSDL/SOAP) is that CORBA provides a true object-oriented component architecture unlike the Web services, which are primarily message based (SOAP, despite its name, does not really deal with objects).

 

 

2.  SOAP vs CORBA

 

In the following sections, we will elaborate the differences between SOAP and CORBA.

 

 

Performance

 

A study presented at the OMG meeting showed tag-based protocols like XML or SOAP to be 30 to 60 times slower than binary protocols like IIOP. Of course, this depends very much on the type of information being transferred. There are even a few cases in which XML can actually be shorter than IIOP (e.g. if you are transferring a lot of double values which all happen to be something like “1”, then this might use up less space than transferring full 64 bit IEEE double encodings).

 

Another performance related aspect is that parsing IIOP messages is generally simpler and more efficient than parsing XML (e.g. you do not have to parse end tags). With SOAP, all data is converted (marshalled actually) to XML, Ints are converted to human readable decimal numbers. Parsing all the XML and converting them back takes more processing power than with IIOP from CORBA.

 

More commonly, you will find that SOAP requires 10-15 times the bandwidth of IIOP and, if you use structures or unions extensively, you can easily end up consuming 50-100 times the bandwidth. SOAP communication can’t ever be anywhere near as fast as binary marshaling, such as IIOP. I can’t see it being used for anything that is intensive either in call rate or in bandwidth.

 

There is a paper from IEEE: Performance of SOAP in Web Service Environment Compared to CORBA

 http://portal.acm.org/citation.cfm?id=785409.785819&coll=GUIDE&dl=ACM&CFID=15151515&CFTOKEN=6184618

 

The abstract of article :

….. Web Services is a new concept that promises flexibility and interconnection between different systems.The communication in Web Services uses SOAP – Simple Object Access Protocol, which is based on XML.We have together with an industrial partner made experiments with SOAP in a Web Service environment to find out the response time using SOAP compared to CORBA.It turns out that a direct and naive use of SOAP would result in a response time degradation of a factor 400 compared to CORBA.We identified the major reasons for the poor performance of SOAP and evaluated some performance improvement techniques.After applying these the techniques, the performance of CORBA is 7 times better compared to SOAP. …

There is a paper from IEEE

 

Development Effort

 

The amount of coding required by a CORBA client vs. a client using a SOAP framework is substantial. Not only did the CORBA client have significantly fewer lines of code, the level of abstraction was much higher. The client simply invoked an operation on the stub/proxy just like it was a local object. The SOAP programmer, however, has to construct a message, put the arguments in the message, and then send the message. Now, we know it will be possible to provide greater abstraction, but then is basically what the IDL compiler-generated stub classes provided by CORBA.

 

 

Here are the basic steps for creating a client which interacts with a SOAP RPC-based service as described in the Apache SOAP v2.2 Documentation:

 

   1. Obtain the interface description of the SOAP service.

 

   2. Make sure that there are serializes registered for all parameters which you will be sending, and desterilizes for all information which you will be receiving back.

 

   3. Create the org.apache.soap.rpc.RPCMessage.Call object.

 

   4. Set the target URI into the Call object using the setTargetObjectURI(…) method.

 

   5. Set the method name that you wish to invoke into the Call object using the setMethodName(…) method.

 

   6. Create any Parameter objects necessary for the RPC call and set them into the Call object using the setParams(…) method.

 

   7. Execute the Call object’s invoke(…) method and capture the Response object which is returned from invoke(…).

 

   8. Check the Response object to see if a fault was generated using the generatedFault() method.

 

   9. If a fault was returned, retrieve it using the getFault(…) method, otherwise extract any result or returned parameters using the getReturnValue() and getParams() methods respectively.

 

Here’s some simplified code from:

 

  http://www.javaworld.com/javaworld/jw-04-2001/jw-0427-soap.html

 

    URL url = new URL(“http://localhost:8080/apache-soap/servlet/rpcrouter”);       

    Call call = new Call();

    call.setTargetObjectURI(“urn:Hello”);

    call.setMethodName(“sayHelloTo”);

    call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);       

    Vector params = new Vector();       

    params.addElement(new Parameter(“name”, String.class, “Mark”,

null));

    call.setParams(params);

    Response resp = null;       

    try {

        resp = call.invoke(url, “”);

        if ( !resp.generatedFault() ) {

           Parameter ret = resp.getReturnValue();

           Object value = ret.getValue();           

           System.out.println(value);

        }

        else {

           Fault fault = resp.getFault();

           System.err.println(“Generated fault!”);

        }

    }

    catch (Exception e) {

        e.printStackTrace();

    }

 

However, the invoke through CORBA is much easier. In CORBA, once the reference to the service is obtained and narrowed, any additional invocation is one line of code, however SOAP requires the construction of a new Call object foreach new request on a different operation!

 

    try {

        org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);

        org.omg.CORBA.Object rootObj =

             orb.resolve_initial_references(“NameService”);

        NamingContextExt root = NamingContextExtHelper.narrow(rootObj);

        org.omg.CORBA.Object object =

             root.resolve(root.to_name(“AcmeMyService”));

        MyService myService =  MyServiceHelper.narrow(object);

 

        int ret = myService.sayHelloTo(“Mark”);

    } catch (MyServiceException e) {

        System.err.println(“Generated fault!”);

    } catch (Exception e) {

        e.printStackTrace();

    }

 

The CORBA approach is clearly closer to the programming style of the host language, and doesn’t require the programmer to fiddle with Call objects, set method names, provide serializes and desterilizes, individually set parameters, extract results, check

for faults, etc. 

 

 

IDL

 

Both CORBA and SOAP have interface definition languages, CORBA’s is IDL (interface definition language), and in the world of Web services it’s WSDL (Web Services Definition Language).

 

While we appreciate the power of XML, the syntax still leaves something to be desired. CORBA’s IDL is clear and because the language mapping is standardized you know exactly what your program should look like.

 

The following are two examples:

 

    struct EchoData {

        long     aLong;

        boolean  aBool;

        string   aString;

    };

 

    <esd:CType name=”EchoData” >

        <esd:item name=”aLong”    type=”xsd:int”     builtin=”true”

array=”false” inout=”false”/>

        <esd:item name=”aBool”    type=”xsd:boolean” builtin=”true”

array=”false” inout=”false”/>

        <esd:item name=”aString”  type=”xsd:string”  builtin=”true”

array=”false” inout=”false”/>

    </esd:CType>

 

    EchoData getData( in long l, in boolean b, in string s );

 

    <esd:Method name=”getData”>

        <esd:InParam name=”GetDataRequest”>

            <esd:item name=”l” type=”xsd:int”     builtin=”true”

array=”false” inout=”false”/>

            <esd:item name=”b” type=”xsd:boolean” builtin=”true”

array=”false” inout=”false”/>

            <esd:item name=”s” type=”xsd:string”  builtin=”true”

array=”false” inout=”false”/>

        </esd:InParam>

 

        <esd:OutParam name=”GetDataResponse”>

            <esd:item name=”return” type=”typens:EchoData”

builtin=”false” array=”false” inout=”false”/>

        </esd:OutParam>

</esd:Method>

 

 

SOAP has a very weak type system. For example, you can’t tell whether a floating point number is supposed to be a float, double, or long double, you can’t tell whether a positive number is signed or unsigned, you can’t tell whether a string is bounded or unbounded, etc…. CORBA does not only structure the transferred data, it also provides standard encodings for data types. For example, the XML-based parser can not correctly handle

“<price>123,45</price>” (german decimal separator) as well as

“<price>123.45</price>” (english convention). 

But IIOP simply does not have problems like that.  

 

 

 

Security & Scalability

 

SOAP is designed to connect together programs running on different machines. Because no security is required in HTTP, XML, or SOAP, it’s a pretty simple bet that different people will bungle any embedded security in different ways, leading to different holes on different implementations. SOAP is going to open up a whole new avenue for security vulnerabilities. So, in effect, anyone who puts up a web server that offers interactive pages that make calls via cgi-bin to back-end applications has already weakened security. By allowing cgi-scripts in this way, I effectively accept that I have now delegated the job of maintaining security from the firewall to the scripts and the back-end applications, effectively disabling the firewall.

 

With CORBA, to open up a hole in a firewall, you have to assign a port number to each server and then punch a hole into the firewall for that port. With SOAP, everything you do goes through port 80, so you don’t have to change the configuration of the firewall whenever you add a new server. So, SOAP is more convenient in this respect. However, it’s also less efficient. By putting everything through port 80, you are putting the entire load on the single web server process that listens on that port whereas, if you use separate CORBA servers, you are getting a separate process and connection for each server. The upshot is that SOAP can’t ever scale as much as a solution that uses separate ports because the single server process at port 80 eventually becomes the critical bottleneck, which is a common disadvantage to all tunneling approaches.

 

Using CORBA for communications between organizations abroad the internet and through firewalls is today practically impossible or really a nightmare because of the usual firewalls configurations which only allow HTTP 80, SMTP… but no TCP on dynamic ports. If many people start let SOAP tunnel RPCs through firewalls, no reasonable system administrator will allow arbitrary HTTP traffic through any longer And yes, speed must be really bad as illustrated at before.

 

 

Reliability

In CORBA, the Portable Object Adapter (POA) policies combined with the Fault-tolerant CORBA features and the Load-balancing CORBA service provide the desired scalability to CORBA applications. The Fault tolerant CORBA uses the entity redundancy paradigm to provide fault tolerance to CORBA objects.

These issues are not part of SOAP, but are left to the components implementing these standards. Application servers (e.g. IBM’s WebSphere) implement their own mechanisms to handle scalability and reliability.

 

3.  Why SOAP is invented?

 

In essence, SOAP is aimed at this business blind spot. The reasoning in many organizations currently goes something like this:

 

        P: We offer customers access to business applications via the web.

        P: We have a firewall, so we are secure.

        —

        C: We have secure business applications.

 

Of course, the conclusion is not convincing, but it sounds plausible in explaining that to a non-technical person. SOAP simply offers a solution that works, given the way most businesses currently set up their web infrastructure.

 

I think SOAP looks very tempting at first because it is so simple and easy to understand that you can even explain it to your managers. Unfortunately, distributed systems in the real world are not that simple and I am sure that if SOAP is generally adopted, all the needed complexity will eventually be added. Why got to the trouble if CORBA already provides the solution now? 

 

 

SOAP will be useful in some situations and it will be useless in others. The old dream of having a single technology for purpose X (be that marshaling, instruction set, programming language, etc…) is just that: a dream. The one size fits all solution always contains trade-offs that are unacceptable in many scenarios. That’s why we have diversity in computing.

 

Using SOAP for communications inside a cluster of machines would be a mistake, whereas CORBA is perfect here. CORBA has already been deployed for real-time applications (telecommunications, finance, aeronautics, etc.). Over ten years of research and development have contributed to highly efficient and fine-tuned implementations. Telecommunication equipment vendors such as Lucent and Nokia are using CORBA to develop and produce telecommunication products enabling service providers to rapidly create, deploy, and manage value added services based on a common Intelligent Network (IN) architecture. Such products need to communicate with a large number of disparate telephony network elements. Long distance carriers such as Sprint have adopted high-efficiency object technology to manage its worldwide network. The network comprises large amount of equipment such as routers, hubs, switches, etc. running on several different hardware and software platforms. Thus, there is a need to use an extensible and flexible integration technology, which is provided by CORBA. To emphasize again, the key difference between CORBA and the SOAP based Web service technology is that CORBA provides a true object-oriented component architecture unlike the Web services, which are primarily message based.

 

4.  Benchmark of CORBA

 

There are numerous paper and benchmark results on the performance of CORBA. Please do a Google: performance of CORBA

 

Some facts from HP NonStop CORBA 2.6 software:

http://h71028.www7.hp.com/ERC/downloads/CORB26PD%5B1%5D.pdf#search=%22corba%20scalability%22

…. The HP Zero Latency Enterprise (ZLE) framework, for example, uses NonStop CORBA software to populate a database, reaching insert speeds of 75,000 transactions per second and beyond. Initial testing of NonStop CORBA 2.6 software shows 98 percent linear scalability across processors….

 

Also look at the link of Research on High-performance CORBA

http://www.cs.wustl.edu/~schmidt/corba-research-performance.html

 

 

5.  TAO

 

The ACE ORB (TAO), which is an open source,  standards-based, CORBA middleware framework that allows clients to invoke operations on distributed objects without concern for object location, programming language, OS platform, communication protocols and interconnects, and hardware. TAO is designed and implemented on the basis of patterns and components in the ACE framework

 

Here is list of successful stories of usage of TAO:

http://www.cs.wustl.edu/~schmidt/TAO-users.html

 

 

6.  Q&A

 

Q: I’m still not very clear on why I would want to use CORBA as opposed to some other method of inter-process communication.

A: There are a few areas where CORBA really shines. For applications that have various components written in different languages and/or need to run on different platforms, CORBA can make a lot of sense. CORBA takes care of some potentially messy details for you, such as automatically converting (through the marshaling process) number formats between different machines. In addition, CORBA provides an easily understood abstraction of distributed applications, consisting of object-oriented design, an exception model, and other useful concepts. But where CORBA is truly valuable is in applications used throughout an enterprise. CORBA’s many robust features–as well as those provided by the OMA CORBAservices and CORBAfacilities–and especially CORBA’s scalability, make it well suited for enterprise applications.

 

 

7. Some important references:

 

 

Performance of SOAP in Web Service Environment Compared to CORBA

http://portal.acm.org/citation.cfm?id=785409.785819&coll=GUIDE&dl=ACM&CFID=15151515&CFTOKEN=6184618

 

Reinventing the Wheel? CORBA vs. Web Services

 http://www2002.org/CDROM/alternate/395/

 

Crypto-Gram Newsletter on SOAP

http://www.schneier.com/crypto-gram-0006.html

 

 

Overview of the CORBA Performance http://nenya.ms.mff.cuni.cz/publications/TumaBuble-OverviewOfTheCORBAPerformance.pdf#search=%22performance%20of%20corba%20%22

 

EXPERIENCES WITH ADVANCED CORBA SERVICES

http://arxiv.org/ftp/cs/papers/0111/0111034.pdf#search=%22corba%20scalability%22