As you saw in Chapter 1, the backbone of COM's distributed infrastructure is based on an interprocess mechanism called the Remote Procedure Call (RPC). This chapter gives you some background on RPC and the process of remote activation. It also covers issues associated with the life cycle of COM objects in a distributed environment.
Security is an important concern in a distributed application. Without a robust security model, COM would be worthless to enterprise developers. This chapter describes how COM creates abstractions on top of the Win32 security model to provide secure access to distributed objects. One of the best things about COM security is that it can be used in either a declarative or a programmatic manner. As a Microsoft Visual Basic programmer, you have minimal control over the programmatic side. However, you can use declarative security to make sure that only authenticated and authorized users can access your distributed application.
This chapter describes how to configure servers and client computers when you deploy an application with Distributed COM. It introduces a new Registry key called the AppID , and it shows you how to modify the Registry to track information about the security and server locality of a COM-based application. As you'll see, the AppID plays an important role in both server-side and client-side configuration.
You'll also learn how applications based on Distributed COM worked before the introduction of Microsoft Transaction Server (MTS). You must wait until the
Finally, you'll learn about a few significant limitations associated with the initial release of Distributed COM. Certain problems relating to application security and configuration are tricky and expensive to solve. Fortunately, MTS provides a
From the early days of computer networks, some programmers were determined to make code on one computer cause the execution of code on another. At the time, the requirements of interhost communication were amazingly high. Only hardcore systems-level programmers were up to the task. To execute a function on a separate computer typically required code to pass messages between computers. This code was almost always written with a specific network protocol and a specific set of hardware in mind.
In the 1980s, it was
A standards group called the Open Software Foundation (OSF) set out to create a specification to solve this problem. The
The RPC specification requires programmers to define remote calls by writing a description in an RPC-specific version of Interface Definition Language (IDL). A set of calls is defined in RPC IDL inside an RPC interface. An RPC interface is simply a group of global functions that defines the calling syntax of each remote procedure call. Each parameter in every procedure is defined with a specific data type and a direction. (This talk of interfaces and IDL should sound familiar to you at this point.)
An RPC client application must establish a connection with the server at run time by negotiating a binding protocol with a server process. Once binding has taken place, the two communicate through the RPC channel. Every procedure call involves moving data back and forth across the channel. An RPC request transmits a procedure call and its inbound parameters from the client application to the server. After the server executes the procedure, the RPC response transmits the procedure's return value and any outbound parameters back to the client application. When a client application makes a synchronous RPC call, it must wait for the response to come back from across the network before it can do anything else.
As OSF DCE RPC became an industry standard for distributed computing, Microsoft created its own version for Windows platforms. Microsoft's implementation of the OSF specification is called MS-RPC. MS-RPC has been integrated into all 32-bit Windows platforms and promises to provide Windows connectivity to many non-Windows platforms.
Developers use MS-RPC by first creating an IDL source file and feeding it to the Microsoft IDL (MIDL) compiler. The MIDL compiler generates C source code files that have the necessary RPC code stubs for both the client and the server. This code is compiled into client applications and server applications. As a result, the client application can call the functions, which are automatically
RPC has one significant problem: It doesn't offer the
When Microsoft engineers were deciding how to make COM interprocess-capable, they saw that RPC had much to offer. RPC was already ubiquitous in the industry, and MS-RPC had been integrated into every significant Windows platform. The
Figure 8-1. The proxy and the stub are generated with an RPC-IDL compiler. They communicate with one another across an RPC channel.
Microsoft's version of IDL includes COM extensions that let you map a COM interface to an RPC interface. The MIDL compiler can build proxy/stub code by examining the definition of a COM interface. As you saw earlier, the proxy and the stub can communicate by establishing an RPC channel. The RPC layer allows a client application to establish a connection with an out-of-process COM object. It also
The RPC layer is transparent to Visual Basic programmers. This means that when you create an out-of-process COM server with Visual Basic, the COM interface-to-RPC mapping is taken care of behind the scenes. The universal
Let's take a rest from all this low-level talk about network protocols and the MIDL compiler for a moment and talk about why the interprocess capabilities provided by RPC are so important. They're important because they let you deploy a set of business objects in the middle
Figure 8-2. Client applications rely on Distributed COM to communicate with business objects running in the middle tier.
In an N-tier architecture, a client application running in the presentation tier activates and uses objects distributed throughout the network. Distributed COM must provide an infrastructure in which two machines can coordinate to load a remote object and bind it back to the client application. Distributed COM must also provide a security layer so that client applications can use objects only after they have been authenticated and authorized.
Let's examine what happens during remote activation. Recall that in local activation, when an out-of-process object is activated the SCM can launch and/or find the running server process that contains the object. Once it finds the server, it goes through the loading and binding sequence described in Chapter 4. Remote activation is similar to local activation except that it requires two sessions of the SCM running on two different computers. When the SCM running on the client machine determines that the CLSID implementation lives on a separate host, it sends an activation request across the network to the SCM on the server's computer. The client-side SCM
The SCM on the server machine can activate the object just as it does when it handles a local activation request. That means that the server-side SCM
Remote activation is coordinated between two separate sessions of the SCM. If the client application has been authenticated and authorized, the server-side SCM
What happens if a client application crashes while holding outstanding object references? The object must have a way to determine that its client application has
COM provides the infrastructure for distributed garbage collection. The system can determine that a client with an outstanding object reference has died. When the system discovers this, it informs the object by calling Release . This means that distributed objects can be released from memory when their clients crash. The need for garbage collection is important in a distributed application that will run for months at a time.
COM's mechanism for distributed garbage collection is based on the client machine pinging the server machine with a notification that says, "I'm still
The ping algorithm has been optimized to avoid excessive network traffic. Pings aren't sent for individual interface references or for individual objects. Instead, the system transmits a single machinewide ping from the client to the server with information about every connection between the two machines. Note that each ping doesn't transmit all the information about every outstanding interface reference. Instead, it transmits the information about what has changed since the last ping. This "delta" algorithm significantly