Developing Internet-based apps means discarding many traditional concepts of client/server design. You have to pay attention to scalability and concurrency issues that never came into play before.

A friend confessed to us recently that he felt unsure about joining the ranks of the Web application industry. His strong C++/MFC skills gave him a sense of job security and self-worth that, in his mind, would be lost by becoming yet another HTML programmer. He was right to assume that simply adding HTML to his resume wouldn't make him invaluable overnight. Anyone can create an HTML page these days, right? Just ask your marketing department.       Not everyone can create interactive Web applications that improve the profitability of your company. Even more difficult is creating Web applications that can scale over time without requiring a rewrite of a single line of code. Web application developers who understand how to build these complex systems are indeed invaluable in today's Web-driven market. If you're a Web application developer or trying to become one, it's imperative to understand the design considerations you'll be facing.       In this article, we'll begin by reviewing the typical client/server design strategies used today and explain why they can't be adapted to the Web model. As you read this article, you'll learn how you can start thinking in terms of Web applications. In the process, you may have to set aside many of the design principles (and habits) you've learned over time because they simply don't work on the Web.       In addition to covering the design limitations with the Web model, we'll define the concepts of a user session and session state in a Web application and how they can influence the overall performance and scalability of your system. We'll tackle one of the toughest design questions every Web application developer faces: where should I store session state?       Next, we'll turn to a new Web application design pattern that we call the one-page Web application. While this innovative design pattern can be implemented on most browser flavors (if the developers are creative enough, that is), it becomes trivial with the new technologies built into Microsoft Internet Explorer 5.0. You'll see how XML along with new features in Internet Explorer 5.0 can help you achieve your Web application design goals. Typical Client/Server Application Design       Whether you come from a C++, MFC, or Visual Basic® background, you have probably dealt with client/server applications. If you've ever written a simple database front end or even a more complex multitier system, you've dealt with the client/server arena. Regardless of the project complexity, most client/server applications share certain design characteristics. First and foremost, typical client/server applications have a limited number of users. At design time, the maximum number of concurrent users that your system must support is given as a requirement. From that point on, most of the remaining design decisions are made around that assumption.       Knowing how many people will be using your application concurrently can help tremendously as you make other design decisions along the way. But, as you design your system around the given requirement, you usually end up with a system that provides exactly that level of functionality and nothing more. If in six months the bigwigs in your company decide that the system should support twice as many users, more often than not you're back to the drawing board, or at least stuck rewriting substantial amounts of code.       Most client/server applications also operate in a very controlled environment. Typically, developers are writing the code for both the client and the server. These same developers can usually dictate to a great extent such things as the required operating system, database, or any other system dependencies for both the client and server machines. Having this kind of control over your system's runtime environment reduces the complexity of the system and makes developers happy. However, arming developers with this kind of information at design time can lead to systems that are difficult to port to new environments.       Another interesting client/server design concept is that of user connections. In most cases, when the user launches the client application, a connection is established with the server and maintained until the client application terminates. Because these connections are expensive and time-consuming, it's usually better to make the connection once and to share it among processes for the lifetime of the client application.       Since the server maintains one connection per client, this model provides a simple mechanism for tracking user sessions. When the server picks up a new connection, it knows that a new user has begun using the system. As the user interacts with the system, the server can associate session-related data (state) with the user's connection or session ID. Once the client connection goes away, the user's session ends and the corresponding session state is released from server-allocated resources.       Not all client/server applications are designed this way. These are just some of the typical client/server design characteristics that are common today. Chances are you're used to thinking about applications as we've just described. Unlimited Users       Unlike client/server applications, which have a limited number of users, Web applications have a potentially unlimited number of users. When you initially design the Web application, you may only expect 5,000 hits per month. But that 5,000 can turn into 500,000 virtually overnight. Most companies underestimate the potential of their applications during the design phase.       In client/server scenarios, the company usually has control over the number of clients accessing the system along with the growth of the client base. This allows the company to plan for scaling the system. On the Web, you need to be prepared to scale from the very beginning. Having to completely redesign your Web application after three months on the market would be devastating to your company's strategic plans (and probably your career).       In short, Web application developers must think in terms of unlimited users and, therefore, scalability. This doesn't mean that your Web application has to handle 500,000 hits per day right out of the gate. It simply means that your Web application needs to be designed with scalability in mind so that when you cross certain thresholds, you can increase throughput by adding additional hardware to your Web farm without changing any code. This is probably the most important thing to get right in your Web application design. We'll be discussing this concept in more detail throughout the rest of the article. Browsers Galore       Most Web applications, with the exception of intranet applications, also have very little control over their client's runtime environment. Users may try to use your Web application with various different browsers.       Since you don't have any control over the client's runtime environment, you must decide early in the design phase which browsers your application will support. If you decide to support all of them, you'll be incredibly limited in client functionality. Most companies today decide to support certain versions of Internet Explorer and Netscape Navigator. This strategy makes development less complex and less restrictive. In this situation, if a user tries to use your Web application with an unsupported browser, the Web application should advise the user that things might not behave properly and advise them to update their browser.       This cross-browser compatibility issue is a major frustration for most Web application developers. They see new technologies surfacing in newer browser versions—like Dynamic HTML (DHTML), Cascading Style Sheets (CSS), XML, and HTML behaviors—that would allow them to create very sophisticated Web applications. But because of corporate policy, they must continue to support every known browser. Many developers in this situation will develop parallel versions of their Web application for the different browser versions and take care of browser identification and redirection on the server (see Figure 1). This approach allows developers to take advantage of the newest technologies without affecting down-level clients. Unfortunately, this also requires the simultaneous maintenance of multiple application versions.

Figure 1: Different Versions for Different Browsers

HTTP       A typical client/server application supports the notion of a physical user connection. The server uses this one-to-one mapping between users and connections to track user sessions and session-related state. Web applications must behave differently. In fact, this basic concept of user connections is what makes Web applications fundamentally different from typical client/server applications.       The reason Web applications can't use the client/server model for tracking user sessions is related to the Web's underlying protocols. The ubiquitous protocol on the Web today is HTTP. To help understand how HTTP works, let's look at a typical HTTP request.       When the user points the browser to a given Web site, the browser first establishes a TCP connection with the corresponding Web server. Once the connection is established, the browser sends an HTTP request using the existing channel. The Web server then processes the request, sends the response back to the client, and closes the TCP connection.       This same process is used for every HTTP request made by the browser. For example, consider a Web page with 20 embedded images. To retrieve this page, the browser has to make an HTTP request for the HTML page itself, and additional HTTP requests for each of the 20 embedded images. As you can see, this protocol is a far cry from the client/server model where the connection is made once and used for the lifetime of the session. With HTTP, the user connects and disconnects on every request.       HTTP/1.1, which isn't supported by all browsers or Web servers, offers a new mechanism called persistent connections to optimize the connection process. With persistent connections, the server maintains the connection with the client for a period of time so the client can reuse the connection for subsequent requests. Session, State, and Security       Since HTTP/1.0 doesn't support the concept of persistent connections, there isn't a straightforward way to keep track of user sessions. HTTP is truly a stateless protocol. In other words, the HTTP server doesn't remember anything about previous HTTP requests. If a user sends an HTTP request and then sends another one a few minutes later, the HTTP server behaves as if it's the user's first request.       Owing to the connectionless and sessionless nature of HTTP, Web application developers are required to implement higher-level session management. The browser and the server must agree on a mechanism for identifying users on a connection-to-connection basis.       Once you have a mechanism for identifying users across connections, you can start associating session state with a given user. In the client/server model the session state is typically stored on the server. While this is by far the easiest solution to implement, you'll see that storing session state on your Web server can severely impair scalability. So where should you store session state in your Web application? This is one of the hardest questions that every Web application designer must face.       Another complex consideration is security. Today, everyone is concerned with security. If you visit an online shopping site and don't see the little yellow lock show up in the browser's status bar, you go elsewhere. If you've ever tinkered with network sniffers like NetMon, you know how easy it is to intercept data submitted as clear text.       To make things even more complicated, developers must also deal with the possibility that their Web application or its clients will live behind a firewall. Firewalls block potentially malicious traffic from reaching your corporate network. They do so by rejecting attempts to establish TCP/IP connections on unsecured ports. Remote procedure call protocols such as DCOM attempt to establish connections on arbitrary TCP/IP port ranges. Unfortunately, since the firewall has no way to know whether these ports are secured, and because they generally have no knowledge of the port negotiation protocol used by DCOM, they simply prevent this traffic from passing through. But there is a protocol that generally passes unimpeded across firewalls: HTTP, which communicates over the well-established port 80. We will discuss ways in which you can invoke code on Web servers by passing appropriate messages using HTTP.       As you can see, designing a Web application is very different from designing a typical client/server application. Considerations you must address early include tracking user sessions and deciding where to store session state. Managing Sessions       There are basically two standard mechanisms for managing user sessions in a Web application. Both require session-related information to be explicitly passed between the browser and the server as part of every HTTP request. Once again, since HTTP is stateless, you must provide the mechanism for reidentifying users. We like to think of this session information as being passed either by value or by reference.       There are two common mechanisms for passing session information by value: by using hidden form elements and embedding data within URLs, and by using cookies. For the first mechanism, as the user interacts with the Web application and the server needs to save session data for the user, the server embeds the data in hidden form elements or relative URLs. This data is passed to the client as part of the HTML page retrieved from the server. The next time the user interacts with the server, either by clicking on the submit button for the form or by clicking on a link, the session data will be passed back to the server as part of the HTTP request submitted by the browser.       This approach, although quite cumbersome, is seen in Web applications today because it works with browsers that don't support more advanced techniques like cookies. However, you must think extra hard about security when using this approach since users can easily tamper with the session data before sending it back to the server.       You can also use cookies to pass session data by value. Each time the server needs to save some session state for a given user, it can send a cookie containing the data back to the client. As long as the browser supports cookies, it will send the cookie back to the server every time the user makes additional requests to the same domain. This works well if you can assume cookie-compatible browsers and you don't need to save large amounts of data (cookies impose various limitations; see RFC 2109 at http://www.ietf.org/rfc/rfc2109.txt for more details). If you need to associate large amounts of data with each session, passing information by reference is much better.       Instead of passing all of the session data back and forth within each request, you could simply pass a session identifier to the client that references the user's session data stored somewhere else (such as in memory on the server or in a database). This decreases the amount of data that has to be transmitted with every request and prevents the user from hacking the data.       The first time the user points their browser to the Web application, the browser will not send a session ID to the server (it doesn't have one yet). The server notices that this is a new user and creates a new session ID, which is transmitted back to the browser. On every subsequent request, the browser sends the session ID back to the server so the server can identify the client (see Figure 2).

Figure 2: Passing Session IDs

The server can pass session identifiers by using a hidden form field or embedding it within every relative link (see Figure 3). Like the pass-by-value approach, this also works on all browsers, but is much less cumbersome than the complete pass-by-value technique. The only thing you would pass as part of every HTTP request is the session ID. The server uses the session ID to look up the user's session data. This approach is commonly used today by big Web applications that have to support a wide range of Web browsers. For an example, point your browser to Amazon's Web site and view the HTML source for the pages you get back. You'll notice a session identifier embedded within every URL from the Amazon domain.       If you can assume cookie-compatible browsers, you can also use cookies to send a session identifier back to the client. This is actually how the built-in Active Server Pages (ASP) session management works. If you have session management enabled (the default), the first time you hit an ASP page in your Web application, the ASP runtime automatically sends a cookie to the client containing the session ID. Since ASP uses in-memory cookies, you won't see the cookie on disk, but you can use NetMon to verify this behavior. Session Lifetime       So when does a Web session end? In a client/server application, the session ends when the user closes the client application. In the Web environment, it isn't clear when a session should end. Should it end when the user browses off the page? Or when the user closes the browser? What if the user leaves the page open for days without doing any work? Should the server keep resources allocated for that lazy client?       The standard answer for Web sessions is a timeout period. For example, if 20 minutes go by without any activity from a given client, the server terminates the client's session and reclaims its resources. In fact, ASP's built-in session management uses a default timeout period of 20 minutes, but this value is configurable. If you're using one of the manual techniques described previously, you're responsible for determining when a session should timeout (possibly by setting the cookie's expiration date).       Transmitting session information through a pass-by-reference technique is becoming the standard in most new Web application development projects because of its obvious benefits. When you pass by reference, you must first decide where to store the session data. Where should you store session state in your Web application? There is no single correct answer to this question. When it comes to Web applications, there is no magic bullet that will solve all of your problems. There are too many variables to consider from one project to another, and we definitely believe in using the right design for a given project.       Nevertheless, there are certain Web application principles that will help guide you toward making the right decision for your project. But you must first understand state durability and the state's scope. Durability and Scope       Most Web applications contain both durable and nondurable state. Durable state is persisted to disk in order to survive system failures. Most durable state is stored in some type of relational database (such as SQL Server™) for optimal storage. Durable state is obviously more robust, but that robustness comes with a performance cost. Accessing and updating durable state requires more CPU cycles along with a data- locking scheme (usually provided by the DBMS).       Nondurable state does not survive system failures. Session state stored in memory on the Web server is an example. If the Web server goes down, the current state goes with it. Nondurable state offers much better performance at the cost of robustness.       Most Web applications today use a combination of both durable and nondurable state. Deciding when to use one over the other can obviously have an impact on system performance and reliability. As a rule of thumb, if the data is not critical or can be regenerated at minimal cost, use nondurable state. For all system-critical data, like user passwords, use durable state.       Web application state can also exist at four different scopes: page scope, session scope, application scope, and external scope. Page-scoped state lives in the currently loaded Web page and exists only for the lifetime of the page. As soon as the user browses to a new page or closes the browser, the page-scoped state can no longer be accessed.       The technique for passing session data by value (using hidden form fields and URLs) described earlier is a good example of page-scoped data. The data in the hidden form fields and URLs exists only for the lifetime of the page. Once a new page is requested from the server, the browser discards the state. This is why you need to pass that state back to the server as part of the request for the next page in the Web application.       Session-scoped data lives for the lifetime of the user's session. As long as the user's session is still active, the session-scoped data can be accessed. Once the user's session expires, the session-scoped data is removed from the system. Data that needs to be tied to a given user for the lifetime of the user's session should be stored at this scope.       Application-scoped data lives for the lifetime of the application. Data stored at this scope is global in nature and needs to be shared between all active sessions. As long as the Web application is running, any user can access data stored at application scope. Once the application terminates, the application-scoped data is removed from the system.       External-scoped data lives beyond the lifetime of the Web application. This type of data is usually managed by another application that is not dependent on the Web application (such as a relational DBMS). Data stored at this scope can be accessed across multiple Web applications.       Now that we've covered the nature of Web application state, let's focus on the different techniques for managing application and session-scoped state. In-memory State on a Web Server       The easiest method for managing session and application-scoped state is to use the support provided by ASP. The ASP Application and Session intrinsic objects exist for this purpose. To store data at application scope within an ASP page, you simply use the following syntax:

Application("HitCount") = Application("HitCount") + 1

This would increment the application-wide hit count. Storing information at session scope is just as easy using ASP:

Session("StartTime") = Now

The ASP intrinsic objects store the data in memory on the Web server on which the ASP page is executing. As noted earlier, the ASP session management scheme uses cookies behind the scenes to match a given client with its corresponding Session object in memory. As you can see, this nondurable state mechanism is very straightforward and easy to use; the ASP runtime hides all of the pass-by-reference details, allowing you to be more productive. If your Web application is small and will never need to scale, this is the best solution for you.       If there is even a small chance that your Web application will have to scale to a Web farm scenario (where you deploy it on multiple identical Web servers), you may want to think twice about using this strategy. In the Web farm scenario, storing data at application scope in memory on the Web server doesn't work; ASP pages running on other Web servers in the farm will not see each other's updates. You could still get away with storing session state in memory on the Web server, but now you've pinned the client to a single Web server for the lifetime of its session (see Figure 4). This completely destroys any type of dynamic load-balancing strategy you might try to implement within the Web farm. Plus, you'll probably need some expensive hardware (like the Cisco Local Director router) or software to accomplish the session pinning. In other words, you've created a very complicated mess.

Figure 4: Effect on In-memory State Storage

Another major downside to storing state in memory on the Web server has to do with fail-over. If the Web server goes down, the state is completely lost and all users in the middle of sessions lose their data. Plus, if a user is pinned to a server and that server goes down, he is stuck until it comes back online. In-memory State on Another Server       Another approach is to store application and session-scoped data in-memory on a distinct server designed to manage data. When your ASP page needs to store session-related data for a given user, it sends the data to the server through a DCOM method invocation. This allows you to take advantage of dynamic load-balancing on your Web farm without pinning a user to a Web server. If one Web server goes down, the next time the client connects, he will get sent to the next available Web server (see Figure 5). This solution is going to be slower than local in-memory storage on the Web server, since you have a network round-trip each time you need to access or update data.

Figure 5: The "Next-available" Web Server Approach

Windows® 2000 will introduce a new technology called the In-Memory Database (IMDB). (IMDB technology has been discontinued. See the IMDB update page for more information — Ed.). This technology will, in theory, allow you to cache database tables in memory on all Web servers within a Web farm for lightning-fast access. The first release of IMDB, however, only works in single-node scenarios. IMDB acts as a write-through cache manager for a specific relational database. All updates to the IMDB tables must take place through the IMDB cache.       To make this work in a Web farm scenario, an IMDB cache must exist on each Web server. Problems arise when you need to do updates on the database tables. If one machine updates a table that lives in an IMDB cache on another machine, the IMDB machine won't see the change. You need to keep the IMDB caches synchronized on all the Web servers in the farm. This cache synchronization mechanism is planned for the next release of IMDB. Today, you can use IMDB on a dedicated state server as long as all changes go through the IMDB cache (see Figure 5). As you can see, IMDB gives you the best of both durable and nondurable state.       Probably the most common approach today for storing application and session-scoped state in large-scale Web applications is to use a durable storage mechanism like a relational database. The database can reside on the Web server at first. Then, when the site needs to scale to a Web farm, it can be moved to a dedicated database server. Shopping cart applications that keep your purchase data around for days or even weeks are probably using this strategy. Although this strategy offers lower performance than the nondurable solutions, it allows your application to take advantage of dynamic load-balancing and fail-over strategies. Furthermore, using durable storage makes system failures much less of a problem. Client State       Up to this point we've been focusing on state management strategies for the server. Although for application-scoped state there really isn't any other alternative, there are several techniques for storing session-scoped state on the client. As you'll see, this client flexibility offers some very compelling advantages over server solutions.       There are a few mechanisms available for storing nondurable session state in-memory on the client. You can use the IWebBrowser2 PutProperty and GetProperty methods for storing and retrieving any variant-compatible data type in Internet Explorer 4.0. You can even use the PutProperty method to store an automation-compatible object reference. If your object implements the IDiscardableBrowserProperty interface, the browser will automatically call release on your object if it hasn't been accessed for ten minutes.       You can also use cookies to store nondurable session state in-memory on the client. If the server sends a cookie to the client without an expiration date, the cookie becomes an in-memory cookie and will not be saved to disk. It remains in-memory until the user closes the browser (once again, this is how the ASP session management works).       Finally, Internet Explorer 5.0 offers a new behavior called saveHistory for storing nondurable session state in-memory on the client. This behavior allows you to save data that can be accessed across page transitions and is very easy to use from scripting languages.       All of these techniques for storing session state on the client take a heavy burden off the server. They allow you to take advantage of the client's memory resources instead of using up valuable server resources. Plus, they all support dynamic load-balancing and will not be affected by system failures on the server (see Figure 6).

Figure 6: Client-side Session State

The biggest problem with this approach is cross-browser compatibility. None of these techniques are universally supported across browsers, and most of them—with the exception of in-memory cookies—are supported by Internet Explorer 4.0 and later.       You can take things a step further and store session state on the client's disk. You can accomplish this today using persistent cookies (cookies with an expiration date). Internet Explorer 5.0, however, offers a much more powerful and flexible solution with its new userData behavior. The userData behavior allows you to store state as XML on the client's disk. This allows you to add rich structural meaning to your data store, and it gets you around the standard 4KB cookie limit. Using this approach, you get all the same advantages described above, plus the ability to persist state across user sessions. If the user closes their browser and comes back to your application two days later, the state will still be on their disk and available for use. The downside, once again, is cross-browser compatibility. Do We Really Need Session State?       All of the state management techniques described here are being used today in Web applications. Some work better than others depending on the given project's requirements. Now let's stop and think about a fundamental question: why do you need these strategies for managing session state?       The answer lies in page transitions. Each time a user interacts with the Web server, the browser loads and renders a new HTML document. Once the new document is loaded (as the result of a page transition), the data contained in the previous HTML page is no longer accessible. In other words, page-scoped state != session-scoped state. Since page-scoped state is not equivalent to session-scoped state, you need an additional mechanism (like the ones described earlier) for preserving state across page transitions. But what if it were possible to devise a design that changed the formula to page-scoped state == session-scoped state? If this worked, you wouldn't have to worry about managing session state outside the scope of a given page. You can make this formula hold true by avoiding page transitions within your Web application. Then any piece of data stored at page scope would also exist at session scope. A One-page Web Application       Avoiding page transitions in your Web application gives you what we call the one-page Web application pattern. How on earth will a one-page Web application accomplish anything useful? We never said that the application couldn't interact with the Web server; it simply can't produce a standard browser page transition.       While it's possible to produce a one-page Web application using some down-level browsers, it's never been easier than with Internet Explorer 5.0; it's as if Internet Explorer 5.0 was designed specifically for this type of Web application. The Internet Explorer 5.0 enhanced XML support combined with DHTML is what makes it possible.       Internet Explorer 5.0 introduces the concept of an XML data island. Using an XML data island, you can contain an XML segment within your HTML document. Internet Explorer 5.0 will automatically parse the XML data and allow you to programmatically access the XML document object model (DOM) from script. The following is an example of an XML data island:

<HTML> <BODY> This is an HTML document <XML ID=sessionData> <ORDERS> <ITEM ID=1> <NAME>Essential WinInet</NAME> <PRICE>34.95</PRICE> </ITEM> </ORDERS> </XML> </BODY> </HTML>

XML data islands also have an src attribute that you can use to point to XML data on the Web server:

<HTML> <BODY> This is an HTML document <XML ID=xmlData1 SRC="orders.xml"></XML> <XML ID=xmlData2 SRC="getorders.asp?userid=2"></XML> </BODY> </HTML>

Notice that XML data islands can point to static XML files or even ASP files that generate XML output. Now for the interesting stuff: you can also dynamically change the src attributes of XML data islands from script.

<HTML> <BODY> <SCRIPT LANGUAGE=javascript> function getXML(id) { xmlData1.src = "getorders.asp?userid=" + id; } </SCRIPT> This is an HTML document <XML ID=xmlData1"></XML> <INPUT TYPE=button VALUE=User1 ONCLICK="return getXML(1)"> <INPUT TYPE=button VALUE=User2 ONCLICK="return getXML(2)"> </BODY> </HTML>

As you can see, XML data islands are a very convenient mechanism for requesting additional data from the server without forcing a page transition.       Another new object in Internet Explorer 5.0, XMLHttpRequest, gives you direct access to the underlying HTTP protocol along with XML parsing support. For example, consider the following script (disclaimer: this only works with the final release of Internet Explorer 5.0):

<SCRIPT LANGUAGE=javascript> function makeHTTPRequest() { var xmlrequest = new ActiveXObject("microsoft.xmlhttp"); strRequest = "<?xml version='1.0'?><user>1</user>"; xmlrequest.open("PUT", "http://www.skonnard.com/getuser.asp", false); xmlrequest.setRequestHeader("Content-type", "text/xml"); xmlrequest.send(strRequest); xmlResponse = xmlrequest.responseXML; } </SCRIPT>

This block of script, which can be executed in response to some user interaction, sends an HTTP request to the server and waits to receive the HTTP response. Once the script receives the response, it can use DHTML to update any scriptable element within the HTML page (see Figure 7).

Figure 7: Updating Session State

Internet Explorer 5.0 also has excellent support for the Extensible Stylesheet Language (XSL). This allows you to store most of your page-scoped data as XML. You can then use XSL to transform the XML data into HTML—use XML to represent page-scoped data and XSL to describe how that data should look to the user.       When you need to persist your XML data across user sessions, once again you can save it to disk using the Internet Explorer 5.0 intrinsic userData behavior.       As you can see, Internet Explorer 5.0 and its extensive support for XML and out-of-band requests makes the one-page Web application very feasible. Imagine being able to save all session-scoped state within a single Web page, having programmatic access to the data via a standard DOM, and being able to easily persist the session data to disk using XML. This gives you better performance, scalability, and simplicity than any of the other strategies we've discussed here. Techniques for Avoiding Page Transitions       To make the one-page Web application pattern work, you must avoid page transitions in your Web application. To do so, you must eschew using the standard behavior for form actions and anchor elements. In other words, you'll have to implement custom actions in script and override the element's default behavior. Your script can use DHTML along with XML data islands or the XMLHttpRequest object to make HTTP requests that don't initiate page transitions:

<SCRIPT LANGUAGE=javascript> function submitRequest() { xmlData1.src = "getorders.asp?userid=1"; } <SCRIPT> <FORM ACTION="javascript:submitRequest()"> <INPUT TYPE=submit VALUE=Submit> </FORM>

To make the user feel like there was a page transition (and that something actually happened in response to the user's interaction), you can use DHTML to hide, show, or update elements on the page.       We should also point out that you could accomplish this type of functionality on down-level browsers using more traditional technologies like Java applets or ActiveX® controls. The downside is that they're more difficult to implement and require downloading binary images. Plus, if you want to take advantage of XML on these down-level systems, you'll have to implement most of the XML functionality yourself. (See Ken Spencer's Beyond the Browser column in this issue for a discussion of how to do this in Visual Basic.) A New Role for ASP       When you start thinking about the one-page Web application pattern, ASP pages should seem more like remote functions for generating XML data. ASP pages are definitely not limited to returning HTML—they can return any type of data that makes sense to your Web application client, such as XML. Web application developers using this pattern will benefit from creating reusable ASP-compatible COM objects to handle XML generation.       More and more database vendors are adding native XML support to their systems. Even today, you can use ADO 2.1 to persist a recordset object to XML. As more tool vendors add XML support to their portfolios, Web applications designed around XML will continue to benefit. Conclusion       Developing powerful and scalable Web applications is not easy; there is much more to Web application design than deciding how to lay out your HTML elements. Hopefully, you now understand the fundamental differences between designing a typical client/server application and a highly scalable Web application. You should also appreciate how session and state management influence the overall performance and scalability of your system.       One thing we'd like to emphasize is that there is not a single design that works for all projects. But given a particular project's requirements, there is probably a design strategy that will give you optimal performance and scalability. The concepts presented here should help you feel more prepared to discover the best design for your project.       We introduced a new design pattern called the one-page Web application, which offers a simplified state management strategy that doesn't compromise scalability or performance. This design allows your Web servers to support more concurrent users because it's capable of leveraging the client's system resources. Internet Explorer 5.0 makes it possible to implement such a radical new design. Due to space constraints, we've barely touched upon the many implementation details that you're probably craving right about now. Not to worry; in a future article we'll present a comprehensive sample application that brings the one-page Web application to life.

http://msdn.microsoft.com/library/techart/msdn_csarctop.htm

From the September 1999 issue of Microsoft Internet Developer.