any web services offer clients a variety of ways to communicate with them, including SOAP and REST, and can often return either XML or JSON. Silverlight can communicate with any of these types of services, parsing the results using LINQ.

Silverlight 2 brings a tremendous number of tools to clients that support the creation of rich user interfaces. It also has the ability to consume a variety of services across a network or the Internet. The ability to communicate with different types of web services in different ways (through RESTful services, syndicated feeds, and SOAP services to name a few) allows Silverlight 2 applications to take advantage of the features these services expose. Silverlight 2 clients provide a robust user experience and it’s a great choice for interactive and service-based applications. This article demonstrates how to build a Silverlight application that communicates with the Live Search web services.

Calling Live Search

	?
Figure 1. Referencing Live Search: Use Visual Studio’s Add Service Reference dialog to add the reference to the Live Search service.

Some available web services are discoverable, such as Live Search; others, such as Amazon ECS, use REST, and are not. Most of these services require that clients send a unique key to the service so that the request can be associated with the key’s owner. Live Search calls its key an AppID. You can find instructions to get a Live Search AppID on MSDN, as well as information about how to use it.

The following example shows how to conduct a simple search using the SOAP-based web service provided by Live Search. First, if you don’t have one already, request an AppID, which you’ll need for use in the LiveSearchClient sample program (available from the CoDe Magazine site for download). Next, you must add a service reference to the Live Search service’s WSDL file. The sample calls the service LiveSearchService as shown in Figure 1.

After adding the service reference, you can create a proxy to the service and invoke its SearchAsync method. This method requires a SearchRequest parameter, which can include a set of intricate parameters that define the type of search you want to make. The Live Search example shown here keeps the search parameters simple, and simply returns the first 10 hits (shown by the Offset property in Listing 1).

	?
Figure 2. Live Search Results: The ListBox on this page has a DataTemplate with fields bound to the results.

Listing 1 shows you how to create a proxy object, set up the search parameters, add an event handler that will be called when the search completes, and call the web service’s asynchronous SearchAsync method.

When the search completes, the proxy_SearchCompleted event handler (see Listing 2) executes and binds the result to the ListBox control. The ListBox’s DataTemplate simply displays the Title, Url and Description of each search result in the ListBox. Figure 2 shows the results of a sample search.

When the Silverlight client makes the web service request, the call originates from the local web site that hosts the Silverlight application on the Live Search domain. Because the call crosses the domain boundary, Silverlight will request the clientaccesspolicy.xml file (see Listing 3), which in this case indicates that Silverlight should allow any SOAP request from any domain to use the web services located anywhere on the web site, which is http://soap.search.msn.com.

Wrap Up

Silverlight clients can call any discoverable web services using ASMX web services and WCF web services. While Silverlight can also call services that do not describe themselves, such as REST services, self-describing services are beneficial, because they can tell the client application exactly how they should be called and what type of data they will return (if any).