[
Lists Home |
Date Index |
Thread Index
]
> Karl Waclawek wrote:
> > What is it that prevented CORBA from gaining more ground in the market?
>
> 1. It started at the API level. Because the wire protocol came later,
> interoperability between products from different vendors came later.
> Too late in some respect.
> 2. Its a closed system. There are no standard ways to hook in various
> goodies the standard missed like reliable transport, caching, character
> set conversion (like EBDIC<->ISO-8859) and so on.
CORBA 3.0 fixed most of this.
> 3. There are a lot of small holes in the spec like setting the time a
> client waits for a server response, which vendors filled with proprietary
> solutions, and wich have to be used in many real world applications.
> 4. CORBA products are complex right from the start, you can't start
> small and cheap and scale up later. Well, you can start with a simple
> product form one vendor without multi-threading and other fancy stuff,
> and switch to a more expensive product once the load increased.
Very untrue.
http://omniorb.sourceforge.net/
http://www.cs.wustl.edu/~schmidt/TAO.html
Both are better than many commercial ORBs, and have all the features you
mention above.
> Unfortunately, the portability and interoperability problems usually
> made this idea a non-starter.
> 5. The APIs are complex and clumsy, and you have to deal with the whole
> load right from the start to get even simple stuff running.
> 6. For a long time you just couldn't buy a client and plug it to an
> existing server which possibly used a different toolkit, or vice versa,
> without *major* configuration work. AFAIK all "component systems" which
> use CORBA are still based each on a single toolkit, with almost no
> interoperability except through hideously expensive specific adapters
> or bridges for individual components.
This has been wrong for a long time. CORBA interop was indeed lousy at the
beginning, but vendors finally got their act together in the late 90s. We
certainly have had minimal interop problems in our experience. We've bridged
omniORB to Visibroker, JacORB and Orbix. The biggest offender in recent times
has been JavaIDL, and I've always figured Sun's compatibility bugs were
deliberate obfuscation, and we would always recommend people just replace
JavaIDL with JacORB or one fo the other options. Perhaps by 1.4 JavaIDL
finally works.
> 7. It took the vendors a loooong time to implement reasonably working
> products because of the complexity, and because the standard itself was
> always moving a bit.
> 8. CORBA products are still not really cheap. There wasn't really much
> competition in the field because once you've choosen a vendor you were
> basically locked in. If you started recently with CORBA 3.0, switching
> is easier, but anything older than 2001 would need a major and expensive
> rewrite.
Again false. See above.
> 9. Availability of CORBA products on your specific platform is more often
> a problem than it should, unless you are using Windows of course. Getting
> a custom implementation is usually shockingly expensive (talk about
> 1.5 Megabucks for OS/390, and the vendor considers this a bargain for
> the customer).
Ah. Perhaps the OS/390 bit explains your perspective? I certainly don't
think omni or TAO have been ported to 390, though I suppose with Linux on 390,
the path to such a port would be straightforward, if not trivial.
> I personally think CORBA (and DCOM, and others) provided valuable lessons,
> and I hope Web Services will provide a much more modular and complete
> architecture for the problem of "applications talking to applications"
Too late. They haven't. WS in the current mainstream have very little to
offer over CORBA/DCOM as I see it. Of course they have potential to offer a
great deal more. The document-oriented WS that people are finally beginning
to talk about, I think is the key to that potential. I don't like CORBA for
all tasks. I think there are relatively few tasks for which RPC is
appropriate. My main point is that *for RPC tasks*, I would prefer to use
CORBA than WS any day. For general inter-process messaging, I would prefer to
have something more flexible than both in their current form.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p
y.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
ex.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
dex.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork
s/xml/library/x-tipgenr.html
|
