Here are some thoughts on CORBA vs. RMI for the CARMA data viewer. I've been reading white papers and working through the CORBA and RMI tutorials on java.sun.com and jguru.com. While nowhere near an expert on either, I have a better understanding of them than I did previously. So let me opine.
Both CORBA and RMI will require us to redesign our client-server models (which is good, methinks). Both come with arcane interface definitions that require separate programs (provided) to generate stub files, CORBA being slightly more arcane than RMI. CORBA is an industry standard with many companies and organizations behind it in the form of the consortium Object Management Group. RMI is a Sun "Pure Java" product. RMI will be easier to use, CORBA will allow easier integration of C/C++ code. A list of pros/cons is below.
The AIPS++ 'Measurement Set' conforms to neither CORBA nor RMI, since its inception predates both. In that respect, it doesn't matter which we choose, since someone will eventually have to write and MS<->CORBA filler/wrapper.
My recommendation is that we choose CORBA as our distributed object
model with the Sun ORB & Java IDL. The Sun ORB is a somewhat behind
the commercial competitors in terms of features, but I think we can
live with it while Sun plays catch-up.
Java/Corba/IDL
Third Party ORBS
| PROS | CONS | |
| CORBA | Industry Standard | Not "Pure Java" |
| Multilingual 1:
Can import classes written in other languages. |
Many vendors and Object Request Brokers. | |
| Multilingual 2:
IDL file can be used to generate object in any language. |
Interface Definition Language (IDL) somewhat arcane. | |
| Proliferation of files (IDL stub/skeleton files.) | ||
| Remote Method Invocation | "Pure Java" | Not industry standard |
| One vendor, Sun. Can rely on it being around in the future. | rmic file generation somewhat arcane | |
| Somewhat simpler than CORBA. Easier to use. | Proliferation of files (rmic stub/skeletion files) | |
| RMI-IIOP (in JDK1.3) can "translate CORBA" | Why not just speak CORBA, then? |
| PROS | CONS | |
| Sun Java ORB (JDK1.2) | One vendor, Sun. | Not fully-featured. Lacks Interface Repository, Portable Object Adaptor, Transaction Service |
| May not need all features immediately. Future JDK releases will implement. | ||
| Very Well-documented. | ||
| Commercial ORB | Can choose industry "favorite", e.g. Visibroker, Orbix. | Makes code less portable |
| More fully-featured than Sun Java ORB | Cost $$ (or $$$$) | |
| Industry "favorites" reliable for longish term | ||
| Probably well-documented. | ||
| Free ORB | Portability not an issue if we ship ORB with code. | Long-term reliability questionable, i.e. no guarantee the ORB won't disappear when the programmer gets a real job! |
| Costs nothing | You get what you pay for? | |
| More fully-featured than Sun Java ORB | Perhaps not as well-documented. |