Enterprises have come to realize that integration is expensive, and homogeneity is an ideal that’s not practically attainable. A large enterprise with many disparate databases, vendor supplied applications, platforms, operating systems, and languages may come to think that life would actually be better in a totally homogenous environment. A mission-critical application is purchased from a vendor and rolled out into the enterprise, and soon a business unit decides it would be great to put a web front end on it to expose a subset of the functions to a subset of the users. Much work and coding ensues to integrate the web application with the vendor’s back-end database. The web application, of course, adds some of its own requirements to the mix, which drives the creation of another database, hosted on another platform. The web application ships with much fanfare, almost on time, grossly over budget, and is met with accolades from corporate users far and wide. This success, and the subsequent wide adoption of the processes, fosters a need for another business unit to leverage some of the data and some of the functionality, but again, of course, with some esoteric deviation in the business rules that only an…

.NET is complex. Not so much in the same way that COM is complex. Not in the way that makes you want to cry as you realize you’re going to have to scrub the registry for references toan old version of COM server again. Not in the way that gives you nightmares about ghoulish GUIDs taunting you from a misplaced type library. No, .NET’s complexity is based more onits sheer size and scale. There are more than 3,000 types in the Framework class library, and these types are designed to do just about anything. The major learning curve to becoming productive in the .NET Framework is not the language, regardless of your language of choice (although moving from VBScript to VB .NET Web Forms has been challenging for more than a few); it’s the Framework class library. It calls to question, What’s out there? When do I use it? How does it work? Distributed applications are also complex. A layered architecture results in an application with a lot of moving parts. Simply displaying a data point within a web browser can involve using an object graph with dozens of instances, a call stack that’s easily five layers deep, code involving…

Configuration of ASP.NET AJAX When you create the project of an AJAX-enabled ASP.NET Web site, everything looks like a classic ASP.NET application at first glance. After a second look, though, you can see that the configuration file contains some changes in the form of new sections and new runtime components. In particular, the runtime components-made-to-measure HTTP modules and HTTP handlers-play a key role in the implementation of ASP.NET AJAX. The web.config File In ASP.NET, the web.config file stores application settings that apply to the folder where it is located and to child subfolders. Each application can have a variety of web.config files to apply different settings at different folder levels. The web.config file is a text file written in accordance with a well-known XML schema. The standard schema file features a built-in number of sections and elements, but new sections can be added to configure custom services and components. As mentioned, ASP.NET AJAX Extensions 1.0 is just an extension to ASP.NET, and it can be easily seen as a new service that requires its own set of extensions to the configuration syntax. New Configuration Sections The ASP.NET configuration file has a root element named . A particular configuration file that…

Overview Most of the power of AJAX resides on the client and is strictly related to the browser’s and platform’s client-side functionality. Even though a large share of AJAX pages are built using a slightly different set of server controls, they couldn’t work without a powerful environment available on the client and written in JavaScript. Such a script code governs the execution of out-of-band calls and often kicks in and replaces regular postbacks with AJAX postbacks. No AJAX functionality would ever be possible without JavaScript and a standard (and rich) Document Object Model (DOM). The DOM, though, is not enough. The DOM represents the programming gateway to the page constituent elements, but it is not designed to provide programming facilities such as those you can find in a general-purpose library. Normally, the script tools you can leverage to consume objects and contents from the DOM are those provided by the JavaScript language. Not exactly a powerful toolkit. Enter the Microsoft AJAX Library. The Microsoft AJAX library is written in JavaScript, although with a strong sense of objectorientation. The JavaScript language does support objects and allow the creation of custom objects. It does not, however, support full object-orientedness since it has…