CORBA emerged in 1991 with another crucial insight: in heterogeneous environments, you can’t just “implement the protocol” in each language and hope for the best. The OMG IDL generated consistent bindings across C++, Java, Python, and more, ensuring that a C++ exception thrown by a server was properly caught and handled by a Java client. The generated bindings guaranteed that all languages saw identical interfaces, preventing subtle serialization differences.
back
5 comments
CORBA got a lot of things right. But it was unfortunately a child of the late 80-s telecom networks mixed with OOP-hype.
So it baked in core assumptions that the network is transparent, reliable, and symmetric. So you could create an object on one machine, pass a reference to it to another machine, and everything is supposed to just work.
Which is not what happens in the real world, with timeouts, retries, congested networks, and crashing computers.
Oh, and CORBA C++ bindings had been designed before the STL was standardized. So they are a crawling horror, other languages were better.
Yeah, the modern JSON centered API landscape came about as a response to failures of CORBA and SOAP. It didn’t forget the lessons of CORBA, it rejected them.
And then rediscovered why we need schemas in CORBA and SOAP, or orchestration engines.
It didn't, though. JSON schema is basically dead in the water.
Doesn't MCP use json schema? And zod? And a myriad of other things? Hardly seems dead.
Just because they discovered it doesn’t mean they fixed it.
Yet I keep seeing it across several repos.
And now we're getting a swing back to sanity. OpenAPI is an attempt to formally describe the Wild West of JSON-based HTTP interfaces.
And its complexity and size now are rivaling the specs of the good old XML-infused times.
I've worked somewhere where CORBA was used very heavily and to great effect - though I suspect the reason for our successful usage was that one of the senior software engineers worked on CORBA directly.
I applied for a job at AT&T using CORBA around 1998 and I think that’s the last time I encountered it other than making JDK downloads slower.
Didn’t get that job, one of the interviewers asked me to write concurrent code, didn’t like my answer, but his had a race condition in it and I was unsuccessful in convincing him he was wrong. He was relying on preemption not occurring on a certain instruction (or multiprocessing not happening). During my tenure at the job I did take the real flaws in the Java Memory Model would come out and his answer became very wrong and mine only slightly.
To be charitable, you can look at a commercially unsuccessful project and appreciate its technical brilliance.
Just an interesting bit of trivia, the Large Hadron Collider uses/used (don't know if it still does) CORBA in its distributed control system. (On the control system I worked on we use Sun RPC, which was fine as things go but doesn't have the language support that CORBA has. We used a separate SOAP interface to the system to allow for languages such as Python. Today I'd use gRPC, or the BEAM.)
On a more general note, I see in many critical comments here what I perceive to be a category error. Using JSON to pass data between web client and server, even in more complex web apps, is not the same thing as supporting two-way communications between autonomous software entities that are tasked to do something, perhaps something critical. There could be millions of these exchanges in some arbitrarily short time period, thus any possibility of errors is multiplied accordingly, and the effect any error could cascade if it does not fail early. I really don't believe this is a case where "worse is better." To use an analogy, yes everyday English is a versatile language that works great for most use cases; but when you really need to nail things down, with no tolerance for ambiguity, you get legalese or some other jargon. Or CORBA, or gRPC, etc.
> but when you really need to nail things down, with no tolerance for ambiguity, you get legalese
If only that were true. Litigation happens every single day over the meanings of contracts and laws that were drafted by well-trained and experienced attorneys.
The law is a much more ambitious attempt at formalization than any programming language, hence the more dramatic failures.
Comparatively, programming languages are very constrained. The environments in which they are interpreted and executed are far better understood than any human courtroom.
Your point is an interesting one but it’s painting with too broad a brush.
It is true. It minimizes the problem, but certainly doesn't eliminate it.
“No tolerance for ambiguity” means something. Most absolute statements are incorrect and
I regularly caution my mentees against making them.
Perhaps you meant “less tolerance”?