At Your Service

The mechanism for serving dynamic pages varies from vendor to vendor, but there is some common ground. When a browser makes a request to Microsoft's IIS for an ASP page, the server initializes application- and session-scoped variables, procedures, and methods. A globally unique identifier (GUID) is generated in both the session object on the server and the browser's memory, in effect acting as a memory-based cookie. The application then checks the global ID as each user moves through the application session.

HAHTsite projects can be published so that state IDs are either stored in cookies or included in URL strings. In the latter scenario, developers drag and drop links to a static start page; the IDE dynamically generates an elaborate URL when t he site is published to Haht's Application Server(s). For example, the link to start a new session might look like this:

http://www.southerndigital.com/cgi-bin/hsrun/webapps/MyApp.htx;start=HS_LoginPage

The hsrun CGI program (or other API module) generates a state ID string, which is then embedded in other links on the generated page returned to the browser. Then hsrun decodes subsequent URL requests to identify which Application Server process gets the request.

Like IIS and its tightly linked ASP engine, the Domino server uses a variant of IBM's ICS 4.2+ HTTP server. When a page is requested, Domino examines the URL and, if it determines the data is a static page, sends it through for normal processing. If it rec ognizes the URL as a Notes object, then it passes the request to Domino, extracts the object from the Notes NSF database, does a dynamic conversion to HTML, and sends the page to the browser. Domino binds data from its own database to its programming logic late in the process, applying a form's formulas, scripts, and images to do a lot of processing before generating the page.