CORBA
The Common Object Request Broker Architecture (CORBA) allows
distributed applications to communicate in a standard but
flexible way. At the heart of CORBA is the ORB (Object Request
Broker) which is the middleware that establishes client-server
relationships between objects.
The CORBA standard is maintained by the Object Management Group (OMG), a
consortium of over 800 leading high-tech corporations; pretty much
every company not based in Redmond, WA. Microsoft offers their Component Object
Model (COM) as an alternative to CORBA. COM-based
technologies are a complex, fragile collection of incremental
solutions whose success is due more to Microsoft's platform
dominance rather than any intrinsic merit.
Leading CORBA vendors and their products include Iona's
Orbix and Inprise's Visibroker.
There are a number of robust open-source implementations as well,
including TAO (The
ACE
ORB) and MICO. The examples
in these tutorials are based on TAO.
Why is CORBA good?
- Location transparency -- CORBA offers an
industry-accepted standard for interprocess communication. All
of the objects with which your application interacts appear as
if they were local to your address space, even though they may
actually reside anywhere on your heterogeneous network or even
the Internet.
- Interface Definition Language (IDL) -- CORBA requires
a programmer to define the behavior of an application in terms
of abstract interfaces. This provides a uniform means of
describing the overall architecture of a system.
- Implementation independence -- Because the CORBA
specification is comprised entirely of interfaces and makes no
assumptions about implementation, your CORBA applications should
be interoperable (theoretically) with any vendor's compliant ORB
core and Common Object Services, as well as alternate
implementations of your own application services.
- Language independence -- CORBA "mappings"
exist for a variety of programming languages including C++,
Java, Smalltalk, C, COBOL, and Ada. There is even a mapping
for Perl!
- Standard Common Object Services -- The OMG has
defined generic solutions to problems common to most all
distributed systems. For example, the Naming service defines
a standard means by which objects may advertise their services
and obtain references to other objects whose services they may
require; a "white pages" pattern, if you will.
- As a side effect of learning CORBA, a programmer will gain
at least some knowledge, if not expertise, in three programming
areas: object orientation, concurrency and remote procedure
calls.
Why is CORBA bad?
Make no mistake about it: CORBA is difficult to learn and
impossible to master. Ironically, CORBA is bad for many of the same
reasons it is good.
- Language independence -- To support multiple
languages, some of which are not object-oriented, there is a
perceived awkwardness to some aspects of CORBA. For example,
function overloading is not allowed, and memory allocation
issues can be tricky. Of course, in garbage-collected languages
like Java and Smalltalk, memory issues are nonexistent (not
entirely true, but go with me on this), making CORBA code
relatively "clean" and straight-forward. The same cannot be
said of C and C++.
- Standard Common Object Services -- The OMG has
over 800 members, and getting 800 people to agree on anything
will involve some compromise as to what should be considered
"standard."
- A moving target -- CORBA is an
ambitious standard, covering many aspects of object-oriented
distributed computing. It is constantly expanding and adapting
to new domains, periodically reviewed and often revised.
Fortunately, the ORB core and the more mature services (Naming,
Event, Trading) are relatively stable.
- CORBA requires at least some knowledge and perhaps some
expertise in three notoriously difficult programming
areas: object orientation, concurrency and remote
procedure calls.
Good CORBA references
- Books:
- Web sites:
- Usenet:
Back to... [ Corba Tutorials ]
Jim Crossley
Last modified: Fri Mar 19 16:17:17 EST 1999