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

Previous | Table of Contents | Next

## Chapter 2
What Is DCOM?

• DCOM is an architecture on which services to build distributed applications are based • It provides a range of service to support distributed processing at runtime and to support the developer when building distributed applications • The purposes of the DCOM runtime services is to provide an environment which is secure, available, reliable, and gives good performance • The purpose of the DCOM development environment is to save the programmer effort

Microsoft’s DCOM (Distributed Component Object Model) is based on Microsoft’s own COM (Component Object Model). COM defines how components interact and is an architecture for simple interprocess communication. It defines a basic model of communication using Microsoft’s equivalent of objects—components. DCOM supports the same model of component interaction, but supports distributed interprocess communication. Thus DCOM is an architecture that enables components (processes) to communicate across a network.

The architecture includes two types of service—services provided at runtime and services the developer can use to develop distributed applications.

Examples of the sorts of service provided at runtime include security services (authorization, authentication, and encryption), load balancing, guaranteed delivery, deferred delivery, triggering, automatic multithreading, shared memory management, distributed transaction support, message queuing support, broadcasting, multicasting, time services, synchronization (support for asynchronous and synchronous communication), context bridging, routing, plus many more.

Very few people realize just how extensive the service support in DCOM is until they “get under the covers.” DCOM enables the developer to completely avoid having to write complicated communication code at the low level sockets or network software level. Thus DCOM takes care of all the communication between machines. DCOM is also supplied with a set of runtime libraries that handle all the functions of communication—session handling, synchronization, data format translation, buffering, and fault identification and handling.

We will be describing what each of the services means, what it aims to do, and how Microsoft has tackled the problem in this book. The main objectives in providing these services are first, to save the programmer the effort of having to write all these services; and second, to provide a secure, resilient, reliable, available, high-performance environment on which to build a distributed application.

Distributed processing is particularly prone to things going wrong. The network can go down, machines can fail, remote databases can fail, performance can be diabolically slow—hundreds of new possible problems can occur because the environment is a distributed one. The services in DCOM either ensure the errors or problems are handled automatically or, if they cannot be handled automatically, errors are trapped and the program is informed.

Anyone who has written a distributed application knows that without this sort of support software, hundreds and possibly thousands of lines of code (difficult, complex code) have to be written by the programmer to support the distribution. By using DCOM, all this effort is saved.

### DCOM Is Middleware

DCOM is just one of a whole range of products which can be classified as middleware. Middleware is “off the shelf connectivity software, which supports distributed processing” at runtime and which is “used by developers to build distributed software.” It is the software that binds the parts of a heterogeneous system together.

Whereas network software handles the communication between one machine and another, middleware provides the developer with services that support process-to-process communication across the network. Processes can be running on machines of different makes and, in most advanced middleware products, processes can be running on machines using different operating systems.

The effect of the middleware, then, is to make all the machines appear as though they were one “virtual machine.” For example, a process on a Sun SPARC machine running Solaris can communicate, using middleware, with a process on, for example, the IBM MVS mainframe or, alternatively, a process on a Compaq machine running Windows NT. The processes can also usually be in different languages.

Figure 2.1 Middleware enables processes to communicate across a network

DCOM was not originally a cross-operating system architecture. When it was first released, it could only provide internetwork communication between Microsoft Windows NT- (and 95-) based machines.

Microsoft has, however, extended the support of DCOM to other operating systems by using partnerships with third party companies to either port DCOM services to Unix and the mainframe or provide access from these platforms to DCOM services. Four companies have so far become involved—Software AG, Digital, Hewlett Packard, and Level8. We will be seeing how these “versions” of DCOM inter-operate with DCOM on Windows NT in Chapter Eleven.

This said, however, most of DCOM’s full functionality is to be found only on Windows NT, and DCOM services are tightly integrated with Windows NT. In fact, some of the services we have come to expect from middleware products are provided by Windows NT in the Microsoft environment. We will see in Chapter Ten how Microsoft is gradually including all the services we might call middleware services in the Windows NT operating system.

Previous | Table of Contents | Next