Making Sense of Distributed Objects
David Chappell - December
Given the popularity of both distributed computing and object technology,
its not surprising that distributed objects are hot. But understanding
this technology can be challenging, since it requires some grasp
of both networking and objects. And as if the technical issues werent
tough enough, distributed objects have also engendered some of the
most confusing vendor marketing of the decade.
But with a little care, sorting through both the technologies and
the competing claims of their proponents is not so hard. And the
payoff is worth itdespite the overblown hype, distributed
objects really do matter.
An Overview of the Players
Allowing objects on different systems to work together requires
addressing some fundamental questions. First, and most important,
what exactly is an object? What does one look like, and how is it
defined? Once these questions are answered, the next problem is
to figure out how these objects should communicate. And once we've
specified a basic communication mechanism, other issues arise, such
as how objects find each other and how secure interaction among
objects can be guaranteed.
The Object Management Group (OMG), a consortium of vendors and
user organizations, has defined the Common Object Request Broker
Architecture (CORBA) as a vendor-neutral standard that addresses
these questions. Microsoft, officially a member but not really a
supporter of OMG, has defined its own solutions, embodied in the
Component Object Model (COM) and its networked cousin, Distributed
COM (DCOM). And more recently, Sun Microsystems has provided solutions
to many of these same problems within the environment provided by
Java. In particular, Sun has defined a technology called Remote
Method Invocation (RMI) for accessing Java objects across a network.
Both CORBA and COM/DCOM provide a language-independent object model,
a protocol for communication between objects on different systems,
standard interfaces for accessing useful services, and more. The
Java camp also provides most of these things, with the notable exception
that there's nothing at all language-independent about their work:
everything assumes use of the Java language. Since all three technologies
provide solutions to the same set of problems, they can appear to
be competitive with one another. When you get right down to it,
though, it's usually fairly obvious which one you ought to use to
solve a particular problem. To see why this is so, it's useful to
examine them one at a time.
Its hard to argue with the idea of defining vendor-neutral
standards for distributed objects. Open standards in networking
have made todays connected world possible, with the global
Internet providing the most visible example. Without standards,
the best we can hope for is a diverse set of single-vendor islands.
But in their hearts, most vendors hate standards. Given a choice,
any vendor would prefer to have its own proprietary technology become
dominant. This is neither surprising nor immoralvendors are
in business to make money, after all, and the commoditization wrought
by multi-vendor standards works against high profit margins. Yet
users love standards, and are often reluctant to buy technology
produced by just one company. Whats a vendor to do?
The answer is simple: create CORBA. From a vendors point
of view, CORBA is perfect. The OMG has produced a host of standards,
all created using a relatively open process, to which each vendors
products must conform. Companies selling products based on CORBA
can quite honestly tout their compliance with these standards. At
the same time, however, the technologies defined in those standards
are so loosely specified that vendors are encouraged (and often
even required) to add proprietary elements. This looseness is rarely
mentioned by CORBAs promoters, and since very few customers
actually read the specifications, the illusion of standardization
The reality, though, is that each vendors CORBA-based product
is quite different from the others. While some products can interoperate
for straightforward requests via CORBAs Internet Inter-ORB
Protocol (IIOP), vendors commonly add extra features that rely on
their own proprietary protocols. Furthermore, the application programming
interfaces seen by developers vary significantly. This is why there
is today no serious third-party market in CORBA-based applicationsa
different version would need to exist for each vendors product.
Does this lack of standardization mean that CORBA is useless? Of
course not. Many organizations have successfully used CORBA-based
products to integrate diverse systems. The technologys great
strength is that the successful CORBA-based productsIonas
Orbix, BEAs ObjectBroker, and othersall run on a wide
range of operating systems. If the goal is to connect a diverse
set of machines together using distributed objects, CORBA-based
products can be an excellent solution.
But theyre not standard. When you buy a CORBA-based product,
make very sure that you like both the product and the company that
makes it. While it is possible to create a multi-vendor ORB environment,
doing so intentionally makes no sense. Since different products
have different programming APIs, different security schemes (when
they have security at all), different administrative interfaces,
and other variations, sticking with a single vendors product
will make your life much easier. And since all of the leading CORBA-based
products run on most popular operating systems, theres typically
no need to use more than one of them.
Some CORBA fans argue that, while CORBA began as a very loosely
defined set of standards, it has gotten more completely defined
over time. To these true believers, its only a matter of time
before the OMG defines everything, and CORBA emerges as a true standard.
But weve been hearing this for several years, and while some
of the newer standards are better defined, others are not. Theres
no reason to believe that the vendors who control the process will
ever allow true, complete standards to emergeits just
not in their interest to do so. The aura of standardization that
CORBA carries is a tremendously useful marketing tool, one that
true standards would do little to improve.
If CORBA-based products are largely single-vendor solutions (and
they are), then they would appear to compete directly against Microsoft,
the biggest single vendor of them all. But, in fact, one can make
a very good case that CORBA and COM/DCOM arent competitors
at all. If they were, a user would be faced with choosing between
these two technologies to solve a particular problem. In the event,
though, this virtually never happens.
To understand why, think about the strengths of Microsofts
approach. First of all, unlike the diversity that exists in the
CORBA world, theres only one implementation of COM and DCOM
(this is true even on non-Microsoft operating systems, a topic Ill
return to in a moment). This homogeneity, together with the tremendous
popularity of Windows and Windows NT, has led to an enormous third-party
application market. Furthermore, COM is installed today on literally
hundreds of millions of machinesits a standard part
of the operating system. While DCOMs penetration lags somewhat
(its built into Windows NT 4.0 but must be downloaded from
Microsofts web site for Windows 95), it still greatly exceeds
the installed base of all CORBA products combined. And although
CORBA fans like to criticize COM and DCOM on technical grounds,
claiming that theyre not really object oriented and more,
the truth is that from a purely technical perspective, both technologies
work quite well. In some areas, in fact, DCOM is clearly ahead (every
copy of DCOM includes solid security services, for example, while
most CORBA products provide little or nothing in this area).
Microsofts approach suffers from one obvious weakness, though,
and its a big one: for the most part, COM and DCOM only run
on Windows and Windows NT. There is a quite good implementation
of COM for the Macintosh, and Software AG is valiantly porting DCOM
to various Unixes and to MVS, but its hard to believe that
Microsoft will ever be seriously concerned about operating systems
they dont own. (In fact, in looks like Microsoft's recently-announced
COM+, while it will interoperate with existing COM and DCOM systems,
will itself be available only on Microsoft platforms.) Yet most
organizations have a multi-operating system environment, and although
Windows NT seems likely to become dominant over the next few years,
diversity will never completely go away.
Given all of this, it should be obvious why CORBA and COM/DCOM
arent really competitors. If the problem youre trying
to solve requires connecting objects implemented solely on Windows
and Windows NT, use DCOM. CORBA-based products make no sense here,
if only because DCOM is free while most CORBA vendors (not unreasonably)
actually expect to make a profit on their products. If, on the other
hand, you need to communicate between objects written in multiple
languages in a diverse environment that includes Unix and other
non-Microsoft systems (and probably Windows/Windows NT as well),
then you must use a CORBA-based product todayit's the only
game in town. The choice is simple, and religious debates about
which is the better technology are entirely beside the point. Instead,
its purely a platform issue: the operating systems youre
running make the choice for you. If Software AG and others can make
a go of their DCOM-on-other-platforms strategy, this may change.
For the moment, however, the decision is easy.
Assessing Java and RMI
And speaking of platforms, there's a new one on the block: the
Java environment. It's entirely possible to write Java applications
that run only on a single operating system, something Microsoft
is doing its best to foster. Sun discourages this, however, suggesting
instead that all Java applications be written solely to the operating
system-independent Java environment instead.
Part of this environment is RMI. RMI is significantly easier to
use than either CORBA or DCOM, and so developers have flocked to
it. Neither the leading CORBA vendors nor Microsoft are big RMI
boosters, however, since it competes with each party's favored solution.
Accordingly, both have tried to discourage its growth. Under pressure
from the CORBA world, Sun has announced its willingness to somehow
merge RMI with CORBA's IIOP. But because RMI is designed solely
for Java while IIOP is more generic, there are technical issues
that make this less than a perfect solution. We will probably see
some combination of the two protocols emerge at some point, but
don't hold your breath: OMG is doing the work, and standards bodies
are seldom speedy. For the next year or two, expect RMI and IIOP
to remain distinct, potentially competing protocols.
Microsoft has offered a much more direct expression of its dislike
for RMI: they've simply refused to support it. Given that Microsoft
provides the operating system for the vast majority of desktops
in the world today, this poses a bit of a problem for organizations
that wish to use RMI. One solution for companies that choose Java
is to use Netscape's browser, which includes RMI support, rather
than Microsoft's Internet Explorer, which does not. For organizations
standardizing on the Microsoft browser, however, using RMI means
installing the necessary library yourself on every client--it won't
be built in.
When should you use RMI rather than CORBA or DCOM? The answer is
easy: whenever you can. RMI is simple and straightforward to use,
but it lacks security and other often important services. But if
these limitations are acceptable, if you have a way to guarantee
the availability of the RMI libraries on both your clients and servers,
and, most important, if the objects on both sides will be written
in Java, RMI is the way to go. Its simplicity and support for multiple
platforms make it too attractive to ignore.
But suppose I choose CORBA, you say, because I want to include
some Unix servers and I can't write everything in Java. Dont
I still have to work well with the desktop, i.e., with the Windows
environment? You certainly do, and the CORBA vendors realize this.
Accordingly, they all provide bridges between CORBA and COM. This
allows tools supporting COM, such as Visual Basic and virtually
all other Windows development tools, to use CORBA over the wire.
Its even possible to create specialized ActiveX controls,
components that encapsulate remote access to various pieces of server
functionality. Once this has been done, those components can be
easily plugged into any number of desktop applications, providing
a straightforward and reusable mechanism for accessing legacy applications.
But the story isnt perfect. While the way CORBA and COM look
at objects is quite similar, its not the same. The mapping
between these two object models, then, has a few problems. As is
so often the case in situations like this, basic functions can work
quite well, but more advanced uses become problematic. Gateways
between similar but different solutions have historically suffered
from these kinds of problems, and the COM/CORBA gateway is no exception.
While its creators did an excellent job, the goal of perfect, transparent
interoperability just isnt reachable.
COM and CORBA arent the only two object technologies that
can be usefully combined. Its also quite useful to combine
both COM and CORBA with Java. As mentioned earlier, CORBA's IIOP
will probably be folded into Java's RMI, making it easy to use IIOP
beneath today's RMI API. Somewhat surprisingly, Microsoft goes even
further--its Java virtual machine includes a transparent two-way
mapping between Java objects and COM objects. While Microsoft doesn't
ship RMI, this does make it relatively straightforward to use DCOM
The Bottom Line
If the OMG, back in 1991, had chosen to define and publish complete
standards for distributed objects, the world today might be a very
different place. As it is, they choose to create something that
was closer to a marketing exercise than a true technology standard.
The result is predictable: a good deal of fragmentation in the CORBA
market, with the eventual emergence of a few major players: Iona,
BEA, Visigenics, Expersoft, and a couple of others. But compare
the size and strength of these "major" players with that
of their primary competitor, Microsoft. Despite years of pro-CORBA
hype, market realities tend to have the last word.
Furthermore, COM and DCOM are given away for free, always a tough
price point to beat, and they are very well integrated with the
dominant tools and application on their target platforms (which
is no surprise since Microsoft produces the dominant tools and applications
on those platforms). For shops that are committing to Windows NT
as a server platform for new applications, DCOM will be by far the
dominant choice for distributed objects. If your organization plans
to move to NT as your primary server operating system for new applications,
plan to move to DCOM, too.
For shops that choose to continue to build new applications on
Unix servers and want to use distributed object technology, CORBA
can be the right choice. Choose your vendor carefully, however,
because once youve installed their product, it wont
be easy to change. Theres another use for CORBA, too, one
that has perhaps been the most common so far: integration of existing
applications on diverse systems. Even organizations that arent
building new applications on non-Microsoft operating systems can
make use of CORBA-based products to tie together existing applications,
something they can do very well.
And finally, if your organization has jumped on the Java bandwagon
in a major way, get used to RMI. Its simplicity has some drawbacks,
such as limited support for security, but Java developers are almost
sure to like it. Microsoft's lack of support will be an annoyance,
but it's not an insurmountable problem. Java's promise of being
able to run more or less the same code on all kinds of systems is
undeniably very attractive.
Ultimately, which technology dominates will depend on how popular
Windows NT becomes as a platform for building new server applications.
In my view, the advantages of NTprice, ease of use, a plethora
of available applications, and better integration with Windows clientswill
eventually lead to its dominance. If (or perhaps when) this happens,
the installed based of DCOM will far outweigh that of the alternatives.
Until that day arrives, though, CORBA and Java's RMI still have
a role to play in many organizations.
This article originally appeared in the December 1997 issue
of Ed Yourdon's American Programmer.
design and development by kmcreative.
KMCREATIVE is a Silicon Valley based graphic design firm specializing
in corporate collateral, web design, web development, identity,
medical illustration and product illustration.