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

Previous Table of Contents Next


Chapter 5
COM

  Same object/component-based interface used to access all services
  All services built using COM
  Components invoke methods on other components—these components can be user or services
  Interface based on MIDL (based on DCE IDL)
  Approach can be “static’”(using stubs and proxies) or “dynamic” (using Type Libraties)

We saw in the last chapter that all applications access the services of DCOM as well as the components themselves using the same class and interface-based approach. In other words, all the services are accessed via a common object-based interface or “API.” The API is implemented in the COM Library.

In this chapter we explore this concept further by looking at the concept of the client at the two ways in which interfaces can be used, via the use of stubs and VTables or using Type Libraries. We will also be briefly covering the IDispatch interface.

Application

Microsoft uses the term application in a generic way to mean either a client or a server or a collection of clients and servers. All applications (clients or servers) have some set responsibilities whether they are clients or servers. On application startup they must:

  verify the COM library version
  and initialize the COM library


Figure 5.1  The COM interface

On application shutdown they must “uninitialize” the COM library.

All applications must also perform their own memory management during processing, and we will see how DCOM provides commands to help in this in a later chapter.

Client

A client is any application requesting for an object to be instantiated via DCOM/COM; as such the term “client” really describes a role. Clients are responsible for:

  creating instances of objects
  initializing the object via its Initialization interface
  and calling the object’s release function when the client has finished with it

Server

A server is a collection of one or more classes that can be invoked by clients.

A server enables components/classes to be grouped together into packages that execute in the same address space. Servers can be deployed as a single unit and where services such as Microsoft Transaction Server are used also share security. (Within MTS servers are component packages.) Servers exist partly to help improve performance but also to aid fault isolation and ease administration.

There are two main types of server—a Dynamic Link Library, which can be loaded into and will execute within the client’s address space—and EXEs—standalone executables.

DLLs are often referred to as “in-process” servers because they execute in the address space of the client. EXEs are often referred to as “out-of-process” because they execute out of the address space of the client—either on the same machine or remotely on another machine. Where the EXE is on a different machine than the client it may be referred to as a remote server to differentiate it from an EXE on the same machine as the client where it may be called a local server.

IDL-Interface Definition Language

We saw in the second chapter that an interface is the contract between the client and the server. The client invokes methods on a class in the server using the interface. The interface defines the class, one or more methods which can be invoked on a class, as well as the parameters for the method.

All interfaces are defined using a purpose built language called MIDL or Microsoft’s IDL (Interface Definition Language). Microsoft’s IDL (MIDL) was based on the DCE RPC IDL from the OSF (Open Group). It is a C++-like language but is actually language independent and built to be language independent. Its specific role is to define the interface. Microsoft added extensions to the basic IDL provided with DCE first, to make it more “object oriented” and second, to ensure it supported COM. At one time, Microsoft also supported another language called MODL (Microsoft Object Definition Language) to define interfaces aimed at type libraries but this has been discontinued.

The format of the header to an interface in IDL defines:

  the Interface name—the programmer uses the interface name
  the key word “object” to show it is a COM interface


Figure 5.2  The Interface

  the GUID of the interface—this is generated when the developer requests that a GUID be allocated to the Interface. Because the GUID is specified within the Interface definition, when the developer uses the interface name in his program, the GUID can be used internally by DCOM.
  an optional help string which can be used to find out more about the class when it is stored in a Type Library or in the program source code

The methods and parameters—input only, output only, or input and output, are then listed.

It may seem blindingly obvious to the programmer used to distributed processing, but it is not always so obvious to the complete novice, that the interface has to define all the data needed by the class, as, of course, no memory can be shared. The data defined in the interface thus cannot be pointers to memory; it has to be a data type with a defined structure that the programmer sets up as part of the invocation. If the developer wants to reuse definitions he or she uses the keyword “import.” This acts like the C++ preprocessor command #include.


Previous Table of Contents Next