Tapping the full potential of RIA applications means involving remote Web services. In this article, I’ll present techniques that demonstrate how to communicate between Silverlight and Live Search using Silverlight’s services infrastructure.
This article is excerpted from John Papa’s book, Data-Driven Services with Silverlight 2, published by O’Reilly Media, Inc. ISBN-13: 978-0596523091 and is reprinted with the author’s permission.
Silverlight 2 brings a tremendous number of tools to the client to allow creating a rich user interface. 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 the ability to interact with a variety of services, which makes Silverlight 2 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
There are many services available on the Web that can be called. Some of these Web services are discoverable like Live Search and others are not and use REST, like Amazon ECS. Most of these services require a unique key be sent to the service so that the request can be tied back to whoever the key belongs. Live Search calls their key an AppID.
Instructions for creating an AppID for Live
Search can be found at
http://msdn.microsoft.com/en-us/library/bb266187.aspx. Instructions for using
the Live Search service can be found at
http://msdn.microsoft.com/en-us/library/bb251808.aspx.
The following example shows how you can conduct a simple search using a SOAP-based Web service provided by Live Search. First, the AppID must be requested and used 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. (You can find this service at http://soap.search.msn.com/webservices.asmx?wsdl.) The sample names the service LiveSearchService as shown in Figure 1.
Once you’ve referenced the service you can create a proxy to the service and invoke its SearchAsync method. This method requires a SearchRequest parameter, which can include a lot of intricate parameters defining the type of search. This Live Search example will keep the search parameters simple and simply return the first 10 hits (shown by the Offset property in Listing 1). Listing 1 shows the creation of the proxy object, the setup of the search parameters, the adding of the event handler for the completion of the search, and the asynchronous SearchAsync method call to the Web service.
Once the search has been completed, the proxy_SearchCompleted event handler (shown in Listing 2) executes and binds the result to the ListBox control. A 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. This call crosses the domain boundary. Silverlight will request the clientaccesspolicy.xml file and will find it (shown in Listing 3).
The clientaccesspolicy.xml file indicates that it will 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 since they can tell the client application exactly how they should be called and what type of data they will return (if any).
