Is CORBA legacy?

Question

For a distributed computing project starting today, with 0 legacy components, are there any good reasons to look into CORBA?

Tablecloth

To be honest, I'm not sure they ever were any good reasons - it's a horrible technology. I'm speaking as an ex CORBA programmer here. – Bascio

The good reason was that when CORBA was first around, there was no viable alternative (unless you could DCOM or DCE). – Denationalize

@Denationalize There were alternativesw - things like TIBCO for example. – Bascio

Sure, but that was just as ugly, not to mention expensive. – Denationalize

@Skaffman You are joking! TIBCO Rendezvous was/is at least 10x easier to use than CORBA. As for expense, I figure the IBs that use this stuff can afford it. Or at least they could, back then. – Bascio

@Denationalize and now Microsoft is disabling DCOM w/ the latest Windows update. – Elderly

Answer 1

There are still situations where CORBA could be a good answer:

• when you are building a distributed system involving multiple programming languages and multiple platforms,
• when your system entails sending complex data structures ... and SOAP doesn't cut it,
• when you have high rates of messaging ... and HTTP doesn't cut it, or
• when you have to interact with existing CORBA clients and/or services.

But having said that, there are alternatives that do what CORBA does, only better ... or so they claim. For example ZeroC's ICE

EDIT @fnieto chimes in to say (or imply) that ICE is not free, but TAO is.

This is inaccurate and misleading.

1. ICE is GPL'ed software, and is available for free download. You only needed to pay for ICE if you / your company are not prepared to live with the terms of the GPL. (Or if you need support.)
2. I used ICE as an example of an alternative to CORBA. TAO is CORBA. The ICE authors make a credible case as to why they can get better performance by not being CORBA compliant.
3. TAO is by no means the only free / open-source CORBA implementation. I can think of 3 others, off the top of my head.

The down-side of ICE is lack of interoperability with CORBA middleware stacks, but in my experience interoperability of different CORBA implementations could also be problematic. (Things may have improved in that area ... but I haven't done any CORBA work since ~2002, so I'm a bit out of touch.)

Liquid

Concerning point 1 - I was expecting CORBA and Web Services to be more or less equivalent from a cross-platform and cross-language perspective. Each will have weak spots they don't cover, but overall I don't see much difference. For this non-legacy scenario I don't see that this is an issue. – Garotte

@djna: but consider that today's non-legacy app is tomorrow's legacy app. Using a multi-language/multi-platform middleware technology today may help you in 5-10 years when you integrate with the next generation of enterprise apps. – Liquid

@Stephen. The only problem with ICE is the price, TAO is free. – Sparse

Well said. Indeed Java is a most conspicuous free CORBA implementation. And the fact that J2EE mandates IIOP as its transport means that CORBA is probably more pervasive and 'current' now than ever. – Undressed

Answer 2

From the existing answers, this gets into almost a religious topic. One can look at CORBA the same way as the half-empty/half-full glass: on one hand, CORBA is dated legacy cruft, and on the other hand it's relatively stable with several implementations available and the "devil you know".

In my line of work, I see CORBA deployed in embedded systems, real-time systems (CORBA has RT extensions), and the like. There aren't many alternatives AFAIK.

Another "advantage" of CORBA is the availability of several high-quality open source implementations, e.g., TAO, MICO, JacORB, etc., with differing licensing and support models. There are also still commercial editions available.

With regard to "most" CORBA apps being implemented in Java--that's not the case in my experience. While the language mapping for CORBA to Java is one of the nicest there is (which may not be saying much), Java already has a very nice distributed computing model that offers richness beyond CORBA, and all-Java apps use that more than CORBA. The vast majority of CORBA development I've seen is in C++ (which is also the worst language mapping).

Finally, CORBA offers standardized asynchronous client-side invocations in the form of AMI, but never offered asynchronous handling on the server side. TAO offers a non-standard server-side implementation called AMH.

Adventurism

Answer 3

I believe that Corba was sort of revived by original EJB spec, as EJB's can be easily turned into CORBA beans by a bit of configuration. I suspect that most Corba deployments were actually implemented in Java.

As to the popularity, I think that there might be some high end deployments remaining for a number of decades but for the majority of people Corba is dead.

There are a whole lot of very sexy ways to do the same stuff (excepting the high end mentioned above).

• Cloud computing (web services, scalable computing, loose coupling, queueing).
• REST services (web-services lite).
• SOAP services (web-services heavy).
• Grid / Cluster computing (queueing, map-reduce and similar)

But of course your Milage May Vary.

Hydrochloride

Answer 4

Obviously it depends on the type of server and interprocess communication you are considering. And I think Stephen C and Chris Cleeland cover the Corba's positives very well.

Our application has used CORBA (Orbix) for over 10 years so is legacy now. And for how it is written CORBA is a good technology. However if I was starting over I would probably not use CORBA:

• It is complicated and only a small number of people in my organisation know it very well as a result all hard problems fall on them to solve.
• Recruiting staff can be a problem. CORBA just isn't cool any more and isn't getting cooler Although in Ireland C++ developers are a little thin on the ground too.
• Most Consulting firms want to use web services for integration work, so if you want 3rd parties to do the integration you will probably require a web services api anyway.

Now depending on the type of communication I wanted I would probably consider:

• protocol buffers for lots of small messages (I know that I would have to provide the transport)
• web services for fewer large messages

This is based more on finding staff and expertise, 3rd party support and leveraging open source libraries then the technical quality of CORBA, which I use everyday and is strong if a little cumbersome.

Towns

@iain: good points. CORBA is not straightforward to use even from Java, where I did most of my CORBA development. The POA / BOA stuff is hard to get your head around. – Liquid

Yes the POA stuff in particular is harder than it should be – Towns

With the standardization of the IDL to C++11 language mapping learning and using CORBA is way easier. The language mapping is straight forward and reuses as much as it can from STL. You still need to learn the POA but that is really not hard. – Combinative

Answer 5

CORBA is certainly old fashioned, but it also provides certain high-level functions out of the box (see here). This functionality could all be done using modern web services, but probably not in a standard fashion, and not without a great deal of extra work.

For 99% of distributed services, though, CORBA is undesirable. It's ugly, complex and hard to use.

Denationalize

And given that last point, that's why people came up with soap/ws-*. Which is now also ugly and complex. – Dastard

Soap is not so ugly when you are working with frameworks that do most of the behind-the-scenes work for you. – Moynihan

What alternatives do you suggest? – Radioman

@Moynihan - That's a bit like saying that SOAP is not so ugly if you can't see it :-) – Liquid

CORBA services are pretty neat. Too bad it weren't implemented. – Security

Answer 6

One thing that no one has mentioned here is OPEN, OPEN STANDARDS. Of all the technologies that exist (excepting SOAP) it is the only true open white paper standard. The standard is not reliant on any one organisations technologies. RMI (Sun/Oracle), DCOM (now defuncted - Microsoft). It is completely Vendor and Language neutral. Excepting SOAP, none of the other DOS (Distributed Object Technology) technologies are

I'm a software architect and regularly having to make the choice as which DOS should be used in a system design. If it weren't for the religious war I face each time, it would either be a MOM or CORBA.

Look at it this way, if it were that dead, none of the 3/4G networks would work. 3GPP is totally CORBA specified. The European Satellite System is all CORBA specified. Ask yourselves why? It's because they must be based on Vendor and Language neutral architectures!

Aristocrat

Ermm ... in the past, I was involved in developing OMG standards, and I can tell you that the processes were not always as open and transparent as one could hope for. And the OMG has historically stayed away from the issue of compliance ... not that IETF or W3C do much better on that. – Liquid

1+ @Aristocrat I was looking for this info – Oyez

@Selvyn, Michi Henning puts forward a pretty convincing argument to the contrary, that OMG's openness is a systemic cause of it's problems - queue.acm.org/detail.cfm?id=1142044. Good read. – Dalrymple

Answer 7

I'd say that the current level of maturity of Web Services (including REST) and in the Java world EJBs (which may even use CORBA under the covers) cover what is needed for distributed enterprise systems.

I'd advise that one aspect that you should look at carefully is the degree of asynchronous interaction that you need in your distributed system. I postulate that any distributed system of a non-trivial scale needs asynchronous communications, and the infrastructure chosen should support asynch processing, typically that means queues.

That's not inconsistent with the use of WebServices (or indeed CORBA) but it does point up an aspect of your product selection that can get overlooked in the initial excitment of getting some distributed processing going

Garotte

Answer 8

No. Do not use corba. (Answer from the future - 2021)

If someone happens to read this very old question, he might think that corba is alive. Legacy applications that where built around year 2000 - 2005 sometimes still have corba.

Companies spend a lot of money to get rid of corba for several reasons.

• Its old
• Its very difficult to find developers who know corba, or are willing to work with this old technology
• Lack of good documentation, and it is not discussed in forums like stackoverflow
• Hard to migrate it to the cloud (Azure, AWS) mainly because

• The IOR contains internal IP, so you may need to configure it to use FQDN, or add iptables, or some routing/proxy solution.
• Sometimes the app starts on a different port each time, so you will need to limit the port

• If you want to use corba in EJB,... note that EJB is also very old and not a good choice

REST api is a much better solution for now-days. It is very common, works over http, https which is simpler to migrate to the cloud, practically every BE developer knows it. You can use REST from any language, there are frameworks that make it easy to use.

See also this stack-overflow discussion

Tamer