[
Lists Home |
Date Index |
Thread Index
]
Some of your points make a lot of sense, some
I can't judge since I don't know the spec that well,
and some contradict my (admittedly not very extensive)
experience, specifically the points
4) I found it simple to build a simple app.
And the complex features are complex anywhere they are offered,
regardless of technology, since they deal with complex problems.
5) I didn't find that. Found it *a lot* simpler than DCOM.
Seems as simples as SOAP - in those cases where you limit
yourself to what SOAP offers..
8), 9): We have an address verification server in operation
that was originally built with MICO. Then we switched to OmniORB.
Switch was no problem almost no re-work, minor configuration changes,
both are free and quite mature.
They are also available on several platforms (various Unixes,
Windows, Solaris and some more). So, for our (admittedly simple)
application we found that those points did not apply,
although I can imagine that this was quite true in the past.
Karl
----- Original Message -----
From: "J.Pietschmann" <j3322ptm@yahoo.de>
> 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
> rewrite.
> 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).
>
> 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.
>
> J.Pietschmann
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
