DCOM Explained
by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98 |
Previous | Table of Contents | Next |
|
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.
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 Digitals 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 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:
The Directory service and Security services are of such importance that we have allocated them chapters in their own right, but the other servicesthreading, shared memory, memory management, distributed file, and timewill 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 systemit 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.
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 isnt 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 |