Introduction

In the third part of this series we talked about asynchronous calls to the server, which are the essence of Ajax development. ASP.NET AJAX lets the developer write less (and consistent) code by providing a framework that hides the details of the XmlHttpRequest object behind a client API.

Another goal of the framework is to further simplify the implementation of common scenarios for asynchronous calls. In the previous article, for example, we saw how to invoke a server method from the client side - using a properly configured ASP.NET Web Service - and process the results without reloading the page.

In this article you will understand how this mechanism works. You will also learn the basics of Firebug, one of many helpful tools that assist the Ajax developer.

Tools for the Ajax developer

In classic ASP.NET applications, most of the work is performed on the server side. As a consequence, powerful tools exist to closely monitor what is happening when a web application is running. Many of these, such as debuggers and profilers, are embedded in Visual Studio.

With the advent of Ajax, it often happens that the browser is responsible for a consistent portion of the processing logic. Suddenly, debugging of JavaScript code becomes a necessity. Keeping an eye on the flow of HTTP requests and responses is crucial, as applications exchange great amounts of data in the background. Monitoring how the DOM (the Document Object Model) is dynamically updated is important when taking advantage of techniques such as partial rendering.

To satisfy such needs, many tools have been developed recently. These tools usually integrate with the browser to give a real-time experience. One of my favorites is Firebug, which runs on the Firefox browser. There are tools that run on Internet Explorer, such as Nikhil Kothari’s Web Development Helper and the Internet Explorer Developer Toolbar.

In this article you are going to use Firebug. However, other tools have a similar usage.

Calling a web method: how does it work?

Let’s recall for a moment the work you’ve done in the previous article in order to invoke a web method from the client side.

You started by configuring an ASP.NET Web Service. The simplest thing that worked was to decorate the Web Service class with the ScriptService attribute. At this point, you were able to call the web method on the client side – using JavaScript – and process the results in a callback.

This flow is depicted in figure 1. The figure presents the main entities involved in this process.

Figure 1: Calling a web method from the client side

As usual in Ajax applications, the client relies on the XmlHttpRequest object to make an asynchronous request to the server. The key point is: How can the client know about web methods declared on the server?

The connection between the client side and the server side is an object called proxy. A proxy can be considered as a projection of an object from one domain, to a different domain. In order to let the client know about a server method, ASP.NET AJAX is proxying the Web Service from the server side to the client side.

To see it in action, let’s run the code provided in part three of this series with the Firebug tool opened. As soon as the page is loaded, click on the Net tab in Firebug. Then, click on the JS tab to see a list of JavaScript files loaded in the page. Steps are reported in figure 2.

Figure 2: Getting the list of JavaScript files loaded in the page

By hovering on the file called js (which is at the bottom of the list in the figure), you’ll see the corresponding URL, which references the path /PushpinService.asmx/js. This path doesn’t correspond to a physical file. Instead, it is processed by a HTTP Handler called ScriptResource.axd, which is configured in the web.config file of every ASP.NET AJAX application.

The handler is instructed to return the proxy for the Web Service declared in the file PushpinService.asmx. The proxy is nothing more than JavaScript code. To see it, you have to expand the corresponding node in Firebug; doing this will reveal the headers of the HTTP request and response. Finally, click on the Response tab to see the response’s payload. This is the proxy code, as shown in figure 3.

Figure 3: Examining the contents of a file sent by the server

By examining this code a little more closely, you will be able to understand how asynchronous calls to Web Services work in ASP.NET AJAX.

The following listing reports the first portion of the proxy code. As you can see, it’s the declaration of a JavaScript constructor.

If you followed the discussion in part 2 of this series, you’ll recall that the registerClass method upgrades a JavaScript constructor - a function - to an ASP.NET AJAX client class. Specifically, this class inherits from Sys.Net.WebServiceProxy. This confirms that, in fact, we are examining the code for the Web Service’s proxy.

You may also recall from the previous article that the sample code accesses the PushpinService proxy in the pageLoad method, which is reported here:

As you can see, we are referencing the PushpinService constructor defined in the JavaScript code for the proxy. What about the subsequent GetPushpins method?

Let’s take a further look at the proxy code. Specifically, we focus on the PusphinService’s prototype.

The previous code reveals an interesting fact. The constructor, which has the same name as the Web Service class, declares a JavaScript method with the same name of the web method declared on the server side – that is, GetPushpins.

The difference is in the method’s body. While the server method returns a list of pushpins, the client method performs a different operation: It sets up an asynchronous request to the server. This is done by the private _invoke method, defined in the base Sys.Net.WebServiceProxy class. What this method does is use the XmlHttpRequest infrastructure to call the web method on the server. In other terms, this method is wrapping the code needed to call the web method, in a friendly function with the same name of the web method. This is how the ASP.NET AJAX proxy works. When programming, we don’t need to understand the inner workings of the networking layer. We can call the web method using an intuitive syntax similar to that of the server side code.

Results

Now that you know how an asynchronous call to a Web Service is made, let’s follow the request up to the server. Here, the real web method is invoked, and the results (if any) are sent back to the client and made available in a callback.

To see the data sent by the server, you have to switch to the Net tab in Firebug. Then, click on the All tab and search for the GetPushpins call, as shown in figure 4.

Figure 4: Inspecting the HTTP flow

The call to GetPushpins generates an asynchronous request like the one shown in the previous figure. If you switch to the Response tab, you will see the payload of the response – that is, the results of the web method. Notice that the data is sent back to the client in JSON, which is compact data suitable for data exchange between a web server and a browser. One of the advantages of JSON is that, being a subset of the JavaScript syntax, it can be suddenly deserialized into a JavaScript object and thus easily parsed and accessed.

On the other hand, there may be cases where we need the data sent by the server in a different format, such as XML. Since our VirtualEarth client control has been programmed to access data in JSON format, let’s make a dummy call just for the purpose of visualizing the data in XML format.

The first thing you have to do is modify the call to the web method in the pageLoad function:

No callbacks will be invoked after the web method returns: this is of course a dummy call that allows you to inspect the response using Firebug, without triggering any code that processes the data.

Next, you have to supply a parameter-less constructor to the Pushpin class. This is needed by the XML serializer in order to generate the XML from a Pusphin instance.

Finally, comes the most interesting part. In order to make the web method return XML data instead of JSON, we have to add a ScriptMethod attribute to the web method. This attribute is used to tweak certain parameters of the request and response exchanged by the server and the client during the asynchronous call. Let’s take a peek at the following code.

The previous code is a portion of the PushpinService class. GetPushpins is now decorated with the ScriptMethod attribute. ResponseFormat is a named parameter set to Xml. This instructs the server to serialize the method results into XML.

By reloading the page and inspecting the response with Firebug, you can see that the data is effectively being sent in the XML format.

Figure 5: Method results sent in XML format

In the next part of this series, we will return on the VirtualEarth control in order to deal with data binding, pushpins and popups.

Summary

By reading this article, you took some time to explore the inner workings of the ASP.NET AJAX networking framework. You saw how an asynchronous call to an ASP.NET Web Service can be made on the client side through a proxy object. Firebug is one of the invaluable tools that lets you inspect the JavaScript code sent by the server, monitor the HTTP traffic and much more.

About Alessandro Gallo

Alessandro "Garbin" Gallo is a Microsoft MVP in the Visual ASP/ASP.NET category and a .NET developer/consultant. He is a contributor for the Ajax Control Toolkit project, owned by Microsoft. Alessandro won the Grand Prize at the "Mash-it-up with ASP.NET AJAX" contest held by Micr... This author has published 23 articles on DotNetSlackers. View other articles or the complete profile here.

---

Discussion

Subject	Author	Date
Great Articles	Chuck Snyder	11/14/2008 4:08 PM
Been fun to work with virtual earth.  Your articles have been quite helpful.  Hope to see the next one too. By the way, did anyone find out the problem with displaying the longitude as a negative number??  I'll work on it for another day or so but so far quite puzzling Reply | Permanent link
RE: Great Articles	Alessandro Gallo	11/29/2008 2:34 AM
Thanks :) Reply | Permanent link
RE: Great Articles	Rob Copeland	5/20/2009 1:37 AM
I changed all doubles to strings and then in the mashup I called the SetCenterAndZoom() object from using the 6.2 version API for virtual earth. just make sure to change the doubles and ints to strings in both classes and the mashup then and the quotes in the web service. At least that is how I got it going in VB.net. i don't see why it woudn't be the same in C#. Reply | Permanent link
Virtual Earth Map with Ajax	Don Katona	11/19/2008 2:11 AM
I've been looking for a way to run Virtual Earth Maps with a master page. Issue one> Is there a way to run a java function from the asp page_load event on the child page? You can't use the body onload event because it is on the master side and would get applied to all the pages in the site. The Java scripts are located in a place holder and the page load is in the script section of the child file. Using Ajax will require I discard my Java scripts and rewrite everything using your Mashup. Issue two> The AJAX method described in this forum seems to work well for my purpose. However, I'm running into a problem getting the map to render in the right place. The panel is located in the html where I want it to display, but the browser puts the map in the upper right hand corner. The funny thing is that I can put the curser in the panel and move the map around. Any ideas? Reply | Permanent link
RE: Virtual Earth Map with Ajax	Alessandro Gallo	11/29/2008 2:33 AM
Hello, Issue 1: what about using the window.onload event? Issue 2: I think it's a matter of styling the container element. In my article, I didn't pay much attention to that. Reply | Permanent link
RE: RE: Virtual Earth Map with Ajax	Don Katona	11/30/2008 12:26 AM
Thank you sir, You gave me the clue I needed. I thought the div was defaulting to relative, but apparently it needed to be set explicitly. That lined up the map nicely. I like it. The editor does not create a window onload handler the way it does for a page load. I’m assuming there is for a reason for that. I’m just going to leave some of the maps in HTML and write all the new ones with your mesh up. Your articles helped me out a lot, thanks. Reply | Permanent link

---

Please login to rate or to leave a comment.