Slashdot Mirror
The Rise and Fall of Corba
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."
1. OMG Stable
2. ???
3. OMG Ponies!
Was hoping for an outline of Cobra Commander's long list of failures :(
Aw Frell this
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?
Let's do SOAs based on WebServices. Right now, right here.
... and so on, and so on...
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.
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
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
My exception safety is -fno-exceptions.
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.
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.
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.
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
See http://wyoguide.sf.net/papers/Cross-platform.html
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?
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.
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.
hilarious
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.
Why I think CORBA and other forms of RPC are a bad idea.
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.
Need a Python, C++, Unix, Linux develop
zeroC are developers of a CORBA alternative called ICE, evidently better in all possible ways, it's GPLed so it must be good.
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.
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.
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 ?
RTFA. COM is microsoft only, and only an idiot would lock themselves into license hell.
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".
--
make install -not war
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.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
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?
Please use [ informative / summarizing ] SUBJECT LINES
Flame me here
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.
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.
Oh, I can't help quoting you because everything that you said rings true
"Make everything as simple as possible, but not simpler"
Wirth may have said it, but I think Einstein said it first.
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.
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.
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 ?)
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.
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...
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.
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.
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.
Corba is too complex and slow. redFox from redPlain is lighter faster better than Corba implementations. Check it out at http://www.redplain.com/ or read about it in Embedded magazine Jan 2006 http://www.embedded.com/
> focusing specifically on the OMG's technology adoption process itself.
Calling themselves "OMG" probably didn't do much to encourage adoption.
Sheesh, evil *and* a jerk. -- Jade
COBRA, they could have had COBRA - now that would have been a cool technology!
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
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 ?
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.
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.
Religion is what happens when nature strikes and groupthink goes wrong.
From an OOP point of view CORBA's core architecture is basically very, very good.
/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!)
/USUALLY/ the case-- crap?
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.)
CORBA is hard, it really is - but it's not impossible to work with. When CORBA started, the distributed development world was hugely different to what we have now - there were very few code-generation tools at the time. It was originally C++ and the Java mapping never really took off. However it was the seeds of the J2EE movement that came after it - read the EJB 1.0 spec and you can see the influence of CORBA on it. In fact, I seem to remember that it mentioned that CORBA should be used to handle persistence. (Which is bizarre, as the OMG persistence specs were always terrible, and the implementations worse). Things have changed though, and the whole web/firewall/security issues did kill it off in front-end situations (anyone remember CORBA Applets?). However, it's still alive and kicking deep inside in telephone networks, aviation industries, stock brokerages and much more. It'll be decades before the existing applications are removed. I still come across sites that have a CORBA infrastructure playing some part of the Middleware architecture - and working well for years. Bad? Maybe, but it works.
Well, I did not see CORBA working for anyone here.... I am sharing my experience working with CORBA and c++.
:)
I work for a Telecom service provider, and we have been and are using CORBA for the past 6 yrs and I tell you that CORBA rocks, at least for us.
We have convered some transcations to webservice call (because of some verdor requirement) but the response time really sucks.. it changed from 4ms to approximately 400ms.
We serve 28Mi+ customers all the transcations go via our CORBA Bus and it rocks...
tchau
Where almost no one can see it, lies a big bunch of corba code.The only problem is that the guys reinvented partt of the wheel, so is only 90% corba.....
So long for the memories
*** Suerte a todos y Feliz dia!
it's the same story repeating over and over again, you have a consortium or forum or simply a bunch of smart guys mostly university based people writing long documents inventing a new techonolgy and backing it with a standard. than you have Joe Doe which finds it too complicated or you have a company not willing to pay an expert so everyone is happy when a simpler technology arrives. the simpler techology runs into problems later on but who cares, the learning curve is not as steep. so the bad technology wins in long term. here sad examples (I was always on the loosing side and am proud of it):
CORBA->SOAP
H323->SIP
HyperLAN->WLAN
ATM->Ethernet
DiffServ->IntServ
C++ -> Java
Y'all talk about CORBA as if it were really dead. Hello? Check out Doug Schmidt's The ACE Orb (TAO). Can you say high performance FOSS distributed computing platform, in use in some of the most demanding of applications and demanding environments in the world?
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.
encryption: HTTPS
.NET web services are about 2 or 3 times faster than Axis, from our benchmarks (which did use stateful web services via WSRF, but I don't believe that distorts the timings apprechiably.) GSOAP is about 5 times faster.
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.
WS-Security, an OASIS standard (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.
Dewey, what part of this looks like authorities should be involved?
"mostly university based people "
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.
Have you ever developed web services? For the most part, it's even more complex. WSDL is more complex than IDL, for sure. Interfaces in WSDL often have to be awkward because they lack object orientedness. Callbacks are a real pain in the neck using SOAP. Performance sucks. Large objects suck. And as someone else said, SOAP is struggling to provide standards and features that were mature in CORBA for years.
.NET, that make developing web services a breeze.
There are some environments, such as
The author has some good points on why we as an industry moved away from CORBA, but SOAP and web services are even worse in my opinion.
The Internet treats crud as an obstacle and routes around it. CORBA - haven't heard that name in a long time. It was so inhumanly complex that even though I had a book where little cartoon aliens tried to explain it to me, I blinked a few times and moved on to something else. CORBA came from a time when the technology industry had a lot of really complex crud like IBM's Visual Age platform, Standard C++, CORBA, etc. It was collapsing under its own weight. All this stuff might have been technologically superior, but it was difficult to use and no one used it and now we've got Linux and much simpler development environments. None of this complex crud ever got any traction.
I always had the impression that nobody at OMG had ever worked on a real system in a real environment.
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 without any architects/managers loosing face.
Currently the only widespread use of CORBA is as the transport for J2EE, and yes they use a single IDL
not too far removed form the one above.
Old COBOL programmers never die. They just code in C.
Is XML-RPC still in use? The Wikipedia entry says it has now evolved into SOAP, which if I remember correctly from the last time I used it is not true as they are different, albeit closely related, protocols and SOAP is not a superset of XML-RPC.
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 API I was up to speed with in a day or two, and it did what was required of it perfectly.
As someone who was worked in both, rather that the position you outline, in my experience, it is the case that in the "real world" more people are more stupid and therefore take longer to learn things.
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 kind of cooled it on that once Reagan was out of office.
-Don
Take a look and feel free: http://www.PieMenu.com
You do appreciate the different concerns adderessed by CORBA and LAMP don't you?
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).
Censorship is telling a man he can't have a steak just because a baby can't chew it. --Mark Twain
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?
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
I quite agree. I know performance and features matter, but surely even the zealouts can start to realise that ease of use is just as important. There seems to be a prevailing attitude in some environments that if you can't get it to work you must be stupid. Man, that's annoying.
One of the measures I use a gauge a new tool is whether it behaves how I would expect *without tweaking* and without needing to refer to the documentation. The idea of thinking "if I do this, maybe it will just work".
This might sound like an ambitious criteria: expecting the developer to read your mind. However, with good tools it occurs more often than you might think. Two examples of this: Python, the language where you can often guess how the arguments to library functions work often without needing to look them up, and the editor NEdit, which just seems to always have its options, features and windows in the right place and behaving as I want them.
Of course, make sure the backend is sound as well, but this out-of-the-box usefulness will win you a lot of friends.
Oh, and in the documentation: examples. Loooots of examples.
Peter
Good thing I never bothered to learn it then.
OMG!
Or maybe they have work pressures that preclude them from doing so. Its very
easy to be a student with very little work to take time out to learn something.
I was an MSc student once and compared to the working world university was a
walk in the park.
I read that headline too quick and was expecting an indepth discussion of GI Joe's arch nemesis. Man, I need to stop drinking in morning!
Sig
Appended to the end of comments you post. 120 chars
Oh, this is about software, nevermind.
I don't think CORBA is dead. I think CORBA just didn't become ubiquitous.
There have been (and will continue to be) many great technologies that have impacted/will impact software in an ongoing basis. Actually, CORBA serves as a great example of how things often work in the software world: a great technology is introduced into the software development world; the development/design world tries to work with it; it makes it as a viable technology or becomes a niche widget/system.
What's positive about CORBA (and GIOP/IIOP)? A great many of us loved the bright and shiny aspects of it, jousted with its windmills, and learned a great deal about cross-technology, cross-language, cross-everything runtime communication/collaboration/data exchange. I sincerely think CORBA made subsequent technologies much better (than they would have if they had been introduced first). In my opinion, similar things like RMI and web services/SOAP-based technologies are clearly easier to understand, implement, and deploy - largely due to many of the lessons learned with CORBA.
A Passionate Independent Musician
Back around 1990-1991, there were also a bunch of HP and Apple people involved with OMG. Some of the HP people migrated over to Sun, and tricked Sun into starting Project DOE (Distributed Objects [Practically] Everywhere).
Michael Powell was "Mr. DOE" at Sun. Before going to Sun, he worked on a Modula-2 compiler . He thought C++ had a really beautiful object model ("once you get past all that other stuff"), and didn't think anybody could understand Lisp (and didn't want anything to do with it). Nobody in the company actually knew what DOE really was but Michael Powell, so if you wanted to know, you had to go ask him, and he'd tell you what he thought you wanted to hear at the time, because he hadn't ever bothered to write it down. That was how he consolidated his power and kept a grip on his position as the architect of DOE, because nobody could pin him down about anything. So after years of development, DOE was so late and bloated that Sun finally released it on *TWO* CDROMs (unheard of at the time).
Arthur van Hoff (who previously developed HyperLook for NeWS, and later wrote the Java compiler in Java, and founded Marimba) didn't think DOE was usable, so he sat down one day and rewrote a tiny version of DOE from scratch called "DOE-Lite", which everybody in their right mind used instead of the official bloated DOE release. Arthur then proceeded to use DOE-Lite to make a distributed object trading demo which Sun demonstrated on the show floor at Object World. Ironically, he implemented using the (then canceled) NeWS window system, instead the officially sanctioned DOE user interface toolkit (because the official DOE gui was vaporware).
Sun put a lot of different colors of lipstick on that fat old pig, DOE: they renamed it "NEO", and then they tried to pawn it off as a back-end to OpenStep (NeXTStep, which they later gave up on), and eventually they tried to imply that it had something to do with Java.
I'd love to know what happened to DOE architect Michale Powell since his reign at Sun back around 1991! (No he's not Colin Powell's son, head of the FCC.) Had anyone heard from Michael Powell ever since? Where is he now? Does he have anything interesting to say about what went wrong with DOE?
-Don
Take a look and feel free: http://www.PieMenu.com
For encryption most web services use HTTPS to make sure everything is encrypted. It's already built, and we know it works well, why try to build something new. On the other hand, web serviecs took over because of the web. It's much easier to just send an HTTP request in XML, and parse the XML you get back. I did some CORBA work in university, and just doing something simple like getting the server to send back Hello World required a more work than it should. Everytime you changed the server side code, you had to copy files to the client box so they could run the code. This wasn't too much of a problem for a university assignment, but imagine doing this with 100,000 clients connecting to your server. Making sure everyone had the same interface files (on development and production boxes) would be a nightmare.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I am sure the author of this article is a fine individual ... however I am serious forced to question is opinions.
CORBA is far from dead ... CORBA is in fact mandidated for use in every radio used US miltary, coastgaurd etc by 2010 (I believe). One only has to google for JTRS and start searching the links for SCA (the standard being used). And this is just the icing on the cake.
CORBA itslef is a enormous overhead saving tool ... I have worked with far to many engineers that want to design there own msg'ing system between processors and devices ... without CORBA you are simply re-inventing the wheel. The CORBA community has already made its mistakes and corrections.
And as for his assesment of the individuals contributing to the standard ... well he could not be more wrong ... these people are highly qualified/knowledgeable individuals building real systems and using CORBA to build real systems ... nothing is added to the CORBA spec ad-hoc.
The biggest problem CORBA has with its addoption is its foot print size in embedded systems ... however thanks to modern memory sizes this is no longer a problem ... so in my humble opinion the author needs to wake up and jump back on the CORBA bandwagon ... otherwise he can go sit on his own and re-invent CORBA's past while CORBA moves on with life.
Rant over :-)
Others have recognized CORBA's shortcomings much earlier. The Common Component Architecture (CCA) specification http://www.cca-forum.org/ provides a slightly better blueprint for distributed coordination; now if we could just get a good implementation of the spec...
How about saying a paved road is better than a dirt bike? :)
COM is not related to CORBA. Perhaps you meant to say DCOM?
Besides, CORBA is cross-language. Thats its unique feature.
DCOM: Windows Windows
RMI(Java): Windows Linux Macintosh
CORBA: Java C C++ etc..
Note: MS may have renamed 'DCOM' once again. I been off windows exclusive programming a while so I'm not sure. I think maybe its ActiveX now!?
CORBA has the approach that OSI had. Having little connection with grass-roots and being heavily driven by committees that are filled with academics and corporate suits wanting to make a name for themselves. If you want a good model for developing technology you can't look much past the IETF and a whole lot of successful open source projects. Oh and once you start charging an arm and a leg to see standards and the like it loses flavour real quick.
Hennings opinions should be taken with a pinch of salt. While he co-authored the bet known book on CORBA, he has since left the CORBA arena following the merger of his own company with IONA, and is now pushing an alternative technology called ICE.
As for CORBA? 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. SOAP has an awful interface definition language based on XML, and is also dependent on XML in many other areas, despite the high overheads of parsing the format. SOAP also suffers from using HTTP as it's primary transport, as this is also highly inefficient. RMI is a great solution for end to end Java systems, but forces a reliance on a proprietary third party bridge if it needs to be intergrated into a non-Java environment.
One area where CORBA is particularily useful, is in event or notification based systems. These standard services offer the same features as Java JMS, but also benefit from a standard wire protocol and standard mappings for languages other than Java.
Overall, CORBA's demise seems to be greatly exagerated. It's not a fashionable technology, nor it is perfect. However, it provides the glue between many systems in organisations such as banks, warehouses and media organisations that no other technology could adequately fill. A number of companies are making a very tidy living from consulting both for their own CORBA implementations as well as open source ones such as MICO and omniORB.
I can speak from personal experience as someone who has successfully used CORBA both as an RPC mechanism and an events system at my last two employers. 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.
If CORBA is any better than COM, then instead of using CORBA, why does Mozilla develop and use XP/COM, which is an open source cross platform clone of COM?
COM and XP/COM have their limitations, but COM is actually very nice for what it's designed to do (which is much less than CORBA is designed to do). But DCOM (Distributed COM) is a lot more than basic COM. The more appropriate comparison is between CORBA and DCOM. And also there's IBM's SOM (not distributed, like COM), DSOM (distributed, like DCOM), and OpenDoc (a component system, like OLE). But Microsoft has moved on from DCOM to web services and SOAP. Which is the point of the article. And that doesn't suck. I'd call it progress.
I wouldn't give up on COM (and its derivitives like XP/COM) -- they're still great for non-networked integration. But I gave up on CORBA and its ilk, a long time ago.
I'm disappointed that Apple has reverted to the circa-1986 NeXTSTEP window system (Cocoa), instead of continuing their pioneering efforts with HyperCard, OpenDoc, CyberDog, Smalltalk, etc. Why can't you flip any Cocoa application into edit mode, then modify, remix and script its user interface, just like good old HyperCard?
Cocoa's tired old NeXT interface builder seems like such a huge step backwards from the wonderful world of dynamic end-user-editability and plug-together components that users could build and customize at run-time, which Apple delivered with HyperCard, and promised with OpenDoc and CyberDog, before canceling those projects (and others, like Dylan, Sk8, ScriptX, etc).
Apple (and IBM) developed all this great component software stuff, then abandoned it for a rehash of something that seemed great in 1986, but is seriously behind products Apple already shipped. A lot of wonderful stuff has happened since NeXTStep was designed, but Apple's still stuck with the same old obsolete 1986 architecture, just appealingly renamed Cocoa and polished up with shiny graphics.
At least IBM kept their eye on the ball, developed Eclipse, and made it open source. IBM's stroke of genius was to name it something that pissed off Sun, so Sun wouldn't participate in the project even though they were invited. Sun missed out on all the good karma and fun and credibility and happy developers, because the name "Eclipse" got between Sun and their customers.
-Don
Take a look and feel free: http://www.PieMenu.com
A few corrections:
Both COM+ and CORBA support multiple languages.
RMI isn't Java's answer to CORBA, EJB is.
As far as I can see all that happened to CORBA is that people built abstractions on top of it so, if you need it, you don't have to learn the CORBA stack yourself. In the Java world, for instance, EJBs use the RMI/IDL CORBA subset for their distributed object model, and use the Java Transaction Service (JTS) which is based on the CORBA Object Transaction Service (OTS). Java IDL includes a CORBA Object Request Broker (ORB) that is available in every deployment of the Java Platform. GNOME uses CORBA internally. Quite a lot of shrink-wrapped web software uses CORBA internally (BusinessObjects WebIntelligence for instance).
Marshall this, marshall that. IDL IDL IDL. ORB. WTF. It really was a huge pain in the ass.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
I really like that word you coined: zealout. Sounds like a cross between zealot and sellout, which may be part of the reason for some of the problems with CORBA.
One of the problems with SOAP and WSDL is that the standard is incompletely specified. Try connecting .NET with, say, BEA's autogenerated WSDL. An element such as:
.NET side since MS insists on trying to instantiate a primative but has no data to use.
<xsd:element type="xsd:int" name="myInt" minOccurs="0" maxOccurs="1"></xsd:element>
is perfectly legal WSDL. But BEA sends this as an empty element if there is no data which will generate a null exception on the
CORBA seems complex in many ways because the OMG went to great lengths to make their specifications complete enough to avoid this type of problem.
On another note, much as I respect Michi Henning, there are definitely well designed and very solid CORBA ORB and service implementations that have made it fairly easy to build C++ CORBA objects. And they are open source, to boot. Just because IONA failed so miserably (their marketing folks were real dicks), does not mean that others didn't do it correctly.
FreeSpeech.org
RMI was out years ago when CORBA was first out. EJB is more recent by comparison.
Note in my post that RMI is platform to platform (through Java) whereas CORBA is language to language. These are different objectives. Thus, they are not 'direct' competitors with each other.
If you don't need language to language object exchange, why would you use CORBA? You'd be putting in a lot of work to get a primary feature that you had no intention of using.
EJB does not compete directly with CORBA. Its a more MS style approach. J2EE tries to offer a complete system such that you dont need to use any other technologies/languages and thus there is no need for interoperability and no need for CORBA. It does not replace CORBA, it replaces your whole system.
This is a shift in Sun's approach from years ago when CORBA was first here. Then Sun wanted Java interoperability, today I'm not sure they care.
I wonder if there is a virtual graveyeard out there of standards that never really took off or that died. Token Ring? X.400?
Can a standard that has only poor tools or kludgey tools every really become popular? Most of us are mere mortals, not so well adapted to strange code formats that belong to a single standard. No, this is not just hypothetical. Years ago, I did a bit of programming using IBM's System Object Model (SOM) under OS/2, using IBM's programming tools. What a mess!! Software development is expensive enough already without having to delve into arcane programming paradigms.
My observation on the software industry is that when an idea is floated around enough (distributed programming) a software engineer will develop a protocol and then programmers will start to use it and then designers start to incorporate it. Then the designers will start to demand the functionality plus some enhancements and then the programmers will change/re-create/enhance/copy/simplify the protocol.
That's how we go from CORBA to SOAP to REST and back to "SOAP-like". The original protocols are created in a time when it takes a lot of for-sight to guess what will be needed because there are so few apps that demand it. As programmers start to identify what can be done with the protocol, designers start to require enhancements that the original protocol was never designed to handle and ignore a great deal of what it was meant to handle. The programmers start to hack the protocol, maybe creating a new one in the process.
When designers can grasp the functionality, or better yet, demand new features, the protocol becomes App-driven rather than engineer-driven. This tends to limit the extensibility, but greatly simplifies the protocol which leads to further adoption.
The reason why CORBA is "dead" (with the exception of legacy code and legacy programmers) is that it was an early protocol that was engineer driven and relatively complex. Contrast that with REST (which gets a lot of play as a web service thanks designer driven protocols like AJAX) which is such a basic inherent part of web application development that it barely deserves a name of its own.
-CF
Phase Relationships in the Standardization Process, 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
Take a look and feel free: http://www.PieMenu.com
No: it's all about the APIs and who's making them available. Got CORBA bindings for Google? How 'bout the National Weather Service?
Slightly tangential to your comment, but the weather channel (http://www.weather.com/), use the CORBA Event Service as the heart of their system. According to a posting on the MICO mailing list by one of their developers, the system scales to millions of events an hour.
I'll second the thrust of the parent - I've used Ice, and find it 'easy' (as these things go), reliable, and fast (even the Java version). It takes the simple idea underlying CORBA (ie IDL describing remote interfaces in an implementation-language-neutral fashion), and implements it well with an adequate but minimal-ish amount of supporting services.
Very highly recommended for folks looking for a multi-language distributed object framework.
"Note in my post that RMI is platform to platform (through Java) whereas CORBA is language to language"
Actually CORBA is both language to language and platform to platform. As long as you can invoke methods on components remotely, it's really irrelevent whether the client and the component are written in the same language.
Correction: DCOM runs on both Windows and OpenVMS. You can write code in any supported language on OpenVMS to chat DCOM to Windoze clients.
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
The article indeed provides a good overview about what is wrong with CORBA. It left out a few additional aspects. For example, that CORBA never delivered the magic that was promised.
...).
One such magic was that legacy-systems never intended to work together could suddenly work together. "All" one was supposed to do was to add CORBA interfaces to each such legacy application - turning their services into distributed objects.
Then they should to work together!
How was that supposed to work? By using (magic) meta-data. Enough meta-data and services everywhere, so one application could discover another, automatically guessing what that other application's distributed objects were good for, and start to use them for whatever purpose. Oh, and not just any kind of meta-data would do, no, it had to be "horizontal-vertical-metadata" (today"s wisks would call it something like "360 metadata". The blurbs change, then words remain meaningless
But CORBA promised more. It promised nothing less than fixing the software crisis once and for all. Nothing less than that. Fixing the software crisis. On all levels. CORBA was not only targeting anything up and including to the Enterprise level. No, it was reaching out for the Global/Industry level on which it promised to fix things. How? Well, by enforcing architectural integrity on Global/Industry level. Which was another great joke. A technology with an own architectural integrity similar to that of jelly-o claims to be the right technology to to enforce architectural integrity.
More jokes? Sure. CORBA promised to be infinitely and infinitesimaly scalable. It promised to be great for even the smalles non-distributed object and class up to the big global distributed application. Of course it didn't deliver. It had and has too much overhead for non-distributed objects, it had and has too much overhead for distributed, fine-grained objects, and it had and has not the means to represent a huge application in a reasonable way.
CORBA barely works and doesn't deliver. It's that simple.
A standard that is too broad is no standard at all. For instance, I could define a "universal language standard" that encompasses C++, C, Java, C#, D, Smalltalk, Lisp, Algol, Fortran, and S/360 assembler code. Now how dumb would that be? CORBA dumb, it seems.
The big problem with IDL-based RPC is that it becomes essentially impossible to version your APIs. Want to add a parameter? You break a bunch of existing clients. These problems dog you everywhere you turn: In development (changing the IDL usually means a complete rebuild), in testing (got all your client versions lined up?) and especially deployment to outside customers. IDL based technology just sucks rocks when you're shipping real applications.
SOAP is a step in the right direction, but its overblown, bloated syntax and lack of a concise binary representation makes it look more like a practical joke gone out of control. ("Oops, they believed it!"). COM got around this by making it easy to version interfaces (but you still have to decide when to assassinate the old versions).
I was part of a start-up in the mid 90s that had most of these things solved. A 166Mhz server could easily keep up with several thousand clients (we were limited by the efficiency of the host's TCP stack). These days, the thought of having to parse XML in order to forward a message is only a little less horrifying than the tower of OMG-how-much-more-complex-can-this-possibly-get that CORBA was . . . shudder.
People hate APIs. Complex syntax or calls that you have to totally understand in order to get your job done will mean that the software in question will sit on the shelf. Simplicity is where it's at. This is CORBA's fundamental reason for failure.
Any sufficiently advanced technology is insufficiently documented.
For all its faults, CORBA does fill an important niche. As far as I know it is the only communication technology that features:
High Performance (implementation dependent, of course)
Language Interoperability (standard language bindings)
OS Interoperability
CPU Interoperability
Vendor Independence
Object Orientation
Healthy Open Source Community
I think we can agree that these are good things to have.
There are a number of caveats, though:
CORBA works best when you have tight integration between the client and the server. The more you try to put between the two (e.g. the public Internet) the more problems you will have.
There is a good bit to learn to be able to design and build a CORBA-based system, from basic concepts to language bindings. Once you have it down most of it makes sense, and developing new applications can go fairly quickly, but it does take a while to get there. You might want to try starting with a Python ORB, since it is a lot easier to use than C++ or Java ORBs, and you can use Python later to build tests for your C++ or Java code.
You have to ignore a lot of stuff. The bulk of the CORBA services out there aren't really useful; stick to things line Naming, Notification, and Trading. Some features like valuetypes are a pain to support, so are better ignored. CCM might be worth something eventually, but it would require really good vendor tools support, and it is better avoided for now. You can get by pretty well with the concepts in Henning and Vinoski's book, "Advanced CORBA Programming with C++".
Interface evolution needs to managed carefully, since IDL is generally more rigid than XML.
These caveats make CORBA inappropriate for a lot of projects, no question, but for those projects which have performance and interoperability requirements which match with CORBA's feature set, it is worthy of consideration.
CORBA was a great idea implemented complexly. People don't like complex.
Interesting point because it reminds me that even geeks, not just Joe Sixpack, reject complexity. Cases in point:
Remember SGML and X.500? Complex standards that have been completely upstaged by their darling, "dumbed down" children, XML and LDAP; to the point that the ancestors are all but forgotten.
Hey! we'll always have sockets
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 the equivalent class on the far side of the RMI link. You can pass any arbitrary object to the other side of the link and know that it will be reconstituted properly, without having to re-do parts of your design in IDL.
RMI is tragically flawed by its limitation to the Java environment, but within that environment, it is a superb solution, providing simple and flexible support for distributed object systems. Want security? Wrap your RMI communications in SSL and turn on cryptographically random ID codes for your distributed objects. Want the ability to penetrate firewalls? Encapsulate your RMI calls in HTTP. Want to have your software automatically bounce from system to system? Java's ability to transparently pass serialized remote object references makes it a snap.
As the article says, CORBA was crippled from birth by its creators' insane idea to deliver a set of castle-in-the-sky specs without testing them out with actual implementations. CORBA 1.0 couldn't even speak from ORB to ORB over the Internet, for pete's sake.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
And as part of the infrastructure for the bloated and slow GNOME desktop environment.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
When I used TAO, it just all snapped together. Minimal noise. No goofy setup, etc.
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 requires all the noise that you typically see with other ORB implementations. And
CORBA's neither slow nor cumbersome- it's all in the ORB implementations. Of which, many
just plain flat suck.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Anyone here ever REALLY try to use CORBA across languages and platforms? ... seriously, using something besides Java on both ends.
... yeah, BONED.
... if you want to build your own, it's completely within the realm of possibility.
No
C? sorta okay, as long as you use C on both ends as well as the same ORB package.
PHP? you're boned.
Python? you're boned.
Perl? there were some early weak attempts but pretty much, you're boned.
Javascript? uhm
So, wonder of wonders, an architecture for WEB SERVICES failed when it turned out that it was basically impossible to use with the most commonly used TOOLS FOR BUILDING WEB SERVICES.
CORBA was a really, really brilliant idea, but it's major failing was that it's core promise of interoperability across languages just never really paned out. Sure there were language mappings for a half dosen languages or so, but they never EVER worked together the way they were supposed to.
SOAP is to CORBA what LINUX is to SOLARIS. It's open, it's fairly easy to understand compared to it's counterpart, and while you can buy SOAP libraries, it's all there in the XML
More than anything, I think the fact that when things get really broken, you can always dump the raw XML to have a peek at whats going on is why SOAP has been more widely adopted.
You didn't NEED to get the IDL on all the platforms.
1) The IDL's only useful for making the interface skeletons. If you needed that, you had a pretty twisted ORB.
2) I think you're referring to the IOR which is a reference to the remote object so the ORB can find it.
3) I will believe the IOR "problem" being obnoxious- it was evil in CORBA v.2 and prior implementations, for version 3, however, you could use iioploc:// type URI's for the same thing, and if your ORB properly implemented things, if you are on the same network subnet you didn't even need that as there's a magic IOR to feed into the load up to bring in the local NamingService which simply makes everything totally plug and play. TAO offers BOTH.
In my case, I've experienced the opposite thing. No IDL issues. No need to plug in IOR hex number sets. Only the rare, occasional iioploc:// invocation to the NamingService because we weren't on the same subnet and had to go through a port-forward on a firewall. It's all in the ORB implementation- and most of the ORBs just stink on ice.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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?
Use an interface repository
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. Therefore I'm very happy for your perspective and insight.
I mostly agree with you that CORBA would have been way better than Web services, if only Microsoft had come on board.
But the Web services standards, while absolutely sucky -- and I hate them passionately, as only someone who has to implement them for a living can -- are (slightly) further along than you think.
For authentication there are WS-Security profiles for UsernameToke, X.509, SAML, and Kerberos. The product I work on supports the first three, and at least the first two have passed interops with other vendors. (The SAML stuff has interopped with other people's code at a client site, but we weren't there to see it so it doesn't count.)
You have a point about transactions, although I'm not sure the CORBA stuff was in any better shape at this stage. The WS-TX stuff is still in committee draft, but it's based on WS-Transaction which is apparently fairly mature and widely used, but as I've never used it myself I won't comment further.
You're just plain wrong about encryption -- WS-Security 1.0 (with Basic Security Profile) supports encryption (and signing) of arbitrary elements in a SOAP message using X.509 and interops basically everywhere, today (including open source implementations such as Apache). (With WS-Security 1.1 the client doesn't need a certificate, but only a couple of vendors have implementations.)
Public UDDI is dead (stillborn, actually) but within organizations it looks like it's going to end up being the de facto directory service for Web services (which sucks, because I hate it, but no I don't have any other ideas either).
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?
It's a BDUF thing. Good design is always an artful compromise between desire and possibility, between imagination and reality. When you leave a bunch of software "architects" alone in a room for too long they will often over-complicated and over-embroider their designs so that every imaginiable issue has a solution. But because they've spent months thinking about the topic, they can no longer imagine how it looks to a newbie. Often, they don't care, forgetting that somebody will need to use this. They focus entirely on desire, ignoring possibility. I have made this mistake myself, and it is very fun and inevitably disasterous.
The solution is to put your designs to the test, both by writing actual useful apps with them and by releasing early and often. Take a look at successful protocols like SMTP and HTTP. They started simple and solved real-world problems. If you know sockets, you can write a server or client that handles the happy path for the basic interaction in under an hour. But both protocols have grown up over time, handling volumes and situations that their creators never imagined.
Totally. I took a week-long course in CORBA programming back in 1996, since my manager was excited about CORBA. Ultimately, I was so weirded out by the oddities and requirements (and vendor implementation bugs) that I wound up writing my own, special-purpose ORB for the specific distributed computing problem that we had to solve. It had a tight focus, and it worked great for the task at hand.
It's too bad CORBA didn't go anywhere, but it was complex and weird. This is one case where being a public standard didn't do much for anyone.
Butbutbut... CORBA is simple! WTF are you doing?
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++? Okay, that mapping is crap. But why? People are constantly grappling with stuff they neither want nor need. Just don't use it, and optionally fix the faults in the things that are needed. (My wishlist: gimme a better C++ mapping that knows about STL, gimme me an ORB for Haskell, allow parametric polymorphism.)
Michi Henning owns a company which develops ICE...which is a competing product to CORBA. Nothing to see here, move along please.
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.
Patriotism is a virtue of the vicious
I'm seriously disapponited in the accuracy of this article. The mistakes here are egregious to the point where malice can be attributed instead of plain laziness. For instance, let's start at the start of the article:
, CORBA had its roots since very early times and had its origins in Tibet. In fact, the article glosses over several structural revision in glibbly stating that 2.0 was published in 1997. (http://en.wikipedia.org/wiki/G.I._Joe)
r a.html).
>> After a false start with CORBA 1.0, which was not interoperable and provided only a C mapping, the OMG (Object Management Group) published CORBA 2.0 in 1997.
First as this reference clearly shows [http://en.wikipedia.org/wiki/COBRA_Organization]
Later on, when in the article it states:
>> Microsoft never embraced CORBA and instead chose to push its own DCOM (Distributed Component Object Model).
It fails to mention the reason why... serious IP issues (prior art: see http://en.wikipedia.org/wiki/S.P.E.C.T.R.E.] and http://en.wikipedia.org/wiki/Legion_of_Doom).
There were also serious leadership problems as well. Several power struggles within the group ensured a reputation of uncertainty (http://en.wikipedia.org/wiki/Serpentor).
It also fails to make the connection to the real reason why its not so prominant today (See Red Shadows http://en.wikipedia.org/wiki/Cobra_Commander).
That being said, at least in 2006, you still see some remnants (http://www.geocities.com/Area51/Station/6563/cob
I think it's totally disgusting how "it can work through port 80" has become such a huge influence on what lives and what dies.
If people are able to send messages that interact with any services (not just web servers) of arbitrary complexity and function through that port, then the "correct" thing for a firewall to do, is block port 80. But of course, no one would do that. Yet if you're going to let 80 be open, then there shouldn't be any resistance to opening other ports too, if they're necessary for getting things done. Thinking as a network admin, I would rather see stuff happening on port n and understand what it means, rather than see more stuff happening on 80 and not have a clue what is going on.
Why the hell do we even have firewalls anymore, if one of the main features that middleware needs to be popular, is that it defeats the firewall? The whole situation is just plain psycho.
Yeah, I know the truth, so you don't need to tell me. The guy in charge of getting things to work, isn't the same guy who is in charge of the firewall. Left hand and right hand aren't working together. I guess what I really want to know is, why have such inefficient entities (i.e. large companies where engineers and PHBs are essentially enemies) had such an effect on technological evolution? They ought to be irrelevant. They ought to take what the truly productive entities give them. Maybe the real question is: why are inefficient and unproductive companies, paying higher wages than efficient and productive startups? The salary issue is why programmers are really silly things like SOAP.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Check out Ice. The C++ mapping is very nice indeed!
DOE/CORBA was one of the primary reasons I left Sun. I couldn't
see any future in such a bloated, slow protocol.
I often thought that M. Powel started DOE so that he could slide
what was left of the Spring OS underneath. Never happened.
- AndrewN
No, I won't. To be honest, I have a bit of a problem with Mr. Henning. I'm pretty sure he misunderstood some parts of CORBA back in the day when he co-authored "Advanced CORBA Programming in C++", and his misconceptions only got worse in time (the tantrum he threw about the allegedly useless "oneway" directive particularly stuck). The he started working on Ice and since that day constantly derailed CORBA as bloated and fundamentally flawed. But it isn't. It is fixable, and it is an open standard, while Ice isn't. And I don't trust the guy not to make more fundamental mistakes; second-system-effect and all that.
BTW, what bugs me about CORBA, is that the most interesting part are poorly documented: the Interface Repository and the wire protocol. Were they easier to grok, you could pull information about an interface from the IR (no need for an IDL compiler) and generate a very simple stub from scratch. Voila! A custom made stellite ORB, almost trivial to write in any programming language, and no heavyweight like that MICO abomination, either. Heck, this way both IDL and the ugly C++ mapping could long be a thing of the past, someone would already support something-sharp, and I would have written my 100% pure Haskell ORB. But no, that would destroy the market for commercial ORBs.
Boy, I'm starting to positively hate this whole industry.
CORBA is used extensively in telecom, and I don't see the situation changing anytime soon. The reason for this is that CORBA is the only (relatively) mainstream high-performance middleware to support heterogeneous environments. WebServices are (mostly) heterogeneous and RMI is high-performance, but if you want both, then CORBA is the only game in town. There is still no replacement for CORBA.
Another thing that many don't realize is that EJB's use CORBA for remoting (but they can also use RMI).
Ten years ago many developers found CORBA difficult to use but I think a lot of the problem was really that they found "distributed computing" difficult in general. I think that you'll find that if you do a side-by-side comparison of CORBA and a full WebServices stack, you'll probably conclude that CORBA is actually the much simpler of the two.
Its good to hear I'm not the only one who was thoroughly confused with it. I managed to become unconfused after a point, but at that point I just wondered "was that worth it?"
What all these systems do is quite similar. The basic idea is this:
This all originated as an internal mechanism within Visual Basic and was responsible for its success. Alan Cooper had finally implemented a reasonably idiot-proof way to make A talk to B. That's why Visual Basic controls were so powerful. Then Microsoft made it a general-purpose mechanism. The Unix/Linux world didn't pick up on this for a long time. The Gnome and OpenOffice people get it, and their stuff plays well together. Most other extensibility is a master-slave relationship, usually involving "plug-ins", "toolbars", or "scripting".
Part of the problem is that the main languages in the Unix/Linux world are C and C++, which have no introspection. If you have a structure, and you need to go through all its fields and get their name and type info so you can format and marshall them for transmission, there's no way to do that from within C or C++, other than by writing glue code by hand for each interface. Preprocessors have been built to deal with this problem (ones exist for OpenRPC and SOAP), but they're clunky and complicate the build process. CORBA requires that you define each interface in its own special language, IDL. The Java world has a solution to this problem, but it's Java-only. Microsoft has put extensions into their various dialects of C and C++ to deal with this, but they were too Microsoft-specific to go into the standard. So making A talk to B without extra work remains hard in the Unix/Linux world.
Subsetting must hurt compatibility though - different vendors will implement different "10%"s of the features.
This is why I cringe whenever I hear about some spiffy new feature in the MPEG standard. I already know most "MPEG" implementations won't be able to handle it.
did GI Joe and Sgt Slaughter finally get that mask off of him?
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 the ORB vendors, such as the TypedEvent interfaces to the NotificationService. That is one of those stupid features that the domain specialists (e.g. IT people from the Healthcare industry) put into the spec, without knowing how difficult and inefficient it would be to implement and use. The ORB vendors responded by ignoring that feature (mostly out of necessity).
Censorship is telling a man he can't have a steak just because a baby can't chew it. --Mark Twain
Thanks to Moore's law embedded systems have grown up enough to use CORBA. I know this because I work on a project which uses CORBA heavily (at least in the TAO and JacORB 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 provides a competitor to CORBA and Web Services. And, you guessed it, that product addresses each and every flaw he outlines in his article.
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.
Amen. We're doing CORBA all over again, just slower with crappier libraries and technologies. WSDL is IDL, your HTTP server/SOAP handler is your ORB. You have to use 2WSDL / WSDL2 just like IDL compilers. I can't wait for another 5 years of tech changes to webservices that will make it run, as you said, just like CORBA has for over a decade. I just want to know who looked at HTTP and said, "Yeah, this is better than IIOP!", cause I don't want them anywhere near my projects.
Webservices should be left to rot, the technology provides nothing that CORBA didn't do better.
Arrogance is Confidence which lacks integrity. -- me
I'm shocked. I've never heard the terms "Corba" and "interesting used in the same sentence before. Back in 98-99, I worked with Orbix, which was a not-so-great (IMHO) implementation of the Corba standard. I'm glad I don't have to repeat the experience anytime soon.
It's good to use your head, but not as a battering ram.
VNC got its start using CORBA no? It seems to have worked out well.
Granted I suspect it only uses a small fraction of CORBA and I
doubt it ever would have worked if the authors didn't design their
own orb as well.
I also recall a few tiny companies doing useful things with Java/CORBA
(anyone remember Thought, Inc) about 10 years back to connect applications
to backend databases in the way we now use xmlrpc.
Also don't Gnome desktop tools communicate with each other using CORBA protocols?
I postulate that the real problem is that everyone working on CORBA really
underestimated how hard distributed systems can be unless significant simplifying
assumptions are made that tend to limit the overall reusability of the underlying
communications subsystem.
The incredibly fucked up NeWS/CORBA/DOE/Slowlaris situation was why I left Sun, too.
I took a job at Sun in 1990, because James Gosling posted this message reaffirming Sun's commitment to NeWS, and during my job interview assured me that Sun was going to publish the NeWS source code in the public domain. (This was before the term "open source" was popular.)
Unfortunately, John Gilmore was right to be skeptical: "I'm glad that people believe James Gosling about NeWS more than they believe me. Check his message for specifics, though. Weed out the promises and soothing noises and what is left?" The only hope was to make NeWS free, so I grilled Gosling about whether Sun would make NeWS free, and he assured me they would, so I took the job with Sun, based on his word. But James Gosling let our team down. Which is why I've never trusted anything he said about Java.
To Sun, making NeWS free meant charging $1000 for media, and prohibiting anyone from distributing "free NeWS" it without buying the $1000 tape from Sun. (Yes, the person who posted that message is the infamous Pat Naughton.)
Sun actually wanted to cancel the NeWS project, but instead of telling us the truth, they said that they were going to use NeWS as "Display Services for DOE", which we all knew was a crock of shit.
-Don
Take a look and feel free: http://www.PieMenu.com
Hi, Andrew! It was fun working with you after Sun, on ScriptX at Kaleida. ScriptX was even more lisp-like and object oriented than NeWS PostScript. Did you know that after Kaleida shut down, John Wainwright (an architect of ScriptX) went on to implement a plug-in scripting language for 3D Studio Max called "MaxScript", that's remarkably similar to ScriptX! It worked so well that Kinetix bought it from him, and made it the official 3dsmax scripting language. It's still in common use, for programming 3dsmax tools, importers, exporters and user interfaces. It was quite powerful because it supported all kinds of ways to integrate other software: DOS command lines, OLE automation, and dynamically loaded C++ extensions for the scripting language itself.
It sucked having NeWS and ScriptX canceled out from under me, while I was having so much fun with them. So no more proprietary platforms for me, thank you. These days, I prefer programming python, and I use SWIG to plug it into C++ and C libraries. I like to use OpenLaszlo on the client side, which supports Flash now and DHTML soon. But I will never fall for something proprietary like FLEX, ever again. In a few years, Flash will be as obsolete as Director, ScriptX and NeWS are today, so it's a bad idea to put all your eggs in that one basket.
-Don
Take a look and feel free: http://www.PieMenu.com
For crying out loud, you are practically equating website creation (LAMP) to e-commerce infrastructure (CORBA).
;-)
If you need to distribute and interoperate applications across different networks with heterogenous computer installations, nobody gives a toss about your killer websites I'm afraid. They are looking at middleware that fits the "big corp grade" bill.
Then it's annother issue altogether how much EJB can eat CORBA's lunch and where... but LAMP is not near that ballpark, not even in the same ballgame.
BTW, if you happen to use GNOME, you'll continue to know CORBA alright
I'm still trying to figure out what the other half of the battle is?
I mean, it can't be killing people--GI Joe troops were elite, and so no one ever actually died during their entire war.
I'm guessing the other half was learning some sappy lesson at the end of each sho^W day?
PS, Andrew:
Here's John Wainwright's page on MaxScript 101. MaxScript has a lot of really cool ideas built into the language that make it easy to script 3D graphics construction and animation (like treating transformations, time, etc as nested scopes that you can temporarily enter and exit, and directly supporting animation).
I dont't mean to confuse anyone by talking about two different pieces of software called "Max" (and not "Macs"), but here goes:
You should take a look at what Cycling 74 has done with their venerable visual programming language MAX/MSP (which supports a huge ecology of of binary plug-ins as well as visually scripted extensions), and Jitter, their 3d/video/image processing extension. Jitter supports writing extensions in JavaScript, and has full access to OpenGL from JavaScript as well as the visual programming language. You can even emit and consume JavaScript data structures on the wires flowing between Max data processing icons! But MAX is proprietary, and incredibly complex and arcane, due to its age. That can also be said for 3D Studio Max, as well.
I'm excited about applying ideas from successful or well designed proprietary systems to future versions of OpenLaszlo, targeting 3D runtimes instead of Flash. One reason I'm sure Flash is doomed is because it doesn't already support 3D, and if Adobe/Macromedia ever gets around to adding it, rest assured it will be a horrible kludge. I want to develop and run OpenLaszlo applications in a well designed full 3D real time environment, and use it to implement visual programming languages like Max, and user interface builders like HyperNeWS. OpenLaszlo's independence from Flash makes that possible.
-Don
Take a look and feel free: http://www.PieMenu.com
to make a blocking function call that actually sends a message.
you need to queue messages in and out.
It's neat if you have something that is supposed to work like a library and sneakilly is on another host... like a GNOME plugin... but to just have it in general, a nightmare to debug.
blocking is teh evil whatever you think.
juggle instead!
-pyrrho
it only appears so. The GIOP protocol itself is completely asynchronous, invocations can be arbitrarily interleaved, results don't even need to be reported in the same order the requests came in. What is synchronous, however, are the language bindings. Then again, how else would you embed remote invocations into C and similar languages? Without first class functions is is simply too cumbersome to compose a program out of parallel invocations and continuations. The only way out are threads, and multithreading should properly be written multithreating.
But consider a functional language. It would be ridiculously easy to define a language mapping where you could explicitly set off parallel invocations, or you could call each invocation with a continuation that tells it what to do when it eventually returns. Nobody did this, and the only explanation is that the guys at OMD did not know Standard ML. That explains some other major blunders, like missing recursive structures, but I digress...
If the "elephants" are close together, the obvious answer is to aim to make the simplest thing that could possibly work. Example: "web services". They're a cluster of awkward hacks held together with baling wire, but they're comprehensible in 30 minutes from a standing start, and they reuse a ton of mature APIs with readily available prepackaged implementations. Web services are the answer to "what can we have built, tested, up and deployed by next Wednesday?" Naturally they won.
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'.
That makes it usable by those forced to use it, but makes things even worse for tools vendors (which was the context in which my statement was made).
When the architect/designer says 'Great a distributed app, let's use CORBA!'
Dum spiro spero
Hey, I kind of like Perl...
Dewey, what part of this looks like authorities should be involved?
You like simple API's for solving complex problems? Then you must LOVE ioctl()!
-Don
Take a look and feel free: http://www.PieMenu.com
COBRA has an ugly sister called HLA. HLA is the US military standard for defense simulations. Trouble was it was designed by a small ivory tower elite who were clueless about the real world. Even funnier, they convinced the US secretary of defense and the IEEE to endorse it as a standard before it had ever been tried in practice. A huge waste of money. After the US secretary of defense made it compulsory, people discovered it didn't work. Oops.
http://www.informs-cs.org/wsc98papers/109.PDF
See DIS and HLA on Wikipedia too. Note how the HLA entry is very vague.
CORBA supports low-level asynchronous communications in the form of "one-way" methods which return immediately. The higher-level "Event" and "Notification" services provide higher-level async/Message-Oriented-Middleware (MOM) solutions.
Issue 8 of the ZeroC (creators of the Ice RPC protocol) linked to an active discussion in the rpc blogosphere on the legacy of CORBA, the fate of SOAP, and the age old problems of RPC:
* exhibit A: 11:40 Oct 3, 05: Mark Baker claims CORBA was a technical failure ( http://www.markbaker.ca/2002/09/Blog/2005/10/03#20 05-10-ws-corba )
* exhibit B: 15:38 Oct 3, 05: Steve Vinoski of Iona (leading CORBA vendor) begs to differ ( http://www.iona.com/blogs/vinoski/archives/000214. html ); a long discussion including Michi Henning from ZeroC ensues in the comments, including:
Even if I do define WSDL that is "loose" and makes lots of things optional, that typically doesn't help me. Loose coupling isn't of interest just for its own sake, but is of interest because people are looking for a way to solve the versioning problem: how can I evolve a distributed application over time without breaking everything that is deployed already, and without having to recompile and redeploy the universe? If I define WSDL that is "loose" to start with, so I get the loose coupling I so much need, by implication, I know in advance how the application will evolve: I put the "loose" bits in the WSDL definitions where I expect future variation in the data. But real life doesn't work that way. None of us is prescient and, as a rule, what makes the versioning problem so hard is that we *don't* know how an application will evolve in the future. In other words, people who say that I can solve the problem by writing "loose" WSDL are kidding themselves: the real world is not cooperative enough for this to work.
* Michi Henning
It's odd that CORBA should end up being sidelined by most of its original supporters, in favour of a supposedly simpler and cheaper system that ends up being frantically complicated (well over 100 related specifications, and counting) and far more expensive. But that's business for you!
* Tom Welsh
* exhibit C: 23:05 Oct 13, 05: Ted Neward discovers and enters the discussion ( http://blogs.tedneward.com/CommentView,guid,070274 e8-ccfd-4ebd-87b5-494564c39b77.aspx )
And here is another prediction: once people get over their current fixation with loose coupling, they will finally realize that, to get loose coupling, I don't need loose type systems that throw away compile-time type safety, and I don't need support at the protocol level at horrendous cost in performance. All I need is intelligent system design, a middleware that offers a workable implementation of multiple interfaces (check out Ice facets), and domain-specific standardization. With that, I get type safety, flexibility, and performance.
* Michi Henning
* exhibit D: 17:32 Oct 22, 05: Ken Horn comments on the issue ( http://kendes.blogspot.com/2005/10/loose-coupling- corba-vs-ws.html )
Links
* PEPt - An Architecture for Adaptable Remoting Systems ( http://haroldcarr.net/pept/ )
* YAML ( http://www.yaml.org/ )
* A Conversation with Roger Sessions and Terry Coatta ( http://www.acmqueue.com/m
It's 10 PM. Do you know if you're un-American?
I'm of the opinion that invested vendors want to raise the bar to entry for competitors, so they inject as much complexity as they feel they can easily manage. This turns into a bidding war at the standards table, when multiple vendors all try to inject complexity in areas where they feel they have leverage. It's just like price-fixing, really. It's an anticompetitive practice.
-I like my women like I like my tea: green-
which is the reintroduction of a messaging paradigm! in which case, why use function call semantics?
ah... this is the problem with the whole RPC model, it's really just a good fit when you really do think the functionality is going to be local, and you want to be able to distribute it somewhere not local, but nearby on the network. Not a bad thing, but limited because if there is a lot of communication, you need to use message passing metaphors to properly design it -as- a communication system.
-pyrrho
Actually it is difficult to find good alternatives to CORBA for high performance and/or mission critical distributed applications.
.net interoperability. OminOrbPy (http://omniorb.sourceforge.net/) offers Python bindings. Et cetera.
ICE, the middleware created by the company where the author of the article works, is very good.
The downsides:
- It is proprietary
- It is not free for commercial applications (this is not bad per se)
Most of the shortcomings of CORBA depicted by Michi Henning are true.
But some of them are avoidable.
These are some pros for CORBA:
- Many freeware implementations (TAO, OmniOrb, JacOrb, etc)
- Very good performances
- Good support (both from public forums and private companies - three or four companies, for instances, offer support for TAO)
- Interoperability with everything. Java is compatible out of the box (even if the JDK ORB is acceptable only on the client side). The excellent IIOP.NET (http://iiop-net.sourceforge.net/) offers
If only CORBA had a C++ binding like ICE...
Sted
P.S.
Like many developers working with CORBA, I am grateful to Michi for his precious help within comp.object.corba in the early days.
Hey Don.
Haven't talked with John W for a while now. I knew about the language work he was doing. I'll check out the other two languages and OpenLazlo.
I've been playing with my own language ideas, similar to Self in that it only has prototyping and delegation as the language mechanism, the underlying engine is very Forth like (dual stack with a couple of addressing registers). The runtime always compiles to machine code through several compilers, simple/fast, simple+profiling, slow optimized compiler using profiled info; all depending on frequency of use. The modules/packages depend on other modules all automatically loaded and cached from the net. You can add hints to the compiler via assertions (that might be checked/utilized). Arrays of similar objects are first class objects allowing efficient packing of numerical/textual data. I'm paying careful attention to the runtime size and making sure that system level driver code could also be written without huge overheads. A real-time GC of course.
I'm hoping to prove it's viability by building a 3D game engine on top (similar to Blitz3D) that used OpenGL underneath, not thought too much about this at the moment. I do recognize that a new language is no good without an adequate well thought out library (NeWS's biggest problem was an immature library).
It will all be open source, just like Linux was/is. It should be possible to write portable applications
across platforms, embed it into browsers and other applications. I probably won't release anything for
another two years until everything runs well on a couple of platforms.
The syntax I'm working on is minimalistic, no static types, little in the way of variables and arguments (being stack based). It's a language for individual smart programmers, without being unreadable, who just want to get the job done. I'm tired of languages that pander to large teams of mediocre programmers.
- AndrewN
You might want to consider writing a back-end for SWIG to support your language, which will make it easy to plug in new primitives and integrate libraries with your language. That will sure save you a lot of work, and enable developers to easily plug their own stuff in! SWIG lets you write interface definition wrappers for libraries (and can even use C++ header files directly, or you can tailor the interface by simplifying and modifying them with annotations), and SWIG automatically generates all the glue code for a wide range of languages, or pure xml that describes the interfaces for other tools to grok. There's an API for extending SWIG and writing new back-ends.
SWIG is brilliantly and practically designed, and deals well with harsh realities and nuances of C++. It totally rocks!
For a great example of a complex library exposed to scripting languages via SWIG, check out the Intel Open Source Computer Vision Library, which plugs into many scripting languages by describing its APIs to SWIG. If you wrote your own language back-end, you'd be able to SWIGify an OpenCV interface to your own language, as well as any other library that has a SWIG interface.
-Don
Take a look and feel free: http://www.PieMenu.com