Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Rise and Fall of Corba

ScuttleMonkey posted more than 8 years ago | from the always-easier-in-hindsight dept.

304

ChelleChelle writes "Chief scientist of ZeroC, Michi Henning, has an interesting look at the story behind CORBA a once-promising distributed computing technology. Henning provides more than a brief history, in addition to several reasons pinpointing why CORBA fell short, focusing specifically on the OMG's technology adoption process itself. Most interesting is the final discussion on what we can learn from CORBA's decline, particularly in reference to web services."

cancel ×

304 comments

COM is better (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15566864)

Because it's backed by MS. It's always to have one or a few strong backers than many backers with competing views.

And that's not taking into account .NET!

Re:COM is better (0)

Anonymous Coward | more than 8 years ago | (#15567018)

RTFA. COM is microsoft only, and only an idiot would lock themselves into license hell.

Let's put it this way (0)

Anonymous Coward | more than 8 years ago | (#15567061)

Imagine a few kids building castles on the beach using little plastic shovels that they can share. However, they kick down their friend's castle when he's not looking.

Then imagine a tsunami of goodness wiping everything clean (Microsoft).

And Bruce Perens is surfing the waves above all this on his MONO board.

OMG's technology adoption process itself. (5, Funny)

Anonymous Coward | more than 8 years ago | (#15566871)

1. OMG Stable
2. ???
3. OMG Ponies!

Misread the title (5, Funny)

Ka D'Argo (857749) | more than 8 years ago | (#15566873)

Thought it said "The Rise and Fall of Cobra".

Was hoping for an outline of Cobra Commander's long list of failures :(

Re:Misread the title (5, Funny)

A Brand of Fire (640320) | more than 8 years ago | (#15566987)

Now we know; and knowing is half the battle!

Re:Misread the title (0, Redundant)

Blue_Nile (793198) | more than 8 years ago | (#15567044)

Corba!

It was the crane kick that did them in (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15566875)

Corba Kai was never the same afterwards.

Yo Joe. (-1, Offtopic)

derrickh (157646) | more than 8 years ago | (#15566876)

This article completly glosses over the contribution of G.I. Joe to CORBA's downfall.

D

nuff said. (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15566883)

Because Knowing Is Half The #*&@ Battle.

CORBA. (5, Interesting)

Anonymous Coward | more than 8 years ago | (#15566890)

CORBA might have been a great messaging infrastructure and all, but any corba websites I saw were confusing, over-diagrammed, impenetrably academic documents. Seriously, could you dumb it down a shade? Spare me your medical mumbo jumbo? Hello world apps?

Re:CORBA. (0, Flamebait)

Zero__Kelvin (151819) | more than 8 years ago | (#15566919)

CORBA might have been a great messaging infrastructure and all, but any corba websites I saw were confusing,
The problem you are experiencing might be that you have absolutely no idea what CORBA is ... it is the Common Object Request Brokerage Architecture, and his quite literally nothing to do with Websites :-)

Re:CORBA. (5, Funny)

Anonymous Coward | more than 8 years ago | (#15566966)

The problem you are experiencing might be that you have absolutely no idea what CORBA is
As I read it, the OP was talking about websites with information about CORBA. Who knows, maybe I'm wrong... but if I'm right, well it kinda makes you look like an ass.

Re:CORBA. (-1, Troll)

Zero__Kelvin (151819) | more than 8 years ago | (#15566975)

As I read it, the OP was talking about websites with information about CORBA. Who knows, maybe I'm wrong... but if I'm right, well it kinda makes you look like an ass.
If you don't know if you are wrong or right, but you "opened your mouth" anyway, there is no 'kinda' about it. You are an ass!

Re:CORBA. (2, Funny)

Anonymous Coward | more than 8 years ago | (#15567075)

Is that your username or your brain temperature?

Re:CORBA. (0)

Anonymous Coward | more than 8 years ago | (#15566969)

I meant webpages describing corba.

Unless you were joking, in which case, never mind.

What a ridiculous trend... CORBA to WebServices. (5, Insightful)

lonesometrainer (138112) | more than 8 years ago | (#15566895)

Let's do SOAs based on WebServices. Right now, right here.

The only Web-Service-Standard that's currently finalized and widely accepted is WS-I basic profile. So, no standard on...

- authentication (no, dear MS people, HTTP basic is _NOT_ sufficient for the IBM MQ guys)
- transaction management, transport and control (please say properietary soap headers)
- encryption (there IS a standard for XML encryption, but it's unsure how to use it within SOAP)
- naming services (UDDI is so dead, it's already smelling, go and find a public UDDI registry that's not just a webpage, that you can query via SOAP, IBM's developing a Websphere Naming Service, superb!)
- ... and so on, and so on...

Stuff that CORBA has been offering for nearly a decade! So why are webservices popular? Because of the technology? No way! They're freaking slow (our Java RMI services are nearly 50 times faster than those implemented with Apache Axis 1.4 here, and axis is pretty good). No, just because of the tools!

Go, build a Webservice with NetBeans and a client with VS.net 2005 and you will have to implement two or three lines of code... That would have been possible with CORBA, too! The fall of CORBA is just a matter of tools, the technology is clearly better, offers more features, is very performant.

But coding these days requires click and run...

Sad.

Re:What a ridiculous trend... CORBA to WebServices (5, Interesting)

Anonymous Coward | more than 8 years ago | (#15566920)

CORBA is too complex, an overengineered attempt at creating a clockwork the size of Tokyo whereas a single wristwatch would have sufficed.


Yes, I have had to use it, unfortunately.


The OMG people are clever bunch, but why do they insist on making these superheavy monolithical monsters? Why not build interoperable but smaller things which you can grok immediately, almost via intuition?


Like you yourself put it indirectly via examples, developers like to develop systems which have the best supporting tools, systems which are the most intuitive and easiest to understand, systems which do not fight back when you try to do something, systems for which development is not an exercise in sado-masochism. So there's a design paradigm for you: make the APIs dead simple to use, and they will be used, a lot.


Nobody wants to hack around some big behemoth. It's about job ergonomics, really. If a chair doesn't feel right for your body, you don't sit in it.

Re:What a ridiculous trend... CORBA to WebServices (0)

lonesometrainer (138112) | more than 8 years ago | (#15566944)

I have to agree, somehow. It's just a matter of tools, even with CORBA tools would have been able to create IDL, the required supporting classes, proxies, whatever so CORBA could have been easy on the surface and a well fitting chair for the developers.

We've had a solid and good working standard for distributed environments, so why this mess with webservices?

Re:What a ridiculous trend... CORBA to WebServices (5, Interesting)

cryptoluddite (658517) | more than 8 years ago | (#15567154)

The problem with CORBA was mostly the technicalities and 'grossness' of the design. Yes I used the Java bindings, and it was just crap. All these "helper" objects and peers and stubs and junk. You'd compile an IDL, which was some hacked up C++ interface which wasn't even C++, get a buttload of Java classes that did not act anything like any other Java object on the planet. Lots of 'icky' exceptions. It just, for lack of a better way to describe it, had no style.

Try to teach CORBA to some normal programmer and they'll be thinking that creating their own wire protocol is probably going to be easier for 99% of the things they need to do. Seriously, you just don't look at CORBA bindings (for Java at least) and want to have anything to do with it. It's probably not so bad for C++ developers because they are used to a lot of noise and complexity, and they have templates and stuff to 'spray perfume' on CORBA and make it smell... better.

But seriously, when your technology drains the life out of any competent developer who actually likes to program then you know something is very wrong.

Re:What a ridiculous trend... CORBA to WebServices (-1, Troll)

WasterDave (20047) | more than 8 years ago | (#15567051)

Tools, maybe. Marketing? Yes.

I bitched about it at the time (i.e. late 90's) and I'm happy to have managed to avoid it ever since. XML and SOAP, the whole f'king shebang. Inefficient shite. There's nothing wrong with binary formats at all - file systems appear to survive, for instance.

To a certain extent I can see the point. I like XML-RPC and can see that if you want to ask a webserver to do something from a piece of code, it's basically OK. It's not a particularly big improvement over doing a semi-tortuous HTTP POST, but it's OK. The performance is dogshit, but then it's not something you do all that often.

But big distributed apps based on SOAP?

OK. I'll stop.

ObAOL: Me Too!

Dave

Re:What a ridiculous trend... CORBA to WebServices (2, Insightful)

Anonymous Coward | more than 8 years ago | (#15567053)

The fall of CORBA is just a matter of tools, the technology is clearly better, offers more features, is very performant.

Well one reason CORBA tools sucked was that it was over-engineered: intended to solve world hunger, clean up the environment, produce a fresh and pleasing scent and tuck you into bed at night - oh yeah and be the glue for distributed systems too. Web-service oriented protocols are simpler because they try to do less. Simpler protocols means that tools are easier to produce, which means tools will be produced.

Re:What a ridiculous trend... CORBA to WebServices (2, Insightful)

The Pim (140414) | more than 8 years ago | (#15567054)

Go, build a Webservice with NetBeans and a client with VS.net 2005 and you will have to implement two or three lines of code
There may be some truth to this (I've never used those tools), but that's not saying much. You've just built a self-contained "hello world" client and service, accepting all the defaults. Now, take a complicated, pre-existing service, using some non-default binding and non-trivial schemas, and integrate a client for it into a large existing application. I tried this recently using apache axis2, and it was a world of pain. Now, it may be that axis2 sucks and there are better tools, but I've read many of the web service standards, and it's clear that there are complexity and interoperability issues (why do these standards have to offer implementors so many options??) that you can't easily paper over. Ultimately, I agree with the author (and hope!) that web services will fail for technical reasons.

Re:What a ridiculous trend... CORBA to WebServices (2, Insightful)

bigmouth_strikes (224629) | more than 8 years ago | (#15567064)

Different people need different things. For many companies being productive - i.e. having appropriate tools - is everything. In many cases tt doesn't matter if you have to roll your own or use a non-standards compliant protocol, as long as you can get the functionality out the door in a matter of months, not years.

Like the article said, CORBA is a niche product for those who absolutely need it.

Re:What a ridiculous trend... CORBA to WebServices (2, Informative)

Anonymous Coward | more than 8 years ago | (#15567094)

Unfortanly the IBM MQ and WebSphere (WAS, WPS, LWP) (in fact, all IBM software) is complete crap; slow, bloated and unstable. iSeries and zSeries are actually very good hardware though.

And no, Axis isn't pretty good, is just as bad as the IBM stuff (probably written by IBM employees, though released through Apache foundation). It's slow and bloated and generates the most horrible code I have ever seen.

You're right about RMI though, it's very fast and extensible.

Where comes the Sun ... ???? (5, Informative)

Zero__Kelvin (151819) | more than 8 years ago | (#15566898)

FTA:
CORBA 2.0 in 1997. ... CORBA's future looked rosy indeed.
I was learning CORBA in 1997. Alas, it was another Sun driven technlogy, like Java, before Sun understood how the technology landscape was changing. The only FOSS CORBA implementation that came anywhere close to implementing CORBA 2.0 was Orbit, and I do not know if the developers didn't have the chops, or (more likely) they were swimming upstream against a Sun that was still either hostile to OSS or simply wrote it off as a non-factor. In the end CORBA suffered the same fate as Java for the same reason(s).

You can still use both .... but why would you?

CORBA could *easily* be revived if Sun finally grasped the revolution in the market and decided to do so. Will they? Seeing as .NET/MONO is the only real competitor, they have an obligation to the community to do so IMNSHO. Will Sun step up to the plate and figure out that they have a very real obligation to the future? Hmmm ....

BTW .. OMG was just a Sun directed organization ....

Re:Where comes the Sun ... ???? (4, Informative)

timeOday (582209) | more than 8 years ago | (#15566928)

CORBA could *easily* be revived if Sun finally grasped the revolution in the market and decided to do so.
I don't think so. I spent almost 3 years working on an abstraction layer over CORBA so the other members of my (very large) development team could use it without being specialists. It's true that CORBA does everything, and does it well, but it's just too much.

Re:Where comes the Sun ... ???? (-1, Flamebait)

Zero__Kelvin (151819) | more than 8 years ago | (#15566980)

I spent almost 3 years working on an abstraction layer over CORBA so the other members of my (very large) development team could use it without being specialists.
Who are you? What makes you qualified to do so? What problems did you encounter? How did those relate to my point(s)? If you cannot add value to the thread, why post?

Re:Where comes the Sun ... ???? (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15567129)

He is right. (In my opinion.)

I am not him, but the problem is the same - Corba is overly complex.
His post illuminates the fact that this is not about Sun at all anymore, if it ever was. On the contrary, I saw Corba as quite popular among the OSS crowd.

I did the same thing as the guy in your parent post. I suspect that in groups of developers all over the world, one guy was the Corba-guy with the task of just making it work. And we all had the same solution (I imagine) - writing the ultimate IDL, then a flexible abstraction layer in code. Then never touch it again.

Nowadays Java and .Net and various libraries does what Corba promised to do, but far far simpler.

I'm not sure where Sun fits in this picture at all. Why would they want to resurrect Corba, with JavaEE in its place?

Re:Where comes the Sun ... ???? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15566935)

Like most FOSS, Orbit was shit.

Stop thinking that FOSS is the key to making software succeed. It's not, it's barely relevant.

Perhaps Sun screwed in some ways, like making CORBA way too complicated. Perhaps Microsoft is just to good at doing what it does: software.

Re:Where comes the Sun ... ???? (-1, Troll)

Zero__Kelvin (151819) | more than 8 years ago | (#15566951)

Like most FOSS, Orbit was shit.
Like most morons, you are a phenomenon. Also, CORBA wasn't FOSS you fscking moron! ROTFL

Re:Where comes the Sun ... ???? (0)

Anonymous Coward | more than 8 years ago | (#15567275)

Maybe you should show your comments on this story to your shrink ... he might need to come up with a new script for you.

Re:Where comes the Sun ... ???? (-1, Flamebait)

Zero__Kelvin (151819) | more than 8 years ago | (#15566960)

Perhaps Sun screwed in some ways, like making CORBA way too complicated. Perhaps Microsoft is just to good at doing what it does: software.
WOW ... you actually think M$ is in the software business!!!! You truly are one of the biggest fscking morons I have heard from recently!

Re:Where comes the Sun ... ???? (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15566989)

Facts:

Orbit [sourceforge.net] is open source.
Microsoft [microsoft.com] makes a number of OS's, office suite, a number of servers, development tools that were better 8 years ago than any FOSS IDE TODAY (Visual C++ 6 VS kdevelop, ajunta, etc to name a few).

To be so much outside reality and insulted by some truth you must be a very passionate Linux advocate, or even a contributor to some useless open source projet that doesn't even compile.

Re:Where comes the Sun ... ???? (-1, Flamebait)

Zero__Kelvin (151819) | more than 8 years ago | (#15567012)

Microsoft makes a number of OS's,
I don't have a problem with a company making "a number of OS's" .... any projections on when they will make at least one that isn't a clearly abominable clusterfuck when compared to any real OS?

Hint --> I have the Latest Beta 2 of Vista at my disposal ... do you?

Oh WAIT ... Of course you do ... you clearly work for Bill "unscrupilous moron" Gates :-)

Re:Where comes the Sun ... ???? (0)

Anonymous Coward | more than 8 years ago | (#15567432)

I thought everyone had a copy by now, since it's available from the Customer Preview Program... :|

Do you come on here just for an argument? Several of your other replies in this article seem to be deliberately inflammatory.

Re:Where comes the Sun ... ???? (4, Funny)

maelstrom (638) | more than 8 years ago | (#15567015)

As a member of the open source community, I have decided to revive the OMG group. To put focus on our roots, we shall be called the Object Management Freedom Group or OMFG for short. Any takers?

Re:Where comes the Sun ... ???? (2, Informative)

Yokaze (70883) | more than 8 years ago | (#15567188)

Alas, it was another Sun driven technlogy, [...]

CORBA? Sun driven? Everyone else did have more complete Corba implementation than Sun in their JDK.

1997... I can't claim that my memory is correct on that matter, but sometime before 2000, JacORB [jacorb.org] provided a FOSS CORBA 2.0 Java implementation, which surpassed Suns by leaps.

One man's simplicity... (4, Funny)

21mhz (443080) | more than 8 years ago | (#15566899)

From TFA:
Many of the APIs were complex, inconsistent, and downright arcane, forcing the developer to take care of a lot of detail. In contrast, the simplicity of component models, such as EJB, made programming a lot simpler
Wow. If EJB (pre-3.0) is simple in comparison, no wonder CORBA never really took off.

Re:One man's simplicity... (2)

lonesometrainer (138112) | more than 8 years ago | (#15566914)

It's a distributed, platform-neutral, language-neutral, object-oriented technology. The best OO could offer. What did you expect?

Btw. EJB > 2.0 wasn't that hard, either. Just unconvenient in some places.

Re:One man's simplicity... (0)

Anonymous Coward | more than 8 years ago | (#15567461)

me fail english? that's unpossible!

Re:One man's simplicity... (1)

FullMetalAlchemist (811118) | more than 8 years ago | (#15566967)

Actually, CORBA wasn't a component framework untill version 3 (and versioning of CORBA specifications is stupid, as a verion is an extension-only of previous verions).
When was CORBA v3 released? Can't remember, 2002? Compare that to COM, which is based on the drafts of CORBA v1 but with added component framework, it's easy to see why COM won.

Re:One man's simplicity... (5, Informative)

Cyberax (705495) | more than 8 years ago | (#15567396)

EJB 2.0 is just a part of CORBA 3.0 specification :) So it's easy to understand why there is no a single CORBA 3.0 implementation.

Early middleware was doomed (4, Insightful)

mshurpik (198339) | more than 8 years ago | (#15566917)

It's not surprising that an early middleware app like Corba failed because it was being developed at a time when the concept of middleware was just a buzzword. The article mentions the "fracturing" of the middleware market and the over-reliance on "screen scraping" technologies like HTTP+CGI. In other words, it wasn't until the standardization of the web platform (Apache+PHP+MySql or IIS+ASP+SqlServer) that people even knew what middleware was supposed to look like, and this standardization didn't happen, actually, until after the dot-com boom was over.

Re:Early middleware was doomed (2, Insightful)

Anonymous Coward | more than 8 years ago | (#15567020)

Some of the technical problems of CORBA went beyond a misunderstanding of what it actually needed to do. The biggest failure from my point of view was uneeded extra state that had to be synchronized. The hardest part of distributed systems is synchronization of views, so anything that makes this harder makes the entire system more brittle. Using CORBA always started out easy enough and then got nastier and nastier as development went on. Good riddance to bad rubbish really.

Re:Early middleware was doomed (1)

The Pim (140414) | more than 8 years ago | (#15567083)

What do you mean by "middleware was just a buzzword"? That nobody really understood it? The article claims the opposite, that many qualified experts, who knew exactly what they were doing, worked on CORBA. I believe him. The point of the article is that even with capable people involved, standards groups tend to produce crap. Are you saying that middleware not a buzzword now? It seems to be more so than ever. What makes you believe that people understand middleware better now? And what do "Apache+PHP+MySql or IIS+ASP+SqlServer" have to do with any of this? None of the mainstream web services tools are based on them. (Not saying that's good or bad.)

The parable of the two elephants (4, Interesting)

Beryllium Sphere(tm) (193358) | more than 8 years ago | (#15567143)

I can't find a citation for this offhand but the original author, whoever it was, deserves credit.

Imagine two superposed graphs, with time on the x axis. One is the rate of technical change. The other is the rate of adoption.

Standards activity needs to happen between the peak of technology development and the peak of adoption. Too early, and you standardize on immature technology that nobody will want. Too late, and the market has committed to somethign other than your standard.

Those two peaks in the charts are called the "two elephants". In fast-moving markets they move closer together, and the standards committee is "squeezed between two elephants".

Given that people were rushing to deploy immature technology for distributed apps, one factor in CORBA's troubles may have been that there was no room between the two elephants for a reference implementation or for nontrivial test deployments.

Re:The parable of the two elephants (1, Informative)

Anonymous Coward | more than 8 years ago | (#15567494)

That is analogy described in Tanenbaum's book "Computer Networks."

Re:Early middleware was doomed (0)

Anonymous Coward | more than 8 years ago | (#15567259)

CORBA was, at heart, basically a simply awesome and very modern object-oriented design.

I'm not suggesting that object-oriented programming is the end-all (I don't believe that
for a minute, actually, although I do often like it), but please remember that CORBA was
neither concieved nor designed by idiots. Even though the committee failed (as Mr. Henning
rightly indicates), that does not mean that it was a ship of fools.

To say that it was "an early middleware app" is, basically, dead wrong.

We faced great chaos before CORBA... and, sadly, we're still facing that chaos now. Michi Henning
discussed a number of reasons in his articulate article. (Aah, aliteration.)

But your comment here... well, it was hilarious:

    "the standardization of the web platform (Apache+PHP+MySql or IIS+ASP+SqlServer)"

So much to pick on. I'm guessing that you're pretty "new" to this corporate software
development stuff.

So, I'll be constructive instead (I clearly am getting old... ;>): why do you percieve
any of the combinations you suggest as a "standardization of the web platform"? Why might
someone else quite seriously object to that claim?

I'll leave it at that. Please investigate further.

Other failures (2, Interesting)

isj (453011) | more than 8 years ago | (#15566933)

Initially the specifications for CORBA (object model, servers, language mapping, ...) were not free. Whenever I tried digging for details I ended up at a page which basically said "buy the expensive book". Of course they needed funding, but the lack of a free specification hindered adaption. I was also turned off by the continued references to UML (which was a new-fangled thing back then). When looking for hard details a floffy box does not help.

It also seems that the vendors had a lot of problems agreeing. AFAIK it wasn't until version 2 that the on-the-wire format was specified. I can only speculate why.

But I must say that the IDL (interface definition language) is close to ideal. Looks a lot like Sun RPC, and way better than WSDL. It only lacks the versioning as the article also mentions.

Distributed applications (4, Insightful)

wysiwia (932559) | more than 8 years ago | (#15566939)

Why should anybody create a distributed application when a simple library API is almost always sufficient. Why making something more complex than necessary. In most cases component APIs are rather stable as soon as all the missing pieces from early beta versions are solved. Yet even if they change it's possible to handle most cases without any intermediate interface definition etc.

Prof. Wirth always said: "Make everything as simple as possible but not simpler". While Prof. Wirth as made many things too simple (to prove his statement true) any component system is yet much too complex for any locale task and many times also even for distributed tasks. I'm still waiting for a component system which is as easy usable as a simple library API.

O. Wyss

Re:Distributed applications (1)

David Off (101038) | more than 8 years ago | (#15566968)

> Prof. Wirth always said: "Make everything as simple as possible but not simpler"

I think you will find that quote is usually attributed to Albert Einstein not some Swiss guy.
 

Re:Distributed applications (4, Insightful)

Ricdude (4163) | more than 8 years ago | (#15566977)

Um, there are instances where you *want* to distribute an application across several machines, and not have to worry about the details of implementing a robust inter-process communication layer yourself. Once you get past the boilerplate code of creating an object, publishing it's reference, and locating that object, CORBA breaks down into simple function calls.

I just wish they'd create a C++ mapping that allowed for STL compliant sequences, and std::string compatibility...

Re:Distributed applications (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15567233)

Ricdude,

I've used both CORBA and Ice.

Check out Ice. You will experience a rush of "the good"!

STL, baby.

never as simple Re:Distributed applications (1)

aaron_pet (530223) | more than 8 years ago | (#15567058)

The threading issue is siply non trivial, and there are going to be errors of different kinds on a distributed system, rather than on a local system... somebody tripped over the cord! and the like...

I don't know much about this stuff, but I'd stop waiting...

Conventions for passing data drrm important.. and I would assume that you could get by omiting some of the failsafes if your application allowed for it, and have a simpiler time dealing with this stuff.

--Am I talking out of the wrong orifice?

Wasn't that Einstein? (1)

Petersko (564140) | more than 8 years ago | (#15567077)

"Make everything as simple as possible, but not simpler"

Wirth may have said it, but I think Einstein said it first.

Re:Distributed applications (1)

NutscrapeSucks (446616) | more than 8 years ago | (#15567302)

Why should anybody create a distributed application when a simple library API is almost always sufficient.

People rarely start out with the goal of buiding a distributed application. It's either a question of scalability, or simply requirements issues such as interaction with multiple systems, distributed transactions etc.

Also, in the Java and DCOM/MTS systems, there's not an enormous difference between using the distributed component and using a library API, which is also component-based. The simplicity is in the abstraction.

Corba isn't dead! (5, Funny)

Anonymous Coward | more than 8 years ago | (#15566947)

Just look at all the projects built on Corba like the Berlin Project [fresco.org] and then you tell me Corba is dead.

This article is nothing but a hatchet job on a mature committee standard. Corba is not falling like DCOM, it's soaring like the Hindenburg.

Re:Corba isn't dead! (1)

GotenXiao (863190) | more than 8 years ago | (#15567073)

Correct me if I'm wrong, but the Hindenburg crashed. In a large cloud of boom. Not really "soaring", that, is it? :P

Re:Corba isn't dead! (0)

Anonymous Coward | more than 8 years ago | (#15567133)

Geez you're sharp. It's almost as if I'm mocking Corba.

Re:Corba isn't dead! (2)

ultranova (717540) | more than 8 years ago | (#15567155)

Just look at all the projects built on Corba like the Berlin Project and then you tell me Corba is dead.

This article is nothing but a hatchet job on a mature committee standard. Corba is not falling like DCOM, it's soaring like the Hindenburg.

Isn't Gnome based on Corba ? Not that that's neccessarily good publicity for Corba, since Gnome is a huge mess with scalability problems: try opening a 100+ Eye of Gnome windows sequentially, waiting until the processor goes idle before opening the next, and notice how much slower the later windows open.

Maybe you could convert Hurd into using Corba for message passing ?-)

Real reasons (5, Interesting)

William Robinson (875390) | more than 8 years ago | (#15566956)

The article focuses on market conditions and forces as reasons behind CORBA's downfall. Having worked on CORBA, I can say there are some technical reasons too.

CORBA always required holes in firewall, more complicated to setup(as mentioned in article), poor/no load balancing/fault tolerance mechanism/ maintainability(probably this was not meant to be there, but very important for an ecommerce setup), poor QoS (this improved in CORBA 3.0 after Douglas Schmidt's and others contribution), security (though iiop over ssl appeared sometime later, security mechanisms for ecommerce were missing, that could bring collaboration from unknown consumers/providers.)

SOAP/xmlrpc address some of these issues nicely, and might become defacto tools for business to business integration. I had only one issue with it. The protocol is too verbose.

My 2 cents.

Re:Real reasons (4, Informative)

The Pim (140414) | more than 8 years ago | (#15567009)

The article focuses on market conditions and forces as reasons behind CORBA's downfall. Having worked on CORBA, I can say there are some technical reasons too.
I don't think you read to the second page, where he says:
No matter how much industry hype might be pushing it, if a technology has serious technical shortcomings, it will eventually be abandoned. This is where we can find the main reasons for CORBA's failure.
This is the point of the article: You have to get the design basically right for a standard to fly, but getting the design basically right (not even all the way right) in a standards process is darn hard. Frankly, we need standards for standards groups, since they keep making the same mistakes and ignoring the very wise and practical advice of people like Michi Henning.

Re:Real reasons (0)

Anonymous Coward | more than 8 years ago | (#15567170)

Er, SOAP's not that popular. Amazon has both SOAP and REST interfaces to their web services, and 85% of their usage is of the REST interface.

Re:Real reasons (1)

zootm (850416) | more than 8 years ago | (#15567262)

To be fair, though, most commercial development (apparently) happens with SOAP, whereas REST is used more by amateur etc. projects. So SOAP is still popular in business. I think I'd personally rather use REST though, yes, but saying "SOAP isn't popular" doesn't really work because it's popular where the money is, which is something of a factor.

Re:Real reasons (2, Informative)

killjoe (766577) | more than 8 years ago | (#15567248)

One thing that gets overlooked with CORBA is the the stateful two way communication between the clients and the servers. The server can raise an event and tell the client to do something. That's just not possible with web services where constant polling is the order of the day.

CORBA was a great idea implemented complexly. People don't like complex.

I should mention that the author of the article works for a company which sells a product they claim is "better then corba". I have never used their products so I can't say anything about it but it's something to keep in mind.

BTW zeroc guys do you have ruby bindings in the works?

Re:Real reasons (2, Interesting)

William Robinson (875390) | more than 8 years ago | (#15567455)

One thing that gets overlooked with CORBA is the the stateful two way communication between the clients and the servers. The server can raise an event and tell the client to do something.

Yes, you are correct. Although, it has trouble with NAT. I remember one case, where we had to drop CORBA and go for designing our own protocol, because clients behind NAT would never recieve the event.

Re:Real reasons (0)

Anonymous Coward | more than 8 years ago | (#15567307)

Um... the article spent several pages on technical issues...

Re:Real reasons (1)

Ulrich Hobelmann (861309) | more than 8 years ago | (#15567484)

Hm, I'm sure your complaints are valid, but it also looks as if they are mostly implementation-dependent.

I'd wager the guess that CORBA applications can be well distributed (i.e. allow load balancing) and that an ORB could also include QoS features. Fault tolerance... are you talking about network errors, or simple return values in contrast to exceptions?

Maintainability is clearly a bigger problem, as APIs evolve, but no technology can really solve that one, it's an organisational problem.

(OT) Thom Yorke "The Eraser" torrent? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15566957)

Since Slashdot is a community notorious for its teeming hordes of criminal freeloaders, I thought I'd ask. I'm having trouble finding a WORKING torrent of Thom Yorke's "The Eraser." All peers and no seeds. Firstly, why is this? And secondly, anyone know where to steal the album (without paying one red pence to the evil recording industry, the evil Steve Jobs, or the oh-so-rich-yet-oh-so-indie Mr. Yorke, natch)? Thanks.

Re:(OT) Thom Yorke "The Eraser" torrent? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15567070)

Thanks, anonymous mod, for reiterating what I stated in the subject: OFFTOPIC. Perhaps you lashed out because I called Mr. Jobs "evil"? That, I assure you, was tongue-in-cheekity cheek. Because I agree--Steve's on our side. He's the ur-hipster. He was indie before indie was cool. Oh, Steve! Anoint me with Your merrie melodies. Bless me with Your taste. Touch me. Touch me.

With that out of the way, does anyone now have a link for Thom Yorke's "The Eraser"?

Corba, Corba: I hardly knew ye (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15566959)

I knew Corba as the Common Object Request Broker Architecture. I knew it was middleware, but I never used it. I've use the entire LAMP stack to build killer web sites. Not one stitch of CORBA within it. You might argue that CORBA is middleware, and I'm not using it. Agreed. But as others have stated, the LAMP stack comes with piles of documentation. Corba usually insisted on a very specific installation...you basically had to know how it worked before being able to set it up and use it properly. Now CORBA is fading. When it's gone, I will remember it as technology that might have been ok, but no one will ever know, and now that it's gone, no one cares.

failures? (0, Offtopic)

santaliqueur (893476) | more than 8 years ago | (#15566974)

cobra kai's failures were summed up by one crane kick by daniel larusso. that kid is something else.

I took a close look at CORBA and wrote this (3, Interesting)

Omnifarious (11933) | more than 8 years ago | (#15566986)

Why I think CORBA and other forms of RPC are a bad idea [omnifarious.org] .

Here is the paper in brief...

The speed of light is a constant. Latency will never improve beyond a certain point. For all but the simplest things, RPC is the wrong model for dealing with the problem of communicating with other systems.

Also, the abstraction layer of function calls is the wrong place to put the communication of disparate, unrelated systems. It encourages too many assumptions about the implementation of either side. There is too much hidden state in the caller and reciever of the messages.

Re:I took a close look at CORBA and wrote this (4, Interesting)

Moebius Loop (135536) | more than 8 years ago | (#15567286)

I'm not sure I agree with your chief argument, WRT latency in RPC calls. The answer to this is to use asyncronous development techniques as part of your IPC.

The increasing amount of network-related latency dealt with in everyday communication generally means that in any reasonable interesting application, there are often large numbers of blocking calls that take a variable amount of time to return. Threads in and of themselves are truly not the answer, except possibly when used sparingly as part of a non-blocking system. (as an aside, I've found that as a Python developer, working with the Twisted Python [twistedmatrix.com] libraries was invaluable in my understanding of asychronous development techniques.)

With regards to the idea of function calls being an innappropriate abstraction for these mechanisms, I think the issue really depends on the implementation. The reasons I've used an RPC/IPC solution to communicate between processes (either locally or remotely) was because the various processes weren't closely related, and needed to have a common interface between them.

Making assumptions about implementation is an inherently bad programming habit, and has much farther reaching consequences. APIs would be essentially worthless if the developers made assumptions about how the work is done "behind the scenes". If you need intimate knowledge of the memory space of another process, it may be an indication to use process fork()ing to provide the same results.

anyways, my 2/100th of a dollar....

-phil

zeroC ICE (0)

Anonymous Coward | more than 8 years ago | (#15566988)

zeroC are developers of a CORBA alternative called ICE, evidently better in all possible ways, it's GPLed so it must be good.

Re:zeroC ICE (1)

BiggerIsBetter (682164) | more than 8 years ago | (#15567074)

You mean the author of an article discouraging the use of CORBA works for a company which has a vested interest in discouraging the use of CORBA? That's unpossible!

Re:zeroC ICE (0)

Anonymous Coward | more than 8 years ago | (#15567138)

Uh, actually Michi Henning was a co-author of _the_ definitive text on CORBA programming, and one of the most respected CORBA gurus out there during its heyday. I'd say he might be a little less biased than you're implying.

Re:zeroC ICE (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15567423)

Note: I do not have any affiliation with ZeroC or Ice, just admiration.

If you have used CORBA (especially the C++ bindings), I definitely suggest that you
try Ice.

I evaluated XML-RPC, SOAP, CORBA, and Ice for my company.

My recommendation was, crushingly, for ZeroC's Internet Communications Engine (ICE) technology. It totally
rocks. It is what you should build SOAs upon.

If you want good technology, that is.

My company though my recommendations were interesting, but went with one of my least-suggested approaches, SOAP. The primary reason cited was that it is ubiquitous. See? If everyone is using something, it must be right to use it for everything.

I'm gonna kick back for a couple of years, and wait for the moaning. I'm sure some "compression technology" or
"deep refactoring" will come to the rescue.

It all seems to be about mindset. And so very few companies really seem to "have it" when it comes to
computers. It is almost as if the late 1970's and early 1980's PC era never really left us, those moments
when real nerds had to have chops in order to /be/ nerds. If you had a personal computer, you built it. If
you owned one that you didn't build, you at least could still program it.

Now, bozos not always but very often make our technology decisions. They just don't know that they are
bozos.

OpenOffice and GNOME use CORBA. (4, Insightful)

Animats (122034) | more than 8 years ago | (#15566999)

The intercommunication system within OpenOffice, the mechanism that allows embedding spreadsheets and drawings in other documents, is CORBA-based. Sort of. Actually, it's something called UNO, which started life as CORBA but went off in an XML direction.

GNOME also uses CORBA internally. But its CORBA isn't compatible with the one from OpenOffice.

The UNIX/Linux world has never really had a good way for applications on the same machine to intercommunicate in a subroutine-like way. Microsoft has OLE/COM/DCOM/ActiveX, which is clunky but always available. In the Linux/Unix world, there's nothing you can assume is always there. There's OpenRPC, there's CORBA (in about five incompatible forms), there's Java RMI, and there are various kludges built out of pipes. But there's been no convergence in two decades.

Re:OpenOffice and GNOME use CORBA. (4, Informative)

Stalyn (662) | more than 8 years ago | (#15567081)

The UNIX/Linux world has never really had a good way for applications on the same machine to intercommunicate in a subroutine-like way. Microsoft has OLE/COM/DCOM/ActiveX, which is clunky but always available. In the Linux/Unix world, there's nothing you can assume is always there. There's OpenRPC, there's CORBA (in about five incompatible forms), there's Java RMI, and there are various kludges built out of pipes. But there's been no convergence in two decades.

D-BUS [freedesktop.org]

Gnome and KDE to use D-BUS ? (1)

Zoxed (676559) | more than 8 years ago | (#15567107)

I do not use/follow Desktop Environments, but I thought I read that both Gnome and KDE are/will be using D-BUS (KDE in 4.0 ?)

Re:OpenOffice and GNOME use CORBA. (1)

nacturation (646836) | more than 8 years ago | (#15567114)

The intercommunication system within OpenOffice, the mechanism that allows embedding spreadsheets and drawings in other documents, is CORBA-based. Sort of. Actually, it's something called UNO, which started life as CORBA but went off in an XML direction.

So, kind of an embrace-and-extend of CORBA?
 

Re:OpenOffice and GNOME use CORBA. (1)

mcpkaaos (449561) | more than 8 years ago | (#15567342)

So, kind of an embrace-and-extend of CORBA?


More like an embrace-and-extend-arms-and-shove-as-hard-as-you can kind of way.

Scary... (3, Insightful)

Gorimek (61128) | more than 8 years ago | (#15567001)

I worked with CORBA around 1997-98. It was one of several new technologies in our project, and we never really got it to work properly. Everything was just really complex and error prone. The company got closed for many reasons, but our stuff didn't help things much.

Recently I've done a lot of XML Web Services work. This can actually be made to work, but it feels a lot more like filling out your tax returns than programming. Everything is really verbose, and you have to tell the system the same thing over and over.

I never really connected dots until I read this article, but it is pretty much the same uneasy feeling I have about this that I had about CORBA. And the article even explains how they're similar!

Not that that has to mean they're destined for identical paths, or that I'm a visionary who can sense the fate of a technology years in advance, but it does make me a bit happier that I quit that job last week.

Gnome and CORBA (1)

droopycom (470921) | more than 8 years ago | (#15567013)

Didnt Gnome used CORBA at some point ?

I remember there was something called Bonobo...

Is that still going on, or was that just a fad ?

Re:Gnome and CORBA (3, Interesting)

WWWWolf (2428) | more than 8 years ago | (#15567197)

Ayup, GNOME has their own implementation of CORBA stuff, called ORBit [gnome.org] .

Bonobo is the component framework in GNOME, and is built atop CORBA.

AFAIK they're still pretty much in use.

Fortuneteller's Orb (1)

Doc Ruby (173196) | more than 8 years ago | (#15567041)

I knew CORBA was doomed when Netscape announced it would use IIOP as its distributed server protocol, back in 1996. Because I never saw a single simple implementation. I'd be surprised it's taking so long to die, except that's the main purpose of OMG's long list of giant corporations which saw HTTP as "the new EDI".

CORBA COM Failure 1: ... Maybe (1)

Matz L.E. (597914) | more than 8 years ago | (#15567090)

If I see this stacktrace once more I'm gonna explode! Useless error messages like that made me hate CORBA. Yeah, I know: "look at your classpath". But when you have an appserver that plays random() with your nicely packaged, clean EAR, it's just... not nice. One last advice: SUN Appserver 8.0.1 - keep your fingers off and RUN! 7.1 and 8.1 seem to be fine, though.

Open/Closed argument (3, Insightful)

Frankie70 (803801) | more than 8 years ago | (#15567111)

CORBA was an open standard.
COM was a propreitary standard.

But still COM succeeded much more than CORBA.

Dox Box's book "Essential COM" has a foreword by Charlie Kindel (one of Microsoft's
COM/ATL developers) which discusses this.

Wow Corba Must Be Difficult to Use (1)

zos (249765) | more than 8 years ago | (#15567120)

From the article, "In contrast, the simplicity of component models, such as EJB, made programming a lot simpler (if less flexible)." That's the funniest thing I've read today; EJB makes programming a lot simpler. Ha! Sure it does...

CORBA and DCOM too buggy for the real world (2, Insightful)

rubies (962985) | more than 8 years ago | (#15567142)

Anybody who had to deal with the woeful implementation of naming services in CORBA, who stupidly subjected themselves to cross-platform / cross language system implementations (try Visual C++ on NT talking to Smalltalk systems on SUN == headaches and midnight support calls every day) will tell you CORBA was a crock. Anybody stupid enough to listen to Microsoft when they said they would fix the DCOM dropouts / timeout issues when the system would stop talking to other DCOM clients (requiring server reboots) will tell you DCOM was a crock. The old RPC stuff was hard to use, but at least it worked. Give me a minimal raw socket solution any day of the week.

next generation is already available (0)

Anonymous Coward | more than 8 years ago | (#15567189)

Corba is too complex and slow. redFox from redPlain is lighter faster better than Corba implementations. Check it out at http://www.redplain.com/ [redplain.com] or read about it in Embedded magazine Jan 2006 http://www.embedded.com/ [embedded.com]

What's in a name? (3, Funny)

Black Parrot (19622) | more than 8 years ago | (#15567257)

> focusing specifically on the OMG's technology adoption process itself.

Calling themselves "OMG" probably didn't do much to encourage adoption.

It's all about the acronym people! (0)

Anonymous Coward | more than 8 years ago | (#15567355)

COBRA, they could have had COBRA - now that would have been a cool technology!

I hate to not bash MS on /. but... (5, Insightful)

Anonymous Coward | more than 8 years ago | (#15567374)

This is definitely a case where Microsoft's way of doing things was vastly superior. Whereas CORBA was designed by a committee of competitors who all wanted to sell object request brokers, COM was designed by a single company who wanted to sell software that could interoperate.

MS saw a need, designed something to fill that need, tweaked it until it worked, then released it. OMG designed something to fill that need, and more or less immediately released it. As a result, no two implementations of CORBA could talk to each other without buying another piece of software. Come to think of it, I don't really know why they didn't just copy COM -- at least it worked.

What they should have done was have a body of experts collaborate on a standard, implement it, tweak it until it worked, and then release it. This is why standards like IEEE 754 (floating point) and JPEG are so successful, while standards like CORBA and VRML2 are such crap. Once the dust settles on ODF, I'm afraid that ODF is going to end up like CORBA, with every program implementing it differently enough that adoption is hindered and it only gets used in-house by companies that mandate it.

dom

Corba sucked as bad as DCOM becuase.. (1)

OneSmartFellow (716217) | more than 8 years ago | (#15567427)

... it was yet another layer between the developer and the socket.

RPC solved the problems of platform independance and marshalling quite well enough; although, I agree it was a bit messy to read.

Any experienced software developer will tell you that too much abstraction introduces its own problems, and typically hides, rather than solves, the original ones.

What's so hard about 'htonl' and 'htons' anyway ?

Horrible, just horrible! (4, Interesting)

shippo (166521) | more than 8 years ago | (#15567458)

Some years ago I worked on a roll-out of some systems management software at a large company.
This software was based on CORBA.

It was hoped that by installing this software on every server and workstation in every branch nationwide (typically only around 3 to 6 machines per branch, although there would eventually be over 2000 branches netweorked), it would be possible to determine that all servers were working properly.

However the memory and CPU footprint used by the monitoring tools was immense. More than half of the RAM in the servers was taken up just by the monitoring software CORBA services, and the CPU load was also huge.

We also had serious problems with firewalls. Far too many open ports for anyone's liking.

Too many features; expressly obscure (3, Insightful)

bytesex (112972) | more than 8 years ago | (#15567499)

CORBA tried to do too many things at once; not only was it supposed to be some kind of OO-RPC, it also specced a declaration language (IDL), which was replaced at some stage by an XML-variant, which it wanted to also use to incorporate data- and other resources, plus some kind of 'discovery' broadcasting protocol that you could use to find (distributed, of course) CORBA servers around you, oh, and object serialization in weird strings. On top of all that, you had to leave your blood, soul and first born child at the omg website in order to obtain documentation, because, as these guys felt it, they had gold in their hands, and they wanted to cash in on it good. And it _was_ good, but it was just that because of this in-built obscurity (in turn caused by its complexity and omg's secretiveness), nobody could really tell where CORBA stood; was it some kind of transactioning system a la the kind that IBM mainframes have ? Was it OO-RPC (but then, why not use RPC) ? Then all kinds of competing tech started to overtake it (java RMI, XML-RPC based tech) to which the omg only vaguely responded (the XML declaration thingy) but couldn't really, because of the moloch that CORBA had become. And thus they faded into obscurity.

The moral of the story ? When you want to sell a protocol or a language, be as simple as you can (modularize) and be as open as you can (throw it around, even) Otherwise, if you're not IBM or Sun or Oracle, you will not make it.

On CORBA, Web Services, and Ice (3, Insightful)

Anonymous Coward | more than 8 years ago | (#15567507)

From an OOP point of view CORBA's core architecture is basically very, very good.

They screwed up the details. Mr. Henning's point of view is much more informed than mine,
but I want to emphasise this: they got a lot right.

Look at SOAP and the "Web Services" trend: like the language-du-jour, "everyone" seems to
think it is something new, something great. Why do we need another MS-DOS every five to nine
years? Percieved convienence is the usual answer.

At my company, a major retailer in our market, we're now taking a legacy codebase that is far
from perfect but nonetheless innovative and moving it all to silver-bullet platforms. You know
the ones I'm talking about. The full-meal deal: all our problems solved.

Even though the language we're "moving up to" is basically 1957 technology billed as cutting-edge,
  with a bloated description system being used to transfer what amount to fixed-field data records,
and all of that piped through another bloated and basically silly but extremely trendy RPC mechanism,
it's all supposedly for the best. Not.

See the trend? Why are we always in a hurry, for everything? Sure, you can swing to a point where everything
is crufty and convoluted (like CORBA), but you can get good things when you think about it a while.

That brings me to Ice.

I have a workmanlike understanding of CORBA. From that base, I have an equal understanding-- and appreciation--
for Ice, gained in much less time. Of course, a lot of that is because the whole paradigm (Ice /does/ keep a lot of the things that were VERY GOOD about CORBA!) wasn't new, but let me say that Ice is a dream in many ways. The C++ bindings are a perfect start. For casual use, blissful. (Great job, guys!)

What's my point? Okay. First, understand Michi Henning's article. Now, with that understanding, pretend that
you're in a meeting in which SOAP and certain other "modern technologies" are all being suggested. Take the
time to absorb the scene. Is the "modern" technology really and truly innovative, or is it just-- and this is /USUALLY/ the case-- crap?

-Anon.

(I have no association with ZeroC, by the way.)

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...