HTTP vs. DCOM

[Previous] [Next]

Many companies that have distributed applications use HTTP as the protocol for all client-to-server communication. I'd like to take some time at the beginning of this chapter to examine the key issues that make HTTP preferable to DCOM in certain situations This should help you understand when a distributed application must rely on a Web server such as IIS.

The first reason for using HTTP is the most obvious: It facilitates cross-platform development. HTTP is ubiquitous—implementations are available on all platforms. HTML processors are also available everywhere as well. You can thus reach many more potential users. Applications that rely on DCOM, on the other hand, can reach only users with a 32-bit version of Windows. When you add the fact that user interfaces built using HTML can run on many different browsers and operating systems, HTTP becomes a very attractive way to build cross-platform applications.

HTTP isn't just for serving up HTML-based user interfaces. Many applications use HTTP as an RPC-like protocol, sending arbitrary information to the Web server in POST requests and interpreting the response messages as appropriate. The most common format for sending this information is XML. XML is a text-based data format that allows applications developed by different organizations to exchange information in a platform-neutral way. Fortunately for Visual Basic programmers, Microsoft's XML parser is built into Windows 2000 and provides excellent support for reading, writing, transmitting, and receiving XML.

Another disadvantage of using DCOM throughout an application is that DCOM requires a significant amount of client-side configuration. Client computers must be configured with information about AppIDs, CLSIDs, ProgIDs, and IIDs. Client computers also require the registration of type libraries. This client-side configuration can be expensive to set up and maintain.

Here's an example of how client-side configuration requirements can be problematic. Let's say you've created a Visual Basic component and installed it in a COM+ server application. You built the component using a MultiUse class with public methods. As you know, you can generate an application proxy to install the type library on the client machine. But what happens if you want to add a few new methods to the second version of the class in an upgraded version of the DLL? If you add new methods and recompile the component under binary compatibility, all client computers will need the updated version of the type library. You therefore have to regenerate and reinstall a new application proxy. This client-side configuration requirement catches many developers and administrators off guard.

The point I'm trying to make is that the problems associated with DCOM and client-side configuration have a tangible administrative cost. You can avoid this cost by using HTTP and a standard Web browser because they lessen or eliminate the need for client-side configuration. Once again, using HTTP without a Web browser or HTML is another viable option.

Another problem with DCOM is that it is impractical for connecting computers that aren't running in a private Windows 2000 or Windows NT-based network. It can be difficult or impossible to authenticate and authorize users from across the Internet. DCOM is also notoriously difficult to configure across a firewall. Most firewall software is designed to allow HTTP requests to pass freely across ports 80 and 443. However, most firewall software makes it far more difficult to configure the ports required by RPC and DCOM.

DCOM also suffers from being a very connection-oriented protocol. For example, client computers using DCOM typically require at least six round trips to the server to run a command. The first three to four round trips are required to create the object. More round trips are required to establish a secure connection to the server process. The last round trip is used to invoke the desired method. Also, tearing down the connection requires at least two round trips, one to execute Release (from IUnknown) and one to tear down the TCP connection. HTTP is far more efficient. A client that relies on HTTP can execute its first method in roughly two round trips—one to establish the initial TCP connection and one to carry the actual request and response.

In Chapter 6, I described how DCOM uses a pinging mechanism to implement distributed garbage collection. This client-to-server pinging is necessary to properly release objects when client applications crash. While this pinging mechanism is important, it's also expensive and limits the number of DCOM clients that can effectively connect to a single server computer simultaneously.

DCOM also poses problems when you want to share a set of server computers across a set of clients. The connection-oriented nature of DCOM pins a client to a specific server, so you can't perform load balancing on a request-by-request basis. Moreover, the apartment-threaded nature of a Visual Basic component pins a client to a specific thread on a specific server. This means that an application based on Visual Basic and DCOM can't take full advantage of the thread-pooling scheme available to a COM+ server application.

An application based on HTTP is much easier to load balance and is far more scalable. Later in the chapter, I'll describe several HTTP load-balancing techniques that are the most common and effective ways of scaling an application. As you'll see, Visual Basic objects should always be created and released in the scope of a single HTTP request. HTTP-based load balancing is the most common way to scale an application to handle thousands of users.

Load-balancing schemes available with HTTP don't merely increase the number of potential users. They can also significantly improve an application's availability because each request for a specific user can be directed to a different server. If one Web server computer crashes or is off line for maintenance, clients can continue to use the application without interruption. This isn't possible when a client is connected through DCOM to a specific object running on a specific server computer.

Despite these arguments for preferring HTTP to DCOM, you must realize that Web-based development presents its fair share of challenges. Emerging standards make it challenging to build and maintain Web applications. It's also tricky to manage sessions of client-specific state when you use a connectionless protocol such as HTTP. Finally, it's difficult to create an effective callback notification system for client applications that are running in a browser on the other end of the Internet. But then again, I know you love a challenge.