CORBA

Common Object Request Broker Architecture the heavyweight distributed computing predecessor

CORBA is the ghost in the machine that nobody in the web API space wants to talk about, but it’s one of the most instructive ghosts there is. The Common Object Request Broker Architecture arrived in 1991 from the Object Management Group — a vendor consortium that included everyone from IBM to Sun to Digital — and it was the serious, enterprise-grade answer to the question of how software components on different machines, written in different languages, should talk to each other. It was ambitious, it was technically sophisticated, and it failed at the one thing that mattered most: being simple enough for the industry to actually use. I’ve come back to CORBA repeatedly over the years as a lens for understanding why the web API era succeeded where its predecessors didn’t, and every time I do, the lessons feel more relevant, not less.

To understand CORBA you have to understand the problem it was genuinely trying to solve. By the late 1980s, software systems were getting complex enough that the monolith was becoming unworkable for large organizations. You had components on different systems — mainframes, workstations, servers — that needed to communicate, share data, and call each other’s functions. The existing approaches were ad-hoc: custom network protocols, shared databases used as message buses, proprietary middleware from individual vendors that locked you into their stack. CORBA proposed a universal standard: define your interfaces in an Interface Definition Language (IDL), register them with an Object Request Broker, and any client anywhere could call any service anywhere, transparently, across language and platform boundaries. On paper it was exactly what enterprise computing needed. An OMG-standardized common object bus for the whole industry.

The execution is where the ghost story begins. CORBA delivered on the technical promise to a degree — it really did allow cross-language, cross-platform distributed object calls. But the IDL was verbose, the toolchains were heavyweight, the interoperability between different vendors’ ORB implementations was often more theoretical than real, and the programming model required developers to think in terms of distributed objects and stubs and skeletons and all the cognitive overhead that came with it. By the late 1990s, as I’ve documented in the API history I’ve been assembling, you had CORBA sitting alongside DCOM (Microsoft’s answer, which had its own interoperability walls), and then XML-RPC arriving in 1998 as something genuinely lighter — HTTP plus XML, no broker, no IDL, just a simple remote procedure call over the web transport that was already everywhere. SOAP followed in 2000, attempting to bring enterprise-grade structure to XML-RPC’s simplicity, and for a while it looked like SOAP might thread the needle: structured enough for enterprises, based on open standards, not tied to any single vendor.

But SOAP carried CORBA’s original sin with it: the belief that you could engineer your way to simplicity through a sufficiently comprehensive specification. WSDL, UDDI, WS-Security, WS-Addressing, WS-Transaction, WS-ReliableMessaging — the WS-* stack grew and grew, each specification solving a real problem and collectively producing something that required expensive tooling and deep expertise to implement correctly. I wrote about SOAP in 2011 noting its origin as a Microsoft project, its W3C standardization, and its fundamental complexity relative to what REST would offer. The RESTful approach that Roy Fielding had articulated in his 2000 dissertation was the quiet revolution: use HTTP as it was actually designed — verbs, URIs, status codes, content negotiation — instead of building a new protocol layer on top of HTTP and treating the transport as a dumb pipe. REST wasn’t an OMG standard. It wasn’t backed by a vendor consortium. It was a PhD student observing how the web actually worked and naming the architectural style that made it work. And it beat CORBA and SOAP not because it was more sophisticated, but because it was comprehensible.

The Amazon story is the sharpest illustration I know of the transition. Amazon launched its e-commerce APIs in 2002 supporting both REST and SOAP, because that was the landscape — enterprise customers expected SOAP, but web developers were discovering REST. Over the following years REST adoption dwarfed SOAP adoption. By 2011 Amazon killed the Alexa SOAP API specifically because of security concerns — SOAP’s complexity had created vulnerabilities that a simpler interface wouldn’t have had. The Bezos API mandate, which I’ve written about extensively, was the internal organizational version of the same transition: mandate that all teams expose their capabilities through service interfaces, using simple protocols, with no back-channel exceptions. That mandate, which shaped AWS and turned Amazon’s internal infrastructure into externally accessible services, was in direct reaction to the complexity and coupling of enterprise middleware. The mandate was partly a reaction against the CORBA/SOAP mode of thinking — where you needed a heavyweight contract, a registry, a sophisticated toolchain, just to connect two internal systems.

I wrote in 2019 about not having done that already — the recurring pattern where a new technology arrives and everyone treats it as if nothing similar has ever been tried. API discovery is a good example: UDDI was CORBA’s and SOAP’s answer to the discovery problem. You’d register your services with a UDDI registry, describe them with WSDL, and clients could discover and consume them programmatically. It was, in 2000, a reasonable answer to a real problem. When the web API era arrived and people started asking “how do we discover APIs,” it was worth remembering that UDDI had been tried, and that it had failed to achieve adoption — not because the problem wasn’t real, but because the solution was too heavy and too centralized. APIs.json and the decentralized discovery approaches I worked on were at least partly informed by that history: don’t build a central registry that requires vendors to participate, because they won’t; build something light enough that the index can emerge from the artifacts that providers already publish.

The SOA conversation is where CORBA’s legacy lived longest in the enterprise. Service Oriented Architecture was the 2000s attempt to learn from CORBA’s failures and build something more practical: services communicating through an Enterprise Service Bus, contracts defined in WSDL, orchestration through BPEL. I was writing about SOA versus APIs in 2013 and 2015, both times making the same argument: we have already done this, and the lesson isn’t that distributed services are wrong, it’s that the vendor-dominated, toolkit-heavy, specification-baroque approach to distributed services is wrong. The web API movement succeeded by stripping away everything CORBA and SOA accumulated and going back to the simplest thing that could possibly work — HTTP, JSON, URIs, simple auth — and building from there. By 2015 I was watching people trying to bring SOA-style governance and complexity into the API space and arguing that we needed to learn from that history rather than repeat it.

The enterprise’s lingering attachment to CORBA-era thinking shows up most concretely in the WSDL-to-OpenAPI translation problem. I wrote in 2018 about the experience of seeing the past reflected in the API pool when translating WSDL to OpenAPI — the way the concepts map imperfectly, what gets lost in translation, what the exercise reveals about how much of the CORBA/SOAP mental model is baked into enterprise systems that are still running. These aren’t dead systems. Many of the SOAP services and CORBA-based middleware that enterprises built in the 1990s and early 2000s are still running, still being maintained, still being wrapped with REST facades that consumers think of as “the API” while the CORBA IDL that defined the original interface sits underneath, untouched and undocumented. The CORBA layer is still there. It’s just hidden now.

What CORBA got right deserves acknowledgment alongside what it got wrong, because the industry has a bad habit of only remembering the failures. CORBA genuinely solved hard problems: the Interface Definition Language as a language-neutral contract is a real idea, and OpenAPI is, at some level of abstraction, that idea applied to HTTP APIs. The principle of separating interface from implementation — defining what a service does independently of how it does it — is foundational to every API design discipline that followed. The object request broker’s vision of transparent remote calls across heterogeneous environments is what microservices and service meshes still aspire to. And the vendor-consortium governance model that produced CORBA’s standards is what the IETF, W3C, and later the OpenAPI Initiative also use. CORBA’s failure wasn’t conceptual — it was political and practical. Too many vendors, too many competing interests, too much complexity in service of too much ambiguity about what “success” actually required.

I’ve argued in my API history work and in the broader 50-year timeline I assembled that you can’t understand the present without the past, and CORBA is the past. gRPC — Google’s modern RPC framework using Protocol Buffers over HTTP/2 — is CORBA’s direct intellectual descendant, and it has succeeded precisely where CORBA failed: it picked a single ecosystem rather than trying to be everything to everyone, it made the toolchain genuinely good, it acknowledged that the right scope for RPC is internal service-to-service communication rather than universal interoperability across all languages and all platforms. When I wrote about learning gRPC in 2017, I was noting that the RPC instinct isn’t wrong — it’s appropriate in specific contexts, and the history of distributed computing is partly the history of figuring out which context each approach fits. CORBA tried to fit every context, and that is exactly what killed it. The web APIs that succeeded did so by knowing what they were for.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

CORBA

References

Guidance Details

Explore more

Discover APIs