I knew CORBA was bad, now I know how much.

ACM has an interesting article about CORBA which I'm forced at times to use at work. I have always hated CORBA, but know I have a list of reasons why:
  • CORBA's object adapter requires more than 200 lines of interface definitions, even though the same functionality can be provided in about 30 lines?the other 170 lines contribute nothing to functionality, but severely complicate program interactions with the CORBA runtime.
  • ...some of the OMG's early object services specifications, such as the life cycle, query, concurrency control, relationship, and collection services, were not only complex, but also performed no useful function whatsoever.
  • CORBA provides quite rich functionality, but fails to provide two core features: Security & Versioning.
  • Design flaws in CORBA's interoperability protocol make it pretty much impossible to build a high-performance event distribution service.
  • The on-the-wire encoding of CORBA contains a large amount of redundancy, but the protocol does not support compression. This leads to poor performance over wide-area networks.
  • The specification ignores threading almost completely, so threaded applications are inherently nonportable (yet threading is essential for commercial applications).
  • Opaque references pretty much force the use of a naming service because clients cannot create object references without the help of an external service.
I've always hated the fact that I have to compile an IDL and usually had to buy CORBA libraries.
What replaces it? My guess (hope?) would be REST and not SOAP.

Comments

Popular posts from this blog

Shortest Sudoku solver in Python

Key-Train Launched