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 resourcedirectories, files, printers, and so onis controlled by the server, the servers 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 clientbe it a DCE client or an application clientrequests 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 DCEs security services as one optionwe 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.
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 detailthe functionality it provides. The main functions provided by MS RPC are, as we saw, to:
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 dataNDR and UDR.
Data format conversion is made easier because the stub has the format of the data being passedit 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 |