Comparing DCE and CORBA

MITRE Document MP 95B-93 (March 1995)

Thomas J. Brando /


Many people perceive DCE and CORBA as competing technologies. Indeed, both support the construction and integration of client-server applications in heterogeneous distributed environments. Comparisons typically focus on differences between individual capabilities or on differences between the maturity of specifications and products that conform to them. There is a fundamental difference between DCE and CORBA, however, that we feel far overshadows either of these criteria as a basis for selecting a distributed computing platform. This document summarizes the main features of DCE and CORBA, presents what we feel is the most important difference between them, discusses differences between individual capabilities and the maturity of both specifications and products, and concludes with our view of how an organization should select the technology most appropriate to its distributed computing goals.


The author wishes to acknowledge and thank Michael J. McGlynn for his technical input regarding DCE, his comments on drafts of this document, and his help designing the illustration of the DCE architecture in Figure 2.

This document was written at The MITRE Corporation by the Distributed Object Management Integration System (DOMIS) project, which is funded by the Air Force Electronic Systems Center. The project office is at Rome Laboratory, Griffiss Air Force Base, Rome, New York. The project officer is Carl DeFranco, RL/C3AB. The project's principal investigator is Dr. Myra Jean Prelle, MITRE.

Table of Contents

List of Figures

1. Introduction

Many people perceive the Open Software Foundation (OSF) Distributed Computing Environment (DCE) and Object Management Group (OMG) Common Object Request Broker Architecture (CORBA) as competing technologies. Indeed, both support the construction and integration of client-server applications in heterogeneous distributed environments, and both do so in very similar ways with very similar capabilities.

Figure 1 depicts at a very high level the manner in which service requests are handled by DCE and CORBA. Both define an Interface Definition Language (IDL). DCE IDL is based on the C programming language; CORBA IDL is based on C++. IDL is used to define the interface that a server implements, that is, the set of services that clients may request of it. Both DCE IDL and CORBA IDL compile into client and server stubs. A client application calls a client stub to request a service. The client stub interfaces to the runtime system, which eventually invokes server code that implements the requested service through the appropriate server stub.

Figure 1. Requesting Services Using DCE or CORBA

The transmission of service requests and responses between clients and servers is handled by both DCE and CORBA so that applications need not deal with concerns like: where clients and servers are located on the network; differences between hardware platforms, operating systems, and implementation languages (for example, data formats or calling conventions); networking protocols; and others.

There are many other similarities between DCE and CORBA, as one would expect. However, our purpose here is not to present a litany of the similarities between these two technologies. It is our intention to examine how they differ from one another.

Comparisons of DCE and CORBA are commonplace; however, they typically focus either on differences between individual capabilities or on differences between the relative maturity of specifications and of products that conform to them. There is a fundamental difference between DCE and CORBA, however, that we feel far overshadows either of these criteria as a basis for selecting a platform for distributed computing.

The purpose of this document is to discuss the differences between DCE and CORBA on all of these levels. Before doing so, we summarize the features that DCE and CORBA offer. After presenting what we feel is the most important difference between the two technologies, we discuss the differences between the individual capabilities they provide and the relative maturity of both the specifications and the products that conform to them. Then we present our view of how an organization should select the technology most appropriate for its distributed computing goals.

2. Overview of DCE

DCE supports the construction and integration of C-based client/server applications in heterogeneous distributed environments. Figure 2 shows the various elements that comprise the DCE architecture.

Figure 2. OSF DCE Architecture

DCE Executive

The DCE Executive consists of the following components:

DCE Extended Services

DCE Extended Services currently consist of the Distributed File Service (DFS) alone. The DFS is a DCE application that implements a single logical filesystem that is available (through Directory Services) throughout an entire cell and across cell boundaries. DFS supports replication of files for availability and fault-tolerance and log-based recovery from hardware failures.

The remaining components that appear in Figure 2 as DCE Extended Services are vestiges of OSF's Distributed Management Environment (DME), which failed to obtain vendor buy-in and has ceased to exist as an entity in its own right. These components are shown in dashed boxes because it is not clear at this time whether they will be incorporated into future releases of DCE. The Network Management Option would provide a means for management applications to access management information using standard network management protocols (CMIP and SNMP). The Event Service would provide a common way for system and user applications to generate, forward, filter, and log events

The Bibliography lists sources of additional information about DCE.

3. Overview of CORBA

CORBA supports the construction and integration of object-oriented software components in heterogeneous distributed environments. Figure 3 shows the various elements that comprise the CORBA architecture.

Figure 3. OMG CORBA Architecture

Object Request Broker

An Object Request Broker (ORB) provides a communication infrastructure for invoking operations on objects transparently with respect to where they are located on the network, the types of hardware and operating system platforms on which they execute, differences in data representations between platforms, the languages in which objects are implemented, and network transports used to communicate with them. CORBA specifies all of the functions that must be provided by an ORB and a set of standard interfaces to those functions.

CORBA Services

CORBA Services are services that are essential for implementing objects. The CORBA Services that have been specified thus far by OMG include:

CORBA Services that are in the process of being specified and are expected to be completed in 1995 include:

CORBA Services that are not yet in the process of being specified include:

CORBA Facilities

CORBA Facilities are useful for constructing applications across a wide range of application domains. They are divided into Horizontal CORBA Facilities, which are typically more user-oriented, and Vertical CORBA Facilities, which support specific application domains. The Horizontal CORBA Facilities currently identified by OMG are grouped into four areas:

No Horizontal CORBA Facilities have been specified as yet. The first CORBA Facilities RFP was issued in October of 1994 for Compound Document Facilities (Compound Presentation and Compound Interchange). Further RFPs will be forthcoming in 1995.

The Vertical CORBA Facilities currently identified by OMG (as a result of responses from interested vertical market segments to an OMG RFI) are: Accounting, Application Development, Computer Integrated Manufacturing, Currency, Distributed Simulation, Imagery, Information Superhighways, Internationalization, Mapping, Oil and Gas Exploration and Production, Security, and Telecommunication. No Vertical CORBA Facilities have been specified as yet.

The Bibliography lists sources of additional information about CORBA.

4. The Fundamental Difference Between DCE and CORBA

The fundamental difference between DCE and CORBA is that DCE was designed to support procedural programming, while CORBA was designed to support object-oriented programming. Object-oriented programming environments are usually characterized by their support for:

In addition to these common characteristics, object-oriented programming environments usually support a style of programming in which:

CORBA supports all of the common characteristics and programming styles described above, with the possible exception of creating new classes at runtime. We believe the creation of new classes at runtime may be enabled by recently adopted CORBA 2.0 specifications. In particular, we refer to additional Interface Repository operations for adding information to a repository at runtime and a Dynamic Skeleton Interface, which supports the implementation of servers capable of handling requests for objects whose types are unknown at compile time.

Distributed procedural programming environments such as DCE support a different set of capabilities than those described above. The basic approach to distributing a procedural program is to:

  1. Partition the program's data and the functions that manipulate the data into servers;

  2. Distribute those servers across multiple hosts; and

  3. Change function calls to RPCs, as appropriate.

This style of programming does encapsulate data and functions in servers, because the only way to access the data is through the server's RPC interface. It does not protect any of the data within a server from access by any of the functions in the server, however. Nor does it support abstraction, inheritance, polymorphism, or the dynamic style of programming described above.

DCE does have additional capabilities that begin to overlap with traditional capabilities of object-oriented systems:

One can argue that these features support some of the characteristics of object-oriented systems described above. The object type UUID does indeed support some form of abstraction and polymorphism. The important distinction to be made here is that procedural programming is not object-oriented programming, although it can be used to implement an object-oriented programming environment, just as C is often used to implement C++ (that is to say, C++ is often pre-processed into C before compilation).

The analogy between C and C++ is a good one. Many CORBA-conformant ORB vendors (DEC, HP, and IBM, for example) are implementing ORBs on top of DCE. The desirability of the object-oriented approach even within the DCE community is evidenced by several efforts to provide C++ interfaces to DCE [Dilley, Leddy, Mock, Viveney]. The OODCE RFC [Dilley] relates DCE and CORBA as follows:

"...our work focuses on integrating C++ within the existing DCE system infrastructure, simplifying the use of the DCE object model.

"OMG CORBA will address creating distributed object systems in C++; some implementations will run on top of DCE. CORBA IDL provides for interface inheritance, which DCE IDL is lacking, and provides a more C++-like syntax for interface specification. The CORBA runtime environment provides a richer set of object invocation and passing than the DCE environment.

"We suggest that our work may assist in the migration from DCE to CORBA by providing an intermediate C++-based distributed object system until CORBA implementations are widely available."

5. Differences Between Individual Capabilities

Although we feel that the most significant difference between DCE and CORBA is in the style of programming each is intended to support, there are inevitable differences between the individual capabilities they provide. For example:

6. Maturity of the Specifications and Conformant Products

DCE Ontogeny

OSF released DCE 1.0, including all the DCE components described above, in 1992. In addition to specifications, OSF delivered a reference implementation to vendors. By 1993, the first DCE implementations were available. A partial list of current DCE vendors includes:

OSF released DCE 1.1 to vendors late in 1994, and vendors are expected to release their implementations by mid-1995. DCE 1.1 provides for enhanced auditing and the X/Open-approved GSSAPI and Extended Registry Attributes (ERA). These will permit enterprises to bring non-DCE domains under the DCE security umbrella for common enterprise-wide security administration.

OSF expects to release DCE 1.2 to vendors in two phases: DCE 1.2.1 in November of 1995 and DCE 1.2.2 in July of 1996. The primary theme for this release will be to remove obstacles to broad end-user deployment of DCE. The focus areas for this release are currently administration, ease of programming, support for legacy systems, scalability, security, and DFS enhancements.

While DCE continues to evolve, a number of large end-user organizations have committed to basing their next-generation, enterprise-wide information systems on DCE.

CORBA Ontogeny

OMG adopted the CORBA 1.0 specification in late 1991. This included no CORBA Services or CORBA Facilities, nor did OMG release a reference implementation. By mid-1993, the first CORBA-conformant ORBs were available; by late 1993, the first CORBA Services were specified by OMG. A partial list of vendors who are currently selling or developing CORBA-conformant ORBs includes:

At this time, OMG has specified only nine of the CORBA Services and none of the CORBA Facilities shown in Figure 3. Furthermore, few implementations of the CORBA Services that have been specified are available yet. Nonetheless, several large end-user organizations are prototyping elements of their next-generation, enterprise-wide information systems using CORBA.


Clearly, DCE specifications as a whole are closer to completion than CORBA specifications. This is not surprising, given the ambitious task OMG has undertaken; Figure 3 is impressive in the breadth and depth of services it depicts. It is another matter entirely whether OMG will be completely successful at defining all of the components in Figure 3. As for the maturity of DCE implementations and CORBA-conformant ORBs, there are mature examples of each.

Let us draw the following distinctions:

Regarding Interoperability

It is common to hear that DCE achieved true interoperability in 1992 with DCE 1.0, while CORBA interoperability was only recently specified and has yet to be delivered. Typically, each vendor ports DCE to a specific platform, and interoperability with the reference implementation ensures interoperability among vendors' implementations.

OMG does not deliver reference implementations, only specifications. CORBA 1.0 did not address interoperability between ORBs because it was considered premature pending experience implementing basic ORB functions. As a result, many vendors implemented ORBs on a selection of platforms, providing interoperability across all of the platforms supported by a given vendor. In fact, some of the ORBs that are currently available run on over a dozen different platforms and support interoperable clients and servers across all of those platforms at this time.

Interoperability between ORBs (that is, between ORB vendors) will be a reality in 1995. The Internet Inter-ORB Protocol (IIOP) specified by OMG in December of 1994 [CORBA2] may be supported via bridges that can be developed by end-users or third parties without proprietary information about an ORB or modifications to the ORB. In addition, SunSoft recently made available on the OMG server a public domain implementation of the major components needed to implement an IIOP bridge. We therefore expect to see widespread interoperability among ORBs via IIOP by late 1995 or early 1996. We expect this even with ORBs that use DCE for intra-ORB communication, although interoperation between DCE-based ORBs may be provided via a DCE-specific protocol specified by OMG as well.

7. Choosing the Right Technology

We have stated that the most important difference between DCE and CORBA is their programming paradigms: DCE was designed to support distributed procedural programming, while CORBA was designed to support distributed object-oriented programming. Religious convictions must be tempered with more pragmatic concerns, however.

Comparing the individual capabilities that each gives the developer, CORBA provides a much richer and more powerful environment. Most of the CORBA services have yet to be specified, however. Current DCE implementations provide services that are not yet provided by CORBA implementations (in a standard way): CDS (Naming), Security, DTS (Time), and Threads. The CORBA Naming Service has been specified, and partial implementations are available now. The CORBA Security and Time Services will not be specified until late 1995, and we do not expect to see them available in CORBA implementations until late 1996. OMG has no plans at this time to specify a Threads Service.

If these services are essential to a development effort, the alternatives at present are to use CORBA and implement the required services yourself or use DCE. If you implement to OMG-specified interfaces, your service implementations will eventually become superfluous and code that uses those services will port directly to vendor-supplied implementations, when they are available.

If you decide to use DCE, we suggest doing so with an object-oriented package like DEC's DCE++ [Viveney] or HP's OODCE [Dilley]. This will position you to make the transition to CORBA more easily in the future. In addition, it is important to be aware that the use of DCE datatypes that are not supported by CORBA (pointers, for example, as discussed in Section 5) can make the transition to CORBA significantly more painful.

During the next two years, the object technology that OMG is specifying will migrate down into the operating systems that are delivered with workstations from all of the major vendors. As a result of OMG's recent adoption of CORBA 2.0 specifications that include inter-ORB interoperability [CORBA2], we expect to see CORBA gaining widespread acceptance during the next two years, and we expect that its object orientation and rich set of services will make it the distributed computing platform of choice.

List of References


CORBA 2.0/Interoperability: Universal Networked Objects, OMG TC Document 95-3-10, The Object Management Group, Framingham, MA, March 20, 1995.


Dilley, J., "Object-Oriented Distributed Computing With C++ and OSF DCE," OSF DCE SIG RFC 49.0, October 1993. Also published in Lecture Notes in Computer Science, Volume 731, Alexander Schill (Ed.), Springer-Verlag, 1993.


Leddy, W., and A. Khanna, "DCE++: A C++ API for DCE," HaL document #030-00209, HaL Software Systems, Austin, TX, March 31, 1993.


Mock, M., "DCE++: Distributing C++ Objects using OSF DCE," Proceedings of the International DCE Workshop, Karlsruhe, Germany, October 1993, published as Lecture Notes in Computer Science, Volume 731, Alexander Schill (Ed.), Springer-Verlag, 1993.


Viveney, R., "DCE IDL With C++ Support -- Functional Specification," OSF DCE SIG RFC 48.2, October 1994.


Common Facilities Architecture, Revision 3.0, OMG TC Document 94-11-9, The Object Management Group, Framingham, MA, November 14, 1994.

Common Object Request Broker: Architecture and Specification, Revision 1.2, OMG TC Document 93-12-43, The Object Management Group, Framingham, MA.

Common Object Services Specification, Volume I, Revision 1.0, First Edition, OMG TC Document 94-1-1, The Object Management Group, Framingham, MA, March 1, 1994.

Object Management Architecture Guide, Revision 2.0, Second Edition, OMG TC Document 92-11-1, The Object Management Group, Framingham, MA, September 1, 1992.

Object Services Architecture, Revision 8.0, OMG TC Document 94-11-12, The Object Management Group, Framingham, MA, December 9, 1994.

OSF DCE Application Development Guide, Revision 1.0, Prentice Hall, 1993.

OSF DCE Application Development Reference, Revision 1.0, Prentice Hall, 1993.

Rosenberry, W., D. Kenney, and G. Fisher, Understanding DCE, O'Reilly & Associates, 1992.

Shirley, J., W. Hu, and D. Magid, Guide to Writing DCE Applications, Second Edition, O'Reilly & Associates, 1992.


APIApplication Programming Interface
CDSCell Directory Service
CMIPCommon Management Information Protocol
CORBACommon Object Request Broker Architecture
DCEDistributed Computing Environment
DECDigital Equipment Corporation
DESData Encryption Standard
DFSDistributed File Service
DMEDistributed Management Environment
DNSDomain Name Service
DTSDistributed Time Service
ERAExtended Registry Attributes
GDAGlobal Directory Agent
GDSGlobal Directory Service
GSSAPIGeneric Security Service API
HPHewlett-Packard Company
IBMInternational Business Machines
IDLInterface Definition Language
IIOPInternet Inter-ORB Protocol
NTPNetwork Time Protocol
OMGObject Management Group
OODCEObject-Oriented Distributed Computing Environment
ORBObject Request Broker
OSFOpen Software Foundation
POSIXPortable Operating System Interface for Unix
RFCRequest For Comments
RFIRequest For Information
RFPRequest For Proposals
RPCRemote Procedure Call
SCOSanta Cruz Operation
SGISilicon Graphics, Inc.
SNMPSimple Network Management Protocol
UTCUniversal Time Coordinated
UUIDUniversal Unique Identifier