5

What is an example of a situation where CORBA would be used? Is it just a matter of using an interface language (e.g. Java) to 'talk' to all applications?

Gabriel Devillers
  • 3,155
  • 2
  • 30
  • 53
  • "What is an example of X?" is categorically too broad to be on-topic under Stack Overflow's current rules. A question needs to be about a narrow, specific, practical problem you currently face. – Charles Duffy May 10 '23 at 15:37
  • @GabrielDevillers, you might reconsider revitalizing old questions by adding very questionable tags. Workflows involving CORBA _use_ an IDL, but that doesn't mean it _is_ an IDL in entirety, or that the question is itself an IDL question; moreover, the question itself would be off-topic today, since our scope rules have narrowed in the 12 years since it was asked; bringing it back to the front page may well get it closed. – Charles Duffy May 10 '23 at 15:38
  • @CharlesDuffy thanks for this advice. I agree with what you say. I will be more careful in the future. I will not undo my edit to reduce the noise (but feel free to do it). – Gabriel Devillers May 10 '23 at 16:07

3 Answers3

11

CORBA might be used to build a language-independent, O/S-independent distributed system. For example, C++ on Linux developers could build a common distributed system with Java on Windows developers. IDL describes the interfaces that bind the two implementations over a common substrate (CORBA).

CORBA is also useful when building a plain old distributed object system - it has a rich set of services defined and is generally very well thought out. However, these days - depending on the language - many folks have opted for either simpler (e.g., RMI, protocol buffers) or message-based protocols (e.g., HTTP) for building distributed systems, so it's not as common. CORBA suffered from design-by-committee (esp on things like security).

More info:

http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

kvista
  • 5,039
  • 1
  • 23
  • 25
2

You will see a list of real-life example of CORBA projects from below website. http://www.cs.wustl.edu/~schmidt/TAO-users.html

TAO is one of the most popular C++ CORBA implementation available today. The project is pretty active.

David Chu
  • 21
  • 1
0

CORBA was intended to be what SOAP, REST, and others are today. Real-life examples of applications of the latter are examples of things attempted with the former.

CORBA technology vendors killed each other through incompatible and bureaucratic implementations. Today, you can safely consider CORBA to be a legacy technology; that is, use it if you have to deal with components that already expose themselves through CORBA. Otherwise, stick to modern RPC/distribution standards like SOAP, or, better yet, REST/JSON.

Joy
  • 321
  • 1
  • 9
Apalala
  • 9,017
  • 3
  • 30
  • 48
  • CORBA doesn't fit the same use case as REST/JSON. CORBA is a binary protocol and can be used where speed matters. – Brian Neal Jan 08 '11 at 19:04
  • @Brian Neal. Note that I didn't mention "efficiency" in my answer. Efficiency is a non-issue when things don't work. I was there when CORBA was being pushed as _the one solution to interoperability_, I used it, and I wrote articles about it. But you don't have to take my word for what happened with the technology. Wikipedia has it all well documented: http://en.wikipedia.org/wiki/Corba#Problems_and_criticism. – Apalala Jan 08 '11 at 20:27
  • I'll add that the "binary" thing was never part of the specification. Participants in a CORBA environment could store objects any way they chose, and protocolos were free to serialize or convert to 7-bit-ASCII the messages. They keyword was _interoperability_, not _efficiency_, and the former was never acheived. You either bought everything from a single vendor, and limited your software to their offer, or forgot about it all. – Apalala Jan 08 '11 at 20:31
  • 6
    I use CORBA every day and I am paid for it. I am well aware of the history and many problems that CORBA has. For what we use it for, we could NEVER substitute it with tech like SOAP, XML, or REST. It's apples and oranges. CORBA uses a binary protocol to serialize and deserialize parameters across the wire, as opposed to XML, JSON, etc. You could not implement an embedded real-time system with high bandwidth, low latency requirements with SOAP or JSON. – Brian Neal Jan 08 '11 at 20:55
  • The last thing I want to come across is a CORBA cheerleader, but your answer is full of FUD and common misconceptions. – Brian Neal Jan 08 '11 at 20:55
  • 7
    In addition, we are using a system that uses CORBA from several ORB vendors and there are no interoperability problems. Those were ironed out years ago. Don't believe everything you read on Wikipedia. – Brian Neal Jan 08 '11 at 20:58
  • 2
    BTW, binary was part of the standard, it's called GIOP. – Brian Neal Jan 08 '11 at 21:06
  • It is not fair to withhold that alternatives like Erlang were designed, developed, and successfully deployed because CORBA failed to deliver. That is history, not opinion. How does a CORBA broker fit in when _efficiency_ and _embedded_ are part of the requirements, I don't know, I don't understand. If CORBA vendors have overcome the many limitations and pitfalls of the past, then good! The FAQ says that discussions about individual experiences are not welcome here, so I'll leave it at that. I won't delete my post because I don't know what would happen with the comments if I did. – Apalala Jan 08 '11 at 21:45