Here we'll delve into the latter Silverlight 3 feature by comparing the options developers have for communicating with services from Silverlight. We'll do so by building a sample application called Cooking with Silverlight, a fictitious site where people can search in a recipe database and read reviews of recipes. We'll start by showing options for exchanging information with a Windows Communication Foundation (WCF) service. After that, We'll build the same application, but now using representational state transfer (REST) services. These two examples will demonstrate the differences between communicating with WCF or REST in a Silverlight app. You can download the complete code for this article by clicking the above link.
Working with Data in a Silverlight App
Silverlight uses the same Base Class Library (BCL) as the full .NET Framework, however, only a subset is available in the Silverlight platform. When browsing the assemblies, you'll quickly notice that many familiar data-related assemblies and classes are missing. Indeed, Silverlight does not contain ADO.NET and has no support for a DataSet or DataReader. In Silverlight 3, the current version at the time of writing, Silverlight has no client-side database access available, and it isn't possible to have a connection string in your Silverlight application, which would allow remote database access.
However, enterprise applications are built around data. To solve this problem, Silverlight can connect with services, on the same server on which the Silverlight app is hosted or on another server, if it complies with a few characteristics, which we'll look at in the cross-domain section of this article. Using services, we can satisfy almost every requirement for working with data in a Silverlight application. Even if we had a client-side database implementation, we'd still have the services required to use up-to-date information.
Out of the box, Silverlight can connect with several types of services, including WCF and REST. Let's first look at how the sample application was built and compare where the two technologies differ from one another.
Silverlight and WCF
WCF is the preferred way of building services in the .NET Framework. Designing a WCF service for use with Silverlight isn't much different from designing the service for use with any other technology. The main difference is the type of binding used for the communication. By default, when you add a WCF service to a project, it's configured to use a wsHttpBinding. In general, a wsHttpBinding supports distributed transactions and secure sessions. Silverlight, however, can't work with this type of binding; instead a basicHttpBinding is required. A basicHttpBinding essentially allows communication with a traditional ASMX web service (based on WS-BasicProfile 1.1) and lacks the options offered by the wsHttpBinding, such as secure sessions.
This means that all data is transmitted as plain XML in a SOAP message. In enterprise environments, this could be risky. To counter this risk, one possible solution is using ASP.NET authentication to allow access only to authenticated users on the services.
Visual Studio offers a Silverlight-enabled WCF service template. This template sets the correct type of binding in the configuration file.
Creating the WCF Service
A WCF service typically offers a service contract. The service contract offered by the service defines the operations exposed by the service. Each operation that needs to be exposed over the service is attributed with an OperationContractAttribute.
The implementation of the service, contained in the *.svc.cs file in a WCF scenario, contains the logic for accessing the data using the repository and returning a list of DTOs.
Using the WCF Service from the Silverlight Client
With the service in place, the Silverlight application needs to connect with it. WCF services are said to be self-describing: They expose a Web Services Description Language (WSDL) file, which contains metadata about the service. This metadata describes, among other things, the operations and data contracts exposed by the service. When you connect to such a service using Visual Studio's Add Service Reference dialog box, the IDE will generate a proxy class. This proxy contains a client-side copy of the service. The proxy class contains all operations, without the implementations, and a copy of the data contracts. Because of this, we get full IntelliSense in the editor when working with the service.
To execute a call to the service, we use this proxy class. However, when the application accesses a service from Silverlight, the call will be executed asynchronously. If synchronous calls were possible, during the call's execution the browser would remain blocked while awaiting a response from the server.
A callback method is specified for the XXX_Completed event. This method is executed when the service returns. Making the actual async call to the service is done using the XXXAsync method. Inside the callback method, the result of the service call is accessible through the e.Result property. This property's type is the same type as returned by the service. These types were generated when the proxy was created upon adding the service reference. We're using the result, here a generic List of Recipe instances, as the ItemsSource for the ListBox. Of course, other data-binding scenarios are possible here.
Silverlight and REST
The biggest advantage of using WCF services is the typed access, which is based on the metadata that the service exposes. This makes the process of writing the client-side code easier. However, not every service exposes metadata. Some services work with human-readable information, mostly in the form of XML, which they send following a request from the client.
This is the case for REST services. Compared with WCF, REST has some advantages. As said, the information is exchanged as pure XML (or JavaScript Object Notation—JSON, if needed). The XML is clean and more lightweight than the SOAP messages exchanged when using WCF. Thus, less data will go over the wire, resulting in faster transfer of the data. REST is also entirely platform independent: It requires no extra software as it relies on standard HTTP methods. However, because REST services are not self-describing, Visual Studio can't generate a proxy class. This means that when writing a Silverlight application that needs to work with a REST service, we manually need to parse the returned XML to capture the server's response. Luckily, Silverlight includes LINQ to XML, making this process much easier. Alternatively, you could use the XmlReader/XmlWriter or the XmlSerializer for this task.
Creating the REST Service
A REST service will send data when it's requested to do so. The request is done over HTTP, for example, by sending a request to a specific URL. The REST service will then respond by sending XML over the wire.
To create a REST service, we can use WCF as well. However, we need to perform some configuration changes to enable the WCF services to work as REST services.
The service operations in the service contract need to be attributed with WebGetAttribute in addition to the OperationContractAttribute. The UriTemplate defines what the URL should look like and which parameters it should contain to get access to the associated operation.
The implementation of the service operation is almost identical to the WCF implementation, as you can see in the previous listings. To test the service and see its response, navigate for example to http://localhost:1234/ RestRecipeService.svc/recipe/find/pancake.
For the sample application, we wrote the REST service ourselves. It's also possible to use one of the numerous, often free, REST service APIs available, such as Twitter, Flickr, or Facebook. Looking at those APIs, it's easy to see that their XML is also the contract for data exchange between a client application and the service.
Using the REST Service from the Silverlight Client
Since there's no metadata available on a REST service, we can't add a service reference to it from Visual Studio. We need another approach.
Using a REST service from Silverlight is a three-step process. Step one: Build the URL to which we need to send a request. The format of this URL is defined by the service and may contain parameters that we must provide as well. Step two: Send a request to that URL. And finally, step 3: Wait for the result to come in as XML or JSON and parse this accordingly.
Building the URL is pretty straightforward. It's constructed by gluing together the URL from the service project with the string defined as value for the UriTemplate. You can send a request to this URL by using either the WebClient or the HttpWebRequest class, both part of the System.Net namespace and also classes included in the full .NET Framework. For most situations, the WebClient will suffice; if you need more fine-grained control over the request, the HttpWebRequest is the best bet. The WebClient is basically a wrapper around the HttpWebRequest with an easier API: Using the WebClient under the covers still uses methods of the HttpWebRequest. We'll use the WebClient here as well.
Cross-Domain Access
When accessing services, Silverlight will not allow access of these services by default if they're hosted on a domain other than the domain hosting the Silverlight application. In other words, if we have a Silverlight application called CookingWithSilverlight.xap hosted on http://www.somedomain.com, the application can't access a service on http://www.someotherdomain.com unless that service specifically grants a right to access it from a client application hosted on another domain. This feature is called cross-domain restrictions and is basically a security measurement to prevent cross-domain attacks.
How can a service allow the access anyway? When a cross-domain service request is launched, Silverlight will check for a file called ClientAccessPolicy.xml at the root of the domain (it will also check for crossdomain.xml, which is the policy file that Adobe Flash checks for). If this file is present and allows the call to be made, Silverlight will access the service. If the file isn't present or we're accessing from a domain that isn't on the list of allowed domains, Silverlight will block the request, resulting in a security exception being thrown.
Cross-domain restrictions apply for both WCF and REST services. Accessing an image or a video on another domain doesn't trigger this check. In the sample application, both the WCF and REST services are hosted in a website different from the one hosting the Silverlight application. In both websites, at the root, a policy file can be found, allowing access from any domain.
Two Services Options for Silverlight Developers
Both WCF and REST have their strong points. WCF really benefits from the fact that it exposes metadata that can be used to generate a proxy class. During development, this results in IntelliSense picking up the types and operations of the services, which makes things much easier. Features like easy duplex communication and binary XML data exchange make WCF in Silverlight quite complete. All SOAP 1.1–enabled services, even if they're exposed from technology other than .NET, can be used from Silverlight in the same manner. In most enterprises, SOAP-enabled services are the standard.
However, we don't always have—or need—all the options made available by WCF. If the data being exchanged is pure text, we can use REST. It's simple, fast, and is based on the HTTP standard methods, requiring no special software. Many large Web 2.0 sites expose an API that uses REST. Working with this type of services does require some more manual work, in that we have to send the request, capture the results, and parse them into meaningful data.
Regardless of what type of service is used, the communication happens asynchronously. In the case of WCF, when the proxy class is generated, both the XXXAsync method and the XXX_Completed event are created. When using REST, the WebClient has a DownloadStringAsync and a DownloadStringCompleted event.
What is so SPECIAL on ASPHostDirectory.com Silverlight Hosting?
We know that finding a cheap, reliable web host is not a simple task so we’ve put all the information you need in one place to help you make your decision. At ASPHostDirectory, we pride ourselves in our commitment to our customers and want to make sure they have all the details they need before making that big decision.
We will work tirelessly to provide a refreshing and friendly level of customer service. We believe in creativity, innovation, and a competitive spirit in all that we do. We are sound, honest company who feels that business is more than just the bottom line. We consider every business opportunity a chance to engage and interact with our customers and our community. Neither our clients nor our employees are a commodity. They are part of our family.
The followings are the top 10 reasons you should trust your online business and hosting needs to us:
- FREE domain for Life - ASPHostDirectory gives you your own free domain name for life with our Professional Hosting Plan and 3 free domains with any of Reseller Hosting Plan! There’s no need to panic about renewing your domain as ASPHostDirectory will automatically do this for you to ensure you never lose the all important identity of your site
- 99,9% Uptime Guarantee - ASPHostDirectory promises it’s customers 99.9% network uptime! We are so concerned about uptime that we set up our own company to monitor people’s uptime for them called ASPHostDirectory Uptime
- 24/7-based Support - We never fall asleep and we run a service that is opening 24/7 a year. Even everyone is on holiday during Easter or Christmast/New Year, we are always behind our desk serving our customers
- Customer Tailored Support - if you compare our hosting plans to others you will see that we are offering a much better deal in every aspect; performance, disk quotas, bandwidth allocation, databases, security, control panel features, e-mail services, real-time stats, and service
- Money Back Guarantee - ASPHostDirectory offers a ‘no questions asked’ money back guarantee with all our plans for any cancellations made within the first 30 days of ordering. Our cancellation policy is very simple - if you cancel your account within 30 days of first signing up we will provide you with a full refund
- Experts in Silverlight Hosting - Given the scale of our environment, we have recruited and developed some of the best talent in the hosting technology that you are using. Our team is strong because of the experience and talents of the individuals who make up ASPHostDirectory
- Daily Backup Service - We realise that your website is very important to your business and hence, we never ever forget to create a daily backup. Your database and website are backup every night into a permanent remote tape drive to ensure that they are always safe and secure. The backup is always ready and available anytime you need it
- Easy Site Administration - With our powerful control panel, you can always administer most of your site features easily without even needing to contact for our Support Team. Additionally, you can also install more than 100 FREE applications directly via our Control Panel in 1 minute!
Happy Hosting!