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
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
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
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.
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.
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
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.
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.
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.
Ayup, GNOME has their own implementation of CORBA stuff, called ORBit.
Bonobo is the component framework in GNOME, and is built atop CORBA.
AFAIK they're still pretty much in use.
> 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
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
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.
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.
GNOME is steering away from CORBA, to the point of rewiring their next major release for D-BUS. I believe this includes Bonobo.
My exception safety is -fno-exceptions.
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.
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 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 :-)
How about saying a paved road is better than a dirt bike? :)
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.
> 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.
b a/browse_frm/thread/6f47a3d21cd0d9dc/f597718937b8a 3f3?lnk=st&q=3eXDf.916%24k6.18007%40nasal.pacific. net.au&rnum=1&hl=en#f597718937b8a3f3).
:-)
Correct--I decided to do something better than CORBA after slaving my guts out for seven years trying to make CORBA better, and largely getting nowhere. Eventually, I realized that there was only so much sh*t I could push uphill and decided to focus my efforts on something more productive.
> The concepts like the POA are too over engineered, but the underlying ideas of language neutrality, a simple interface definition language and a common wire protocol have not been bettered.
I beg to differ. The CORBA POA interface requires over 200 lines of IDL definitions when, in fact, I can provide all of the functionality of the POA, plus some extra, in just over 30 lines.
Yes, language neutrality is a good idea. No, CORBA IDL is *not* simple, not by a long shot. (Look at the last section of the Slice chapter in the Ice manual for some of the reasons.)
IIOP is a very poorly designed protocol that has more flaws than a dog has fleas. Among them a quite major one that prevents efficient implementation of notification services. (See the Ice manual for details.)
> One area where CORBA is particularily useful, is in event or notification based systems.
The CORBA event and notification service are interface nightmares, and cannot be efficiently implemented due to design flaws in IIOP. (See http://groups.google.com.au/group/comp.object.cor
> Most recently, I used CORBA to replace a SOAP based system. Compared to SOAP, the CORBA based system was faster, easier to work with and far more reliable.
I don't doubt that. It's very hard to beat the ineptitude of SOAP and WS. Now, if you had used Ice to do the same thing, you would probably have done it in half the time, with half the pain, and twice the performance
Cheers,
Michi.
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
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.
s ue8.pdf "Can a Leopard Change its Spots?" for a versioning mechanism that allows you to seamlessly version an application without breaking backward compatibility.
That is true for CORBA, but it is not true for Ice. Have a look at http://www.triodia.com/staff/michi/connections/is
Cheers,
Michi.
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.
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
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
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.
"Anyone here ever REALLY try to use CORBA across languages and platforms? ... seriously, using something besides Java on both ends."
No
Yes. We use Java for our clients, and C++ for our servers. Works great on Linux, HP, AIX, Windows, and Solaris with very little cross-platform issues. Your assertion that language interpoerability failed is incorrect - it works as designed and works well.
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
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.
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.
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-