AJAX application Architecture, part 2nd

When using asp.net ajax Extensions to transition your site to an AJAX experience, there are two main programming models to choose from: Partial rendering and scripting services. In last month's column, I mainly discussed partial rendering from the perspective of architecture. In short, with partial rendering, you do not need to change the underlying architecture of the ASP.net application-it is a convenient way to implement some of the best elements of AJAX, such as the flicker-free update of a site page. Implementing this type of improvement involves adding new server controls (especially ScriptManager and UpdatePanel) and quietly using some tricks to convert traditional postbacks through asynchronous requests that run on XMLHttpRequest objects. This approach is easy to implement because it simply applies AJAX functionality to the existing WEB development model.

If you are ready to implement a comprehensive schema transformation for building AJAX applications, you should be aware of the scripting services approach. In general, a typical AJAX architecture is fairly easy to understand. Figure 1 shows a high-level view of how it works. There is a backend consisting of application-specific services, usually just the outer layer of an AJAX script, below which is the middle tier of the business logic and the functioning of the system. The service communicates with the front-end via HTTP, passing parameters and return values in multiple formats. The front-end consists of JavaScript code running on the client, which, after receiving and processing the data, faces a major task of building a graphical user interface using HTML and JavaScript. The dependencies on JavaScript are limited by the browser structure, which can only change when browsers support more powerful programming features.

Figure 1 Typical AJAX architecture

Login via AJAX

Abandoning the traditional ASP.net model can cause a lot of real repercussions. Consider the login process and see how the changes will occur in a pure AJAX solution.

Currently, for ASP.net, enabling the login process includes configuring the login page with the login control, configuring the protected page with the LoginView control, and setting up the ASP.net membership provider. Protected pages graphically reflect the results of the authentication process using either a login template or an anonymous template. In asp.net 2.0, you don't have to write any code to do most of this work. To successfully log on, you need a redirect (HTTP 302) that occurs when a user arrives on a protected page, a postback from the login page to the authentication credential, and then a second redirect to the original requested page.

This is not necessarily true for AJAX pages. If a user requests a protected page from the address bar, you cannot do anything other than repeat the asp.net process. However, if you have a link to a protected page in the page, you can add some scripts to the link's OnClick event to check that the user is authenticated. If not, you can eject a warning box to alert the user, as follows:

function checkFirst()
{
　　var loggedIn = Sys.Services.AuthenticationService.get_isLoggedIn();
　　if (!loggedIn)
　　{
　　　　alert("You must be logged in to follow this link");
　　　　return false;
　　}
　　return true;
}