History of a CMS Page Request

To clarify an important part of the CMS server architecture, let's trace the path of a CMS page request (Figure 3-2). First, the client requests a CMS URL. This request goes to IIS and passes through the Internet Server Application Programming Interface (ISAPI) filters loaded on the server. The CMS ISAPI filter examines the URL to see if it maps to a posting in the CMS server. If there is a matching posting, the URL is modified to point to the ASPX template file for the posting. The new URL also includes a query string that specifies the posting to render. For example, the URL homepage.htm might point to a posting that uses a template file called home.aspx. The URL would be modified to be /home.aspx?NRNODEGU where "xxxxx" is the Globally Unique Identifier (GUID) of homepage.htm. This URL is returned to IIS, and it runs the specified ASPX page to render the posting. In the live site mode, CMS can translate this GUID-based URL to a more readable hierarchical URL (e.g., http://www.botsconsulting.com/home.htm).

Figure 3-2. The path of a CMS page request

To create the page's HTML, IIS runs the specific ASPX page template. This page may contain server controls and a code-behind page that interacts with the CMS system. If the needed information has not been requested before, the CMS server requests the required content and resources from the CMS database. If the page has been requested before, the many CMS caching strategies limit trips to the database. This dynamic page assembly process is one of the fundamental features of CMS. Each time an author edits a page and goes through the CMS workflow, the changes are saved by the CMS system. The next time the pieces are requested, the updated HTML will be served to the user. By combining the CMS caching features with ASP.NET output caching, it is possible to serve up ASP.NET pages much faster than with regular ASP pages. Considering that CMS 2001 only supported ASP, this provides a significant improvement over CMS 2001 performance.