CORBA: The 1000-Page Dream
In 1991, the Object Management Group (OMG) published the first CORBA specification. The vision was extraordinary: write a Java object and a C++ object on different machines on different operating systems with different vendors, and have them talk to each other transparently through an Object Request Broker. Any object. Any language. Any platform. Universal interoperability.
The spec grew to over 1,000 pages. Each vendor implemented a different subset. "Universal" objects could not actually talk to each other across vendor ORBs. Setting up a deployment required IDL compilation, ORB configuration, naming service registration, and enough expertise to fill a book. CORBA shipped with most enterprise middleware until the late 1990s and was used heavily in financial systems, telecommunications, and defense.
What CORBA Got Right
Before dismissing CORBA, it is worth noting what it solved. CORBA invented the Interface Definition Language (IDL) as a way to specify an API contract independent of any programming language. This idea is still alive in Protocol Buffers, Thrift, and OpenAPI. CORBA also invented the concept of an ORB interceptor - middleware that sits between caller and callee to add logging, security, or tracing. This is just a middleware chain, and every web framework has one.
Microsoft DCOM: Windows for Everything
While CORBA tried to be universal, Microsoft built DCOM (Distributed Component Object Model) as an extension of COM to work across Windows networks. DCOM was technically impressive within a Windows-only environment. Banks ran it. Trading systems ran it. The Windows developer experience was smooth. The moment you needed a Java client to talk to a Windows server, you needed custom bridge code.
Java RMI: Write Once, Call Anywhere (Java Only)
Sun Microsystems answered with Java RMI (Remote Method Invocation) in 1997. If both sides were Java, it worked elegantly. Extend Remote, throw RemoteException, register with an RMI registry, and call methods on remote objects as if they were local. The Java ecosystem adopted it widely for application servers. But it was Java to Java only. Any cross-language call required a CORBA bridge or a custom protocol.
Platform lock-in created exactly the problem that APIs were supposed to solve. The answer had been hiding in plain sight since 1991: HTTP, a protocol that every platform already supported.
Why REST Won
Roy Fielding did not invent REST in a vacuum. His 2000 dissertation was a direct response to watching CORBA, DCOM, and RMI fail. His constraints - statelessness, uniform interface, client-server separation - were specifically chosen to avoid the complexity traps that killed those technologies. Every REST constraint exists because one of the 1990s distributed object systems violated it and paid the price.
When you design a REST API using plain HTTP and JSON instead of IDL-compiled stubs and object brokers, you are making the same bet that Fielding made: simplicity and reach matter more than raw capability for external interfaces.
The Hidden Costs of Transparent Distribution
CORBA's worst design decision was not its 1,000-page specification. It was transparent distribution: the goal of making a remote call look exactly like a local call. This was not a CORBA-specific error. It was the foundational error of the entire distributed object model. Peter Deutsch articulated why in his 1994 paper on the Fallacies of Distributed Computing. Local calls cannot fail partway through. Remote calls can. Local calls have microsecond latency. Remote calls have millisecond latency with unlimited variance. Local calls never lose data in transit. Remote calls can.
When you hide these differences behind a transparent API, you guarantee that your application will behave incorrectly when the network does what networks do. Your retry logic will double-process requests because you do not know if the first attempt succeeded. Your timeouts will be wrong because you cannot distinguish a slow response from a dead server. Your error handling will be incomplete because the failure modes of local code and remote code are fundamentally different. REST's explicit HTTP semantics - status codes, idempotency keys, explicit timeout headers - are the correct response to this lesson.
The IDL Lesson in Modern API Design
The one truly good idea in CORBA was IDL (Interface Definition Language): specify the contract in a language-neutral format, then generate code for each target language from that specification. This idea is now universal. Protocol Buffers uses .proto files as IDL and generates code in 10+ languages. OpenAPI/Swagger uses YAML/JSON as IDL and generates server stubs and client SDKs. GraphQL's type system is an IDL that tooling generates typed clients from. Thrift, Cap'n Proto, and FlatBuffers all use this pattern.
The lesson CORBA did not internalize but its successors did: IDL is valuable for contract enforcement and tooling, not for hiding the network. gRPC uses .proto files to generate typed code but does not pretend remote calls are local. It exposes deadline propagation, status codes, and retry policies as first-class API concepts. The IDL handles the boring parts (serialization, type checking) while leaving the distributed systems parts (timeouts, retries, failures) explicit in application code.
- Never make remote calls look like local calls. Distributed failures are not exceptions to handle - they are the normal operating condition.
- Use IDL for contract enforcement and code generation, not for abstraction of the network.
- Platform-neutral protocols win over platform-optimized protocols for external interfaces, even when the native protocol is faster.
- Specification completeness and practical usability are in tension. CORBA maximized completeness. REST maximized usability. Usability won.
What Happened to the Enterprises That Standardized on CORBA
The enterprises that built on CORBA in the 1990s faced a painful decade of migration in the 2000s. CORBA applications could not be incrementally replaced because the object model was deeply integrated with the application structure. You could not replace the CORBA broker with REST calls while keeping the rest of the application intact - the entire object graph depended on the ORB. This is the cost of deep platform coupling: migration is not incremental, it is a rewrite.
Telecom companies that standardized on CORBA through 3GPP specifications are still running CORBA infrastructure in their core networks. Financial institutions that built trading systems on DCOM in the early 2000s are running custom bridges to REST APIs built in the last decade. These are not failures - they are working systems. But they illustrate that technology choices made for sound business reasons in one era become architectural constraints for the next generation of engineers. The systems you build today will be the legacy that your successors inherit. Design them with migration paths in mind.
The Hidden Costs of Transparent Distribution
CORBA's worst design decision was not its 1,000-page specification. It was transparent distribution: the goal of making a remote call look exactly like a local call. This was not a CORBA-specific error. It was the foundational error of the entire distributed object model. Peter Deutsch articulated why in his 1994 paper on the Fallacies of Distributed Computing. Local calls cannot fail partway through. Remote calls can. Local calls have microsecond latency. Remote calls have millisecond latency with unlimited variance. Local calls never lose data in transit. Remote calls can.
When you hide these differences behind a transparent API, you guarantee that your application will behave incorrectly when the network does what networks do. Your retry logic will double-process requests because you do not know if the first attempt succeeded. Your timeouts will be wrong because you cannot distinguish a slow response from a dead server. Your error handling will be incomplete because the failure modes of local code and remote code are fundamentally different. REST's explicit HTTP semantics - status codes, idempotency keys, explicit timeout headers - are the correct response to this lesson.
The IDL Lesson in Modern API Design
The one truly good idea in CORBA was IDL (Interface Definition Language): specify the contract in a language-neutral format, then generate code for each target language from that specification. This idea is now universal. Protocol Buffers uses .proto files as IDL and generates code in 10+ languages. OpenAPI/Swagger uses YAML/JSON as IDL and generates server stubs and client SDKs. GraphQL's type system is an IDL that tooling generates typed clients from. Thrift, Cap'n Proto, and FlatBuffers all use this pattern.
The lesson CORBA did not internalize but its successors did: IDL is valuable for contract enforcement and tooling, not for hiding the network. gRPC uses .proto files to generate typed code but does not pretend remote calls are local. It exposes deadline propagation, status codes, and retry policies as first-class API concepts. The IDL handles the boring parts (serialization, type checking) while leaving the distributed systems parts (timeouts, retries, failures) explicit in application code.
- Never make remote calls look like local calls. Distributed failures are not exceptions to handle - they are the normal operating condition.
- Use IDL for contract enforcement and code generation, not for abstraction of the network.
- Platform-neutral protocols win over platform-optimized protocols for external interfaces, even when the native protocol is faster.
- Specification completeness and practical usability are in tension. CORBA maximized completeness. REST maximized usability. Usability won.
What Happened to the Enterprises That Standardized on CORBA
The enterprises that built on CORBA in the 1990s faced a painful decade of migration in the 2000s. CORBA applications could not be incrementally replaced because the object model was deeply integrated with the application structure. You could not replace the CORBA broker with REST calls while keeping the rest of the application intact - the entire object graph depended on the ORB. This is the cost of deep platform coupling: migration is not incremental, it is a rewrite.
Telecom companies that standardized on CORBA through 3GPP specifications are still running CORBA infrastructure in their core networks. Financial institutions that built trading systems on DCOM in the early 2000s are running custom bridges to REST APIs built in the last decade. These are not failures - they are working systems. But they illustrate that technology choices made for sound business reasons in one era become architectural constraints for the next generation of engineers. The systems you build today will be the legacy that your successors inherit. Design them with migration paths in mind.
