Lists Home |
Date 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.
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.
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.
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
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
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"
> I know it was discussed here, but I didn't quite see one
> explanation emerging as the one everbody would agree to.
People working on different systems with widely varying backgrounds
tend to have different points of view on what are problems and how
important the individual problems are.