> And thus, other than some dedicated weirdos (who either invested too
> much time in learning, or have too much legacy code that needs it)
> CORBA is dead, dead, dead because of it's inherent complexity,
> slowness and overall braindeadedness.
>
I sincerely hope that you do not have any experience with CORBA. To make
these statements without CORBA experience is merely brash. To make them
with CORBA experience means that you have wasted X months/years of your
life without 'getting it'. CORBA is basically the opposite of everything
that you listed.
* CORBA is simple. Sure, you could choose to delve into obscure corners
of specifications and IIOP profiles, but for most corporate programmers,
*using* CORBA is very simple. In real production scenarios, I almost
never use: POA policies, POA interceptors, alternate IOR profiles, etc.
CORBA can be used as little more than a fast, straightforward,
object-oriented, RPC mechanism. Their are basically 6 types that you
need to concern yourself with (long, string, boolean, float, sequence,
struct) and a bunch of others that will not usually be a concern for
most programmers (short, wstring, array, etc) You build your own
datatypes (very C-ish 'struct' syntax) from these. Nothing could be
simpler, and still be as useful.
* CORBA is fast. Is it as fast as hand-optimized (assuming well
optimized) TCP/IP messages? No. But it is much faster than nearly every
one-off protocol that I have ever seen used in TCP/IP projects. It is
many times faster and smaller than encoding and decoding XML. By using
pre-compiled IDL stubs and skeletons, you get what might be the best
possible balance between generic and custom. You get compiled (rather
than interpreted) code, that has been written (automatically) for *your*
datastructures. If you use DSI/DII, then you have chosen to avoid this
optimization (size vs speed tradeoff).
* CORBA is far from braindead. CORBA is being used by thousands of
companies, and in practically every major industry. I used to work for a
company in Lakeland that provided real-time, embedded CORBA ORBs. Our
biggest customers were telecom companies. The companies wanted very
small and very robust above all else. Our ORB runs inside cell phones,
land-line telephone switches, etc. CORBA was designed to meet the needs
of ALL companies. The standards documents can be hard to read, because
every OMG company got to make sure that their needs could be met.
The TCP/IP version of the CORBA on-the-wire protocol is called IIOP
(Internet Inter-ORB Protocol). It is so powerful and flexible, that it
became the defacto standard for JAVA RMI (aka RMI-over-IIOP). As for
.NET, the entire 'Object Remoting' technology is such a subset of CORBA,
that there are several .NET packages that let you treat CORBA Objects as
though they were 'remoted' .NET ojects (one of these packages is
CORBA.NET).
The biggest 'drawback' to CORBA is probably the fact that clients and
servers need to assume nearly identical IDL (IDL can be added-to, but
not changed or reduced, without changes to clients). The XML proponents
like to crow that they can change schemas on-the-fly, without
recompiling all of the clients. This has some practical advantage when
it comes to rolling-out new clients and server in a legacy environment,
but it has drawbacks as well. CORBA IDL provides a nice, clear
definition of the interface between components. You can have client
teams and server teams writing to the IDL, and when everything comes
together, their will be very few communications related bumps (note that
IDL is not responsible for logic related bumps). The IDL also provides a
great starting point for documenting the interactions between components.
I have used CORBA in the following languages: C++, C (that's right, you
can do network OO in a non-OO language), Python, PHP, JAVA, and VB 5.0
(weird but true). If you ever need to do client-server or distributed
object computing, give CORBA a very hard look.
--ronan
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 13:31:26 EDT