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

Previous Table of Contents Next


Chapter 4
The Main Services of DCOM

DCOM is much easier to understand if you first see how all the different parts that make up the “middleware” services fit together and what they are. In this chapter I describe each service in brief, showing where it fits in relation to the others. In the following chapters each one of these services is described in detail.

I always believe a picture helps enormously in an explanation. Below you find a diagram I will be using throughout the rest of the book, which shows the parts of DCOM in overview.

DCOM is an architecture that groups a set of services used to build distributed systems. Unfortunately what constitutes a DCOM service and what doesn’t isn’t that precise within Microsoft’s own literature, but we have defined it to mean any service capable of being used to build distributed systems, then we get round the problem of whether MSMQ is DCOM or not, whether MTS is DCOM and so on.

COM Interface

All the services of DCOM are accessible via the COM interface—a component- and interface-based interface to all the services of DCOM—not only application components. Put another way, DCOM services are invoked in exactly the same way as a developer may invoke the methods on an application component.

Thus, to access security services, for example, the programmer invokes security methods on security classes. Similarly, to use the Transaction services in MTS, the programmer uses classes and methods specifically designed to handle distributed transactions. In effect, the paradigm used by the developer for building applications is exactly the same as that he or she will use to invoke the services in DCOM.


Figure 4.1  Overview of DCOM services

Windows NT

As we have shown it in the diagram, DCOM is a fundamental part of Windows NT and Windows 95. In fact, DCOM services are, in effect, embedded in Windows NT and are free with it, but this does not mean that DCOM services are not available on other platforms. In fact, there are limitations at the moment with the picture for other platforms looking more like that shown below, but this could change in the future.

One of the difficulties of the embedded approach to service provision, however, is that it makes it much more difficult for companies trying to port DCOM onto other platforms to both decide whether to provide a service and to provide the service itself. When a service is tightly integrated with an operating system, it can be difficult to unscramble the logic enough to provide the equivalent on other platforms. We will see that this is particularly the case with features such as threading support.


Figure 4.2  DCOM on other platforms

There are services in Windows NT, such as its time clock, which are very useful when building distributed systems (and thus ought to be considered a part of DCOM), but which are not provided in the same way on other platforms and which are not part of the plans of other vendors in their ports of DCOM. We will be looking at both the services provided by Windows NT and the services on other platforms in separate later chapters.

ActiveX

Clients invoke the methods on DCOM services or invoke application components. These application components can be ActiveX components or OLE Automation components. ActiveX components are perhaps the more interesting because they are intended to be portable—capable of being developed for more than one platform. So expect to see ActiveX components on Solaris, HP-UX, even the MVS mainframe in the future! A separate chapter explains the difference between ActiveX and OLE Automation components and describes the tools which can be used to develop components. Note that Microsoft is now downplaying the term ActiveX in favor of “just class,” but I believe it is useful to discuss the tools and concepts by using the ActiveX term.

MS RPC

MS RPC is Microsoft’s core Remote Procedure Call technology. It is based on the OSF’s DCE RPC standard. Microsoft did not use the OSF’s code to produce their implementation, but used the API and developed their own code. The implementation is thus DCE compliant, but is not OSF sourced.

MS RPC can be used by a developer, but Microsoft prefers the developer to treat MS RPC as enabling technology hidden from view by other interfaces. MS RPC should thus be viewed as a foundation product used by Microsoft and their partners to build other enabling software or middleware. It is the foundation for DCOM.

It is worth noting that Microsoft developed their own implementation in order to avoid having to pay OSF license fees (and keep core technology in house). By doing this they could keep the cost of products such as Windows NT and DCOM services down. On other platforms communication with MS RPC is achieved by other implementations of DCE RPC. We discuss DCE and RPCs in the chapter on MS RPC.

OLE DB and Active Data Objects

OLE DB and Active Data Objects provide class, interface, and method-based access to data—data in tables, data in databases, data in files, and so on. The aim of OLE DB is to provide a common API with which to access data of various sorts—thus it could be relational data or data in flat files or even data in spreadsheets or hierarchical file systems.

OLE DB is not a replacement for ODBC, but supplementary to it. The ODBC (Open Database Connectivity) standard was developed by Microsoft but was intended to be used for access to relational DBMSs. Microsoft supplies a number of ODBC drivers (translation products that convert the ODBC dialect to the dialect of SQL used by each vendor) and its own driver manager (which routes requests to the correct driver).

OLE DB extends this basic relational database connectivity solution to incorporate access to data sources of other kinds—not just relational databases. OLE DB is thus a more powerful product. The reason this category of service is described with the overall box called “translation services” is because there has to be translation of the method invocations from an “object invocation”-based approach to an “API” approach—whether this is translation to SQL or translation to some other data manipulation language.


Previous Table of Contents Next