5. CORBA Documentation
Linux CORBA Reference and Evaluation
This page is part of the Linux Business Solutions Project, and has an excellent presentation of various CORBA systems that can run on Linux, as well as some comparative information.
Components in the GNOME Project
This document describes the strategies being used to decompose GNOME applications into "components."
Amazon present Unix Shell Objects
Advanced CORBA Programming with C++ by Michi Henning and Steve Vinoski
Easter Egg Contest Results from Advanced CORBA Programming with C++
The Open Brand for CORBA - Program Data Sheet
>Brand Fees
Open Brand program for CORBA are based on annual revenues:
$15,000 per annum - For Organizations less than $25M
$20,000 per annum - For Organizations greater than $25M but less than $100M
$30,000 per annum - For Organizations greater than $100M
Execution of the Open Brand Trademark License Agreement (TMLA) is prerequisite.
Test Suite Fees
$85,000 - First Language(C and C++ or JavaTM), 10 Year Corporate Source Code License
$21,250 - 12 months Standard Support & Maintenance
$65,000 - Second Language (C and C++ or JavaTM), 10 Year Corporate Source Code License
$16,250 - 12 month Standard Support & Maintenance.
Execution of The Open Group Test Suite Source Code License Agreement is a prerequisite.
On the issue of "What if the Internet were built using CORBA?" the following is interesting.
The Internet uses a collection of many, fairly ad-hoc, application-level protocols. We have ftp for file transfer, telnet for interactive sessions, NNTP to move news, SMTP to move mail, HTTP to serve web pages, etc, etc.
These protocols were added over time as the need for them arose. (Note that all of these are connection-oriented protocols.)
Assume that we had CORBA before all these protocols were developed. In that case (assuming wide-spread availability of CORBA), it seems to me that a lot of these protocols would have never been invented. Instead, we would have designed IDL interfaces to these application services and used IIOP underneath for all of them. The advantage would have been that a whole plethora of application-level protocols would have never arisen. This has benefits -- for example, a web browser wouldn't have to ship with a whole stack of protocol engines built into it.
Given that an object reference is typed and universally identifies an object, we also could have ditched a whole lot of addressing conventions. URLs, e-mail addresses, newsgroup names, ftp path names, telnet ports, etc. Instead, we would be using object references and a federated naming service to find them, similar to the DNS. The recently adopted Interoperable Naming Service spec defines a URL format for names in a CORBA Naming Service, so we could have used something like this format as a universal naming convention for everything.
If we would use object references instead of URLs for web pages, I could move a web page to a different location without breaking all existing links to that page. That's because CORBA references don't hard-code an address and path into a file system -- instead, they use a level of indirection that permits migration of objects to different address spaces.
Some more idle musings... Suppose for a moment that CORBA is built into the OS kernel and that OS objects, such as segment descriptors and inodes are CORBA objects that are addressed via object references. Suddenly, a whole new world opens up. For example, there would be no need for distributed file systems such as NFS, RFS, or DFS (which are just more application-level protocols for a specific purpose, namely file sharing). Instead, all file systems would be automatically distributed, almost by accident. You could share files at any level of granularity, down to a single file, simply because they are individually addressable by object references (instead of having to export sub-trees of a file system).
If we had segment descriptors that are CORBA references, shared memory could transparently be accessed over the network, without the need for another protocol.
As I said above, these are idle musings, and there are technical issues that I have ignored (such as security and performance, but I don't think these would be insurmountable). So, life could be a whole lot simpler if CORBA were the substrate of the Internet. But, of course, it isn't, and I don't think it is likely to be that substrate any time soon.
I tend to agree with Michi's comments; CORBA essentially represents a way of describing protocols in a portable manner, allowing the descriptions to largely ignore implementation and interoperability.
Much of the complexity of Internet protocol definitions come from struggling with describing protocols in such a way as to ensure interoperability. If interoperability is a given, by using an ORB as an intermediary, protocol descriptions could be made more sophisticated without making them more complex.
On a more practical note, it would be interesting to implement IDL that represents some of these protocols, and thereby provide alternative interfaces to some IETF protocols, not unlike the way that XML has been used to provide alternative data representations for some IETF "data protocols," notably the XML DTD for iCal.
An interesting experiment would be to build IDL for things like NNTP, SMTP, or even NTP, and see how such services perform "across CORBA" as compared to present implementations using sockets.
More practical might be to use this for HTTP, and possibly other protocols commonly used by web browsers, that goes along with Michi's comments about web browsers including a "whole stack of protocol engines."
Also interesting would be to do a CORBAized LPD, as printing services on Unix systems have long been somewhat problematic due to the limited feedback that the LPD protocol permits.
kORBit is a port of the CORBA Object Request Broker ORBit to the Linux kernel.
This may not be the wisest project ever attempted; the point of the exercise is to try it out and see if it does have merit...
Columns from C++ Report Magazine on CORBA by Steve Vinoski and Douglas C. Schmidt.
These contain a lot of worthwhile material regardless of what language you use with CORBA...
I wrote chapters on CORBA for the Wrox Press book Professional Linux Programming
published by Wrox Press. IBM DeveloperWorks: Building Secure Software - Selecting Technologies