Xml Rpc Vs Corba

Two very different approaches to distributed computing:

XmlRpc -- Simplicity.
CommonObjectRequestBrokerArchitecture -- Feature-completeness.

(Summaries of each can be found on their WikiPages)

How did things turn out?

XML-RPC is simple. CORBA is featureful. Is XML-RPC simple-stupid or simple-elegant? Is CORBA feature-complete or feature-creeped?

Bandwidth - The XML data format adds overhead compared to CORBA's binary format. If this becomes a problem, one could compress the text en route. (XML compresses very well due to its repetitivity.)
Latency - Creating a connection for each invocation could add up. CORBA has configurable policies to let you choose how this works. With XML-RPC, you'll have to figure out something with persistent HTTP.
Co-location advantages - That is, if the sender and implementor of a method are both on the same machine or program, CORBA does what it can to reduce the overhead of the invocation. One might wonder, though, how often this is a problem - why are you using a distributed object system if loopback calls are too expensive?
Rigid Interface Specs - CORBA forces you to explicity define interfaces for types. With XML-RPC you don't have to (though you can via DTD's). It's up to you to decide which is better.
Object References - CORBA's solution is rather complex that requires a good bit of explanation beyond the source code. XML-RPC just uses URLs. This comes back to the "flexibility or simplicity" choice.
Compile-time - Compiling a CORBA "Hello World" takes more than a minute on a 400mhz/128Mb. The XML-RPC equivalent takes less than a second. Does this hold for larger projects?
Getting Started - With CORBA, you'll need a huge amount of knowledge, downloading, and configuring. With XML-RPC, you'll be able to do something useful in less than thirty minutes.
Completeness - CORBA provides a complete end to end transport, session and presentation layer. XML only defines the presentation layer, leaving the other layers to be agreed upon separately. Usually, XML is carried over HTTP, which was not really designed as a data protocol.
Transactions - CORBA implemenations have from the beginning supported transactions. For many business components it is essential to have reliable and determinate protocol. Most CORBA implemenations include support for distributed two phase transactions. A stock trading component for example cannot maybe make a stock trade.

Hmmm. With CORBA I can build an object-oriented distributed system, including the ability to pass object references from computer to computer. What is your work around for that?

Good point. I added a bullet point above. You can pass URL's and such, which isn't nearly as "flexible" but it's simple enough to make up for it, IMHO.

In CORBA, the object implementation can move, and my client can transparently follow the implementation to its new location. You would have to consciously reestablish a new connection using a different URL.

I can access the objects in this distributed system using many different languages (without having to rewrite the implementation). How do you do that in XmlRpc? -- don davis

As with CORBA, someone needs to write an implementation. But yes, XmlRpc is language-independent in nature. Actually, I learned it by alternating between using the API and manually typing in requests over telnet. Try that with IIOP and you'll win a prize.

That's fine for ascii, but how do you type in binary data? What about data derived from some existing program that you want to transfer? I think the obvious difference here is that the more complex CORBA can perform more complicated tasks, but XMLRPC is perfectly suited for simple transfers.

CORBA may be complicated internally, but it is actually quite easy to use: You put your interfaces in IDL, compile them, and then derive your classes from theirs to provide an implementation. The CORBA code is doing lots of complicated things, but it's their code; you don't have to write the code, or debug it. -- JeffGrigg

You don't have to debug it??? Wow, you must be a good programmer!!! ;-)

: A: I am a truely amazing programmer. ;->

True, it can be easy to use, but caveat emptor. But trade-offs I've experienced for products like Orbix and others based on the CORBA architecture are that they can be bulky, IDL stubs can get out of whack with the proxy classes, and tracing/debugging through IDL-generated code can be a nightmare, especially if you're required to snoop on IIOP/GIOP packets. And that whole interoperability thing was a joke.

With XML-RPC and/or SOAP, you can open a socket on a host and port, send a string, close the connection, and you're done. Or as mentioned above, you can simply telnet an invocation into a server. With HTTP as its wire protocol, its platform is already absolutely ubiquitous. Now, it's up to the developer community (e.g., an Apache group equivalent) to build lightweight, open abstractions that make it easier to use.

-- PhilipEskelin

You don't have to debug the hundreds of thousands of lines of code that Orbix had to write to make CORBA work. So if it meets your needs, it can be quite easy to use. (But I think I'll add a few points to "WhatsWrongWithCorba" too. ;-) -- JeffGrigg

True, but there were times with I was working with Orbix that I wish I *could* have debugged all that code ;-). Anyway, I agree with you and have a funny story: one time a technician at Iona wanted me to write some inline assembly to make a call into their DLL to shut down an internal factory that did a GetProcAddress?() on a C++ method and basically faked the this pointer on the stack to invoke an internal method, in a last ditch attempt to solve a problem where using Orbix in any DLL or ActiveX component would cause a crash upon app exit. -- PhilipEskelin

Ick!!! ...but then you already knew that. ;-> -- JeffGrigg

Don't judge CORBA, the standard, by Orbix, an implementation of that standard. There are other CORBA implementations that are faster, more flexible, more reliable, more configurable, etc. Orbit, TAO, Mico and Omniorb come to mind.

The threading model enforced by ORBs is very limiting. To have CORBA handle your thread pooling architecture is a big mistake. As an application i want to handle my own threading. It's quite easy to make an ORB run out of threads because of downed connections. We make extensive use of message queuing which ORBs could easily support but don't.

The Portable Object Adapter, which is part of the CORBA 2.3, allows an application to control the threading model used to dispatch object requests.

There is also the CORBA Messaging spec, which provides queuing, asynchronous invocation, and other such niceties.

This didn't appear to be possible in Visibroker. There were more options on assigning pools to clients etc, but not about skipping pools altogether. Could have missed it though.

Don't judge CORBA, the standard, by Visibroker, an implementation of that standard. There are other CORBA implementations that are faster, more flexible, more reliable, more configurable, ...

I want to be able to do everything in my code. With IDL I have to run a compiler to generate code that has to be compiled. With XML I can do everything on the fly in my application. I'm not dependent on external tools.

OTOH, It's much easier to maintain a few lines of declarative IDL than it is to maintain the many more lines of code required to encode and decode queries into and out of XML.

You can trade runtime flexibility for compile-time type safety in CORBA by passing around Any parameters (i.e., dynamically typed blobs). The difference is that the ORB is likely to provide better programming language level support for decoding this data than an XML-RPC implementation. -- EricMarsden

CORBA has the Dynamic Invocation Interface and Dynamic Skeleton Interface, making it possible to write a CORBA client or server without any IDL. (But it's a whole lot easier with IDL and the static stubs and skeletons.)

XML really is nothing more than a repackaging of the EDI ideas of old.

Compile-time - Compiling a CORBA "Hello World" takes more than a minute on a 400mhz/128Mb. The XML-RPC equivalent takes less than a second. Does this hold for larger projects? No, it doesn't. It doesn't really take long to compile (about 18 seconds on my machine for 170 line IDL, including make dependency checking, idl processing and compiling the stubs and skeletons). Anyway the IDL changes infrequently, compared to the implementation code. Generally, IDLs get agreed on early, and are pretty stable after that. -- RichardHome

"Getting Started - With CORBA, you'll need a huge amount of knowledge, downloading, and configuring. With XML-RPC, you'll be able to do something useful in less than thirty minutes."

That depends. As already mentioned, there are some great implementations out the (OmniORB) that are as easy to download, install and run as XML-RPC. Just as with XML-RPC, look for good documentation (examples), and support and you should be on your way with a minimum of knowledge. Certainly, should you require the more advanced features of Corba, you will need to hit the books (Henning and Vinoski).

The complexity of Corba is certainly a myth. Duncan Grisby has some nice presentations available at http://www.grisby.org/presentations/. Especially, check out the Python bindings with OmniORB :)

I look around at the CORBA people, and all I see is: "No, no, no! It's a myth that XML-RPC is easier than CORBA. With the right tools..."

And then after researching and researching and figuring out ORB vs. IOR vs. IID vs. what have you, you download the "right tools," and they don't work.

But then you just open up Python, "import xmlrpclib", and...

Ptbhthbhthbht.

Has Python got a "import RestHttp?" and give you close to all tool support you will need for WebServices? -- dl

CategoryProgrammingLanguageComparisons CategoryXml CategoryCorba