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

Previous | Table of Contents | Next

### DCE Services

DCE is a set of specific management services with a communication layer based on Remote Procedure Calls. In effect, the Remote Procedure Call technology provides the foundation of DCE, and the rest of the services implement various management-related tasks such as security, threads, time synchronization, directory services, and distributed file services.

The architecture is layered bottom up from the most basic supplier services such as the operating system to the highest level of consumer services—the application. DCE is a layer of software that sits on top of the host operating system and network services and offers its services to the applications above.

The RPC and Threads services are base DCE services that are available on every system on which DCE is installed. All the other services use these services. So, for example, when a call is made to the Directory service, it is transported using the RPC mechanism. Furthermore, increases on the load to the Directory service are handled internally by DCE using its own thread service—the Directory service simply multithreads itself using the Threads service—complicated but efficient.

DCE’s services are layered so that the user can use one or more services separately or in combination. The application uses only the APIs it requires and does not have to use all DCE’s APIs. It is possible, for example, that a user could use the threads, RPCs, or security service and not use the time or Threads services. It is this ability to use only one or a selection of services that made it possible for Microsoft to simply extract the RPC mechanism and use it on its own for use in DCOM.

DCE services are divided into Fundamental services and Data Sharing services. Fundamental services are aimed at the developer of systems and help him to develop distributed applications. These services include the RPC, directory service, time service, security service, and Threads service.

The Data Sharing services build upon the Fundamental Distributed Services and require no programming by the developer. They include a distributed file system and support for diskless workstations. The services provided and their function are described below:

Time service-The DCE Distributed Time Service (DTS) synchronizes host clocks in LANs and WANs. By having clock synchronization, distributed applications are able to determine the sequencing, duration, and scheduling of events, independently of where they occur. DTS is transparent to the end users of a system and users cannot access DTS directly, but applications which use DTS can schedule events for the user; for example, a conference call scheduling application can use time zone information to determine the best time to schedule conference calls that span multiple time zones. The time service could also usefully be used in transaction processing applications.

Microsoft could have used this time service with advantage when developing DCOM but instead use their own time service in Windows NT. No equivalent service for DCOM on other platforms exists, so if the developer needs a time service he or she may find it useful (if his company uses DCE) to use this service directly.

Directory service-The Directory service is a key component of DCE and acts much like a telephone directory assistance service that gives a person’s telephone number when given a person’s name. By using the Directory service, any resource—person, disks, print queues, servers, and so on—can be contacted anywhere on the network by using their unique name. When the Directory service is given the name, it returns the network address of that resource along with other information associated with the name.

Microsoft, as we will see, does not use the DCE Directory service and uses their own Registry and in future Active Directory service. We will be seeing what happens with DCOM on other platforms in the chapter on other platforms.

DCE RPC-The client RPC runtime routines provided with DCE:

  • Gets the call arguments from the program and prepares then for transmission. This is called “marshaling” in DCE speak.
  • Determine which network transport to use for communication. In reality, DCE only supports TCP/IP at the moment, but DCE was designed to support more than one network transport.
  • Search the directory service for the server’s host address. When an application server initializes, it places its host address in the directory—so the Directory always knows where a running server is. When Microsoft used the DCE RPC code, this code had to be adapted to use their own Registry service.
  • Connect to and transmit the RPC to the server.

The server RPC runtime routines provided with DCE run continuously in wait for an incoming call. When the call arrives, the runtime library dispatches the call to the proper procedure in the server stub. The stub “unmarshals” the data by converting it to the form needed by the server machine, changing byte orders, converting 16 to 32 bit data, and so on, turning it back into a normal argument list. Once the procedure has executed, the program passes the argument back to the calling code in the stub, which calls the RPC runtime routines that marshall the data and transmit it back to the client. As we can see, therefore, Microsoft has used the DCE RPC mechanism almost in exactly the same way with only very minor changes.

Threads service-DCE Threads is an implementation based on the POSIX 1003.4a standard, which includes realtime priority scheduling. Threads and the use of multithreading is well known in the world of high transaction systems. Multithreading saves memory space, as well as improves performance where a very large number of users or “clients” may be wanting to use the same process simultaneously.

Multiple threads of a process use the same address space, so they share all static and external data, as well as open files and any other services available to the whole process. They execute concurrently and in parallel, which improves performance, whereas single thread processes execute serially. They do not require the process to be duplicated, however, and this is how memory is saved.

Previous | Table of Contents | Next