architectingweb2

8/14/2019 architectingweb2

1/14

Architecting Your Web

Applications

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 theWeb application industry. His strong C++/MFC skills gave him a sense of job securityand 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'tmake 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 overtime without requiring a rewrite of a single line of code. Web application developerswho 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 readthis 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 theconcepts 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 Istore 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 mostbrowser 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 XMLalong with new features in Internet Explorer 5.0 can help you achieve your Web

application design goals.

Typical Client/Server Application DesignWhether you come from a C++, MFC, or Visual Basic background, you have

probably dealt with client/server applications. If you've ever written a simpledatabase front end or even a more complex multitier system, you've dealt with the

client/server arena. Regardless of the project complexity, most client/serverapplications share certain design characteristics. First and foremost, typical

client/server applications have a limited number of users. At design time, themaximum 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 madearound that assumption.

Knowing how many people will be using your application concurrently can helptremendously 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


2/14

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 requiredoperating 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 withthe server and maintained until the client application terminates. Because these

connections are expensive and time-consuming, it's usually better to make theconnection 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, itknows 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'sconnection 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 thetypical client/server design characteristics that are common today. Chances are

you're used to thinking about applications as we've just described.

Unlimited UsersUnlike 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 canturn into 500,000 virtually overnight. Most companies underestimate the potential oftheir applications during the design phase.

In client/server scenarios, the company usually has control over the number ofclients 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 applicationafter 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 certainthresholds, you can increase throughput by adding additional hardware to your Webfarm 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 detailthroughout the rest of the article.

Browsers GaloreMost 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.


3/14

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 youdecide 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 NetscapeNavigator. 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 andadvise 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 browserversionslike Dynamic HTML (DHTML), Cascading Style Sheets (CSS), XML, and

HTML behaviorsthat would allow them to create very sophisticated Webapplications. But because of corporate policy, they must continue to support every

known browser. Many developers in this situation will develop parallel versions oftheir Web application for the different browser versions and take care of browser

identification and redirection on the server (see Figure 1). This approach allowsdevelopers to take advantage of the newest technologies without affecting down-level

clients. Unfortunately, this also requires the simultaneous maintenance of multipleapplication versions.

Figure 1: Different Versions for Different Browsers

HTTPA 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 trackuser sessions and session-related state. Web applications must behave differently. Infact, 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 usersessions 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 HTTPrequest.

When the user points the browser to a given Web site, the browser first establishes


4/14

a TCP connection with the corresponding Web server. Once the connection is

established, the browser sends an HTTP request using the existing channel. The Webserver 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 HTTPrequests 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 everyrequest.

HTTP/1.1, which isn't supported by all browsers or Web servers, offers a newmechanism called persistent connections to optimize the connection process. With

persistent connections, the server maintains the connection with the client for aperiod of time so the client can reuse the connection for subsequent requests.

Session, State, and SecuritySince 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 HTTPrequests. 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 browserand 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 sessionstate 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 severelyimpair 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 withsecurity. If you visit an online shopping site and don't see the little yellow lock showup 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 cleartext.

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. Firewallsblock potentially malicious traffic from reaching your corporate network. They do so

by rejecting attempts to establish TCP/IP connections on unsecured ports. Remoteprocedure 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 passingthrough. 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 usingHTTP.

As you can see, designing a Web application is very different from designing atypical client/server application. Considerations you must address early include

tracking user sessions and deciding where to store session state.

Managing Sessions


5/14

There are basically two standard mechanisms for managing user sessions in a Web

application. Both require session-related information to be explicitly passed betweenthe 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 ofthis 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 pageretrieved 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 datawill 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 likecookies. 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 theserver.

You can also use cookies to pass session data by value. Each time the server needsto 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 cookieback 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'tneed 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 associatelarge 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 sessiondata 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 andprevents 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 thatthis 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 alsoworks 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 thesession 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 awide range of Web browsers. For an example, point your browser to Amazon's Web
http://www.ietf.org/rfc/rfc2109.txthttp://openurl%28%27webapptextfigs.htm/#fig3');http://openurl%28%27webapptextfigs.htm/#fig3');http://www.ietf.org/rfc/rfc2109.txt


6/14

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 ServerPages (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. SinceASP uses in-memory cookies, you won't see the cookie on disk, but you can use

NetMon to verify this behavior.

Session LifetimeSo 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 clearwhen 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 lazyclient?

The standard answer for Web sessions is a timeout period. For example, if 20minutes 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 managementuses 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 fordetermining 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 itsobvious 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 manyvariables 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 youtoward making the right decision for your project. But you must first understand statedurability and the state's scope.

Durability and ScopeMost 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. Durablestate 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 ofrobustness.

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 orcan 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


7/14

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 beaccessed.

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 thatstate 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'ssession 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 thatneeds 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 longas the Web application is running, any user can access data stored at application

scope. Once the application terminates, the application-scoped data is removed fromthe system.

External-scoped data lives beyond the lifetime of the Web application. This type ofdata 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 accessedacross multiple Web applications.

Now that we've covered the nature of Web application state, let's focus on thedifferent techniques for managing application and session-scoped state.

In-memory State on a Web ServerThe 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 usethe 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 theASP page is executing. As noted earlier, the ASP session management scheme usescookies 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-referencedetails, 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


8/14

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 onother 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 pinnedthe 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 usersin 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 ServerAnother 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 storesession-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 onyour 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 onthe Web server, since you have a network round-trip each time you need to access orupdate 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. Thefirst 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
http://www.microsoft.com/isapi/gomsdn.asp?TARGET=/library/techart/whatimdb.htmhttp://www.microsoft.com/isapi/gomsdn.asp?TARGET=/library/techart/whatimdb.htm


9/14

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 Webserver. 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 IMDBmachine 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 aslong 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 oreven weeks are probably using this strategy. Although this strategy offers lower

performance than the nondurable solutions, it allows your application to takeadvantage of dynamic load-balancing and fail-over strategies. Furthermore, using

durable storage makes system failures much less of a problem.

Client StateUp 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, thereare 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 GetPropertymethods 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 onyour 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 cookiebecomes an in-memory cookie and will not be saved to disk. It remains in-memoryuntil 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 fromscripting languages.

All of these techniques for storing session state on the client take a heavy burdenoff 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


10/14

these techniques are universally supported across browsers, and most of themwith

the exception of in-memory cookiesare supported by Internet Explorer 4.0 andlater.

You can take things a step further and store session state on the client's disk. Youcan 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 asXML 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 acrossuser 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 youneed 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 HTMLpage 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 anadditional mechanism (like the ones described earlier) for preserving state across

page transitions. But what if it were possible to devise a design that changed theformula 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. Youcan 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 sessionscope.

A One-page Web ApplicationAvoiding 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 withthe 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-levelbrowsers, 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 InternetExplorer 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 XMLdata 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:

This is an HTML document


11/14

Essential WinInet

34.95

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


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 changethe src attributes of XML data islands from script.

function getXML(id) {

xmlData1.src = "getorders.asp?userid=" + id;

}



12/14

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):

function makeHTTPRequest() {

var xmlrequest = new ActiveXObject("microsoft.xmlhttp");

strRequest = "1";

xmlrequest.open("PUT", "http://www.skonnard.com/getuser.asp", false);

xmlrequest.setRequestHeader("Content-type", "text/xml");

xmlrequest.send(strRequest);

xmlResponse = xmlrequest.responseXML;

}

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 StylesheetLanguage (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 HTMLuse XML to represent page-


13/14

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 cansave 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 sessiondata 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 TransitionsTo 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 standardbehavior 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 tomake HTTP requests that don't initiate page transitions:

function submitRequest() {

xmlData1.src = "getorders.asp?userid=1";

}

To make the user feel like there was a page transition (and that something actuallyhappened 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 ActiveXcontrols. 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 thesedown-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 howto do this in Visual Basic.)

A New Role for ASPWhen 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 HTMLthey can return any type of data that makessense to your Web application client, such as XML. Web application developers using

this pattern will benefit from creating reusable ASP-compatible COM objects to handleXML 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
http://www.microsoft.com/mind/0999/beyond/beyond0999.asphttp://www.microsoft.com/mind/0999/beyond/beyond0999.asp


14/14

architectingweb2

Documents