DCOM Explained
by Rosemary Rock-Evans
Digital Press
ISBN: 1555582168   Pub Date: 09/01/98

Previous Table of Contents Next


DCE Threads enables the programmer to write client and server processes that incorporate support for multithreading, with protection of shared resources, synchronization of the threads, scheduling of activities, and resolution of Unix signals and errors. Perhaps of most importance, however, is that this service is the same on all platforms on which DCE runs. So, if a client or server wants to multithread, they can, knowing the resulting application will be portable. As we saw earlier, Microsoft did not use the DCE Threads service in DCOM, but it is more than likely that some of the other suppliers of DCOM on other non-Windows platforms will, particularly for non-Unix platforms.

Security services-DCE provides authentication and authorization services and can support encryption. Authentication services enable the client to prove its identity to the server. Authorization services are used by the server to regulate access to resources. Once the client has proved it is authentic, a check is then made to determine whether the client is authorized to use the services/resources requested. DCE Security service uses the Data Encryption Standard (DES) to support encryption.

The system works on the basis that every client must prove it is authorized to use a server to the server itself. Because access to every DCE resource—directories, files, printers, and so on—is controlled by the server, the server’s demands for authentication and authorization provide the network security required.

Security checks are applied not only to application servers, but also to DCE servers such as the Cell Directory Service. In effect, every time any client—be it a DCE client or an application client—requests a service, its authenticity and authentication are checked and optionally the requests and replies are encrypted. Encryption is a developer-controlled service and is only provided if requested.

Microsoft did not use the DCE security services in DCOM, but used the Windows NT services. There are plans, however, to support DCE’s security services as one option—we will be looking at this in the chapter on security.

The Distributed File Service (DFS)- actually works much like an application because it uses the underlying DCE services for distribution. It provides a single integrated file system that can be used by all DCE users to share files and the information in those files across a network of machines running different operating systems. When you install and configure a DFS server on a host, the DCE Local File System exists alongside the native file system.

Everyone using DFS has their own directory in the file system and uses the same interface to move around it. End users use native operating system commands to control directory and file operations. So, for example, a Unix user would use cd to change directories, ls to list directory contents, and mkdir to create new directories. DFS also has some extra commands to show things like the location of files.

To speed operation and provide some resilience to network failure, DFS has a cache manager which stores versions of the retrieved data in a portion of the local disk and then writes it back to the file server after the application has finished. Microsoft did not implement DFS and has no apparent plans to do so.

The Functions of the RPC Service

We have looked at what an RPC is, what MS RPC is, and how it relates to DCE RPC and the DCE standard. Now we will take a specific look at what the MS RPC actually does in more detail—the functionality it provides. The main functions provided by MS RPC are, as we saw, to:

  Pack and unpack the data in the message
  Perform data format conversion
  Pack and unpack the data into buffers ready for transmission
  Establish sessions
  Handle the network calls
  Coordinate transmission
  Handle faults

Packing/Unpacking the data in the message

The code generated by DCOM in the proxy objects and stub objects handles the packing and unpacking of the data for the developer. Developers define the object, the functions to be called, and the data to be input and output using the Interface Definition Language. The data structures supported thus depend on the structures supported by that language; there are no specific restrictions on the types themselves.

But, since MIDL is C++ like, its support of data types is also going to be C++ like. This means that data types used in other languages such as Java hash tables, primitive data types, vectors, bit numbers, and high precision numbers that have no equivalent in C++ could not be exchanged. There are normally no limits to the length of the call data.

Translation of data formats (from sending to receiving machine format)

Procedures in distributed applications often run on machines which use different data storage formats, which again requires application code to translate the formats. The conversion performed by a product such as an RPC system sorts out the differences between data formats. Thus, for instance, Tandem and DEC define byte positions within a 16 bit word differently. The middleware contains library routines called by the stub code that convert data formats between the systems from ASCII to EBCDIC and from big endian to little endian.

You may think that this is trivial code, but those who are using middleware that does not support data format conversion, or building distributed systems without using middleware, can tell you that data format conversion is anything but trivial. In practice, two formats are used by DCOM as the “on the wire” formats for transporting the data—NDR and UDR.

  NDR-NDR—Network Data Representation—is used for communication between MS RPC and DCE RPC and, as such, between DCOM on Windows NT and DCOM on other platforms. DCOM uses the DCE standard to handle data format translation. NDR is a neutral in-between format in which the reader “makes right.” Conversion using NDR is achieved at both the client and server ends into this neutral format.
  UDF-UDF—Uniform Data Transfer is the format used to exchange data between objects on the same machine or between machines of the same type.

Data format conversion is made easier because the stub has the format of the data being passed—it knows what data is being sent and returned and its format. In messaging systems, where a message is sent across rather than a call to a function, the middleware has no idea what data is being sent across and data format conversion has to be tackled in other ways. We will be looking at this problem in the chapter on MSMQ, as it provides a message queuing service.


Previous Table of Contents Next