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

Previous Table of Contents Next


Timing Services

There is only one middleware product (as far as I’m aware) that supports distributed time services and that is DCE. Windows NT has a clock, but it doesn’t provide distributed time services.

To be a truly distributed time service, the times on each computer must be synchronized in the network to a recognized time standard. This could be an internal and largely arbitrary time, or it could be an external source such as that obtained through a hardware device that receives time from a radio signal or other public source of time. Furthermore, there needs to be constant resynchronization of the clocks to ensure they stay in step.

In Summary

As we have seen, Windows NT is important to any developer needing to build distributed applications because some of the services needed to build a distributed application are found not within DCOM but within the operating system. The main services we believe should be provided to build distributed systems which are currently provided within Windows NT rather than defined as DCOM services are:

  Threading service
  Security service
  Distributed File service
  Memory management
  Shared memory service
  Time service
  Directory service

The security service and Registry/Directory service are described separately in later chapters. We will be seeing that the Registry service is being ported to other platforms by other vendors of DCOM, but the security services may not be “end-to-end.”

The Registry is so fundamental to the operation of DCOM that it has to be ported, and as such it makes the development of distributed applications possible. The absence of a full “end-to-end” security service may cause problems as the applications will not necessarily be totally secure as a result. The success of the security services may well depend on how the developer uses third-party products.

The memory management service is being ported to other platforms by vendors of DCOM, so this service will end up being a distributed one and will support the development of distributed applications on platforms besides Windows NT. The threading service, as we have seen, may be ported, or an alternative service may be used. Either way a service of one sort of another will be available to build distributed applications.

The Distributed File service is a fully distributed service on Windows NT but is not being ported and, as such, will not be available with DCOM on other platforms. As DFS is not a service normally used to develop applications or support them at runtime, this may not be a problem for many developers, but as we have seen, it does deny developers a useful service if it is not available.

The new Windows interface will provide a unified distributed file service for ready access to information in files and pages on the Internet and across local and remote Windows servers giving a good compromise solution, though not fully distributed file service functionality. But, there are two services on Windows NT that are not only not going to be ported, but even on Windows NT are not fully distributed—the time service and shared memory service.

This means that DCOM is missing some useful services—services which could be used to build distributed applications. Where developers need a time service, they could use DCE’s Time service instead, using the fact that both DCOM on Windows NT and DCOM on other platforms are supported by the DCE RPC, and as such, as long as the service is available on some of the platforms, it can be accessed—albeit with an RPC call rather than a method invocation. All of which brings us on to our next chapter—DCOM on other platforms.


Previous Table of Contents Next