• Choose a category
• All
• Classic-Fiction

The Timer control is the server counterpart of a client timer created using the window.setTimeout method. In the preceding code, the Timer control causes a postback every second as specified by the Interval property. The postback fires the Tick event. By using the timer as the trigger of an updatable panel, you can refresh the content of the panel periodically. In the code, the second UpdatePanel control just renders out a digital clock:

protected void Timer1_Tick(Object sender, EventArgs e)

{

// Update the client UI to reflect server changes

...

}

The downside is that a timer-based polling system implemented over the partial rendering engine is still subject to concurrent calls and can be stopped at any time.

REST and Ajax

When the client requires that a specific operation be executed on the server with no frills and in a purely stateless manner, you should consider options other than partial rendering. Enter remote server method calls and REST, or Representational State Transfer.

REST refers to the idea of having data and resources exposed to Web clients as public HTTP endpoints. Clients interact with these endpoints using HTTP verbs such as GET, POST, PUT, and DELETE. In REST, the URL is a representation of a resource, and the HTTP verb describes the action you want to take regarding the resource’s representation. Data exchanged in those interactions is represented in simple formats such as JSON and plain XML, or even in syndication formats such RSS and ATOM.

From a programming perspective, REST is all about making a call to a Web-exposed service from the client browser. This requires that a public, well-known API be exposed and made accessible from JavaScript or whatever other programming technology you have available in the browser (for example, Silverlight).

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—which 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.

Scriptable Services

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 20-4 gives an overview of the architecture.

Figure 20-4. A typical Ajax architecture.

The HTTP façade works out a convenient API for the presentation layer to call. The API is built on top of the existing application services and workflows. The HTTP façade 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 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