The Rise and Fall of CORBA (2006)

http://queue.acm.org/detail.cfm?id=1142044

by ptx • 11 years ago

67 56 11 years ago

queue.acm.org

ssaddi• 11 years ago

Nice article. I remember reading about CORBA in uni days. The article summarized it well as it became a bulky technology with very length and confusing documentation. Industry on the other hand, was ready to adopt simpler technology that focused on web-based protocols, like HTTP (HTTPS). Then SOA came and it changed the landscape completely with REST-based services, that relied on HTTP protocol themselves. Finally, it comes down to simplicity. A technology that is too complex to implement and understand will not easily meet demands of constant change and innovation. Hence, as mentioned, it is reduced to a niche technology.

xorcist• 11 years ago

You skip an important part where "web based protocols" means web services, which in turn was synonymous with SOAP. This architecture was based on remote method invocations and was dominant for the better part of a decade (if it isn't still, for some domains).

2sk21• 11 years ago

"the simplicity of component models, such as EJB" Sure the author must have been joking :-)

That aside, good points in this article. CORBA is emblematic of a time when elaborate architectures were created without any thought of actual implementation. At IBM in the early 1990s, we had an entire group of 40 people working on the architecture for a broadband network infrastructure who had never written a line of code.

AnimalMuppet• 11 years ago

"the simplicity of component models, such as EJB" Sure the author must have been joking :-)

Perhaps not entirely. If that's the kind of problem you have, there may not be any possible solution that is much simpler than EJB.

There's a reason all these architectures wind up being horrible. The problem is horrible, and there's no simple, clean solution for it.

kaonashi• 11 years ago

I bet their UML diagrams were magnificent, though.

lukeh• 11 years ago

Interesting article. CORBA is still hanging around in Avid's EuCon protocol for controlling audio applications. Not always that reliable (but hard to say where the blame lies there).

gmfawcett• 11 years ago

CORBA also persists in the Ada community (e.g. see http://www.adacore.com/polyorb/).

benaston• 11 years ago

Those working on other standards should take heed.

ak39• 11 years ago

CORBA's "failure" was the distributed part, and distribution is an essential element of the architecture. Unlike COM, where you could easily separate the OO (IDL) based aspect of the architecture from its distributed implemention (DCOM), CORBA was always assumed to be distributed.

The idea of implementation language agnostic binary IDL is still powerful though.

_pmf_• 11 years ago

The idea of implementation language agnostic binary IDL is still powerful though.

IDL is a downright nice specification language when compared to alternatives with a similar power (I'm looking at you, ASN.1!).

dcuthbertson• 11 years ago

ASN.1 wasn't so bad. In the 90's, I worked for a little company, Gradient Technologies, where we modified Kerberos to add authentication via Security Dynamics' key fobs. I hadn't seen ASN.1 before, but found it wasn't much effort.

sgt1012• 11 years ago

well, web services were a complete bust too!

It's interesting (as other commenters have noted) that now people implement rest interfaces and we don't seem to have any (other) standards for imposed (controlled) shared state.

Agent standards like FIPA were supposed to enable consensual shared state by agreement, but have never really been used to do that.

I guess the world really doesn't need these things yet?

tracker13• 11 years ago

In the end, simple, documented, defined (even if the documented/defined are simply the source you have access to) is easier to deal with than overly complicated systems that add little value, and a lot of cognitive overhead, confusion and indirection. This is why today's JSON services rule the roost so to speak.

Not that there aren't attempts to create some standards... It's just that a lot of the time they don't add much value.

rwmj3• 11 years ago

CORBA (and SOAP) had type safety, something which is missing from "modern" systems.

JSON is an ill-defined standard - integers, for example, are almost completely undefined, and this causes real problems in real programs (eg [1]).

[1] https://lists.gnu.org/archive/html/qemu-devel/2011-05/thread...

sepeth• 11 years ago

How CORBA compares to Apache Thrift, or Google's protobuf? or do they try to solve different things?

dekhn3• 11 years ago

I consider CORBA's IDL/IIOP combo to be roughly identical to protobuf. CORBA's distributed RPC capability is like gRPC. At a higher level there are some differences but they are substantially isomorphic.

lobster_johnson2• 11 years ago

CORBA was terrible at versioning. If you tried to use a client with a mismatching server (e.g., the server's IDL added a field that the client didn't have), you would typically get segfaults.

Protobuf, on the other hand, builds in versioning right from the start. Every struct field is tagged with an ID, so unknown fields can simply be ignored, and marshalling/unmarshalling can be adaptive. It means that structs can be preserved across version boundaries; in theory, a "v1" client can read a "v2" struct, modify it, and pass it back with the "v2" fields intact, even though the client didn't know about them. (This requires that the client doesn't unmarshal the data into something that would lose the metadata, like a C struct.)

Another big difference is that CORBA had IORs (Interoperable Object References), a kind of smart pointer to a remote object. With CORBA, as with DCOM, you could pass object references around and make method calls on them, and the calls would be transparently routed to the correct server. You could have client A get an object from B which got the object from C, and if A did a .foo() call on the object, it would call C. Of course, this leads to all sorts of issues, such as having to make sure objects stay alive for as long as any client (or server, since it goes both ways!) has a reference to it, and dealing with unresponsive clients/servers.

gRPC is much simpler in this respect, in that it's just RPC calls, pure data, no objects. In that sense, gRPC is closer to DCE RPC (the basis for Microsoft RPC, which was the underlying RPC technology of DCOM) [1].

[1] https://en.wikipedia.org/wiki/DCE/RPC

thorn• 11 years ago

I still maintain the piece of backend which I wrote 8-10 years ago using Python and omniORB. Performance of CORBA was critical back then. But I have started to use CORBA for parts where performance and network overhead was not that critical, which corrupted my code beyond any limits. I was not very experienced back then. I still struggle and feel pain when I see that old code. Also omniORB has some weird memory leaks related bug, which I could not figure out in many years. Sigh...

Partially I have migrated most of component from CORBA to beanstalkd (MQ server). This is much more simple approach, testing is easier, code flow is simple. I cannot recommend enough this simple and robust MQ server: beanstalkd.

For the part when one component wants to call another component in Python and there is no way I could plug a queue into the flow, I prefer to use Pyro. Dirty and simple.

late2part• 11 years ago

Of particular note, Joel Spolsky's missive on Architecture Astronauts: http://www.joelonsoftware.com/articles/fog0000000018.html

Ygor• 11 years ago

Particularly interesting should be the part about design by committee.

Remove Corba references, and it might apply to many other past and current pieces of technology:

"There are no entry qualifications to participate in the standardization process. Some contributors are experts in the field, but, to be blunt, a large number of members barely understand the technology they are voting on. This repeatedly has led to the adoption of specifications with serious technical flaws."

“Vendors respond to RFPs even when they have known technical flaws. This may seem surprising. After all, why would a vendor propose a standard for something that is known to suffer technical problems? The reason is that vendors compete with each other for customers and are continuously jostling for position. The promise to respond to an RFP, even when it is clear that it contains serious problems, is sometimes used to gain favor (and, hopefully, contracts) with users.”

smhenderson• 11 years ago

I find this one to be very familiar as well. I'm sure we could come up with our own examples and combined have dozens or more.

"Vendors sometimes attempt to block standardization of anything that would require a change to their existing products. This causes features that should be standardized to remain proprietary or to be too vaguely specified to be useful. Some vendors also neglect to distinguish standard features from proprietary ones, so customers stray into implementation-specific territory without warning."

hyperpallium12• 11 years ago

Since then, XML webservices have Risen and Fallen; JSON seems to have just peaked, with the complex, XS-like JSON schema seeming to finally gain traction.

The cynical common wisdom was that people happily adopt a new simpler technology, until they finally understand the problem... and to address it, the new technology must become just as complex as the old one.

The article's main point, about non-competitive standards-setting is a good one, but can only work for non-competitive technology. This is happening to some extent, as infrastructure is commoditized as a complement.

andersriutta• 11 years ago

"JSON schema seeming to finally gain traction"

Could you describe this further? Are you referring to http://json-schema.org/ or to more general efforts to bring typing to APIs, like GraphQL?

hyperpallium12• 11 years ago

Sorry for late reply. I meant the former, json-schema. It's the one that seems to get used.

Other approaches might be better, esp for specific uses, but most people just want some typing, and json schema is closest to it. I hadn't heard of "GraphQL".

ptx• 11 years ago

JSON with a schema is still simpler than CORBA and DCOM, isn't it?

The former is simply an RPC mechanism whereas e.g. DCOM builds on top of MSRPC to provide distributed objects, which involves remotely creating instances of objects, which requires distributed reference counting, which adds all sorts of complicated timeouts and keep-alives to deal with network problems.

lmm• 11 years ago

JSON with a schema seems broadly equivalent to SOAP.

I can believe that early implementations were buggy, but working with WS-* these days is actually very nice - nicer than JSON webservices, IMO.

mands6• 11 years ago

I agree that getting just the right amount of simplicity is actually a hard challenge. JSON over HTTP feels like it has won as it was so trivial to implement in any language, however experience has taught me that the lack of a schema causes problems over time.

At StackHut (www.stackhut.com) we're using JSON with a lightweight schema. So far this is working very well, providing simple yet 'typed' remote interfaces into containers. However I often wonder about switching to XML/XML-schema/XML-RPC, protocol buffers/gRPC or some custom system in the future or to just keep it simple and not over-complicate things.

hyperpallium12• 11 years ago

I think what happened is that people building a complex system, who knew they needed schema etc would just use the XML/ws-* ecosystem, because as repugnant as some might feel it is, it is all written, debugged and works. If people didn't need complexity, they used JSON.

The XML option kept complexity out of JSON.

However, its inevitable people starting with simple systems (using JSON) would become complex - perhaps partly due to dramtic success. And converting everything to XML would be time-consuming and error-prone and... repugnant. So. This is where the demand for json-schema comes from. And it does seem inevitable: the inertia of back-compatibility is one of the more predictable features of software.

I can make the hopeful observation that things aren't quite as bad as the cynic take above: people do learn from some of the mistakes of previous technologies. There is some progress.

I dislike JSON-schema because it's like a JSON version of XML schema. I think a simpler scheam would better serve JSON and its typical uses.

Is your "lightweight schema" a simple schema written in json-schema? Or written in a lightweight schema language?

todd8• 11 years ago

As chief scientist at a start up company in the 90's I had to occasionally attend standardization meetings to protect our products. This included some of the very early CORBA meetings. Without participating, we risked being non-compiant with evolving standards in our space and so I had to attend and keep up with the directions things were going.

Companies like DEC, HP, and IBM might send five or six people to the important meetings and consequently it was easier for them to influence the direction of standards in a way that favored the architectures of their products. While I met a few, very bright, systems architects actually interested in coming up with a design that would provide the benefits of industry-wide standards, many of the participants couldn't grasp good design or simply acted in a partisan way for the sole good of their own company. What struck me was that there were mostly "goers" not "doers" attending these meetings. The organizations real developers and architects were busy working on real products, too busy to attend the excruciating standards meetings. The goers on the other hand might be from the "planning" organizations in these large companies. These planners often had very little background as developers and little insight into realistic requirements.

At the CORBA meetings, powerful members couldn't agree on the lowest levels of the protocol. Would it run over UDP? or TCP? what about IP vs Token Ring vs OSI networking architectures. At a slightly higher level some companies had their own, completely incompatible, RPC, data marshaling, and security efforts well under way and they simply wouldn't sign off on any standardization below the Application or Presentation layers of the protocol. This was crazy; CORBA was burdened with an architecture requiring standardization at the application layer between products that couldn't actually communicate with each other.

Hopelessly deadlocked at the most fundamental communication levels, the key people involved in CORBA needed progress to keep CORBA alive, so CORBA moved forward on standardization of things like nested distributed transactions--trying to run before they could walk.

dekhn3• 11 years ago

I thought the CORBA IDL and the IIOP were both great. It made the transition to protocol buffers and Google's RPC system pretty painless.

j03m1• 11 years ago

I thought this was the rise and fall of COBRA (gi joe) and when I realized it wasn't I was sad.

billyhoffman• 11 years ago

This sentence shows a trap most technical people keep following into:

"These arguments cannot fully account for CORBA’s loss of popularity, however. After all, if the technology had been as compelling as was originally envisaged, it is unlikely that customers would have dropped it in favor of alternatives."

Wrong. Those arguments more than explain the failure.

CORBA, like most technology, doesn't succeed or fail because of how "compelling" or repulsive it was. People use terrible technology all the time. Major applications are written in terrible technology. Business make huge amounts of money off terrible technology. Great technology is skipped all the time.

As engineers we care about this kind of thing. The problem is that, the vast majority of people in a business don't give a shit what technology stack you use.

Technology does not exist in a bubble, where it lives or dies in some kind of hippy meritocracy. Technology exists in the real world where other factors tend to dominate far more than we think they should. This is also why when engineers start companies, they quickly learn that 90% of running a business has nothing to do with technology or development.

rwmj3• 11 years ago

I agree with your points, but I think the paper was probably referring to actual problems in CORBA which were very obvious to everyone - technical and non-technical - and caused a lot of pushback.

For example, the original C++ bindings were a train wreck: All C++ types including strings got a second CORBA::.. definition, so you couldn't interoperate with other C++ code easily. You had to write pages of boilerplate to do even the simplest thing. There were lots of traps which could cause your program to crash or leak memory, causing troublesome bugs in production systems. This affected schedules (and hence marketing) and field support.

Another example was we couldn't get different supplier's ORBs to talk to each other - which is, like, the whole point of a standard communication broker (right?)

markbnj• 11 years ago

Nice walk down memory lane. We used Orbix in 1995 to build a production banking platform, one of the first true web-enabled banking services, and it was a nightmare. It wasn't necessarily the complexity. Our engineers could understand proxies, stubs, and bindings well enough, and when it all worked it worked well. But memory leaks on NT and mysterious performance issues sucked all the life out of the project. Over the next few years I watched CORBA wither away in the face of growing adoption of simpler web-oriented protocols, and it never made me even a little sad to see :).

wainstead• 11 years ago

In the early 2000s I worked within a CORBA system. Daemons written in C++, servers in Java, and the system was scripted via Python.

That you could instantiate an object from the C++ or Java sides in Python and do things with those services was actually quite fun. I was insulated from the difficulties of the CORBA implementation because the system came from a vendor, but bugs and performance issues were perpetual. And this system ran within the same local network behind the firewall.

One of the truly sucky things about this system was it had its own version of Python server pages: Python and HTML intermixed within the same file, and whoa be to you if you got your Python indentation messed up between blocks of HTML. It was ridiculously hard to debug.

And as the article points out, upgrading was a stop-the-world process where everything had to go offline, usually for hours. One of the other crippling "features" of this system were C++ objects persisted in the database as binary... man those caused headaches. And half the data was in DB2 and half in an LDAP server. This vendor never met a technology they didn't want to through into the mix.

The Rise and Fall of CORBA (2006)

Related Stories