Information Unbound Archive 1998 - 2000
An On-line Column by Erick Von Schweber

# 1: Microsoft's Millennium approach to Computing Fabrics presents weighty challenge to CORBA and Java

# 2: Computing Fabrics compared with distributed and parallel software technologies

# 3: Computing Fabrics - The BIGGER Picture
(a 4 part series)

# 3-1: Computing Fabrics extend the cell phone paradigm
# 3-2:
Virtual Personal Supercomputers (VPSCs)
# 3-3:
Computing Fabrics and next generation Interface Devices
# 3-4
Hyper-Reality - A Wild and Crazy GUI
# 4: Is History Repeating Itself?
The low-level procedurality of the past returns to haunt IT.
# 5: Object Based Semantic NetworksTM
Toward a Fusion of Knowledge Representation and the Relational Model



Information UNBOUND # 1

Also see: Computing Fabrics


Millennium a weighty challenge to CORBA/Java
October 5, 1998

Executive Summary: Microsoft's COM has led CORBA for creating applications to be run on a single machine while CORBA has presented advantages for heterogeneous distributed systems. It appears that Millennium will reinforce this distinction but expand the runtime platform of COM from single machines to extremely large assemblies of machines tied together by very high performance interconnects, providing a software-based technology for creating Computing Fabrics.

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.


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


To Contact the authors send mail to
Infomaniacs home is

Copyright 1996-2004 by Infomaniacs. All Rights Reserved.  
Updated October 26, 1998





By Erick Von Schweber
Copyright 1996-2004 by Infomaniacs. All Rights Reserved.
Updated January 22, 2002