| < Free Open Study > |
|
This chapter gave you the lowdown on COM's location transparency. We began by reviewing the three relationships a client and server may take: in-proc, local, and remote. From here, we discovered that stubs and proxies are the keys to making a server's physical location an unnecessary detail in a client's mind. We dug into the stub/proxy architecture, and discovered a set of new COM interfaces and the associated managers that help stubs and proxies communicate with the RPC layer.
Next we examined COM's marshaling options. Custom marshaling allows you to have complete control over the process of moving data between processes using the IMarshal interface. Standard marshaling is almost free when you write your interfaces in IDL, leaving you to the task of creating the DLL for this stub/proxy. Universal marshaling is as free as you can get, as you have no need to worry about a separate DLL to distribute; however, you must constrict all your interfaces to use variant compliant parameters, and configure each interface to point to the CLSID of the universal marshaler.
We examined how to create a local server. As you have seen, this requires a new way to work with server lifetime management, as class factories must remain active as long as there is a connected client. We then examined the AppID, and saw the various ways that we can configure security contexts for our servers. Finally, you learned how to use the dcomcnfg.exe utility to configure and access remote servers, and wrapped up by examining remote access on the programmatic level using the COM library.
| < Free Open Study > |
|