Understanding the Role of DCOM in COM | COM Programming with Microsoft .NET

Understanding the Role of DCOM in COM+

COM has been through a number of changes as Microsoft works to make it fulfill the needs of developers. The Microsoft Distributed Component Object Model (DCOM) was the second step in the evolution of COM. This version of COM helps components and applications communicate over a network no matter how widely separated the participating computers are from each other. In general, DCOM isnt a component technology, its a binary data transfer technology. Microsoft modeled DCOM after the Open Software Foundation (OSF) distributed computing environment remote procedure call (DCE RPC) specification.

DCOM can communicate over a broad range of network protocols. This includes both the HTTP and TCP/IP protocols used by the Internet. In other words, a component on a laptop in New York could communicate with a server running in Paris and use that servers resources as if the two were in the same room. In addition, DCOM takes care of handling the network protocol details for you so that you can concentrate on the business logic of the component youre designing.

The theory of DCOM is great, but the implementation has proved a little less than stellar , so we now have Web Services for the Internet. Because DCOM is a binary rather than a text-based data transfer technology and because DCOM uses a range of ports in its communication, it has problems getting through the firewalls most companies need to have in place. However, there are ways to make DCOM work for private application communication.

Tip

You have quite a few resources at your disposal when it comes to DCOM on the Internet. The best place to start looking for the latest information about this technology is at the Microsoft DCOM Web site at: http://www.microsoft.com/com/dcom.asp . This site provides a link to the DCOM specification, books on how to work with DCOM, programming samples, white papers, and links to other Web sites with additional DCOM information. One of the better places to get information about the OSF DCE RPC specification (the underlying technology for DCOM) is at: http://archive.dstc.edu.au/AU/research_news/dce/ dce.html . This Web site will help you find the specification, frequently asked question (FAQ) sheets for using DCE RPC in a variety of environments, and a list of vendors who support DCE RPC in their products.

Most developers are aware of the DCOMCnfg.exe utility used to configure components for use with DCOM. Essentially, with the DCOMCnfg utility you can tell the local machine where to find the component on a remote machine. The configuration utility also helps you with issues such as security and adding new protocols for data transfer. Microsoft Windows XP uses the Component Services console for this purpose and entering DCOMCnfg.exe at the command line will bring up this console. Youll find a DCOM Config folder similar to the one shown in Figure 5-8 for configuration issues. Right-click the component of interest and choose Properties from the content menu to configure the component.

Figure 5-8: Use the DCOM Config folder options to configure components if you use Windows XP.

We wont pursue DCOM development in this book except as it applies to making COM+ work. DCOM is an older technology that a few developers still use. It has lost favor to newer technologies, such as Web services, for most new development. In addition, if you know how to make COM work with .NET, you have a good idea of how to make DCOM work tooat least from a development perspective. With this in mind, the following sections examine some of the inner workings of DCOM and describe how they apply to COM+ application development.

How Does the Connection Work?

In this section, well present a birds-eye view of how DCOM creates and manages a connection between the client and server. You need to understand how this connection works so that you can troubleshoot problems in your own applications. Figure 5-9 contains a block diagram of the flow of data from the client to the server. The list that follows Figure 5-9 describes each of the diagram elements.

Figure 5-9: A simplified DCOM connection overview block diagram

Note

Figure 5-9 assumes a generic component setup. We arent doing anything fancy here because the idea is to learn how the connection between the client and server works. A real-world component would provide more in the way of functionality and, therefore, would perform a lot more communication to complete a task. The underlying communication technology will remain the same no matter how complex or simple your component is. The only thing that will change is the amount and type of communication between the client and server.

Client Originates requests to the server for resources and support. As far as its concerned , the component is local and of an unmanaged type.
OLE32 DLL containing the methods used to create an instance of an object (along with a wealth of other functionality). There are five methods available for remote object creation: CoCreateInstanceEx() , CoGetInstanceFromFile() , CoGetInstanceFromStorage() , CoGetClassObject() , and CoGetClassObjectFromURL() . However, if you look at the registry entry shown in Figure 5-10, youll notice the client will use one of these functions to call Mscoree.dll instead of your component. The Mscoree.dll creates the COM Callable Wrapper (CCW) for your component.

Figure 5-10: The Registry holds the key to understanding how DCOM calls the component.
Service Control Manager (SCM) Creates the initial connection between the client and server. DCOM relies on the SCM only during object creation. This feature is implemented by the TransportLoad() method in the Rpcltscm.dll file.
Proxy Creates the servers presence within the clients address space. The operating system creates and manages the proxy, which is a table of interfaces, at the request of the COM runtime. It allows the client to think that the server is local, even though the server is located on another machine. Windows uses a method like CreateProxyFromTypeInfo() found in the Rpcrt4.dll file to create the proxy.
COM runtime Includes the operating system elements that host objects and provide client/server communication. The COM runtime is part of any COM- related scenarioboth in-process and out-of- process, and local and remote.

Security provider Ensures all parties in the data exchange have the correct rights. The security provider logs the client machine onto the server machine to allow the data exchange to take place. Some security providers will also protect all data transferred between the client and server in some wayusually by using encryption.

Note

Windows provides support for several standard security providers for both Internet and local network use. These providers include NT LAN Manager (NTLM, the standard Windows NT security protocol), Kerberos, Distributed Password Authentication (DPA, which is used by CompuServe and MSN), secure channel security services like Secure Sockets Layer (SSL)/ Private Communications Technology (PCT), and third-party Distributed Computing Environment (DCE) providers. The choice of security provider usually depends on the application setup and the media used to transfer the data. In addition, the security provider chosen must work on both client and server.

DCOM Network Protocol (DCE RPC Network Protocol) Defines a protocol (the set of rules) for creating a connection with a remote server for using objects installed on that server. In addition to implementing a component protocol, this block contains all the elements needed to implement the Object Remote Procedure Call (ORPC) specification at an application level. This particular component has several names in the Microsoft documentationthe most popular of which is DCOM wire protocol . For the most part, this low- level data transfer protocol is invisible to the .NET developer and youll never need to worry about it, even if you decide to work with DCOM.
Protocol Stack Provides the low-level connectivity required for the network at various levels. The actual network communication requires more than just one protocolthere are network-related protocols to consider as well. The protocol stack consists of all the protocols required to create a connection between the client and server, including network-specific protocols such as TCP/IP. Figure 5-9 shows a typical protocol stack consisting of a Winsock driver, a User Datagram Protocol (UDP), an Internet Protocol (IP), and an Ethernet driver. The Ethernet network interface card (NIC) actually used to create the physical connection between the client and server doesnt appear in the figure.
Stub Creates the impression of the clients presence within the servers address space. The operating system creates and manages the proxy, which is actually a table of interfaces, at the request of the COM runtime. As far as the server is concerned, its working with a local client. Windows uses a method such as CreateStubFromTypeInfo() , which is found in the Rpcrt4.dll file used to create the stub.
Server Instantiates the COM object from which the client has requested services and resources.

Two communication paths are shown in Figure 5-9. The first path (the dotted line) shows how to create an instance of the object. The second path (the solid line) shows the path of normal communication between the client and server. Creating a line of communication between a client and server normally follows these steps.

Note

The following discussion follows a pure COM perspective of the DCOM data transfer technique. If youre using a .NET component or client, the .NET interoperability technologies discussed in Chapters 3 and 4 come into play. The point is that .NET creates a seamless method of making DCOM work. As far as DCOM is concerned, its working with both an unmanaged component and an unmanaged client. Only the common language runtime knows that one or the other (or perhaps both) is a managed version of the code.

The client issues one of the five object creation method calls we discussed earlier in the section (in the Ole32.dll bullet item). The call must include both a class ID (CLSID) and a server name (along with any information required to log onto the server). As an alternative, the client can issue a standard call that Ole32.dll will resolve to a remote location based on a registry entry, or the client can use monikers.
Ole32.dll calls on the client-side SCM to create a connection to the server machine because it cant service the call locally.
The DCOM network protocol creates the required packets to send information from the client to the server.
The server-side SCM creates an instance of the desired server-side component and returns a pointer of the object instance to the client. The pointer actually points at the CCW for a managed component.
The server-side SCM calls on the COM runtime to create a stub with which the component will interact.
The client-side SCM calls on the COM runtime to create a proxy with which the client will interact.
The SCM returns a pointer to the proxy to the client. Remember that this pointer belongs to the Runtime Callable Wrapper (RCW) for a managed client, not the actual client.
Normal client-side and server-side component communications begin.

Connection-Oriented Data Flow Optimization

Sometimes, the development and placement of a component depends on how much communication is taking place. Consider a situation in which a client needs access to the contents of a database. You could place a component directly on the client machine that would access the database manager, gain access to the required data, and then format it for the user. However, this design would require a lot of network communication because the client would need to constantly communicate with the database manager and send or receive the data.

Splitting the component in two would allow you to reduce the amount of data traversing the network. One component on the client machine could send data requests and format the incoming data. A second component on the server could make the data requests and deliver only the required information to the client. Using this approach would significantly reduce network traffic, enhance both client and server efficiency, and make the user more productive all at the same time.

DCOM performs some connection manipulation on its own. One of the most important changes DCOM will implement automatically is connection optimization. For example, if you have a server-side component thats manipulating a database using OLE DB or ODBC, DCOM will more than likely copy the component to the client and then remove itself from the data stream. Because the connection to the database exists through a third party (normally, a provider), neither the client nor the database manager notice any difference in the performance of the component. However, since DCOM is out of the picture, the component executes more efficiently . Obviously, this is a very specific kind of connection change and DCOM implements it only when the client will see a significant performance gain.