Limitations
HTTP routing is a relatively transparent alternative to direct DCOM access, but not entirely so. Client code must be written to use the Initiate method instead of the ASONameServer.Connect method, and to provide a specialized set of parameters on the Initiate call. There are a number of other limitations to keep in mind:
• Unlike DCOM, HTTP is a connectionless protocol. Cookies (or authentication tokens) can be used to simulate a connection over HTTP, but web server applications are configured to time out and release resources being held on behalf of clients that do not send any requests for a long time. If your HTTP clients remain idle for long periods, they may lose their connection to the OpenROAD Server. You can configure the time-out period to be infinitely long, but then resources held for clients that fail to disconnect cleanly will not be released until the web server is recycled.
• HTTP routing is significantly slower than DCOM. Depending on the characteristics of your application, this difference might or might not be noticeable to your users.
• The client-side implementation of HTTP routing relies on the Microsoft XMLHTTP control, and is therefore subject to all the limitations and idiosyncrasies of that control. For example, HTTP routing is not appropriate when the client is running in a server context, such as a web server, or the OpenROAD Server.
• The Java implementation of the example gatekeeper application requires the use of Session State, implemented by cookies. This means that the client's Internet options must be configured to allow the use of non-persistent cookies. The ASP.NET implementation does not require cookies.