The Server Architecture

Web Connection is made of two separate components that comprise the full Web Connection framework: An ISAPI connector (as well as an optional CGI component for those Web servers that don't support ISAPI) that communicates with the Web server and a Visual FoxPro based framework that knows how to communicate with this ISAPI extension.

The ISAPI connector's job is to take the request information that a Web request provides - HTML Form variables (HTTP POST data), Server Information (server port, Software etc.), client information (Client IP address, Browser etc.) and Request state information (such as cookies and authentication info) - and pass it forward to a Visual FoxPro server application that waits for incoming requests. As such the connector is an Application Service Provider that provides the interface between Web Server and Visual FoxPro.

The Visual FoxPro server application can run in a number of different ways - as COM server for deployed applications, as file server for development - and there can be multiple instances of this server running to process simultanous requests. Because Visual FoxPro is a single threaded environment that can process only one request at a time, this pool of instances is used to provide support for simultaneous request processing.

The server or servers receive the incoming request data as input to individual request processing. The server is built using pure Visual FoxPro code and it contains the Web Connection Framework and your application specific implementation code. The code that fires is responsible for generating HTTP output for an incoming request. In most cases this output will be HTML, but it can also be XML, or binary content such as a data file, a Word or PDF document for example. The result is returned through the Web Connection Framework - typically the Response object - and returns essentially a string that is then displayed in the browser or served to an HTTP client.

The above diagram demonstrates how requests travel from client to server. The request starts with the HTTP client which tends to be a Web browser, but it could also be a Fat Client HTTP application (for example a VFP application using the wwIPStuff class) to request data from the Web server over the HTTP protocol. There are two common mechanisms that the client can use to request data: HTTP GET or HTTP POST. Get simply requests data, while POST can request data as a result, but also has the ability to receive data back.

The client makes a request over the Web through either an HTTP GET or POST operation. HTTP GET's are typically hyperlinks accessed in a browser, POST operations occur when you submit an HTML form in a browser which 'posts' the input field values to the server. Both operations can return data to the client but only POST can push data up to the server.

When the request hits the server it hits the server with a link against the Web Connection DLL:


This causes the Web server to load the ISAPI extension into memory - once it's loaded it stays loaded and the single instance of the DLL is recycled. The ISAPI extension is written in C++ and is a true multi-threaded ISAPI extension, which means it can take multiple requests simultaneously on multiple processor threads.

The ISAPI DLL receives the incoming request and picks up all of the server's request information and encodes it into string and passes this information forward to the Visual FoxPro Web Connection server. The server picks up the request information and uses this information as the request input much like you would fields on a form or parameters.

At this point your server code has full control and can run any Visual FoxPro code using the Request object to retrieve input and the Response object to send output into the HTTP output stream. You can use FoxPro tables and cursors, you can use SQL Server if you like, you can call COM objects - just about anything that the FoxPro language allows except user interface operations which for obvious reasons won't work in a Web environment.

The mechanism and syntax for the actual request processing varies depending on the method you use to generate your output. You can use low level code that uses the Response object directly and allows raw access to the output generated directly, or you can use high level tools like the Web Control Framework that abstract the output processing using an object oriented and control based model. Other tools allow generation of PDF documents from reports, parsing Visual FoxPro forms to HTML and to provide various Web Service type interfaces.

In all cases the output is channelled through the Response object and is then passed back to the ISAPI extension, which in turn sends the output back to the Web server.

The mechanism used to pass data between the ISAPI connector and the Visual FoxPro server depends on the messaging mechanism used: File based, COM based or ASP.

© West Wind Technologies, 1996-2018 • Updated: 05/30/17
Comment or report problem with topic