The Rise and Fall of Corba 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."
OMG's technology adoption process itself. (Score:5, Funny)
2. ???
3. OMG Ponies!
Misread the title (Score:5, Funny)
Was hoping for an outline of Cobra Commander's long list of failures :(
Re:Misread the title (Score:5, Funny)
Now we know; and knowing is half the battle!
CORBA. (Score:5, Interesting)
Re:CORBA. (Score:3, Informative)
If you'd RTFA, you'd understand that that's exactly why it failed. Corba is badly designed, and overly complex for what it does.
First of all it's a lot of hype. Today, it might sound daft, but when CORBA was envisioned, everybody did not use http and XML
Re:CORBA. (Score:3, Interesting)
Heh. This article was actually the first clue I've ever read that CORBA was anything but hype. I've run across the acronym a zillion times, but before today, I'd never actually read anything that got through my thick skull that it was a communication protocol, much less what problems it was designed to solve. Same with pretty much anyone that I worked with. When management pushed it on us (complete with the management-friendly hype but not much more), the reaction of the
Re:CORBA. (Score:3, Interesting)
Re:CORBA. (Score:5, Funny)
Re:CORBA. (Score:2, Funny)
What a ridiculous trend... CORBA to WebServices. (Score:5, Insightful)
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!)
-
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 (Score:5, Interesting)
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 (Score:2, Interesting)
There are some environments, such as
The author
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Interesting)
The killer for CORBA in the real world was how the f*** do you get 5000 copies of the IDL to 10 platforms at the same time?
The very few succesfull implementations of CORBA had a single IDL that went:
int msg_type;
long msg_length;
char[] msg_buffer;
Thus quietly dumping 97% of CORBA and implementing a solution that could more easily be done with BSD sockets but witho
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Interesting)
More specifically, CORBA does what needs to be done. You want location transparency, so you need a wire protocol and object references that include endpoint adresses. You want language neutrality, so you need the IDL. These parts are necessary and not overly complicated. A Naming Service is probably a good idea, and it is still simple.
What are you doing that's complicated? Trading Service or stuff layered even on that? Useless junk. Programming in C++?
Re:What a ridiculous trend... CORBA to WebServices (Score:5, Interesting)
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.
This wasn't my impression of things... (Score:3, Informative)
If it's on the same network segment, it just finds the NamingService object on the
segment (If you've properly started it...) and just works. I know, I've designed
massively distributed trasaction processing systems with it that had to handle situations
like vending a toll gate with a vehicle going through it to speeds up to 55 mph.
Now, to be sure, this is more the ACE/TAO people's doing, but there's NOTHING in CORBA
that requi
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Informative)
Trust me when I say this: CORBA for C++ is much worse!
I've tried both, and CORBA in java was such a relief from doing it in C++, I almost started thinking CORBA was sane, and only the C++ bindings sucked. The
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Insightful)
Re:What a ridiculous trend... CORBA to WebServices (Score:2, Insightful)
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
Re:What a ridiculous trend... CORBA to WebServices (Score:5, Interesting)
Your comment is similar to many of the other comments in this thread. You're right that the CORBA specifications are HUGE and overly complex. But here's one of the great things about CORBA: it can be easily 'subsetted'. I use CORBA every day. I use 10% of it's features, and it is beautiful. If you gave me an exam about the esoterica of CORBA, I would fail, but for the parts that my company uses, it's easy.
BTW, most of the huge CORBA spec that we ignore is stuff that isn't part of the SOAP spec anyway; SOAP isn't really comparable to CORBA, SOAP is comparable to IIOP (the most popular CORBA wire protocol). Saying that SOAP is better than CORBA because it's easier/simpler is kind of like saying that MS Works is better than MS Office because it's easier/simpler (no, that wasn't a great analogy, but at least it isn't an automotive analogy).
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Insightful)
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Interesting)
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Informative)
No, the ORB vendors should provide all of the spec'ed functionality. And to be fair, they tend to do a very good job at this completeness. As a programmer who uses CORBA (omniORB, ACE+TAO, and VisiBroker), I only *use* 10% of the features. I never use: POA interceptors, POA policies (hardly at all), Trading Service, AVService, etc.
There are a few features that are almost never implemented by
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Insightful)
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 usin
Re:What a ridiculous trend... CORBA to WebServices (Score:3, Insightful)
Like the article said, CORBA is a niche product for those who absolutely need it.
Re:What a ridiculous trend... CORBA to WebServices (Score:2, Informative)
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.
I think you're missing some standards... (Score:5, Informative)
authentication: HTTP Basic over HTTPS, or certificate based authentication over HTTPS
transaction management: WS-Coorination.
I mean, you can use WS-Security; WS-SecureConversation and all that XMLSecurity jazz, but frankly, why bother when HTTPS just plain woks? (You probably have to give up on the 'firewall friendly' approach of everything over port 80, but that is a significant step forward in my book.)
naming: I'll give you that. UDDI feels overengineered for what it's normally used for. On the other hand, why are you looking for a public UDDI registry? The Registry is essentially the single point of contact for a particular application; thus you normally would want to keep some level of control over it. On the other hand, for public acces web serivces, have a look at Xmethods (which does offer a UDDI query interface).
Oh, and I disagree that Axis is any good at all, especially not in performance terms. In fact, Axis 1 is the second slowest (and second worst) way of using SOAP (Axis 2 is the only thing worse). If you want something fast, try GSOAP and C++. (To elaborate: every call made with Axis is essentially a dynamic call, the 'compilation' just writes code to change the defaults. This is a very poor design if you want performance, as you can optimise a SOAP engine a lot if you know the schema at compile time - and I'argue that's the most common use case.
Web serivces have the potential to be approximately the same speed as CORBA, if they're not, look at your middleware.
Java RMI can always be faster, because it knows that the classes is needs are already on both sides of the wire or that it can get the actual class directly. That's not possible in a language independant system, where instead you have to give a description of the objects. Also, RMI can pass richer objects than SOAP can, (SOAP is can't pass objects with methods, just data holders). That allows for better architectures to be generated, also improving speed.
Re:I think you're missing some standards... (Score:3, Informative)
Because HTTPS only offers point-to-point security. If you need to encrypt or authenticate through a web service proxy (e.g. an ESB) you can't guarantee or prove the security of the document from point A to B to C. Also, SOAP can
Re:What a ridiculous trend... CORBA to WebServices (Score:4, Insightful)
WS-Security [coverpages.org], an OASIS standard [oasis-open.org] (like OpenDocument Format), has been around since 2001. You may wish to update your SOAP knowledge.
No: it's all about the APIs and who's making them available. Got CORBA bindings for Google? How 'bout the National Weather Service? If nothing else, people are publishing SOAP APIs that we actually want to use. That alone makes it much more interesting that competing RPC protocols.
Where comes the Sun ... ???? (Score:5, Informative)
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
CORBA could *easily* be revived if Sun finally grasped the revolution in the market and decided to do so. Will they? Seeing as
BTW
Re:Where comes the Sun ... ???? (Score:5, Informative)
Re:Where comes the Sun ... ???? (Score:3, Funny)
You must be really, really, REALLY new here.
Re:Where comes the Sun ... ???? (Score:5, Funny)
Re:Where comes the Sun ... ???? (Score:3, Informative)
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.
Re:Where comes the Sun ... ???? (Score:3, Informative)
I was learning CORBA in 1997. Alas, it was another Sun driven technlogy, like Java, before Sun understood how the technology landscape was changing.
Bullshit. Sun was pushing RMI by 1997. CORBA is a standard backed by the hundreds of companies that signed up to the OMG. (At my side are some NextSTEP developer manuals which I'm amused to see even have an OMG logo on them).
The only FOSS CORBA implementation that came anywhere close to implementing CORBA 2.0 was Orbit
Bullshit again. Go check out omniO
One man's simplicity... (Score:5, Funny)
Re:One man's simplicity... (Score:2)
Btw. EJB > 2.0 wasn't that hard, either. Just unconvenient in some places.
Re:One man's simplicity... (Score:5, Informative)
Early middleware was doomed (Score:5, Insightful)
Re:Early middleware was doomed (Score:2, Insightful)
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 (Score:2)
The parable of the two elephants (Score:5, Interesting)
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.
Phase Relationships in the Standardization Process (Score:4, Interesting)
Phase Relationships in the Standardization Process [archive.org], James Gosling, August, 1990. [see link for illustrations]
Toshi Doi of Sony describes the standardization process in terms of the diagram at left. The i axis describes level of interest and the t axis describes time. Ti describes technical interest, and Pi describes political interest. As time passes, technical activity declines as the technology becomes understood. Similarly, generally fueled by economic pressures, the political interest in a technology increases in some period.
For a standard to be usefully formed, the technology needs to be understood: technological interest needs to be waning. But if political interest in a standard becomes too large, the various parties have too much at stake in their own vested interest to be flexible enough to accommodate the unified view that a standard requires.
In this model, Ws is the `window of standardization' where technical interest is waning (i.e. the technology has become understood), but the political situation hasn't become too hotly contested for constructive negotiating.
This model has many interesting insights, but there is more complexity in the situation that can be explored. In the original model, the T and P curves are open ended. The situation is more like the diagram at left. These curves, Ta and Pa, represent technical activity and political activity. In general, technical activity precedes political activity. Both types of activity go through phases of different intensity. As these activities proceed, they produce results. The result curves are the integrals of the activity curves.
The integrals of these two curves are drawn at left. The integral of Ta is K (knowledge) and the integral of Pa is C (calcification - revealing a strong personal cynicism). Ss, the sensibility of standardization, is just K-C. The optimum time for standardizing a technology is when Ss is at a maximum, which will be in a region where knowledge is high, but calcification has not yet set in.
A very interesting quantity to observe is the phase relationship between Ta and Pa. When the maximum point on Pa follows the maximum point on Ta by a sufficient distance, there is a wide Ss window. A sensible standard can be fairly easily set since the political activity which leads to the standard has the necessary technical knowledge in hand when needed. If Pa lags Ta sufficiently, Ss will have a long high flat top, which forms a convenient table on which to work.
Consider moving Pa left, closer to Ta. When it is close to Ta, Ss will have a shallow and flat region where the upward slope of Ta matches Pa approximately. This region is the time of chaos. Before calcification builds up, there isn't enough knowledge to do anything sensible, by the time that there is enough knowledge, there's too much calcification to allow a sensible compromise to be reached. In between, the region is flat enough that there isn't a clearly defined optimum moment for developing a standard, so there is instead a drawn out period of chaotic bargaining and soul searching.
Consider moving Pa even farther left, until it is to the right of Ta. This is the worst case: Ss is always negative. The long flat minimum region is the time of panic where the political/economic process has decided that a technology needs to be standardized, but no one understands it. Standards get set by making random guesses that are not grounded in any technical reality, but are instead grounded totally on political expedience.
The case described in the previous diagram is impossible in practice. The very act of setting a standard inhibits technical activity
Other failures (Score:3, Interesting)
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 (Score:5, Insightful)
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 (Score:2)
I think you will find that quote is usually attributed to Albert Einstein not some Swiss guy.
Re:Distributed applications (Score:2)
Yet Prof. Wirth used it all the time even if he wasn't original author. I wouldn't be surprised if it isn't Einstein either. So while people get known to use a quote that never implies they've invented it.
I'm using the term "schitter bis bewölkt" (sorry German) on all possible occasions and if I ever get as famous as Einstein, people would certainly attribute it to me albeit I definitely can't reclaim authorship.
O. Wyss
Re:Distributed applications (Score:5, Insightful)
I just wish they'd create a C++ mapping that allowed for STL compliant sequences, and std::string compatibility...
never as simple Re:Distributed applications (Score:2)
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? (Score:2)
Wirth may have said it, but I think Einstein said it first.
Re:Distributed applications (Score:2)
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
Corba isn't dead! (Score:5, Funny)
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! (Score:3)
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 notic
Re:Corba isn't dead! (Score:2)
Seems like the only thing keeping CORBA alive these days is Gnome [gnome.org].
If I understand things right, it is a very fundamental part of the architecture, so it's not likely to go away any time soon.
Real reasons (Score:5, Interesting)
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 (Score:5, Informative)
Re:Real reasons (Score:3, Informative)
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
Re:Real reasons (Score:2, Interesting)
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 (Score:2)
Sorry dude I couldn't resist. This industry cracks me up sometimes.
Anyway, I feel your pain. I really do. NAT has been my nemesis all too frequently.
Re: (Score:2)
Re:Real reasons (Score:3, Insightful)
Right, so SOAP gets around this problem by reusing port 80 which on insecure networks sometimes has an unrestricted hole in the firewall already. In secure environments, you still have to put a new server in the DMZ whether it's port 80 your talking on or port 9001.
As for load balancing and fault tolerance, Websphere here load balances CORBA clients ov
Re:Real reasons (Score:2)
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.
I took a close look at CORBA and wrote this (Score:4, Interesting)
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 (Score:4, Interesting)
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
OpenOffice and GNOME use CORBA. (Score:5, Insightful)
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. (Score:5, Informative)
D-BUS [freedesktop.org]
Re:OpenOffice and GNOME use CORBA. (Score:2)
My system doesn't have D-Bus. Besides, according to it's own nearly-nonexistent docs, D-Bus doesn't have a stable API, so what would you code against ?
Re:OpenOffice and GNOME use CORBA. (Score:2)
Re:OpenOffice and GNOME use CORBA. (Score:2)
Re:OpenOffice and GNOME use CORBA. (Score:2)
So, kind of an embrace-and-extend of CORBA?
Re:OpenOffice and GNOME use CORBA. (Score:2)
More like an embrace-and-extend-arms-and-shove-as-hard-as-you can kind of way.
What it all does, and why Linux/Unix lacks it (Score:3, Informative)
What all these systems do is quite similar. The basic idea is this:
Scary... (Score:4, Insightful)
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 (Score:2)
I remember there was something called Bonobo...
Is that still going on, or was that just a fad ?
Re:Gnome and CORBA (Score:3, Interesting)
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.
Re:Gnome and CORBA (Score:4, Informative)
Fortuneteller's Orb (Score:2)
Open/Closed argument (Score:4, Insightful)
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.
CORBA and DCOM too buggy for the real world (Score:2, Insightful)
What's in a name? (Score:4, Funny)
Calling themselves "OMG" probably didn't do much to encourage adoption.
I hate to not bash MS on /. but... (Score:5, Insightful)
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
Re:I hate to not bash MS on /. but... (Score:4, Informative)
CORBA, on the other hand, is heavily used in telecom, aerospace, financial, and high-performance, realtime scientific and control applications. Check out Doug Schmidt's TAO [wustl.edu] if you want to see what complete free, open-source CORBA can do. And stop bothering us with MS's abortive attempt at the same.
Horrible, just horrible! (Score:5, Interesting)
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.
Re:Horrible, just horrible! (Score:3, Insightful)
Too many features; expressly obscure (Score:3, Insightful)
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 (Score:3, Insightful)
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
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
-Anon.
(I have no association with ZeroC, by the way.)
Not as bad as all that! (Score:2, Informative)
CORBA is alive and well in TAO (Score:3, Informative)
Yeah, it's got CORBA's steep learning curve, but once you're there, you can write distributed systems that perform much better than any web service platform will ever perform. It's FOSS, completely free for any use, unlike Michi Hennigs' ICE. I respect the hell out of Michi. I love ICE, but Zero-C's commercial usage fees are way too high for me to consider for any of my company's efforts. So I went back to TAO for my distributed computing needs and I'm as happy as can be.
XML-RPC (Score:2)
I coded a distributed application (a word game) with XML-RPC for a client some years back having been given the choice of language and communications option. I looked at SOAP at the time, but used XML-RPC as it was very simple to implement with a straightforward A
CORBA is like SDI (Score:2)
Hey, I've hated CORBA/OMG/DOE at least since 1992, so I really loved that article. The author hit the nail on the head!
From: Don Hopkins
Date: Sat, Feb 27 1993 4:17 am
Email: hopkins@cs.cmu.edu (Don Hopkins)
Groups: comp.object
Svante Kleist (etxs...@garboa03.ericsson.se) wrote:
Well, there was the Strategic Defense Initiative (Star Wars), but they kin
Boneheaded sysadmin port blocking (Score:4, Insightful)
Correct me if I'm way off base here, but it seems like the following happened with regards to ports:
Clearly, blocking ports selectively is not a sufficient security measure, but being able to block services based on the ports they use is a handy tool to have in the armoury. Isn't it? And isn't it one we've thrown away because sysadmins have been to anally retentive?
Re:Boneheaded sysadmin port blocking (Score:3, Informative)
On the ports, the biggest problem was applications (not necessarily the corba orb - don't remember from my one project with it) wanted a range of ports rather than a specific port. Had we been able to say port 4567 or something like that, our security folks would have been more than happy to open up the firewall a bit. Many of the product we were wanting to use would try to use ports 3000-4000 or something silly like that
CORBA v ICE (Score:3, Interesting)
As for complexity, SOAP is heading the CORBA way, thanks to Microsoft, IBM et al. SOAP has lots of interoperability problems btn languages, Java and Perl for example.
You could use xml-rpc but most of the implementations are brain-dead, and unusable for complex apps.
If you have to go btn two languages, just use sockets.
CORBA in embedded systems (Score:3, Interesting)
Thanks to Moore's law embedded systems have grown up enough to use CORBA. I know this because I work on a project [nasa.gov] which uses CORBA heavily (at least in the TAO [wustl.edu] and JacORB [jacorb.org] incarnations). Since CORBA has strong typing, it is attractive to developers who depend heavily on typeness to provide checks in systems where no one likes bugs. And really, who wants to write another middleware to deal with distributed systems? I sure don't.
There is no disclaimer in the article so I think it is worth mentioning that even though Michi was CORBA for all intents and purposes for a number of years, his current employer [zeroc.com] provides a competitor [zeroc.com] to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article [zeroc.com].
To be fair ZeroC and Michi do put their money where their mouth is by supplying Ice in source form, licensed under the GPL. Although I do not see them putting this in front of a body like the IETF or trying to get Ice bindings integrated into something like boost. This would really attack that one point in the article talking about having real systems implemented and having it in front of a standards body.
Now that I have put in the proper disclaimers, I have to say that having used CORBA the last 5 years I agree with Michi on every point. Our knowledge of POAs is just now getting to the point where we are comfortable using it in complex ways. We are only now willing to entertain the notion that we are actually using CORBA the right way. We have spent weeks reading, coding, recoding, testing and testing again to understand the spec and the real world usage. The learning curve is easily the steepest and tallest of any technology I have had to learn. I said "Amen" out loud when Michi mentions that people really screw up when they don't do it right.
Using CORBA as a real distributed object system is not possible unless the system is in a network that you have complete control over. Even now we use cumbersome workarounds to develop our system remotely because we can't use CORBA like we were supposed to. Thank you very little script kiddies for making us use firewalls every where! But if CORBA had been built with security in mind in the beginning at all, it would be vastly more useful then it is now.
And we have not moved on to things like Web Services precisely because we do not want to move away from type checking and we can see the train wreck associated to security. So we use CORBA the best we can (and we have been largely successful, BTW).
Now I am going back to checking whether try blocks have been done properly for the naming service code we have to implement because of the exact reasons Michi says most implementers need the CORBA naming service.
Re:zeroC ICE (Score:2)
Re:good technologies left behind by stupid mediocr (Score:3, Insightful)
And therein lies the problem. A lot of these ivory tower academics have
never worked in the real world where there are things known as deadlines,
costs and "lots of work". Ie , people don't have a few weeks free to kick back
and learn a highly complex API. They need to be able to learn it on the fly.
And if the API is over complex and over engineered thats not going to happen.
What? (Score:2)
Re:Biased opinion from Henning (Score:4, Informative)
Correct--I decided to do something better than CORBA after slaving my guts out for seven years trying to make CORBA better, and largely getting nowhere. Eventually, I realized that there was only so much sh*t I could push uphill and decided to focus my efforts on something more productive.
> The concepts like the POA are too over engineered, but the underlying ideas of language neutrality, a simple interface definition language and a common wire protocol have not been bettered.
I beg to differ. The CORBA POA interface requires over 200 lines of IDL definitions when, in fact, I can provide all of the functionality of the POA, plus some extra, in just over 30 lines.
Yes, language neutrality is a good idea. No, CORBA IDL is *not* simple, not by a long shot. (Look at the last section of the Slice chapter in the Ice manual for some of the reasons.)
IIOP is a very poorly designed protocol that has more flaws than a dog has fleas. Among them a quite major one that prevents efficient implementation of notification services. (See the Ice manual for details.)
> One area where CORBA is particularily useful, is in event or notification based systems.
The CORBA event and notification service are interface nightmares, and cannot be efficiently implemented due to design flaws in IIOP. (See http://groups.google.com.au/group/comp.object.cor
> Most recently, I used CORBA to replace a SOAP based system. Compared to SOAP, the CORBA based system was faster, easier to work with and far more reliable.
I don't doubt that. It's very hard to beat the ineptitude of SOAP and WS. Now, if you had used Ice to do the same thing, you would probably have done it in half the time, with half the pain, and twice the performance
Cheers,
Michi.
RMI is better, in a Java-only world (Score:3, Informative)
Actually, the ability of RMI to depend on a common code execution on either side of an RMI link (at least when using JRMP, the original wire-level protocol for Java-to-Java RMI) means you can do a good number of tricks that you can't easily do with CORBA. You can pass classes (not just objects) from JVM to JVM. You can operate with distributed garbage collection and multithreading out of the box. You never have to worry about whether your native Double class has the same representation and semantics as t
Re:interop killed CORBA (Score:3, Informative)
No
Yes. We use Java for our clients, and C++ for our servers. Works great on Linux, HP, AIX, Windows, and Solaris with very little cross-platform issues. Your assertion that language interpoerability failed is incorrect - it works as designed and works well.