Web Application Execution Process-differences between wad, CGI, and ISAPI

Web Application Execution Process -- Differences Between wad, CGI, and ISAPI

Borland provides various types of Web application development in Delphi/C ++ builder. The most commonly used Web application debugger application for debugging (WAD Application) and cgi/ISAPI running on Windows/IIS platform. Although theoretically, there should be no major difference between these types of Web applications except for different types. That is, it is easy to change its type. For example, if there is a wad application that has been debugged, you only need to create an empty ISAPI application, then, add necessary units in the wad application to compile and generate an ISAPI application with the same function. Unfortunately, this is not the case. Shortly after the article C ++ Builder 6 bizsnap (2)-custom data transmission was published on this site, A few of my friends sent me a mail indicating that they encountered some problems after changing the program in the text to ISAPI, so I found some important differences between these types of Web applications. The problem lies in the database access control and datamodule. In that example, I put the data access control in the webmodule, which is no problem in Wad, but there is a problem in ISAPI, this is related to the different execution processes of these two types of programs. The other is about datamodule. Adding a datamodule to wad is fine, however, in CGI, the program is not executed (that is, a file download prompt or error occurs), and in ISAPI, the access violation error occurs. So this article will analyze the execution process of these types of web applications to see their differences. Let's take a look at the wad execution process: The WAD source program is analyzed to find that every wad application uses twebappautoobjectfactory to create an Automation Object, when wad receives a Web request sent to the wad application, it uses getactiveobject to call a running instance. If no instance is running, it starts one. Once the running wad application instance is obtained, the Web request is sent through the interface of this automation object, and thus the Automation Object calls webmodule to simulate the real Web server. Subsequent execution is necessary for general web applications. When the Automation Object is released (for example, when the reference count is reduced to 0), webmodule is released at the same time. That is, the webmodule is available throughout the SOAP request. Let's take a look at the CGI application: CGI runs independently as a process outside the Web server. It is a standard console program, but the Web server redirects Web requests to the standard input of the CGI program, redirects the standard input of the CGI program to the Web response. However, Borland may have some special practices during compilation and processing, that is, when the program contains datamodule, it will be compiled into a non-web application, the CGI program cannot be run in IIS (that is, the download dialog box appears when you enter the URL in the browser ). Therefore, you must dynamically create datamodule when processing the request. Because CGI creates an instance based on each Web request, when the response is returned, the CGI program ends and the webmodule is released. Therefore, during the entire SOAP request, webmodule is available, which is the same as that of Wad applications. Finally, let's take a look at the ISAPI application: In fact, the ISAPI application is started when the first request reaches the Web server (webmodule is created at this time). This operation is implemented in the ISAPI entry: dllentrypoint function. After the request processing is complete, the ISAPI application still exists in the memory, including webmodule. The Web server creates a worker thread for each request for processing. After the processing is completed, the worker thread is terminated. That is, when processing the request, it is in the worker thread and is not associated with the webmodule. In particular, IIS can use dllhost.exe to call ISAPI, make it run in an independent process space (in this case, the dllentrypoint is not executed), so the webmodule and datamodule created at the same time (if any) cannot be accessed when processing the request ), if they are used during request processing, an AV error will occur. Therefore, the global datamodule cannot be used in ISAPI, and it can only be created dynamically. Another solution to datamodule is to use the SOAP server data module instead of datamodule. Why? Soapdatamodule is actually only an interface derived from iappserversoap. It will automatically create corresponding instances during each request processing, saving the trouble of manually creating datamodule dynamically. However, it also has a problem, that is, there are many unnecessary interfaces in the WSDL: iappserver/iappserversoap and so on. At the same time, if datasetprovider is included in the interface, the unnecessary tables are exported. In particular, when dbexpress is used, use sqlclientdataset instead of sqldataset + datasetprovider + clientdataset. [Mental Studio] birds aug.17-02