Featured White Paper
Download Now
Improving productivity and saving money with an Executive Assessment
What is the relationship between DCE and CORBA?There is not a lot of direct relationship. DCE and CORBA are tools to help you build distributed systems. Each has its advantages and disadvantages. Use of one will not hinder future use of the other. DCE provides a lower-level programming model than does CORBA. DCE is not fully "Object-Oriented". DCE has far better inter-operability than (current) CORBA products. DCE is an optional interoperability mechanism in the CORBA 2.0 specification. The long answer: In order to understand the relationship between DCE and the Common Object Request Broker Architecture (CORBA) of the Object Management Group (OMG), it is necessary to consider the past, the present and the future. Past - Historically, the object paradigm has been viewed as a break with procedural styles of the past. Objects, which encapsulate data and procedures behind an external interface, are often contrasted with other approaches where procedures and data are treated separately. In this context, DCE is a descendant of the procedural school which emphasizes the decomposition of programs into procedures and achieves distribution by locating some of those procedures remotely. Thus there was a tendency for the object community, including the OMG, to view DCE as technology which was obsolete before it was available. However this view ignored the fact that designers of distributed systems had for a long time recognized that the most successful approach to developing distributed systems was to created encapsulated objects that can only be accessed via well defined interfaces. Thus the cornerstone of DCE RPC is the interface definition language (IDL) which allows the external attributes of a set of server operations to be specified. Furthermore, the name-based binding mechanisms of DCE were extended to include the ability to bind to a server based on the object instances which it supports. These object binding mechanisms also allow the transparent selection among multiple implementations of the same server operations based on the type of the specified object. In object terminology this is called polymorphism. The DCE notion of a server supporting interfaces consisting of one or more operations is so close to the notion of an object which provides one or more methods, that it should be no surprise that CORBA defines an IDL which differs from DCE IDL in only a few significant respects. Principal among these is that in CORBA IDL every call must specify an object, which is used in determining the server to use. DCE can do this as well, but there is more work involved and it is optional. Another difference is that CORBA IDL allows an interface to be defined as a extension of one or more other interfaces, this is called interface inheritance. DCE does not permit interface inheritance, but may in the future. Implementation inheritance is not specified by either DCE or CORBA. The use of object oriented techniques and principles should not be confused with using an object oriented language. Object oriented designs can be expressed in procedural languages, and in fact most of the current object environments supported C before supporting C++ or Smalltalk. Therefore, the fact that the DCE API is implemented in C is no barrier to using it to create a distributed object system. In fact, CORBA specified C language bindings first. Present - CORBA should not be viewed in isolation, but in the context of all of the OMG's standardization efforts. OMG has defined a reference architecture (OMA) and has defined or is defining standards in a broad range of areas, including: databases, events, lifecycle, transactions, persistence, security, naming and relationships. Viewed in this way, OMG's activities are much more ambitious and broader in scope than DCE. A recent addition to CORBA, as a part of the CORBA 2.0 work was the definition of the means of interoperability between ORBs. CORBA 2.0 defines one mandatory and two optional mechanisms. The mandatory means is a new, lightweight protocol called UNO. The optional means are 1) via a gateway and 2) via an alternative protocol definition. At the present the only alternative protocol that has been defined is DCE RPC. Many people who had hoped that DCE would be selected as the mandatory protocol were disappointed at this result. However, it should be observed that DCE is endorsed as alternative protocol and that several vendors have committed to providing ORBs that inter operate via DCE. Another difference between DCE and the OMG standards is one of general philosophy. DCE has been defined quite rigorously in a series of documents published by X/Open. There is a set of conformance tests that are available to anyone. Any product passing these rigorous tests can be branded as DCE, without necessarily being based on the Open Group code. Several vendors, including Microsoft and Tandem have reverse engineered significant portions of DCE. OMG standards vary considerably in their level of detail, but in general, aim at a much looser level of standardization. In some cases, the standard merely specifies an object interface and some general semantics. This approach is a deliberate attempt to encourage diverse solutions which may be applicable in different environments. Even where specifications are relatively tight, for example in the area of CORBA portability, there is still room for considerable interpretation, as witness the fact that there is at least one company that provides consulting services on how to make CORBA applications compliant in practice. At the present time, CORBA-compliant products and products that work with them do not provide a scaleable infrastructure suitable for large environments. Key features such as concurrence mechanisms, security and distributed transactions are not currently available. In contrast, DCE provides proven heterogeneous interoperability and most of the capabilities required by robust, production applications. Additional capabilities can be obtained by means of third products, such as transaction monitors built upon DCE. This situation will change over the next 2-3 years from a combination of standardization work by OMG and new product development by vendors. Future - Most authorities agree that in the long term object technology will be the basis for building large scale distributed systems. In addition to the principle of encapsulation, object- based systems allow systems to be built up, evolve and be reconfigured as needed because of their ability to dynamically bind requesters to objects that provide services. There are many specific issues concerning the properties of distributed object systems that are the subject of research and debate. It is also clear that there are some features of existing local object environments and languages that will not scale effectively to large scale distributed systems -- dynamic inheritance is one. Never the less, the general direction of the future is clear. Clearly, the high level of interest in OMG defined standards comes not from current products, but from their exciting future potential. There is a natural tendency to compare DCE's current capabilities with the promise of CORBA's future. However, DCE is also evolving and will likely add additional object oriented features in the future. For example, HP is offering a DCE C++ class library which is expected to eventually become a standard part of DCE. Where DCE was built by integrating existing software, OMG has chosen by and large to start with a clean sheet of paper. The idea is to be better able to implement object oriented constructs without the baggage of features carried over from previous systems. However, OMG faces great challenges. Object theory is currently in a great state of flux. Experts disagree on very fundamental issues about what features are necessary, useful or harmful. Developing standards under these conditions is extremely challenging. OMG's approach to date has been to compromise and allow multiple alternatives. It is unclear whether this will succeed in the long run. Does the conclusion that future distributed systems will be object- based mean that it is a mistake to build distributed systems today using DCE? The answer is no for several reasons. First, many organizations cannot afford to do nothing for several years. End users have pressing needs for robust, scaleable systems today. For many organizations, waiting would mean attempting to catch up with competitors who will have a tremendous head start. Second, as this brief discussion has shown, it is possible to employ object techniques when developing distributed applications using DCE. Carefully designed systems will be able to take advantage DCE features such as dynamic binding and polymorphism and converge with CORBA-compliant systems as they mature. Third, if object environments are to be successful in supporting industrial-strength distributed systems, they will have to address the problems that DCE addresses. The skills and techniques developed in working with DCE will be directly applicable to distributed systems environments of the future. This applies not only software developers, but also to operations personnel, planners, even business managers. Further, the likelihood that DCE will be at least one technology for CORBA interoperability, implies that the eventually migration of applications which use DCE directly to an object environment should not present any insurmountable difficulties. Finally, your direct experience in developing and operating robust distributed systems will provide you with great insight into the important characteristics of distributed systems environments as they apply to your organization's applications. This knowledge is vital to the shaping of successful tools of the future. History has shown that vendors and standards bodies, left to their own devices, will often miss the mark. . AcknowledgementsACK: Thanks to the following, who provided net news and email messages from which this information is gleaned. Compiled by Jon Mauney. (Corrections are actively solicited.) Hal Lichtin, Open Software Foundation |
