Location transparency—the idea that it doesn't matter whether code runs locally or remotely, in-process or out-of-process—has been part of COM from the very beginning. But the full power of location transparency has been realized only in COM+. Due to the foresight of the COM designers, the transition from a single machine to a distributed model has been smooth.
In previous chapters, we built and tested in-process components and examined a wide range of COM+ services, including connection points, monikers, and persistence. In this chapter, we'll move beyond the in-process model and begin to examine the remoting architecture.
Remoting is the mechanism used to communicate with two types of components, local and remote. A local component is an executable file that runs on the same machine as its client but in a separate address space. A remote component executes on a machine separate from that of its client and is a more elusive entity. As you know, in-process components are dynamic-link libraries (DLLs) and local components are executable files (EXEs). Microsoft Windows does not provide a third type of code module, so how do you set about remoting a DLL or an EXE? Well, executable components don't need much help in this regard because they can simply be launched on a remote computer. As you'll see, however, an executable file is not always the best housing for COM+ objects.
Most COM+ objects feel much more at home with an in-process component. Why? Since a DLL runs in the process address space of its caller, DLLs usually run faster than equivalent executable components. Also, the COM+ run-time environment works only with in-process components. But does the much-vaunted location transparency apply to in-process components as well as executable components? In other words, can you launch and call a DLL remotely? Contrary to what logic might lead you to believe, in-process components can be remoted. Permit us to explain.