pitfalls that lead to bugs, particularly
with respect to thread safety, exception safety, and memory management.
A number of other examples of overly
complex and poorly designed APIs can
be found in the CORBA specification,
such as the naming, trading, and notification services, all of which provide APIs
that are error-prone and difficult to use.
Also, CCM configuration is so complex
it cannot be used productively without
employing additional tool support.
Poorly designed interfaces and language mappings are a very visible part
of any technology because they are the
“coal face” of software development:
they are the point at which developers
and the platform meet, and their usability and safety has major impact on
development time and defect count.
Obviously, any technology that suffers
from endemic complexity does little to
endear itself to developers, and does
even less to endear itself to managers.
Complexity also arises from architectural choices. For example, CORBA’s
IORs (interoperable object references)
are opaque entities whose contents are
to remain hidden from developers. This
is unfortunate for three reasons:
˲Opaque references pretty much
force the use of a naming service because clients cannot create object references without the help of an external
service. This not only complicates system development and deployment, but
also introduces redundant state into
the system (with the concomitant risk
of corrupting that state) and creates an
additional failure point.
˲Opaque references considerably
complicate a number of APIs. For example, CORBA’s interceptor APIs would be
far simpler had object references been
˲ Opaque references require remote
calls to compare object identity reliably.
For some applications, the overhead of
these calls is prohibitive.
Another source of complexity is the
type system. For example, CORBA’s interface definition language provides
a large set of types, among them unsigned integers, fixed-point and extend-ed-precision floating-point numbers,
bounded and unbounded sequences,
as well as arrays, and an “Any” type that
can store values of arbitrary type.
Supporting these types complicates
many APIs (in particular, the interfaces
is used mostly
to wire together
that run inside
is protected from
the outside world
by a firewall. it
is also used for
sector in which
coRBa is actually
use is in decline
and it cannot be
but a niche
for introspection and dynamic invocation) and leads to subtle portability
problems. For example, Java does not
support unsigned types, so use of an unsigned integer in an interface can lead
to overflow problems when a Java client
communicates with a C++ server. Similarly, on platforms without native support for fixed-point or double-precision
floating-point numbers, implementations must emulate these types.
Emulations are difficult to implement such that they behave identically
across platforms, and they require additional APIs. This adds further complexity and is a source of hard-to-diagnose
Finally, some of the OMG’s early object services specifications, such as the
life cycle, query, concurrency control, relationship, and collection services, were
not only complex, but also performed
no useful function whatsoever. They
only added noise to an already complex
suite of specifications, confused customers, and reinforced CORBA’s reputation of being hard to use.
Insufficient Features: CORBA provides quite rich functionality, but fails
to provide two core features:
Security. CORBA’s unencrypted traffic is subject to eavesdropping and man-in-the-middle attacks, and it requires a
port to be opened in the corporate firewall for each service. This conflicts with
the reality of corporate security policies.
(Incidentally, this CORBA shortcoming
was major factor in the rise of SOAP. Not
having to open a port in the corporate
firewall and sending everything via port
80 was seen as a major advantage, despite the naïvety of that idea.) The OMG
made several attempts at specifying security and firewall traversal for CORBA,
but they were abandoned as a result of
technical shortcomings and lack of interest from firewall vendors.
Versioning. Deployed commercial
software requires middleware that allows for gradual upgrades of the software in a backward-compatible way.
CORBA does not provide any such versioning mechanism (other than versioning by derivation, which is utterly inadequate). Instead, versioning a CORBA
application generally breaks the on-the-wire contract between client and server.
This forces all parts of a deployed application to be replaced at once, which is
typically infeasible. (This shortcoming