11 ms·

The Rise and Fall of CORBA (2006)

67 points by ptx 11y ago

ssaddi 11y 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 11y 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 11y 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 11y 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 11y ago
  I bet their UML diagrams were magnificent, though.
lukeh 11y 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 11y ago
  CORBA also persists in the Ada community (e.g. see http://www.adacore.com/polyorb/ http://www.adacore.com/polyorb/).
benaston 11y ago
Those working on other standards should take heed.
ak39 11y 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_ 11y 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 11y 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.
sgt101 11y 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?
- tracker1 11y 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.
  - rwmj 11y 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/threads.html#02162 https://lists.gnu.org/archive/html/qemu-devel/2011-05/thread...
    - tracker1 11y ago
      Integers don't exist in JS/JSON... You get IEEE754 double precision floating point numbers, meaning whole numbers between -(2^53 - 1) through (2^53-1) are supported without rounding issues. If you need greater precision or fixed decimals, use a base10 string and an appropriate library in your application. I'd say the lack of strict date/locations in the spec are probably as big of an issue, but there are standards for how to handle that that have evolved as well... (geojson and ISO-8601 date-time strings).
      - 11y ago
sepeth 11y ago
How CORBA compares to Apache Thrift, or Google's protobuf? or do they try to solve different things?
- dekhn 11y 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_johnson 11y 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 https://en.wikipedia.org/wiki/DCE/RPC
    - dekhn 11y ago
thorn 11y 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 11y ago
Of particular note, Joel Spolsky's missive on Architecture Astronauts: http://www.joelonsoftware.com/articles/fog0000000018.html http://www.joelonsoftware.com/articles/fog0000000018.html
Ygor 11y 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 11y 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."
hyperpallium 11y 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 11y ago
  "JSON schema seeming to finally gain traction" Could you describe this further? Are you referring to http://json-schema.org/ http://json-schema.org/ or to more general efforts to bring typing to APIs, like GraphQL?
  - hyperpallium 11y 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 11y 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 11y 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.
todd8 11y 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.
dekhn 11y 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 11y ago
I thought this was the rise and fall of COBRA (gi joe) and when I realized it wasn't I was sad.
billyhoffman 11y 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.
- rwmj 11y 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 11y 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 11y 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.

67 points by ptx 11y 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 11y 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 11y 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 11y 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 11y ago
I bet their UML diagrams were magnificent, though.

lukeh 11y 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 11y ago
CORBA also persists in the Ada community (e.g. see http://www.adacore.com/polyorb/ http://www.adacore.com/polyorb/).

benaston 11y ago

Those working on other standards should take heed.

ak39 11y 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_ 11y 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 11y 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.

sgt101 11y 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?

tracker1 11y 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.
- rwmj 11y 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/threads.html#02162 https://lists.gnu.org/archive/html/qemu-devel/2011-05/thread...
  - tracker1 11y ago
    Integers don't exist in JS/JSON... You get IEEE754 double precision floating point numbers, meaning whole numbers between -(2^53 - 1) through (2^53-1) are supported without rounding issues. If you need greater precision or fixed decimals, use a base10 string and an appropriate library in your application. I'd say the lack of strict date/locations in the spec are probably as big of an issue, but there are standards for how to handle that that have evolved as well... (geojson and ISO-8601 date-time strings).
    - 11y ago

sepeth 11y ago

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

dekhn 11y 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_johnson 11y 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 https://en.wikipedia.org/wiki/DCE/RPC
  - dekhn 11y ago

thorn 11y 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 11y ago

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

Ygor 11y 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 11y 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."

hyperpallium 11y 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 11y ago
"JSON schema seeming to finally gain traction" Could you describe this further? Are you referring to http://json-schema.org/ http://json-schema.org/ or to more general efforts to bring typing to APIs, like GraphQL?
- hyperpallium 11y 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 11y 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 11y 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.

todd8 11y 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.

dekhn 11y 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 11y ago

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

billyhoffman 11y 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.

rwmj 11y 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 11y 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 11y 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.