Millennium, an ongoing project
at Microsoft Research, aims to leverage Microsoft's COM technology
into nothing less than a fully distributed operating system
that will run over conventional networks but exploit high performance
cluster interconnects when and where they are available. For
distributed applications CORBA has enjoyed a significant edge
over COM on several fronts. But can CORBA compete with a Millennium-enabled
COM?
To answer this question we'll review
the origins of COM and CORBA looking for their essential differences
in this context. Then we will survey how Millennium builds on
these COM foundations reaching for distributed nirvana. Lastly
we'll explore what's involved for CORBA to achieve similar goals
and conclude with our expectations of the appropriate targets
for these technologies.
Roots
COM and CORBA have very different
roots. Today's version of COM evolved from Microsoft's need
for a compound document architecture in the Windows environment,
first served by OLE - Object Linking and Embedding. This was
used to allow an Excel spreadsheet to be embedded in a Word
document, for example, including support for full manipulation
of the spreadsheet as though it were running stand-alone.
As COM grew from this basis its
development was strongly shaped by the needs of Windows programmers,
especially those at Microsoft. COM matured into a framework
for building Windows applications, enabling compiled binaries
developed for one application to be reused for another, even
when linked at runtime (the dynamic link library - DLL). Internet
Explorer today stands as a testament for this component style
of program design and implementation as it's primarily a framework
within which many COM components interact.
Through nature and nurture COM
grew up into a technical architecture for designing and building
applications involving large numbers of software components
in a local context - meaning in a single Windows memory
address space.
Over time COM expanded to support
additional languages for implementing components, and most recently
gained support for distributed components by way of DCOM, Distributed
COM. In the recent time frame Microsoft has been partnering
with vendors of other operating systems to support COM objects
outside of the Windows address space. Most notable have been
Software AG, HP-UX, and recently SGI's IRIX.
CORBA's evolution, though today
approaching a destination nearby COM's, began from a vastly
different starting point. In the early 90's hardware and software
vendors sought a way to make applications interoperable and
distributed, while shielding programmers from the software and
hardware mechanisms that would provide translations between
formats and languages and span distributed system boundaries.
So while efficient support for integrating large numbers of
software components within a local context was not an early
requirement, distributivity was, between components coded in
different languages running in differing operating systems on
differing hardware platforms.
The emphasis on diverse components
available to a wide range of equally diverse and also unknown
client applications served as a shaping influence on CORBA.
From this came the definition and specification of services
and common facilities in the Object Management Architecture
(of which CORBA is the most well known aspect).
As CORBA matured it was found lacking
in a number of areas just as Microsoft found COM to be an incomplete
solution. In CORBA's case a compound document model was needed
as well as a method for providing code mobility. This is in
stark contrast to COM which began "as" a compound document model
and inherently provided code mobility as long as all runtime
platforms were the same - Windows.
Java and its derivative technologies,
Javabeans and Enterprise Javabeans, provide CORBA with a means
to assemble software components into a larger whole and to move
software components across address spaces, from machine to machine,
though both of these capabilities are still in the developmental
stage.
We must recognize that both COM
and CORBA are technology "suites", not atomic tools, and the
tools within each suite are not of uniform maturity or development.
As we approach the end of 1998 the biggest difference between
COM and CORBA stems from the areas in which they are mature.
COM is stronger for developing
and deploying systems of large numbers of software components
on the Windows platform. CORBA is superior for distributing
smaller numbers of software components across diverse systems.
As time passes each will mature
in the areas they encountered more recently. COM will become
a potential architecture for distributed systems as more platforms
provide support and DCOM matures. CORBA will improve for applications
where code must be mobile and dynamically assembled into larger
frameworks.
Approaching the Millennium
The Millennium research project
is now entering its third phase. The first prototype was BORG,
a distributed Java VM (Virtual Machine) that ran across a number
of separate machines, fooling the Java objects it executed into
believing they were running within a single Java VM running
on a single machine. This enabled a Java program to exploit
the computational resources of multiple machines without the
need for the programmer to know this when they coded their application.
Next up was Coign, developed at
the University of Rochester by Galen Hunt, the topic of his
Ph.D. thesis. Coign distributes COM objects (compiled binaries)
to the same effect as the Java objects in BORG, meaning the
programmer of the COM objects required no knowledge that these
object would be distributed to different machines and executed
in different address spaces.
Note the exploitation here of two
facilities: the mobility of COM objects allows Coign to distribute
these objects and execute them wherever the computational resources
are found. Further, the facility for remotely invoking the functionality
of a distributed COM component, provided by DCOM, enables this
mobile collection of COM components to continue functioning
as if they were still located within the same address space.
Both capabilities are required
for Coign to pull this off: code mobility and transparent, remote
invocation. We'll return to this point later when we consider
what CORBA requires to provide the same functionality.
With Continuum, the third prototype
of Millennium, now its earliest stages, the lessons learned
with automated distribution of Java and COM objects will now
be applied to COM+ objects. I'll have more to say on COM+ in
a future column of "Information Unbound". Over the summer a
research intern at Microsoft Research layered the DCOM protocol
over the VI Architecture (VIA for short) interface (developed
by Intel, Microsoft, and Compaq). VIA promises to radically
cut the overhead of distributed communications between processors
connected by a reliable medium such as a cluster interconnect.
Consider, then, a cluster of servers
and workstations running Continuum over VIA. Applications designed
and implemented following object oriented principles will have
their objects automatically distributed across the cluster in
such a way as to best exploit the cycles and computational resources
available from moment to moment. Objects so distributed continue
interacting as though they were operating in a single address
space, communicating with each other and moving about the cluster
with the low latencies typically found "within" a multiprocessor,
such as an SMP. Need more power? Add another processor and beef
up the cluster interconnect if needed. As COM is supported on
more platforms these too can partake in the cluster - they needn't
be running Windows to become part of the distributed shared
object space.
CORBA at the Millennium
For CORBA to compete it must, like
DCOM, support remote invocations, and like COM, provide code
mobility. With IIOP the first is a well accomplished fact -
but too slow - milliseconds for a remote invocation instead
of the required microseconds. This could be accomplished with
an ESIOP, CORBA slang for an Environment Specific Inter Orb
Protocol. An ESIOP layered atop the Scheduled Transfer (ST)
protocol (a multi-vendor standards effort derived from HIPPI-6400
and potentially compatible with VIA), would provide similar
low latency connectivity to the "DCOM atop VIA" approach
that Microsoft Research is now taking.
Code mobility requires CORBA objects
that can be moved from platform to platform, without a recompile,
and while retaining the ability to be accessed through a CORBA
skeleton bound to the ORB at the new location. Such functionality
will likely become available, but a standardized form is in
the future and could well require Java for mobility, negating
CORBA's benefit of language neutrality and imposing the performance
overhead of just in time compilation of Java objects into native
machine code.
Overall, the differences between
COM and CORBA's evolution may be preserved into the future.
As COM benefits from Millennium it is likely to continue to
be most appropriate for large collections of tightly coupled
objects - but across assemblies of many machines connected by
super fast interconnects. CORBA looks to retain its strength
across loosely coupled systems, possibly distributed around
the globe, where the availability of a large variety of services
and facilities is of greatest importance. Add to this that each
machine in the ensemble may in reality be a Computing Fabric
Cell of a thousand processors, tightly coupled with dedicated
hardware and even faster interconnects. The result should be
robust distributed systems and services to take us into the
next millennium.
Erick Von Schweber
