Silverlight Hack

About Me

Welcome to Silverlighthack.com. This is a site where you can find many articles on Silverlight, Windows Phone 7 and .NET related technologies.

My name is Bart Czernicki. I have been working with computers since 1988 and have over 12 professional years in the IT field focusing on architecture, technology strategy and product management. I currently work as a Sr. Software Architect at a large software development company.

Below is the cover of my new book that shows how Silverlight's unique RIA features can be applied to create next-generation business intelligence (BI 2.0) applications.

Contact: bartczernicki@gmail.com

NONE of the comments or opinions expressed here should be considered ofmy past or current employer(s). The code provided is as-is without anyguarantees or warranties.

Silverlight 2.0 technology is based on a web plug-in that runs on the client's computer. Writing applications/tools/games that don't depend on data is straightforward and doesn't require the Silverlight developer to think much beyond the client's domain. However, what if the developer wants to introduce external data into their Silverlight 2.0 application?

First, the bad news:

Silverlight 2.0 currently runs on a small subset of the .NET 3.5 Framework. This means some of the "direct" data channels/communication libraries are not available to you (i.e., remoting, COM, database, etc.)

Silverlight hosts its app domain on the client's workstation. This means that even though it is a web technology hosted on a web server, it can't leverage resources on the web server that do not cross the web server domain (i.e., database calls, local dll files that call a database, local dll files that consume a service)

Another limitation is that because Silverlight utilizes a minimal/secure plug-in architecture, you cannot access local workstation data channels easily. For example, a fat client windows application can call a database, windows/web services, make remote calls, etc. Most of these (as you guessed it) are not available to you.

So HOW can I consume some data from an external data source? Silverlight 2.0 Beta 2 currently supports these communication channels:

Consume data using JavaScript/HTML bridge from Silverlight 2.0 (I am not going to cover this as I consider this an undocumented/workaround feature). I did want to mention this option because there are some real nice solutions that can be done with this.

As you can see from the list above, Silverlight 2.0 (as of Beta 2) supports a variety of communication mechanisms. Most of these, excluding Sockets/JavaScript-bridge, focus on service technology. Therefore, as a developer, you can talk to the data store inside your service application and expose it via any types of these services. Consuming these services can be done several ways, but that is not the focus of this article. Designing these services can be done several ways as well.

As a developer, what is the best way to design services that a Silverlight plug-in client can consume? Luckily, this is where WCF comes in (Finally, the meat of the article).

WCF is an acronym for the Windows Communication Foundation, which was introduced in .NET 3.0. WCF (like LINQ/.NET) is one of these technologies that is hard to summarize in one good definition. Some developers simply say WCF is web services or a way to design SOA. My definition of WCF is actually not mine. This definition is from Juwal Lowy's forward from his great book Programming WCF Services:

"WCF is a fundamental technology that provides an easy and clean way to generate services and applications in compliance with what I regard as sound design principles."

WCF (without going into too much detail) allows you to architect applications by applying best practice guidelines automatically. Security, throttling, opt-in serialization, logging, etc., are handled for you just by creating a service inside the WCF framework and setting config/attribute values. Juwal Lowy (in web casts/book/classes) says you can spend time writing plumbing code and trying to adhere to best practices or use WCF and allow it to do the majority of the work for you.

Silverlight runs on a subset of the .NET 3.5 framework, so it does not support all of the WCF bindings and can't consume every type of WCF binding/endpoint. However, from the list above utilizing WCF (as your service engine) you can design: SOAP 1.1 Services, Duplex Services, AJAX Enabled Services & REST Services. All of these can be consumed by the Silverlight 2.0 client.

A great aspect of WCF is that it allows you to write your application and expose it using various binding endpoints supported by Silverlight. Furthermore, existing WCF services can simply be "Silverlight enabled" by providing a compatible Silverlight endpoint. Depending on the functional requirement, of course, this might not be possible.

The diagram below demonstrates the same services being consumed by different clients using different endpoints:

Quickly doing a search on services+Silverlight, you will notice that WCF comes up a majority of the time. Microsoft is pushing WCF heavily as a best practice for writing services for Silverlight. In fact, after installing the Silverlight 2.0 SDK, you have a new template called "Silverlight-enabled WCFService" for quickly creating WCF services that can be consumed with Silverlight.

Silverlight 2.0 Beta 2.0 allows the developer to configure the WCF service inside a ClientConfig file. This is a real nice add for additional configuration of WCF services, especially if you are a software vendor that needs to change connections/tweak settings for different deployments declaratively.

WCF (in .NET 3.5) has great support for creating RESTful services. RESTful services are used all over the place: Flickr, MySpace, Amazon, etc. WCF allows you to quickly create low/high REST services that can use XML, JSON or RSS encoding. Silverlight can consume these easily. In fact, many examples online show this by communicating with external REST services and manipulating the data on the client (i.e., using LINQ).

Summary of benefits using WCF to consume data in Silverlight:

All the different Silverlight service types can be designed with the single WCF technology. Basically, anything you can do with other service design you can do with WCF. However, with WCF you are doing it with a single technology

Allows the developer to design services focusing less on implementing best practices and plumbing code (WCF's biggest selling point, since it does a lot for you out of the box)

WCF endpoint abstraction allows the developer to create service endpoints for both Silverlight and non-Silverlight consumers (while sharing the same code)

Microsoft recommended best practice. WCF includes first class support in Silverlight: online examples, Silverlight-enabled WCF service template and clientConfig XML configuration file

Best practice for the future. As Microsoft adds additional support to the Silverlight service stack, developers can be assured that probability-wise this will be done via WCF. For example, Duplex services (introduced in Beta 2)

In summary, Silverlight and WCF technologies complement each other very well. WCF is a single technology that provides you a single design mechanism to create a variety of solutions for exposing your data to a Silverlight client. WCF is not a requirement in order to consume data inside Silverlight (lots of examples online with 3rd party REST services). However, because of how well it works with Silverlight and deprecates other SOA design (at least in the MS world), it is a no-brainer that WCF is recommended by Microsoft. In my opinion, WCF is a technology every developer needs to master in order to be effective with consuming data inside Silverlight.