This chapter is from the book
This chapter is from the book
This chapter is from the book
ATL Server Sequence of Events
As mentioned earlier, three main pieces make up any ATL Server project: the Web application DLL, the ISAPI extension DLL, and the server response file. These three pieces can be seen using the Solution Explorer within the IDE, as shown in Figure 14.6. Each of these pieces plays a certain role within the overall architecture of ATL Server.
){kind=link}
Figure 14.6 The Solution Explorer view showing the three main components of the ATL Server project.
The first action to happen in this sequence of events is the client request for an SRF file. Once IIS receives this request, its first job is to load any DLLs that are registered for this file type and are located in the virtual directory specified by the URL passed to it. The ISAPI extension DLL you created will register itself to handle SRFs as long as the Deployment Support option is checked when you create your project using the ATL Server Project Wizard.
At this point, control has passed from IIS to your ISAPI extension DLL. The next step is to check the server response file cache. When an SRF file is loaded for the first time, it is parsed and any information related to that SRF, such as what DLLs are required, is saved in this cache for subsequent performance improvements should that SRF be needed again.
Once the SRF has been loaded and its DLL references have been determined, the ISAPI extension DLL loads the main application DLL required for the SRF. After the DLL is loaded, the ISAPI extension asks the Web application DLL for certain configuration parameters by calling the GetFlags function provided by the IRequestHandler interface that your Web application DLL implements. It follows this function call with another implemented function in IRequestHandler, called InitializeHandler, to perform any necessary initialization.
It's important to note that so far in this sequence, none of the code you will write has even been touched yet. In other words, the Project Wizard code that was generated for you handles all these tasks, allowing you to concentrate on the main logic of your application.
Finally, the SRF is parsed (if it hasn't already been parsed and isn't already in the server response file cache). Static content is sent back to IIS along the HTTP response stream. Dynamic data, which is represented as tags within the SRF, is replaced with whatever content is sent by your Web application DLL tag replacement handler.