Yes. First of all, since you can call C functions from C++ you can access all the DCE services from a C++ program. But that will not give you the benefits of C++. There are several packages that provide a C++ interface to DCE. They different quite a bit in style and approach, so you'll need to consider them carefully in light of your own needs and preferences. Objtran was produced by Citibank, and is available by anonymous ftp at ftp://wilma.cs.brown.edu/pub/Objtran.tar.

The Open Group maintains an Open Software Registry, which contains information about DCE products, among others. Access is free, but you must register. The registry is available on-line at http://www.opensoftware.com/ Once you get in, you can search for DCE, and your favorite platform or other criteria. Hint: A search using "DCE" as the product name will find only those products whose listed name starts with DCE.

First, DCE provides services that can be found in other computer networking environments, but packages them so as to make them much easier to use. For example, the DCE Remote Procedure Call (RPC) facility provides a way of communicating between software modules running on different systems that is much simpler to code than older methods, such as using socket calls. Second, DCE provides new capabilities that go beyond what was available previously.

DCE RFCs are requests for comments for ongoing DCE development. They are similar in concept to the Internet RFCs. Nothing in there is promised from by Open Group. They are a formal way to pass ideas among DCE development partners. You can access them by WWW (or gopher) by: http://www.pilgrim.umass.edu/pub/osf_dce/RFC/rfc-index.html

DCE is fully supported on most major platforms, including all major Unix platforms and many non-Unix platforms. Most vendors support at least the "secure core" which means all of the DCE services except the Distributed File Service and X.500 interface to the Global Directory Service. Some products are client-only, which means that the actual servers for the DCE services are not provided: Directory Service, Security Service, Time Service.

The OSF calls the specification an Application Environment Specification, or AES. The AES documents both the software programming interfaces and also the communications protocols employed by DCE. Thus it would be possible, in theory, for someone to build a compatible implementation without using the code from the Open Group. The AES for RPC, Time, and Directory services have been accepted as standards by X/Open. The AES for Security is currently undergoing review.

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.

IDL stands for "Interface Definition Language," and the idea of using a special language to define the interface between entities is not unique to DCE. In particular, OMG's IDL for CORBA is used for the same purpose as DCE's, but the two languages are not identical; see Q 1.08 for more information. There are other Interface Definition Languages as well. IDL also stands for "Interactive Data Language", which is a completely unrelated product.

Performance testing at several user organizations has shown that DCE RPC performance is similiar to other RPC implementations when doing the same things. The throughput and response times for a series of remote procedure calls is similiar. The use of features in DCE not present in other implementations may consume additional time and resources. For example, name-based binding may required additional time, depending on the number of directories traversed.

DCE does not track this information, does not supply any tools to help collect this information, does not provide any hooks in the security server to allow you to collect this information. If you must track who is logged in, you'll need to build your own service to maintain the information. An obvious approach is to capture login and logout events and report them to some central location; this requires that you be able to instrument all login/logout commands on hosts within your cell.

Windows NT comes with an RPC which interoperates with DCE RPC. Windows 95 apparently provides this interface as well. However, it is not quite the same as DCE. The wire-level protocol is the same as DCE RPC, so applications running on NT can communicate with DCE applications on other platforms. However, the application source code is not instantly portable. Microsoft changed the format of procedure names and moved the status result from a parameter to the function value.

Documentation on DCE should be supplied with vendor products. The Open Group sells complete sets of documentation. The DCE set consists of 14 volumes. The three volumes of specifications (AES) can be purchased separately. Information on DCE documentation available from The Open Group can be found at: http://www.opengroup.org/publications/catalog/dz.htm. Order documentation by contacting The Open Group via E-mail at: sales-team@opengroup.

In October 1994, Digital Equipment Corporation and Hewlett-Packard released into the public domain the RPC implementation used by DCE. This code includes the IDL compiler and the RPC runtime. It does not include any of the other services: DTS, CDS, Security, DFS. In fact, it is not a sufficient base for a client machine, as it does not include the CDS, DTS, and security clerk processes that are normally required. Be warned that building anything from this release is not a simple matter.

Yes. Besides the Open Group itself, there are local DCE users groups in several areas. Changes in the set of users groups have proven difficult to track in this FAQ, so contact the Open Group to find the user group nearest you.

interface is a set of remote procedure call operations and associated data. Every interface contains one or more operations. An operation is an actual remote procedure. Each operation may have input and output parameters associated with it, just like any procedure call.

Yes. A client can use as many different services as it needs. To code such a client, simply include the header files for all the RPC interfaces used, and code each call the same way you would if using that interface in isolation.

Yes. A client can connect to multiple servers providing different services, and/or multiple servers providing the same service. To use multiple servers with the same interface, the client must obtain a binding handle for each server and use explicit handles in the RPC.

Yes. A server can provide service on multiple interfaces simultaneously. A common example is a server that exports an application interface and a management interface. To code such an application, repeat the calls to rpc_server_register_if(), rpc_ep_register(), (and rpc_ns_binding_export() if you do that sort of thing in your server) for each interface, before calling rpc_server_listen().

Certainly it is reasonable to plan on cells with thousands of nodes and perhaps tens of thousands of users. The University of Michigan Center for Information Technology Integration has done a study in which they added 50,000 entries to the Cell Directory and to the security registry. Their results are reported in technical reports 93-12 and 94-1. See Q 3.01 for the ftp site for CITI tech reports. Lexis-Nexis has a more recent study in which they added 400,000 accounts to the DCE registry.