[Fresco-devel] [ReFresco 02] Pre-existing alternatives to CORBA

Nathaniel Smith <[email protected]> Mon, 19 Jan 2004 01:22:05 -0800
Newsgroups gmane.comp.video.fresco.devel
Message-ID <[email protected]>
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?)


-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco