AJAX has fundamentally changed how we build and consume Web applications. Reloading pages, posting forms, and even Web site navigation have changed drastically since I first started building Web pages back in 1992. Today, customers expect rich Internet applications with live data, not just pages of static information. This is especially true as more and more business applications are moved to the Internet and browsers such as Google’s Chrome browser are developed to optimize rich Internet applications.

A few years ago AJAX was a novel concept. Most of us had seen AJAX used in dramatic ways in applications like Google Maps and Microsoft’s Windows Live Local, but only a few developers understood how to use it in their own applications. It was magic then, but today it’s expected, and applications without AJAX feel unresponsive, clunky, and outdated.

It’s also important to note that AJAX isn’t a term for the user experience. While you may get some of the user experience benefits of AJAX without developing a service-oriented application, you won’t get the flexibility and longevity of the purist AJAX approach. One thing I don’t cover in this book is the Update Panel, a Web control introduced with ASP.NET AJAX that implements "magic" AJAX-like behavior with the ASP.NET postback model.

Rather than the user experience, AJAX describes the architecture pattern: asynchronous JavaScript and XML. Another way to describe this pattern is this: "Write Web services, and then write a JavaScript library to use them." It is this approach that I take in this book, which is also dubbed service-oriented AJAX.

Service-oriented AJAX takes the approach of starting with the Web service API. The API implements the core functionality of the application and exposes the application to multiple clients. With this approach, you can easily swap out the JavaScript application with alternate clients, such as Flash or Silverlight, or even remote Windows or Macintosh clients. Because we’re taking a service-oriented approach, the same services can be extended to implement a remote API as well as the JavaScript API that our AJAX application will use. While the X in AJAX stands for XML, the data format isn’t important, and WCF supports both XML and JavaScript-serialized (JSON) data streams.

In this book, I use the Microsoft AJAX Library—the client-side library for ASP.NET AJAX—to implement the client runtime. The Microsoft AJAX Library is utilized throughout the book but is covered in detail in Chapter 4 through Chapter 8. It is the Microsoft AJAX Library that is used to build the client runtime, which will make asynchronous Web service calls to the backend through the JavaScript library.

When I first started implementing this pattern several years ago, I used a combination of ASMX Web services and HTTP handlers to implement the API, and I used the Microsoft ASP.NET AJAX extensions to integrate JavaScript support on these services. But then came Windows Communication Foundation (WCF) and then the WCF Web programming model introduced in the Microsoft .NET Framework 3.5. This changed everything and enabled further abstraction through which the service developer doesn’t need to identify how the service will be exposed—the same service can be extended using a great number of bindings and behaviors, and it can be called from everything from JavaScript clients to TCP/IP bindings or even message queue integration.

Just as a poorly designed ASP.NET application is difficult to maintain, a clumsily built AJAX application can be a developer’s nightmare. Switching to AJAX does have its challenges: browser compatibility issues, accessibility issues, and architectural challenges with moving the user interface logic from the server to the client. In essence, we’re moving the user interface from a compiled language such as C# or Visual Basic.NET in ASP.NET to JavaScript, an interpreted language that runs on the client. But with a properly built service-based architecture, your back-end application will be more flexible and secure than you could have imagined, and it will be built for the future. Your application won’t be tied to a front-end technology such as ASP.NET, AJAX, or Silverlight—it will be built to be consumed as services. This will free up your front-end programming a great deal—you will be able to add features and integrate multiple components with much less effort than with traditional Web applications.

Armed with a proper understanding of service-based AJAX architecture and Microsoft’s rich frameworks for Internet applications, including ASP.NET AJAX and WCF, developers can create enterprise-class applications that are quicker to write, more maintainable than traditional Web applications, and future-proof. The main application won’t be tied to the user interface but will remain in compiled code on the server. On the back end, you’ll use WCF to expose application data through services that will be consumed by multiple applications, not just your AJAX application. WCF is another technology that is geared toward the future—it is built to decouple the application from the interface, so as technology evolves you won’t be stuck with an outdated service platform.

AJAX development will use your existing skills and knowledge of ASP.NET, but it does require a fresh approach to Web development. This book is aimed to help you take your existing developer skills and use them to build fresh applications using the service-oriented AJAX architectural pattern.