I’m just learning about midleware in class, and our teacher has told us about CORBA. Doing a bit of research, I’ve found that the last version (CORBA 3) was released in 2002, which seems quite old in the computers science (well, in fact I know there is also CORBA 3.3, released in 2012, but..)
So there’s my question: is CORBA outdated?
Update: to make it less subjective, let’s try asking some particular things:
- Is being CORBA used in large new projects?
- Does CORBA have known difficulties that makes it useless in that scene?
- Are there new frameworks rising to fill its place?
I think all this fits quite well with the original question (and have been already answered)
Thanks in advance
7
Yes, CORBA is rarely specified for new systems. But, there are plenty of live systems that you might want or need to connect to using their CORBA interface, as it was very popular from the early 1990s, for about twenty years, and live systems often last many decades.
@Blrfl shared a link to The rise and fall of CORBA (Michi Henning, 2006, ACM Queue magazine) which backs up my assertion.
During its lifetime, CORBA has moved from being a bleeding-edge technology for early adopters, to being a popular middleware, to being a niche technology that exists in relative obscurity. … CORBA’s history is one that the computing industry has seen many times, and it seems likely that current middleware efforts, specifically Web services, will reenact a similar history.)
6
The short: Yes, sadly(*), CORBA is outdated, as in:
- No decent
.NETimplementation - The existing C++ binding is ugly, although there does exist a new C++11 binding
- No decent implementations for other modern languages (except Python)
That being said, existing CORBA implementations like omniORB, TAO, R2CORBA are supported and used, and are IMHO much more mature than many other IPC/RPC frameworks, although these are certainly more “modern” and are probably the future.
(*) I write sadly, and it is indeed a sad affair, because (point 3 from Q), there are quite a few frameworks rising, but there’s not one that can fully replace it at the moment, and they all have problems of their own. (Immaturity, tailored for a narrow usecase set, interoperability (e.g. WCF via net.tcp), performance, footprint, licensing (ICE), …)
Additionally, addressing point 2., while I do not agree with some points in The Rise and Fall of CORBA, one point that is indeed today a pain point is the lack of good versioning, quoting:
Versioning.
Deployed commercial software requires middleware that
allows for gradual upgrades of the software in a backward-compatible
way. CORBA does not provide any such versioning mechanism (other than
versioning by derivation, which is utterly inadequate). Instead,
versioning a CORBA application generally breaks the on-the-wire
contract between client and server. This forces all parts of a
deployed application to be replaced at once, which is typically
infeasible. (…)
While it is not as horrible as the paragraph makes it sound, it is an issue for which I do not know of an elegant solution, even when sticking to a single CORBA implementation for all your parts.
1