What CORBA got wrong?
Ted Neward compares the WS* efforts with the older CORBA efforts - and has a few criticisms. Hmm. The more I look at what's happening with WS*, the more I think it looks exactly like what the OMG did with CORBA - a blizzard of specs no one cares about, which tend sto make vendor interop harder and harder. But anyway - I thought this was an interesting thing:
For me, the fatal problem for CORBA was that they also tried to tackle standardizing programming models/language bindings. Ever use CORBA using the C++ language bindings? Yuck. How about in Java - not so good either.
Hmm - there's a standard Smalltalk model as well, and somehow, it's simply not that complex. I'll show you:
Step one - turn on the listener in the DST control panel - make sure to enable I3. Step two - create a small class with a count variable, accessors for that variable, and an "API" method:
initialize "set the initial state" self count: 0.
add: aNumber self count: self count + aNumber.
Now, modify the #initialize method this way:
initialize self counter: 0. ORBObject namingService contextReBind: 'counterService' asDSTName to: self.
And add this method to "tear down" the service when you are done
release super release. ORBObject namingService contextUnBind: 'counterService' asDSTName.
Now, you can set up an instance by executing Counter inspect and leaving the inspector up for examination. Now, start up DST on another system, and execute this in a workspace: ORBObject namingService contextResolve: 'counterService' asDSTName.. That's it - you can now send the remote objects messages, like #add:, write there in the inspector. From there, wrapping a UI on it isn't hard.
Sure, there's exception handling, dealing with dropped connections - but that's no different than network programming has ever been. If you want the demo above to work with non-Smalltalk code, you need to go ahead and generate the appropriate IDL - but again, that happens for you. Seems a wee bit simpler than the complexity you see in Java and C++, eh? CORBA really didn't have to be complex - it just became so in the mainstream languages. Which says more about those languages than it does about CORBA, IMHO. The main reason that WS* is succeeding where CORBA failed? Port 80


Comments
[] October 4, 2004 6:30:59.386
"If you want the demo above to work with non-Smalltalk code...". That's the whole point of CORBA! How does the performance of Smalltalk's dynamic dispatching compare to the performance of generated stubs/skeletons?
succeeding with port 80?
[bryan] October 4, 2004 7:01:32.647
succeeding at making port 80 as non-trustable as every other port?
What CORBA got wrong?
[ James Robertson] October 4, 2004 7:19:19.882
Comment by James Robertson
In Smalltalk, generating the IDL (and a handful of associated methods) is done for you - for the above example, it would take seconds.
[] October 4, 2004 8:19:25.014
It takes seconds to dispatch each call? That can't be right. Do you mean seconds to generate the code from IDL? If so, that's no different from using C++ or Java. You hit the build button, the code gets generated and compiled.
What CORBA got wrong?
[ James Robertson] October 4, 2004 9:06:30.914
Comment by James Robertson
I wasn't talking about dispatch - I was talking about the ease of doing CORBA work in Smalltalk (as opposed to, say, Java).
[] October 4, 2004 10:11:36.147
So how does the performance of the Smalltalk example above compare to that generated from IDL?
What CORBA got wrong?
[ alan knight] October 4, 2004 16:14:25.922
Comment by alan knight
Performance is probably slower, but also probably faster than parsing XML
CORBA got more wrong in heaven and earth than is dreamed of in your philosophy
[Brendan] October 6, 2004 16:21:15.215
I remember with early Apache SOAP implementations people complaining that they could not talk to Microsoft SOAP implementations and vis versa. I have never heard someone complain that their Microsoft browser could not talk to their Apache web server, or their Apache Http client could not talk to Microsoft IIS.
It is clear that taken as a package the issues with CORBA make it a bad way to build loosely coupled distributed systems. Just is SOAP is a bad way to build such systems now.
CORBA has a nasty network protocol and ideas like "location transparancy" that also are mistakes.
CORBA also encourages designs that rely on object references. These seem to help people do the wrong thing.
CORBA also has a bunch of different implementations which each get other things wrong.
I don't think it is clear all of the things that CORBA did wrong.
Brendan