You might already know that Dino Esposito is an expert on Web technologies. If you do, you’ve probably been looking forward to his new book, which is now available: Microsoft ASP.NET and AJAX: Architecting Web Applications (Microsoft Press, 2009; ISBN: 9780735626218; 352 pages). In this post we’ll provide you with some excerpts from the book.

This is the book’s high-level structure:

And here is Dino’s overview of the book:

Introduction

This book is the Web counterpart to another recently released book I co-authored with
Andrea Saltarello: Microsoft .NET: Architecting Applications for the Enterprise (Microsoft
Press, 2008). I wrote it, in part, in response to the many architectural questions—both small
questions and big ones—that I was asked repeatedly while teaching ASP.NET, AJAX, and
Silverlight classes.

Everybody in the industry is committed to AJAX. Everybody understands the impact of it.
Everybody recognizes the enormous power that can be derived from its employment in
real-world solutions.

Very few, though, know exactly how to make it happen. There are so many variations to AJAX
and so many implementations that even after you have found one that suits your needs, you
are left wondering whether that is the best possible option.

The fact is that AJAX triggered a chain reaction in the world of the Web. AJAX represents a
change of paradigm for Web applications. And, as the history of science proves, a paradigm
shift has always had a deep impact, especially in scenarios that were previously stable and
consolidated.

I estimate that it will take about five years to absorb the word AJAX (and all of its background)
into the new definition of the Web. And the clock started ticking about four years ago. The
time at which we say “the Web” without feeling the need to specify whether it contains AJAX
or not . . . well, that time is getting closer and closer. But it is not that time yet.

Tools and programming paradigms for AJAX, which were very blurry just a few years ago,
are getting sharper every day. Whether we are talking about JavaScript libraries or suites
of server controls, I feel that pragmatic architectures can be identified. You find them
thoroughly discussed in Chapter 3, “AJAX Architectures.”

Architecting a Web application today is mostly about deciding whether to prefer the richness
of the solution over the reach of the solution. Silverlight and ASP.NET AJAX are the two
platforms to choose from as long as you remain in the Microsoft ecosystem. But the rich vs.
reach dilemma is a general one and transcends platforms and vendors. A neat answer to that
dilemma puts you on the right track to developing your next-generation Web solution.

Who This Book Is For

I believe that this book is ideal reading for any professionals involved with the ASP.NET
platform and who are willing or needing to find a solution that delivers a modern and rich
user experience.

Finally, here is a longish stretch of text from Chapter 3:

Chapter 3
AJAX Architectures

Freedom is not worth having if it does not include the freedom to make mistakes.
—Mahatma Gandhi

In the previous chapter, we examined strategies for getting AJAX easily and smoothly into
our ASP.NET applications. Partial rendering is definitely worth a try because it doesn’t require
a steep and long learning curve and has a limited, often low, impact on the existing code.
Unfortunately, though, partial rendering doesn’t really capture the heart of the AJAX
paradigm. A very similar metaphor to describe partial rendering in the context of AJAX is
the following. Partial rendering doesn’t teach you how to fish; rather, it opens up a new fish
market nearby where you can order nearly all types of fish and pay for it. In the fish market,
though, deliveries are not possible every day and the fish is not always the catch of the day.
All things considered, if you want your seafood shopping to be easy and are ready to make
some compromises, this fish market is an excellent solution—just as partial rendering might
be a good solution in the AJAX world.

What alternatives exist to partial rendering?

Pushing the focus to the server was ASP.NET’s remarkable contribution to the success of
the Web platform. Before ASP.NET, Web professionals and software professionals were two
distinct categories of developers, with different skills. With ASP.NET, many C++ developers
approached the Web without needing to learn JavaScript and HTML in depth. AJAX
moves the focus back to the client, and the Web client platform is made of JavaScript and
HTML. This means that at the other extreme of partial rendering you find a handcrafted
combination of JavaScript and HTML.

Frankly, a similar solution can hardly be employed in a large enterprise solution with hundreds
of pages because such an approach is too risky, fragile, and error prone. An alternative that
can really speed up development while remaining reliable and effective is to use specialized
server controls that offer AJAX functionalities out of the box. Many commercial frameworks do
exactly this. Depending on the level of abstraction of the various frameworks, you might feel
like you’re using a brand new component-based language on top of ASP.NET or just an
enhanced version of ASP.NET.

Regardless of the level of abstraction, the underlying architecture remains the same.
You essentially design the user interface using server controls that emit both JavaScript and
HTML. The output of each server control is bound to some JavaScript event handlers that fire
HTTP calls to the Web server as the user interacts with input elements. The server-side
recipients of HTTP calls might also take different shapes (for example, SOAP, JSON, or
REST services), depending on the design principles and vision that inspired the framework
you’re using.

In this chapter, we’ll review the two main AJAX application architectures that have emerged
as the most popular and effective. No recognized names exist (that I’m aware of) to indicate
these two architectural patterns. I’ll (kind of arbitrarily) refer to them as AJAX Service Layer
and AJAX Server Pages.

The AJAX Service Layer Pattern

At the highest level of abstraction, Web applications are client/server applications that
require an Internet connection between the two layers. Before AJAX, this connection was
incorporated in the special client application—the browser. The browser opens the
connection, clears the user interface, and then updates the screen with the results of a
server operation.

With AJAX, the client code has the ability to bypass the browser and can handle connections
itself. This enables the client to enter user interface updates without fully refreshing the
displayed page—a great step forward toward usability and rich user experiences.
To make the usability of Web applications grow as close as possible to that of desktop
applications, the overall software platform must fulfill two key requirements. As mentioned,
one is a client-side infrastructure that can manage the Internet connection with the server.
The other requirement is the availability of a public and known programming interface on
the server—the AJAX-specific service layer.

Architectural Overview

Any AJAX solution is made of two main layers that are neatly separated but communicating—
the JavaScript and HTML presentation layer and a service layer that acts as a façade for HTTP
endpoints. Figure 3-1 gives an overview of the architecture.

The presentation layer is hosted in the browser and communicates via HTTP with an ad hoc
façade made of URLs. Behind the URLs, you have server code at work. The server code can
be exposed in a number of ways determined by the programming API you choose—for
example, Windows Communication Foundation (WCF) services.

The data being exchanged between the presentation layer and the HTTP façade depends on
the client and server APIs and their capabilities. However, most of the time, albeit not always
and not necessarily, JSON is the serialization format of choice.

The communication between the HTTP façade and the rest of the system happens either locally
or over a protected network environment where only trusted callers are allowed.

HTTP Façade

As shown in Figure 3-1, the HTTP façade just reworks a more convenient API for the
presentation layer to call. The API is built on top of application services and workflows. The
HTTP façade just scripts these middle-tier components from the client.

The architectural relevance of the HTTP façade is that it decouples the middle tier from
a very special presentation layer, such as an AJAX presentation layer. An AJAX presentation
layer is special essentially because it’s a partial trust Web client.

For security reasons, service technologies hosted on the Web server require special adjustments
to enable JavaScript callers. In addition, it’s likely that some of the application services you have
in the middle tier run critical procedures. Any piece of code bound to a URL in the HTTP façade,
instead, is publicly exposed over the Internet. Not an ideal situation for a business-critical
service. So decoupling application services from the AJAX presentation layer is a measure of
design but also a matter of security.

As an architect, you know that a business layer might sometimes include an outermost layer
of code that is used to script the domain model and business components and services.
The structure of this layer is inspired by the Service Layer pattern. In general, a service layer
defines an interface for the presentation layer to trigger predefined system actions. As the
name suggests, the service layer is a sort of boundary that marks where the presentation
layer ends and the business logic begins. The service layer is designed to keep coupling
between the presentation layer and business logic to a minimum, regardless of how the
business logic is organized within the business logic layer.

How does the HTTP façade relate to a service layer?

HTTP Façade and the Service Layer Pattern

A service layer doesn’t really perform any task directly. All that it does is orchestrate the
set of business objects in the middle tier. The service layer has an intimate knowledge
of the business logic (including components, workflows, and services), and likewise it
knows the domain model, if any, very well. The service layer is, therefore, part of the
business layer.

Ideally, the HTTP façade lives on top of the business layer and, subsequently, it lives
on top of the service layer. Despite the word service in the name, a service layer is not
necessarily made of services such as WCF or Web services. The service layer also can be a
plain collection of classes. This is not uncommon in classic ASP.NET applications, where the
code-behind class lives on the server and doesn’t need a Web or WCF interface to call into
the middle tier. A service-based service layer is more common when you have a smart client
and need a physical connection to the server to operate. In this case, a WCF service is the
best option.

In general, I suggest you opt for a WCF service only if you really need it. Note that having
a WCF service only to connect presentation and business components might be overkill in
some simple cases. On the other hand, when the client is an AJAX platform, you do need
an HTTP endpoint to start server-side operations. In the .NET Framework 3.5, a simple
WCF service is an excellent HTTP endpoint, but other options exist as well. The endpoint
exposed to the client can be made of the services in the service layer (if you have services
there), or it can be an additional layer of ad hoc AJAX services that just talk to the service
layer or, more in general, to the business layer. (See Figure 3-2.)

The service layer (if you have one) is the layer invoked by the presentation layer. In the case
of an AJAX presentation layer, either the service layer is publicly exposed to the Internet
( becoming itself the HTTP façade) or it’s shielded by a made-to-measure HTTP façade.

Let’s expand on the technologies available to build an HTTP façade.

Technologies for the HTTP Façade

The HTTP façade is the list of public URLs known to and managed by the AJAX presentation
layer. In an AJAX scenario, the presentation layer is made of only JavaScript code. All the logic
you can’t or don’t want to code in JavaScript must be referenced on the server.

Public HTTP endpoints are the only point of contact between AJAX clients and server
applications. In the .NET Framework 3.5, you can write endpoints callable by AJAX clients
using a number of technologies.

To start off, an AJAX-callable endpoint can be an .asmx ASP.NET Web service. If this is your
choice, you need to configure the host application so that its hosted Web services can accept
JSON calls in addition to, or instead of, SOAP calls.