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

Previous Table of Contents Next


Chapter 10
DCOM and Windows NT

  DCOM is embedded in Windows NT
  But some other services needed to build distributed systems are embedded in Windows 95 and Windows NT 4—not part of DCOM
  Knowing about these services is important—to help in building distributed systems and to understand the implications on portability.

DCOM is embedded within Windows NT and 95, and, at the moment, it is possible to classify what constitute DCOM services and which services are not DCOM, but provided by the operating system. But some services we need to build distributed applications are classified by Microsoft itself as services of Windows NT and not DCOM. This confuses the issue.

We use DCOM to build distributed applications. But, in reality, what we see is that occasionally we are going to have to go outside DCOM and use Windows NT to get the services we need. Knowing about these services is important because if we start to build applications for other platforms, DCOM ports may not provide these services for us.

Even if equivalent services are provided, the suppliers of these ports may be using a different mechanism, which may in turn require changes to our code and limit portability.

About Windows NT

Windows NT was first launched in July 1993; since then Microsoft has sold well over 15 million copies. It was designed by Dave Cutler, creator of Digital’s highly successful VMS operating system for the VAX, and it provided, on its launch, full 32 bit operation, preemptive multitasking, virtual memory, C2 level security, and built-in networking.


Figure 10.1  Operating system middleware services

At the time I wrote this, Windows NT was on version 4, but the key and most important version of Windows NT to affect DCOM will be Windows NT version 5.0. Windows NT 5.0 is due to enter beta testing late 1997, with a launch in 1998.

DCOM is embedded within Windows 95 and both Windows NT 4.0 Workstation and Windows NT Server. DCOM will play an even greater role in Windows NT 5.0.

Windows NT and DCOM

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. What are these services? The main services provided within the operating system rather than defined as DCOM services are:

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

The Directory service and Security services are of such importance that we have allocated them chapters in their own right, but the other services—threading, shared memory, memory management, distributed file, and time—will be described in this chapter.

To complicate matters further, many of the obviously DCOM services such as MSMQ and MTS use the Windows NT services we have described above. MSMQ, for example, uses the Registry/Directory to store its queues, as does MTS (the buffer pool). All the services use the threads service; some of them use the Directory service. DCOM is thus far more integrated into the operating system than other middleware products might be.

This is going to make it far more difficult for the vendors providing ports to other platforms. Perhaps of most importance is that Microsoft themselves places absolutely no importance upon whether a service is classified as DCOM or not.

As far as it is concerned, all the functions are really functions of the operating system—it just so happens some of them support distribution over a network. Unfortunately, this argument leaves the vendors of DCOM ports with an even more difficult task because they have their job cut out to untangle what in effect is a highly integrated set of operating system services, to produce a set of coherent equivalent middleware services on other operating systems.

Multithreading

DCOM and the threads service

One of the complexities of describing the threading service is that it is Windows NT that provides the threading service but DCOM services use it. First, they use it themselves to improve their own performance, increasing the throughput of their own services. Second, however, a DCOM programmer uses the interfaces defined in DCOM to invoke the services of the thread service.

Surely, you might ask, if it is accessed by a DCOM interface this isn’t it a DCOM service? The problem with this argument is that the threads service exists and can be accessed outside of the DCOM approach. DCOM has just added to the existing service, creating a COM-based approach to access the service, a new terminology for the functions provided, and added-value functions built on top of the service.

In the following paragraphs we look at what is meant by multithreading, why threads are useful in general, and then go on to look at how they work in the DCOM context.

What are threads?

A process instance (a running process) can support multiple threads. We could think of a thread as a piece of figurative string through the process, not needing duplicate code (copies of the code) to exist in memory. Thus one copy of the process exists in memory, but multiple executions of that code may be proceeding in parallel.

Threads support simultaneous access to shared resources. Multiple threads of the same process use the same address space and share all static and external data as well as open files and any other services available to the whole process. If multithreading is used, locks have to be placed on shared data, and resources and locking is the responsibility of the programmer.


Previous Table of Contents Next