CORBA2 - reinventing the wheel?
Posted Aug 2, 2004 14:04 UTC (Mon) by
alextingle (subscriber, #20593)
Parent article:
Connect KDE apps using D-BUS (IBM developerWorks)
Sounds like somebody's reinventing the wheel. Why not just use CORBA?
> "The protocol is low-latency and low-overhead, designed to be small
> and efficient to minimize round-trips. In addition, the protocol is
> binary, not textual, which removes the costly serialization process.
> The use cases are biased towards processing on the local machine,
> so all messages are sent in the native byte ordering. The byte ordering
> is stated in each message, so if a [...] message does travel over a
> network to a remote host, it can still be parsed correctly."
Every word of this description applies to CORBA and its native protocol, GIOP.
What is the point of a completely new protocol, when there is a well-established one ready to
use? I really think this question needs answering, can anyone give me a link?
Here are some possible answers:
1. CORBA is 'heavyweight'.
Really? The underlying protocol is pretty lean. There is certainly a great deal of functionality
layered on top of that, but if you want a light solution, why not just implement the subset you
need?
2. The C++ mappings suck.
So make a new mapping, if you don't like it. Why throw the baby out with the bathwater?
3. It's insecure.
There is a whole secure infrastructure in CORBA, just waiting to be used. Why not build on that
rather than inventing something new?
Don't get me wrong, I'm not a huge fan of CORBA, but it does get some things right. There needs
to be real, serious justification for abandoning it all in favour of something completely new.
Where is that justification? What is the guarantee that the same mistakes will just be made all
over again?
These are worth reading:
http://mail.gnome.org/archives/orbit-list/2003-March/ms[...]
http://www.fresco.org/docs/refresco/
(
Log in to post comments)
