Chapter 6 Local/Remote Transparency

According to the Handbook of Chemistry and Physics,1 "Transparency of a layer of material is defined as the ratio of the intensity of the transmitted light to that of the incident light. Opacity is the reciprocal of the transparency. Optical density is the common logarithm of the opacity." In other words:

Optical density = log10(Ii/It)

Obviously, then, a perfect transparency of 1.000 is achieved only when optical density (not necessarily physical density) is exactly 0. A total vacuum falls into this category, and high-quality lenses—for which professional photographers shell out tens of thousands of dollars—come rather close. A perfect opacity, on the other hand, has an infinite optical density. In this category, you'll find materials such as trees, concrete, electrical tape, other people's heads in movie theaters, and even the Handbook of Chemistry and Physics.

In the field of engineering acoustics, the notion called transmission loss is almost identical. Transmission loss measures sound through various types of wall construction, such as gypsum wallboard, 4-inch bricks, concrete, and piles of outdated Handbook of Chemistry and Physics volumes. The acoustics textbook I used in college2 describes transmission loss with this equation:

TL = 10dB log10(Ii/It)

The concepts of optical density and transmission loss, even those of electrical resistance and conductivity to some extent, relate exceptionally well to the member function calls that a client of some object makes through one of that object's interface pointers. As we saw in Chapter 5, the effective optical density—the transmission loss—for a call from a client to an in-process object is 0: there is nothing standing between the call made in the client and the code that implements that function in the object. Whatever piece of machine code in the client issues a call instruction, the next point of execution is at the beginning of the implementation of that function inside the object code itself.

With the aim of complete component integration, OLE and COM also allow clients to communicate with local and remote objects. Process and network boundaries are real and substantial, and significant work is required to change from one address space to another or to transmit information across network cables. For complete component integration to work, a function call made in a client must show up in any object as if no barrier existed at all. From the client's perspective, any function call to any object's interface is an in-process call, regardless of the boundaries between the client and the object. From the object's perspective, the object receives interface calls as if the client were in the same address space as well, and so the object enjoys perfect transmission.

The crux of Local/Remote Transparency is that somehow a server process has an interface pointer that it wants to make available to other processes. This always begins with a server's IClassFactory pointer—the first interface pointer of this kind that a server gives to COM. COM must then create the structures that allow clients in other processes to make function calls through this pointer. That's what ultimately matters. Of course, Local/Remote Transparency isn't at all important when a client is dealing with an in-process server. Only when a client is working with local or remote servers does sharing an interface pointer matter at all.

Fortunately, COM makes the whole process utterly trivial: the server can just hand the pointer to COM, and COM sets up everything required for the client to make calls into the object. This is why COM is so powerful: there is so much work to make Local/Remote Transparency work, but the burden is all on COM, not on the client or the server.

The whole trick to this technology is to always have the client call some in-process code when making any interface call and to always have the object receive that call from some code in its own process. This chapter is about the mechanisms and devices that COM uses to achieve this. Called marshaling or remoting, these mechanisms determine how an object in a local or remote process communicates with a proxy in the client process. An object can employ different marshaling mechanisms—custom marshaling, in which the object controls the interprocess communication itself, or standard marshaling, in which OLE provides a default mechanism. With standard marshaling, OLE offers some facilities to support custom interfaces for cases in which standard marshaling support is not already built into the system. To wrap it all up, we'll also see concurrency management (also called message filtering), through which clients and objects can gracefully handle time-outs and rejected calls, informing the end user of the situation.

The idea of COM's Local/Remote Transparency is to make interface calls to local and remote objects as transparent as calls to in-process objects, regardless of how the interprocess or intermachine communication occurs. Because COM itself handles all of the work involved and allows you to make specific customizations of the underlying architecture, clients, servers, components, and objects don't care how it all works—they just know that calls go through without one shred of loss in transmission. Not only are calls transparent as far as transmission is concerned, they are also effortless to both clients and objects; just as effortless, in fact, as an in-process call—that is, a simple function call through an interface pointer. You get zero opacity, perfect transmission.

Note: You can accomplish quite a lot with OLE without knowing much of the information in this chapter, which is fairly detailed. If you are interested primarily in high-level concepts, feel free to skip this chapter or simply peruse it quickly, but be sure to read "The OLE UI Library and the Busy Dialog Box" on page 316, which is relevant to material in other chapters. Otherwise, come back to specific sections when you need to understand a specific topic.