Using DCOM over the Internet

[Previous] [Next]

Although the use of DCOM between a desktop client and a COM+ 1.0 application (or generic DCOM server) is rare over the Internet today, the use of DCOM in a demilitarized zone (DMZ) setting, in which the requirements are substantially similar to firewall issues, is much more common. Therefore, the scenario we'll examine here is Internet Information Services (IIS) running in a DMZ interacting with a COM+ 1.0 application within the corporate firewall, as shown in Figure 7-19.

Figure 7-19. COM+ in a DMZ scenario.

COM Internet Services

COM Internet Services (CIS) introduces support for a new DCOM transport protocol called the Tunneling Transmission Control Protocol (TCP), which allows DCOM to operate over TCP port 80. This allows a client and a server to communicate in the presence of most proxy servers and firewalls, thereby enabling a new class of COM-based Internet scenarios.

A DCOM transport protocol

In many Internet situations, the network connectivity between a client and a server is subject to a number of restrictions:

• A proxy server that filters outbound network traffic might control the client's ability to send information over the Internet. This is often the case for applications running in a corporate environment, but it can also apply to applications run by a user connecting to the Internet through an ISP.
• A firewall often controls incoming Internet traffic and defines which combinations of network ports, packets, and protocols are accepted to protect the server (or client) network environment.

In practice, the net effect of such restrictions is that a client and a server will probably have a very narrow set of protocol and port combinations available to carry out a conversation. Because DCOM dynamically selects network ports in a range (1024-65535) in which Internet-to-intranet network traffic is typically not allowed, it's not possible to reliably use the existing DCOM transport protocols over the Internet, although they are perfectly suitable for intranets. Moreover, firewalls are often set up to restrict access to port 135, upon which DCOM depends for a variety of services.

The Tunneling TCP protocol introduces a special handshake at the beginning of each DCOM connection that allows the connection to pass through most firewalls and proxies. After this handshake, the wire protocol is simply DCOM over TCP. This means that the protocol is transparent to both client and server. Neither the client code nor the server code needs to be modified to use CIS. Also, all the DCOM-over-TCP protocol services are available—including DCOM security and lifetime management (that is, "pinging") services.

Tunneling TCP protocol overview

The Tunneling TCP protocol is illustrated in Figure 7-20 and proceeds as follows:

1. If the client configuration indicates that HTTP traffic to the server should be routed through a proxy, the client DCOM run-time environment establishes a TCP/IP connection to that proxy. It then sends the HTTP CONNECT method to the proxy, requesting connection to port 80 on <server host>.
2. The proxy establishes a TCP/IP connection with <server host>. Note that this assumes that the proxy is configured to enable the HTTP CONNECT method on the port connected by the client. This port configuration on the proxy is sometimes referred to as enabling SSL tunneling.
3. If the client configuration does not use a proxy, the DCOM run-time environment establishes a TCP/IP connection to port 80 on <server host>. After this step, whether or not the client uses a proxy, the client has a connection to port 80 on <server host>, which is perhaps mediated by a proxy. The client now sends the RPC_CONNECT command to the server, requesting connection to the DCOM server on <server host>.
4. In response to the RPC_CONNECT, the server RPC run-time environment—implemented in part by an ISAPI filter/extension pair—establishes a local connection to the DCOM server.
5. Client and server have now established a mediated TCP/IP connection and engage in a DCOM-over-TCP conversation.

Figure 7-20. The Tunneling TCP protocol.

For more information regarding CIS, refer to http://msdn.microsoft.com/library/backgrnd/html/cis.htm.

A Tunneling TCP protocol limitation

The Tunneling TCP protocol has the following requirements:

• It requires that IIS 4 or later be installed on the server-side machine hosting CIS-accessible COM objects, because part of CIS functionality is implemented using an ISAPI filter.
• Because Tunneling TCP consists of non-HTTP traffic after the initial handshake, CIS requires that proxy servers and firewalls permit such traffic over a port opened to HTTP.

Note that because of these requirements, CIS does not support callbacks. For example, your applications cannot perform notifications by using the connection point or advise sink mechanisms. However, if the CIS client can function as a CIS server, nothing prevents the client from receiving DCOM calls—including callbacks.

Simple Object Access Protocol

The Simple Object Access Protocol (SOAP) is a proposed standard defining a protocol for accessing objects over the Internet. While products supporting SOAP were not yet available at the time of this writing, we expect them to become available shortly.

SOAP defines an RPC mechanism using HTTP as the transport and XML documents for encoding request and responses. The primary objective of SOAP is to provide an object invocation mechanism built on Internet standards. In particular, one of the important design goals of SOAP is that it be usable over today's World Wide Web infrastructure, specifically with regard to the use of proxies and firewalls.

For details about the SOAP protocol, visit http://msdn.microsoft.com and search for SOAP.