When to use COM

Web Connection supports both File based and COM operation. File based is meant for development while COM based is meant for deployed applications, but it's also possible to run file based in production.

COM Advantages

• COM Servers start automatically
  COM Servers are automatically launched on the first hit to the server. They also shut down if the Web application shuts down. They do not need to run as a service or require any other auto-start mechanism.

• Crash Protection
  Reality: FoxPro servers crash occasionally, try as you might. Using COM Web Connection can detect failures immediately and restart crashed COM servers automatically. This is not possible in file mode.

• Better Remote Management
  COM servers can be administered entirely over the Web. You can easily start and stop instances and change the count of instances running. You can get basic server execution stats. You can also remotely update your Web Connection Server binary without shutting down the site, simply by uploading a new binary and hot-swapping the new binary on the fly.

• Improved Performance in high volume environments
  COM operation provides better performance under load as it eliminates the message files that are used for file based messaging. Under low load scenarios the difference is minimal but under heavy load COM can significantly improve throughput.

COM Disadvantages

COM Servers require a little bit of extra setup initially if you are doing manual configuration as the COM server has to be registered on the remote server.

It can also be harder to fix startup errors in COM servers, because COM Servers generally run invisibly. It's important to test your COM servers locally before deploying them to a live server and possibly also running your live server in file mode first to ensure that everything works. There's more info in Dealing with COM Server Load Errors.

If you run into startup errors make sure you check out wctracelog.txt which logs startup errors.

No code changes required

COM operation is supported transparently by Web Connection and you can very easily switch back and forth between COM and File modes. Other than potential security related issues (if your COM server launches under different credentials) file and COM server applications behave the same.

Server Startup Code in wwServer::OnLoad()

Make sure you don't have server startup code in the wcDemoMain startup code snippet. It's a common error that startup configuration is placed in the PRG files startup code which is not contained in the server. When running in COM this startup code is never fired - the COM Server is directly instantiated.

Any startup code you want to run when your server loads should be handled in the wwServer::OnLoad() overload in your Web Connection server class.

Using File Mode in Production

Generally COM is recommended for production applications because it is faster and provides better administration.

But there are situations where File base operation can be used.

Debugging

If you have a persistant problem in one of your application, running in file mode or running through the Visual FoxPro IDE even with source code can provide better insight into the application as you can stop operation and potentially attach a debugger.

You can also run interactively on the desktop which can make it easier to stop code and display debug messages.

Scale over many Machines

COM is a local machine protocol. Although COM has support for Remote Activation of components, that functionality is very difficult to set up correctly and more importantly very buggy and prone to random unloads and crashes. It's not recommended to use Remote DCOM servers.

File mode however allows you use multiple machine to process requests against a single Web Connection server by sharing messaging file in a shared temp messaging folder. Multiple machines can run multiple Web Connection instances each looking at the same network path where Web Connection Temp Files are picked up.

This can allow many machines with many instances to share a single Web site for request processing.

Although this approach is quite possible and has been successfully used, this mechanism also has limitations due to Windows' problem with large numbers of files in a single folder that Web Connection uses for messaging. However it can work well for applications that have many long running requests that may tie up server instances for lengthy periods of time.

Ultimately, the preferred approach for scalability is to use proper load balancing with multiple identically configured machines running their own set of Web Connection instances behind a hardware or software load balancer that fires requests at these multiple machines.