The communication layer between the ISAPI extension and the Web Connection VFP server depends on which mechanism is used. The data passed back and forth using strings, but the data may be either a physical string (in COM messaging), message files (file based messaging) or via ASP objects (ASP messaging).

All of these modes support simultaneous request processing by managing multiple instances of your FoxPro server application to work around the limitations of Visual FoxPro as a single threaded environment.

File Based Messaging

This mechanism is the default mechanism and is used primarily when developing and debugging applications. It uses message files to pass information between the Web Server and your FoxPro Web Connection application.

In this scenario the ISAPI extension sends a message file that is picked up by the Web Connection VFP server application to retrieve its input. The HTTP result is returned to the server as an output file. While this mechanism exists primarily for debugging, you can also run this mode as a standalone EXE. File based is easy to set up and work with and requires no configuration. Because of the files created there's some overhead involved, which is critical only when the site running it becomes very busy where the number of message files can cause directory congestion.

You can run multiple file based instances to allow for simultaneous request processing.

COM Messaging

COM messaging uses your Web Connection application as an EXE COM Server for communication between the Web Server and your FoxPro Web Connection application. It uses a plain parameter and return value interface to pass information between the two.

The VFP server is compiled into a COM object and receives the request input as a parameter of one of the COM methods. The HTTP result is returned as a string return value of the method call. COM messaging performs better than file based operation, but is more difficult to set up and configure. Additional advantages include usage of the ISAPI pool manager for scalability, remote server management, auto server restart.

You can configure a pool of COM instances (up to 32) to allow for simultaneous request processing. The Pool is managed as part of the ISAPI extension, which starts the servers and manages their lifetime. The big benefits of COM are better performance, the ability to automatically start servers on the first hit and to automatically recover from any hangs or crashes inside of your FoxPro code.

ASP Messaging

ASP messaging allows a Web Connection COM server to be run as part of an ASP request.

The VFP server must be compiled as an MTDLL (multi-threaded DLL) and is called from an ASP page to generate a complete or partial HTTP response. The request input is retrieved from the ASP Request, Session, Cookies and Server objects and output is sent to the ASP Response object. You should create a separate project from your EXE servers if you plan to mix and match between ASP and either COM or file based operation since compiling a project for different types of servers tends to screw up the ClassIDs in the registry.

Simultaneous request processing is managed through COM and ASP or ASP.NET which will internally load multiple instances of your application. Although InProcess servers can be faster, they also suffer from greater instability and the inability to be effective managed (shut down, restarted, reconfigured) due to the inprocess nature of thes MTDLL COM servers.

It's all transparent

The Visual FoxPro Web Connection framework handles all these messaging mechanisms transparently, automatically adjusting inputs and outputs to the appropriate types. Your application user code does not need to differentiate between these operational modes and should work without any modifications in either mechanism.