ReFresco 02: Pre-existing alternatives to CORBA =============================================== (or, "Yes, I've heard of D-BUS -- why do you ask?") I think there's a lot of reluctance to roll-your-own when it comes to protocols. When I tell people about the problems with CORBA, almost everyone starts trying to come up with different off the shelf systems that could replace it. I'd love to find such a system, but everything I've looked at falls pretty short. Here I'll briefly list the various systems that I've come across, and explain briefly (or not so briefly) why I think they fall short. CORBA/ICE: CORBA spec: http://www.omg.org ICE spec: http://www.zeroc.com/download/Ice/1.2/Ice-1.2.0.pdf - Discussed in ReFresco 1. D-BUS: http://www.freedesktop.org/software/dbus/doc/dbus-specification.html - Generally, designed for multicasting small messages and the like, not for full-fledged distributed objects; by itself this doesn't mean it will be inappropriate for a more demanding system, but makes impedence mismatch more likely. But some consequences follow. - Designed for use with well-known object names (UTF-8!), so making secure is awkward - No way to do pipelining - Method returns are forgeable -- identified by 32-bit serial number. (I.e., if I can guess that you're calling a remote method, and what serial number you're using, I can send back a forged reply that you will think is the real reply. The constants are such that making such a guess is probably doable.) - Not clear to me that they've really thought through protocol versioning (compare to ICE versioning scheme) - Marshalling system has no pointer sharing - Leaves us dependent on external software, big projects, etc. If we have something small and simple, we can adapt it to our needs. For instance, it is not clear what ordering guarantees D-BUS provides on message delivery, yet this is absolutely critical to a system like Fresco. Far easier to just make our system handle this correctly than to try to fork D-BUS or convince the freedesktop.org people that they should change their software for us. Pluribus: The protocol used by E ( http://erights.org ), see http://www.erights.org/elib/distrib/index.html - Very good, deeply designed security and pipelining, gets things like ordering right - Based around a CORBA-ish object model with many-to-many communication; not clear if could support a spoked hub model. - Very complicated and tied up in another project; only current implementation is in Java, and specification may change. Too complicated to be reimplemented in other languages, especially while the specification is changing based around another project's needs! XML-RPC/SOAP: - Far, far too heavyweight and clunky. COM/DCOM/COM+: - Mentioned for completeness only. ASN.1: - Only a method for encoding data, not a general communications framework - Can't represent pointer sharing (I'm pretty sure) - Haven't looked at closely Mbus: http://www.mbus.org , http://www.ietf.org/rfc/rfc3259.txt - Haven't looked at in detail; seems oriented towards many-to-many communications, with a fairly inefficient protocol (sequence numbers represented as ASCII strings?)