MITRE Document MP 95B-93 (March 1995)
Thomas J. Brando / email@example.com
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.
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.
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.
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.
The DCE Executive consists of the following components:
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.
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
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 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 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.
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:
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."
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:
CORBA does not support the use of pointers as, or within, operation parameters. The set of CORBA IDL basic datatypes and constructs for building complex datatypes do not include pointers (although they may be implemented using pointers). This means that a programmer may pass complex structures that contain pointers as operation parameters in two ways. The programmer may write additional code to marshall the actual values addressed by pointers into pointer-free datatypes in the client and then reconstitute the complex parameter with pointers in the server. Alternatively, the programmer may redefine the complex data structure as a collection of one or more objects, since CORBA does support complex structures composed of objects.
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.
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:
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.
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.
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.
|API||Application Programming Interface|
|CDS||Cell Directory Service|
|CMIP||Common Management Information Protocol|
|CORBA||Common Object Request Broker Architecture|
|DCE||Distributed Computing Environment|
|DEC||Digital Equipment Corporation|
|DES||Data Encryption Standard|
|DFS||Distributed File Service|
|DME||Distributed Management Environment|
|DNS||Domain Name Service|
|DTS||Distributed Time Service|
|ERA||Extended Registry Attributes|
|GDA||Global Directory Agent|
|GDS||Global Directory Service|
|GSSAPI||Generic Security Service API|
|IBM||International Business Machines|
|IDL||Interface Definition Language|
|IIOP||Internet Inter-ORB Protocol|
|NTP||Network Time Protocol|
|OMG||Object Management Group|
|OODCE||Object-Oriented Distributed Computing Environment|
|ORB||Object Request Broker|
|OSF||Open Software Foundation|
|POSIX||Portable Operating System Interface for Unix|
|RFC||Request For Comments|
|RFI||Request For Information|
|RFP||Request For Proposals|
|RPC||Remote Procedure Call|
|SCO||Santa Cruz Operation|
|SGI||Silicon Graphics, Inc.|
|SNMP||Simple Network Management Protocol|
|UTC||Universal Time Coordinated|
|UUID||Universal Unique Identifier|