In part six of this series, I'm shifting my focus towards how an application can use a web service to post data to and from the client without having to post back to the server. The Visual Studio environment makes this process really easy, even providing Intellisense in an ASPX's JavaScript code, helping to ensure code correctness.

Right now, web services are the mode of transportation for pushing data to/from the server. When a web service passes data to the client, it serializes the data into a JavaScript object. If the object you are passing is not serializable, an exception will be thrown to the client. This happens especially for LINQ to SQL or LINQ to Entities, as the LINQ business object contains many complex properties (foreign key collections and primary key objects) that it doesn't serialize. There is an easy answer for this: create an anonymous type and return it instead. We'll look at this later.

For now, let's being by looking at the web service. There are additional resources on this site that are helpful for understanding this process. So my focus is on rendering content on the client with this web service. But first, why do this?

If you look at sites like Facebook, this site works seamlessly to incorporate minor changes to the UI (adding a comment, viewing a possible friend's profile, etc.) without having to post the page back. The benefits are enormous. First, less data is streamed from server to client; this is because only the required data is streamed, and not a bunch of HTML. Secondly, those features provide "bonus points" with the users. The caveats can be that this streams the data more often than not, but typically the total volume of data being transferred is less for an asynchronous way.

The first key is the web service. Let's take a look at the web service code that gets generated by the ASP.NET framework. The web service generates some client-side code that is important for us to understand. This code segment is large, so I'm going to examine it piece-by-piece. Let's start with the constructor.

Listing 1: The Web Service Proxy Constructor

The web service starts with the namespace declaration, which happens to be the same namespace as the server-side web service. The constructor defines some useful variables like the timeout to allow a web service call execute for and the context and callbacks to use for a call. To see how this gets used, let's take a look at the class registration portion of the code.

Listing 2: Class Definition

You may not see the complete definition of the methods of this code because the generated class inherits Sys.Net.WebServiceProxy. The web proxy is the core class used for general web service calls, and we'll see it in action next.

Listing 3: Prototype Definition

Notice a few things here; the prototype of the web service class defines our core CreateNewsItem method. The CreateNewsItem method on the server looks like:

Listing 4: Server-Side Definition of CreateNewsItem

And thus, on the client, we have the same method with some additional properties. These properties are:

• succeededCallback - The method to call back whenever the web service call finishes successfully.
• failedCallback - The method to call whenever the web service call finishes in error.
• userContext - A value that can be anything, or can be null. Typically, this is a reference to the HTML element that will be updated whenever the web service call finishes, but could be data values like a key value or something else.

It's important to understand the Microsoft model for web service calls uses an asynchronous approach, which is good and bad. This approach is good because it doesn't stop the application and wait for your operation to finish. It's bad because all of the code in a function has to wrap up in the success/failed callback methods and not the original method that it belonged to.

Also notice the private path property getter: this property is a helper property determining which object has the web service URL set. Notice how it uses a _staticInstance object? This object follows the Singleton approach to web services and is defined in the following code:

Listing 5: Web Service Static Instance Code

At the beginning of the code segment, you see the instantiation of _staticInstance. This is the same case with the singleton pattern in C# or VB.NET; a private variable holds a reference to the current class. Then each static method defined for that singleton class uses the _staticInstance variable to do something. To define a static property or method in ASP.NET AJAX, simply state the class name, followed by the static method to create, and assign it a function. A static method looks like:

Normally, the static instance calls the non-static methods defined in the prototype to do the actual work, so the prototype is important here too and it's what you see above. Though, what you see above is actual reads and writes to the values specified in the Sys.Net.WebServiceProxy class.

Notice towards the end, before CreateNewsItem, that the explicit location of the path is set; this ensures that the URL is pointing to the correct location. In addition, notice that the CreateNewsItem static method calls the CreateNewsItem method defined in the prototype above.

The last bit of interesting code appears below. The reference to the _generatedTypeContructor is used to generate the returning NewsItem object. We saw above that the server-side web service returns an object of type NewsItem. ASP.NET AJAX mocks this object type by generating code for it too using the gtc instance.

Listing 6: Generating the NewsItem client-side class

This object uses the same namespace/class name as what appears in the server-side code, and thus it mocks it directly. So now we can use this client-side proxy class to make a web service call. In a web site starter kit solution I'm developing, this happens for a News web part, where the web part sends information via web service calls to the server to create an AJAX style interface.

The core interface of the web service looks like the following:

Listing 7: Web Service CreateNewsItem definition

The web service creates a new item in an XML file. It takes a reference to the news item; the news item on the client does not map to the NewsItem server-side class type, so the approach is to pass in an object reference. Actually, what gets passed in is an object reference on the client-side that looks like the following:

Listing 8: Creating an object on the fly

This passes in the data in a Dictionary<string, object> form. The question is: can we create a new NewsItem using the code above to pass in a reference to the server? Let's take a look. The following code passes a strongly-typed NewsItem object back to the server, using the following:

Listing 9: Creating a NewsItem object

Because of this, I can change the web service to look like:

Listing 10: Update to Server-Side Web Service

And a strongly-typed object can be used, which is very, very nice feature. Using this approach, a server-side web service can pass data to the client-side, which the client-side could do something like the following to display it:

Listing 11: Updating the user interface

This is one scenario; there are many things you can do with this approach. I will be attaching, albeit incomplete, the web site starter kit solution so you can see one of the approaches I used to update the user interface.

Conclusion

Overall, the ability to call web services from client-code is mostly done for you. No more needing to worry about XmlHttpRequests to the server, as this is all encapsulated in the Sys.Net.WebServiceProxy class, which even this is encapsulated in the generated proxy code. So in reality, ASP.NET AJAX tries to make this as easy as possible for you to create rich applications.

Rich applications require rich user interfaces and thus this means more JavaScript coding on the client-side, a brief example I included. Take a look at the starter kit; I'll be updating it periodically to a web site I'll disclose later.

About Brian Mains

Brian Mains is an application developer consultant with Computer Aid Inc. He formerly worked with the Department of Public Welfare. In both places of business, he developed both windows and web applications, small and large, using the latest .NET technologies. In addition, he had spent many hou... This author has published 73 articles on DotNetSlackers. View other articles or the complete profile here.