Silverlight clientaccesspolicy.xml files for the Enterprise (Part 1 of 2)
I decided to move this article up the chain in my backlog of articles as I have come across this scenario numerous times on the http://silverlight.net/ forums. This article will give some basic information that has been covered on numerous other sites and times and give some additional insight on how to handle cross-domain issues in enterprise Silverlight service deployments.
Note: This article is pretty long and doesn't really fit well into a blog format (which I find is very limited for effectivily presenting technical ideas on a larger scale). I am going to start moving some of my bigger articles into possible whitepaper format as well.
Contents of this article (Part 1 of 2):
Background Information about cross-domain service access in Silverlight
Silverlight 2 uses services as its primary source of retrieving data across domain boundaries. Once you enter the services and web application domain, you are exposing your content to malicious attacks. One way Silverlight prevents its applications from launching malicious attacks on other sites is through opt-in cross-domain access. This means the site has to say yes in order to receive and respond to requests from a particular domain. This opt-in feature is controlled by a clientaccesspolicy.xml file. If you have done any WCF programming with Silverlight, this should be familiar to you. If not, check the basic information on the MSDN site here.
Suppose that we have a Silverlight application hosted on http://contoso.com/ (means the main/initial XAP file). This application has a service backend that retrieves data from http://mycontososervice.com/. These are obviously on two seperate domains and we have a cross-domain issue. By default, this scenario will not work. We need to create a clientaccesspolicy.xml file on the http://mycontososervice.com/ site that will allow calls from http://contoso.com/. The location of the file must be located on the root of the site (http://mycontososervice.com/clientaccesspolicy.xml).
Here is a graphical representation of what is going on:
The clientaccesspolicy.xml file is located where the service is being hosted. This is a very important point. Most Silverlight developers that are starting out make a mistake in that they think the clientacesspolicy.xml is deployed onto the server where the Silverlight application is hosted. This is not true and can cause many debugging headaches. The clientacesspolicy.xml NEEDS to be deployed on the server hosting the WCF service so that Silverlight can properly consume it.
Note: For simplicity reasons, I am not adding the crossdomain.xml file which is used by Flash. Silverlight also uses this file in case the clientaccesspolicy.xml doesn't exist. This is done for obvious reasons as Flash/Flex has a bigger install base and Silverlight is simply leveraging a possibly pre-existing cross-domain file.
Example of the format of the clientaccesspolicy.xml file that grants all domains access:
Example of the format of the clientaccesspolicy.xml file that grants access ONLY to contoso.com:
Note: Notice how the only change was to add the <domain uri="http://contoso.com"/>. This is more secure and other domains will be disallowed from making service calls.
Clientaccesspolicy.xml file that only grants service access from contoso.com (other requests are not fulfilled):
Deploying cross-domain policy files on Enterprise Servers
One of the key aspects of a clientaccesspolicy.xml file is that it needs to be accessed on the root of the website. In our example above, the request is http://mycontososervice.com/clientaccesspolicy.xml. In order to achieve this on IIS, we would simply place the clientaccesspolicy.xml file on the root of our website (default IIS: c:\inetpub\wwwroot folder). If you want to grant multiple domains access, an admin simply can modify the clientaccesspolicy.xml file.
As mentioned above, Flash has an equivalent cross-domain configuration file to Silverlight called the crossdomain.xml file. This file has a different format; however, it serves the same purpose as the Silverlight clientaccesspolicy.xml file. Let's take look at how some of the largest companies based on services use this file. You can try this yourself by using any browser.
Examples of Enterprise cross-domain configurations:
Example of the Amazon crossdomain.xml file (http://www.amazon.com/crossdomain.xml) :
Example of the MySpace crossdomain.xml file (http://www.myspace.com/crossdomain.xml):
Some notes to take away from the two examples above:
-
Root domains are different and this obviously makes the domain calls cross-domain. (i.e., amazon.com != amazon.fr). You need to list all the different domains
-
Sub domains also define cross-domain calls (i.e., lads.myspace.com != myspace.com). You need to list the different sub domains.
-
Secure and unsecure (http vs. https protocols) also make the calls cross-domain.
As you can see, maintaining these files can get quite complex very quickly in more advanced scenarios. These files need to be accurate and improperly formatted xml config files can cause the validation of the configuration to be invalidated.
Problems with maintaining the clientaccesspolicy.xml file manually
Maintaing the clientaccesspolicy.xml file manually on a single or even a couple of servers is not a problem. However, maintaining complex properly validated clientaccesspolicy.xml files on multiple servers or domains can be quite challenging. One single fat finger and the file can invalidate all service calls. Improperly adding or not removing a domain can cause a serious security violation.
Scenarios where manually maintaining the clientaccesspolicy.xml file manually can be an issue:
-
You are maintaining 2 different RIAs and want to keep both XML files in sync (I know Silverlight can use Flash's file, but we want to prepare for mass Silverlight deployments)
-
The clientaccesspolicy.xml file is complex. You have over 10-15 domains, subdomains and protocols that all have to work.
-
The clientaccesspolicy.xml is dynamic
-
The solution you offer allows clients to access the site through specialized domain (i.e., client.mydomain.com, client2.mydomain.com)
-
Architecture/hosting uses SaaS model (You host services others can consume)
-
Lots of changes occur to the file and you want to eliminate the "human factor".
-
The web service server is part of a web server farm or a cluster. The files need to be in sync almost instantaneously.
-
Client anonymity is important (i.e., You don't want to expose who is consuming your services)
Obviously some of these challenges can be mitigated with other security measures and designs. However, let's assume that in your scenario you have a properly working architecture/deployment and the clientaccesspolicy.xml file is becoming a maintenance nightmare. What can you do?
HttpHandler solution for dynamic clientaccesspolicy.xml files for the Enterprise
To overcome complex cross-domain scenarios by using some of the more advanced features of ASP.NET, we can mitigate some of the manual work that comes with creating cross-domain policy files. HttpHandlers are one way to solve some of the problems I listed above.
Httphandlers are a pretty powerful tool for ASP.NET applications that extend ISAPI extensions. There are many uses for Httphandlers and one of them is to map certain web requests to specific handler functionality. (I am not going to go over handlers in detail. If you need more information, try this link: http://www.15seconds.com/issue/020417.htm). We can create an HttpHandler that will see a request for a clientaccesspolicy.xml file. Instead of manually copying the file off of the root server, we can generate the file dynamically.
Walkthrough - Creating a basic HttpHandler for clientaccesspolicy.xml files
We are going to create a few sample handlers and add functionality to each one.
Basic Clientaccesspolicy Handler Part 1 - HttpHandler basics
-
Open Visual Studio 2008 and create a new project.
-
Select "Class Library" and let's call the project "SilverlightCrossDomainHandler" (Note: Do NOT create a Silverlight Class library.)
-
Add a reference to the System.Web assembly. (We are going to be creating an ASP.NET HttpHandler which requires the IHttpHandler interface found in the System.Web assembly)
-
Add a new class to the project and call it BasicClientaccesspolicyHandler.cs.
-
Navigate to the class and change its access modifier to be public.
-
Add a using statement "using System.Web;". (This is needed as we will be implementing the IHttpHandler interface.)
-
Implement the IHttpHandler interface by simply typing ": IHttpHandler" after the BasicClientaccesspolicyHandler class name.
-
Right-click on the IHttpHandler name and select Implement Interface -> Implement Interface. This will create the methods we need to implement for this handler to work.
You should have something like this now: (If not, simply just copy and paste the code from below)
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
namespace SilverlightCrossDomain
{
public class BasicClientaccesspolicyHandler : IHttpHandler
{
#region IHttpHandler Members
public bool IsReusable
{
get { throw new NotImplementedException(); }
}
public void ProcessRequest(HttpContext context)
{
throw new NotImplementedException();
}
#endregion
}
}
Basic Clientaccesspolicy Handler Part 2 - HttpHandler adding some code
-
Change the getter for the IsResusable property the exception to simply "return true;" (This allows the Handler to be pooled.)
-
Delete the "throw new NotImplementedException();" inside the ProcessRequest method. We are going to replace this with code. We are going to use LINQ in order to build the clientaccesspolicy.xml file. We can just as easily use StringBuilder, XmlDocuments or other forms. (This is NOT meant for production. This is just illustrating a concept.)
- Add a reference to the System.Core assembly. (This houses the LINQ methods.)
-
Add the following using statement: "using System.Xml.Linq;" .
-
Copy and paste the code below and insert it into the ProcessRequest method. The code below uses the Parse method from the XDocument class to load a string and transform it into an XDocument object.
XDocument clientaccessPolicyDoc = XDocument.Parse(
@"<?xml version=""1.0"" encoding=""utf-8""?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers=""*"">
<domain uri=""*""/>
</allow-from>
<grant-to>
<resource path=""/"" include-subpaths=""true""/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>");
context.Response.Write(clientaccessPolicyDoc.ToString());
Your class file should now look like the following:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Xml.Linq;
namespace SilverlightCrossDomainHandler
{
public class BasicClientaccesspolicyHandler : IHttpHandler
{
#region IHttpHandler Members
public bool IsReusable
{
get { return true; }
}
public void ProcessRequest(HttpContext context)
{
XDocument clientaccessPolicyDoc = XDocument.Parse(
@"<?xml version=""1.0"" encoding=""utf-8""?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers=""*"">
<domain uri=""*""/>
</allow-from>
<grant-to>
<resource path=""/"" include-subpaths=""true""/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>");
context.Response.Write(clientaccessPolicyDoc.ToString());
}
#endregion
}
}
Deploying managed HttpHandlers on IIS 7.0
This will go over deploying the HttpHandler solution we created above into IIS 7.0. I wanted to provide some basic instructions on deploying handlers as it can be tricky, making this article a complete resource. However, this article is not about deployment so I will cover only IIS 7.0. Why IIS 7.0 and not 6.0? Simply because I think that most advanced developers should be taking advantage of IIS 7.0 features and some of the new WCF 4.0 bits will only work in IIS 7.0. If you haven't converted to developing on either Vista or Windows 2008 now is a good time to do so.
This is one way we can deploy the HttpHandler on our server. I like this solution as it is a global way to add the handlers to the entire web server and it is simpler to follow. There are several different ways to do this. Another good solution would be to deploy the handlers with a Silverlight web project. This way the clientaccesspolicy.xml handler is only enabled when a Silverlight application is deployed.
-
Build the SilverlightCrossDomainHandler solution in release mode
-
Sign the assembly so that we can deploy it to the GAC
-
Install the assembly into the GAC by copying the assembly to the c:\windows\assembly\ folder
-
Edit the web server web.config and add our assembly type
-
Navigate to the C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\ folder (v2 because that is the last version that has hooks into the core ASP.NET assemblies....NET 3.0 and 3.5 simply build on top of this)
-
Open the web.config file with Visual Studio
-
In the compliation element there is an assemblies element with several assemblies listed. We will add our custom assembly here.
-
Add this element: <add assembly="SilverlightCrossDomainHandler, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d1c49f632a38a3c"/>
-
Note: The PublicKeyToken could be different if you are doing this project on your own. Simply copy it and replace it with whatever your assembly has been signed with. You can check what your public key token is by right-clicking the assembly once it is in the GAC
-
Save the web.config file
-
Add the HttpHandler to the global web server
-
Open up IIS Manager
-
Double click on "Handler Mappings"
-
There will be several listed that are pre-installed when ASP.NET and IIS are set up by default. In order to add your own right-click and select "Add Managed Handler..." (this can take a few seconds)
-
A dialog box will appear
-
In the Request Path enter: clientaccesspolicy.xml (this will mean that ANY request to the clientaccesspolicy.xml file will be handled by our handler we choose)
-
Select the SilverlightCrossDomainHandler and whatever type you want (i.e. BasicClientaccesspolicyHandler) from the dropdown menu (if it is not located there, you probably messed up editing the web.config file)
-
Name the handler what you like (i.e. Clientaccesspolicyhandler)
-
Perform a restart on the web server or an iisreset or restart the application pool
Testing managed HttpHandlers (inside the browser)
To test our deployment simply point your browser to http://localhost/clientaccesspolicy.xml. Of course, you want to make sure that you actually do not have a clientaccesspolicy.xml file on the root of IIS. If you put the URL into the browser and click OK, you will simply get a blank page (as this is not an HTML/ASPX/RSS etc request that has a visual reponse). You can either use Fiddler or Web Development Helper. To test using the Web Development Helper (for those that use Fiddler, you know how to do this already):
- Install the tool, if you haven't done so already. The tool is an add-in for Internet Explorer after you install it you have to close all your IE sessions.
- Go to Tools -> Web Development Helper
- A window shoul appear on the bottom
- Check Enable Logging (this will let you monitor any requests made from the browser)
- Navigate to the page hosting your handler (i.e. http://localhost/clientaccesspolicy.xml)
- You will see a row entry for the response from the server
- Double-click on the row and a dialog pops up with detailed information about the request
- Click the Response Content Tab and notice that we have a well formed clientaccesspolicy.xml file
Note on the screen shot that Enable Logging is checked. We received a response from the request and the Response Contect is well formed for the clientaccesspolicy.xml and it is ready to serve us:
The fun doesn't stop here :) Since we deployed the handler to handle ANY request anywhere for clientaccesspolicy.xml (which you may or may not want to do). All requests for subdomains work fine as well and are handled by the very same handler we installed. In my test case I created a sub domain and profiled and it works fine:
TroubleShooting
If you do not have the proper IIS ASP.NET and Extensibility add-ons (ISAPI) turned on, you might receive this error: (Simply go back to Add/Remove programs and add the ASP.NET and Extensibility features for IIS). Furthermore, ensure that ASP.NET is properly registered on your site.
Summary
This article introduced you to some of the basics in managing a clientaccesspolicy.xml file for the Enterprise. We looked at other cross domain files how they are published in Enterprise scenarios and how some scenarios could warrant a more dyanmic configuration file. One way to solve the complexity of dynamic cross-domain configurations is to use HttpHandlers to create the configuration for us. In part 1 of the series we created a simple HttpHandler that returned a well formed file. In part 2 of the series, we will create a dynamic clientacesspolicy.xml file from a database store that will properly create the file in a more complex scenario.
SilverlightCrossDomainHandler.zip (18.51 kb)
PDC 2008 - Silverlight 2 Wrap-Up
PDC (Professional Developers Conference) 2008 is over and there was a lot of information released over the course of the 4 days. You probably have heard some of it if not all of it. I wanted to write a post to summarize the information pertaining to Silverlight either directly or not directly that was released last week. Over the course of the week, Silverlight developers were bombarded with information that was coming out and this post's goal is to help developers get a handle on all of the information. Here is the summary of what has been released during the week of the PDC 2008:
- Silverlight Tools for Visual Studio 2008 SP1
- Silverlight Control Toolkit
- Expression Encoder SP1
- PDC Silverlight Videos (directly related)
- PDC Silverlight Videos (indirectly related)
- Silverlight 2 for Mobile Devices
- WCF REST Starter Kit
- Silverlight and SEO
Silverlight Tools for Visual Studio 2008 SP1
Silverlight Tools for Visual Studio 2008 SP1 were released over 3 weeks ago. However, for those people who are detailed oriented, this release was labeled as RC1. I posted a question on this on the forum the day this was released. Apparently, this was NOT the final release of the tools. On 10/30/2008 Microsoft released a new build of the Silverlight Tools. I don't think anything has changed, but regardless, you will want to update your tools to this new build. The new build of the tools can be downloaded here: http://www.microsoft.com/downloads/details.aspx?FamilyId=c22d6a7b-546f-4407-8ef6-d60c8ee221ed&displaylang=en
Silverlight Control ToolKit
The Silverlight Contol Toolkit was announced at the PDC 2008. It has a bunch of great controls, themes and charting cababilities. The big news is that the toolkit is open sourced and it you can extend it or build your own controls. Not only is it a great way to enhance your current Silverlight applications, but it is also a great way to learn about Silverlight control development and architecture. Shawn Burke's team has also included a bunch of unit tests using the Silverlight Framework so you can learn how to implement some TDD with Silverlight. You can download the toolkit here: http://www.codeplex.com/Silverlight
Expression Encoder SP1
Expression Encoder SP1 has been released. I like the approach Microsoft took by adding service packs to both Blend and Encoder rather than forcing people to upgrade. Therefore, people who have invested in version 2 are getting their money's worth. SP1 of Encoder allows you to create custom Silverlight 2 video player skins. It also includes H.264/AAC support. The service pack is available here: http://www.microsoft.com/expression/try-it/default.aspx?filter=servicepacks (Note: Expression Encoder also has an Express version which will work after the trial expires allowing you to do some basic things.)
PDC 2008 Silverlight Related Videos Online
If you weren't at the PDC, Microsot published the videos from the 4 days to the web. You can watch the PDC 2008 Videos online here: https://sessions.microsoftpdc.com/timeline.aspx. Here are the videos that are either directly or indicrectly related to Silveright development and I have some notes on the ones I watched.
If you are an architect, development manager, etc., I highly recommend watching some of these videos and then getting your team together for a lunch or a meeting and watching this together. I find this spurs developers thinking together about the current and future technology earlier.
PDC Silverlight videos (directly related to Silverlight)
PDC Silverlight Videos (indirectly related)
Silverlight cannot consume data directly from objects or databases located on servers (even if it is the same server Silverlight is hosted on). Silverlight is all about consuming data from services. These videos are an absolute MUST to watch if you are a Silverlight developer and consume data from services.
-
-
-
Excellent video that deals with ADO.NET Data Services development and the Entity Framework. This video shows some of the cool interceptors for security and enhancing services that exist in ADO.NET Data Services. If you are building a simple Silverlight client that needs, call batching, smart data and/or security concurrency management, ADO.NET Data Services provide a lot of great features here.
Silverlight 2 For Mobile Devices
Microsoft is porting Silverlight to mobile devices. This is a really welcome feature. Many users who have an iPhone know that Apple is currently "blocking" the availability of Flash to mobile devices. This is where Silverlight has a potential advantage and put a dent in the Flash market share by targeting mobile devices. Most of this information is coming from this video here from the PDC: http://channel9.msdn.com/pdc2008/PC10/
Here are some of the highlights from the PDC:
- By 2010 statistics show that there will be about 4 billion mobile phones in the planet. There is a huge opportunity here! So how do you write applications that are rich to thousands of users? Silverlight :)
- Silverlight 2 (That's right; the same Silverlight 2 on desktops) has been announced for the mobile space.
- Plublic CTP will be available in 2009 (Q1). My guess is that they will release this at the same time as MIX 2009.
- The really cool part is that the SL 2 on mobile requires NO CODE changes to work on a mobile device where Silverlight is installed!! That is really nice and very powerful and one code works on both the desktop and mobile devices.
- The Baby Smash demo really drives this point home further. So not only can you share code between WPF and Silverlight 2, you can share code between WPF, Silverlight 2 and Silverlight 2 Mobile! That is impressive; three platforms with one codebase.
WCF REST Starter Kit
One of the ways that Silverlight can consume data is through RESTful services. WCF was part of the .NET 3.0 framework back in 2006. In 2006 REST services were just starting to get traction as many Web 2.0 companies used this design as a preferred method for their service APIs. WCF .NET 3.5 has added some features for REST services. However, there was still a lot of plumbing code in order to write proper RESTful services in .NET 3.5. The MySpace API is a great example of what can be done with WCF and REST on a very large implementation.
In order to make writing some of the WCF REST services easier, Microsoft released the WCF REST Starter Kit during the PDC.
The WCF Starter Kit makes building RESTful services a lot easier. It also shows the impressive architecture of WCF. It can be enhanced with using attributes and interceptors to build a REST architecture for services.
Silverlight and SEO
Several months ago Google announced that it can now crawl Flash-based applications. This is pretty important because now Flash-based content is searchable and this is critical to any revenue model that is based on high-page ranks on Google (sales, ads, etc). Silverlight currently cannot be crawled by Google (maybe in the future). However, there are couple things you can do right now to make sure your Silverlight application gets crawled by Google:
- Ensure that the page hosting your Silverlight content has proper meta tags and place the SEO there.
- You can also place a page for a "deprecated" client. Therefore, if you receive a hit from a user that doesn't have Silverlight, you can bring them to an HTML page rather than the full Silverlight client. This way when the Google robot tries to crawl your site, it will crawl it based on the HTML page.
This information is really important for developers that are jumping into RIA. Most architects are ready to jump right into the technologies and try to solve problems with RIA. However, things like SEO sometimes might fall through the cracks and might not be acceptable to a client. Check out this post for more information on Silverlight SEO Optimization: http://nerddawg.blogspot.com/2008/10/search-engine-optimization-for.html
Silverlight 2 for Mobile - Why you should start using a MVC pattern
Silverlight 2 for Mobiles was announced at the PDC. I wasn't there, but I read about it on Chris Hayuk's blog here. The real cool part of the announcement is what they announced that there will be no changes required to your code. So, this is not some Silverlight-type Compact Framework step child subset of .NET. To quote Chris exactly:
"YOU DO NOT HAVE TO DO ANYTHING
TO MAKE YOUR SILVERLIGHT APPLICATION TO MAKE IT WORK ON THE MOBILE,
NO RECOMPILING, NOTHING."
That is a pretty cool goal if Microsoft achieves this kind of transparency with the Silverlight 2 plug-in on mobile handhelds. However, to think that your 1280x1024 site with huge graphics and animations is going to automatically scale properly is ludacris. However, this is what software design/architecture patterns were made for.
You have problaby heard of the ASP.NET MVC Beta out there that has all the no postback and no viestate fluff etc. However, the MVC pattern at its core seperates the business logic from the UI. For example, in your web form you have a button and then you write a click handler to print "Hello". In ASP.NET this would be handled all in your codebehind cs file. With the MVC pattern changes this where the user click is handled by the controller and then sent to the model. I am not going to go over MVC in any kind of detail. However, the main thing to understand is that the UI code is seperated from the business logic properly and other UIs can simply be plugged in with a different View component. This lends itself very nicely to the Silverlight MVC pattern. Imagine writing an application in Silvrerlight 2 and simply swapping out the View for Silverlight 2 Mobile and the entire application just works. No code changes just that inside a regular browser you will load a normal View object and for Silverlight 2 Mobile you will use your Mobile View. This mobile view might be: simpler in scale, use a simpler/clearer theme, use less animations in order to fit nicely inside the smaller resolution screens. Depending on how your app is designed this might be all enclosed inside your XAML.
I had my "oh that makes sense now" moment with MVC several months ago, after seeing an example similar to this. Hopefully Silverlight developers can see that using a pattern like MVC (or MVP etc) is really powerful and not just some loosely thrown around "best practice". Furthermore, hopefully this example with Silverlight 2 Mobile helped. If Microsoft achieves its goal of being able to have one single runtime for the web and mobile; investing in the MVC pattern can potentially save you a ton of work in the future if you are thinking about targeting the mobile market.
Silverlight & ASP.NET MVC vs Web Forms (Very High Level)
Silverlight 2 RTW has been out for a couple of weeks now and it is already being compared to ASP.NET MVC which is an evolutionary way to design web applications using ASP.NET. I read a concise summary (pros and cons) of ASP.NET MVC from Jason Young. His article can be read here: http://www.ytechie.com/2008/10/aspnet-mvc-pros-and-cons.html
I decided to compare Silverlight in a similar way to what Jason did when he compared ASP.NET MVC vs. Web Forms.
Here are the items he listed as ASP.NET MVC vs. Web Form:
PROs vs. ASP.NET Web Forms
- No ViewState or "surprise crap"
- This applies to Silverlight as well. Silverlight brings the "desktop" experience to the end user and there is no ViewState that is used in Silverlight.
- Faster server-side & client-side
- Silverlight is faster on the client/server side depending on how you look at it. Silverlight is compiled in a .NET subsystem of Silverlight. You have access to multithreading, LINQ, complex data structures, etc. The performance vs. an ASP.NET or AJAX/JavaScript application is it magnitudes times better because of the client execution and some of the items that normally are handled in a server BLL can be brought down to the client
- Simplified model for multiple related views
- Silverlight supports the complete seperation of the data and the UI. Taking this further by just creating seperate views for say another consumer of Silverlight is pretty powerful. You can apply the same MVC/MVP pattern inside Silverlight and attain this level of abstraction. Jason mentions an example of being able to create a seperate view for an iPhone and only the View component has to change. This applies to Silverlight as well for different things. For example, I have large sized Silverlight app I want to port to SharePoint. I can create a "Smaller View" for SharePoint so it fits nicer into the UI. Furthermore, Silverlight Mobile is being private tested now. I would assume that same very powerful level of abstraction applies as well to create a "Mobile view" for your Silverlight application.
- Unit Testable
-
Challenges if you are not running IIS 7
-
Client Caching
CONs vs. ASP.NET Web Forms
-
Difficult to convert existing code
-
Silverlight is a completely different programming platform than either ASP.NET WebForms or MVC. Not only will a lot of the code not convert, you also have to think about the client layer and in most cases a complete re-architecture is needed if you are replacing large modules inside your existing ASP.NET site.
-
NOT the best SEO out of the box
-
Data access
-
Security
-
Silverlight runs on the client. A lot of your bits are then roaming in the wild on the internet. Furthermore, some of the data access techniques do not support full WS* standard security. Therefore, beyond certificate based transport security, you are either writing a lot of your own plumbing code or waiting for the next rev. The XAML code is pretty much insecure; not many applications have their Intellectual Property in their UI. In Silverlight, that can be very easily reverse engineered using
Silverlight Spy for example. Silverlight, just by nature, is a little less secure than an ASP.NET MVC application. Obviously, you would want to encrypt/obfuscate your Silverlight assemblies before letting them off in the wild.
In conclusion, even though Silverlight and ASP.NET MVC are two completely different technologies, they share A LOT of the same pros and cons Jason pointed out vs. Web Forms. The only difference is that the hosting model for Silverlight is a lot simpler. Silverlight does have its nuances with data access and security that you have to worry about. Furthermore, you do get other benefits like client-side performance and client-caching.
Silveright 2 GUIMark - Big Performance Boost in Silverlight 2 RTW
10/23/2008 Update: Updated the code (rendering and MaxFrameRate) and some notes below

GUIMark Background
Silverlight has had a few iterations since the Silverlight 1.1 Alpha Days. We started at Silverlight 1.1 Alpha in 2007. This year we had two beta releases and RC0 before Silverlight 2 RTW was released. Silverlight and JavaFX are two new RIA technologies that were introduced this year competing with Adobe's Flash/Flex. In comparing the different technologies, it is natural to compare the performance of the different RIA products and their AJAX/Java Applet cousins.
One of the big performance indicators was GUIMark. GUIMark is a performance test designed by Sean Christmann to gauge the performance of the rendering subsytem of the given technologies. One of the claims of this benchmark is that it uses a variety of tests to give a more true test of the rendering pipeline. There are a variety of different visuals that truly test the performance of the rendering engine. No test is perfect, but I found this one to be pretty good.
GUIMark and Silverlight 2 Beta 1 & 2
I have been playing with Silverlight off and on in the Alpha 1.1 days and since Beta 1, a lot more. I came across the GUIMark site several months ago and was pretty disappointed with the results with the Silverlight rendering engine. Looking at the site you can see that Silverlight 2 Beta 1 had a HORRIBLE performance of about 7-8 frames/second. It even lagged behind Silverlight 1.0/JavaScript! Flex/HTML was many factors ahead in performance (30-40/FPS).
Silverlight 2 Beta 1 at the time the results were published the technology was obviously not finished. Why was the rendering so poor? Alex Grenier in the GUIMark website pointed out that the text rendering was the bottleneck. Sure enough, I tried the test myself and removing the text rendering resulted in Silverlight dramatically having the same FPS as Flex. Microsoft obviously had some work to do in order to improve the text rendering for Silverlight.
GUIMark and Silverlight 2 RTW Code
Silverlight 2 RTW has been out for a couple of weeks now. GUIMark has not updated the source code since Beta 1 so I decided to upgrade the code and see how how the performance has increased. I essentially took Sean's Silverlight Beta 1 code and upgraded it for Silverlight 2 RTW in its bare essentials. (The code can be downloaded below)
- I updated the dependency properties to use double data types instead of ints.
- After Beta 1, Silverlight apparently does not support binding from an object that is subclassed from the DependencyObject. You can read more about this here: http://silverlight.net/forums/t/13593.aspx To me, this is really weird and it is worth a discussion outside this topic.
- I changed the namespace and added a web project for deployment and testing
I did NOT TOUCH the rendering loop which is totally inefficient and can now leverage the Silverlight 2 RTW. This can easily add several FPS to the project. See the 10/23 update below, I updated the rendering loop to use the CompositionTarget.Rendering
Silverlight 2 RTW Performance Test
In one of the changes from the betas to RC0/RTW was the text glyph rendering. We knew this was a bottleneck before, lets see how well this performs now. The best way to judge the performance is to see the code run yourself. Click the links below to run the test. Open each link individually and make sure nothing processor intensive is running. If you click the "Run Test" button, just click it once to receive an average FPS over 10 seconds. (If you keep clicking Run Test, the test will fail).
Results - On my Vista Dual Core IE 7 (Your results will vary depending on your processors and browser):
- Flex 3: ~43 FPS
- Silverlight 2 RTW: ~43 FPS (updated code with MaxFrameRate set to 500)
The performance is almost identical between Silverlight and Flex. Microsoft definitetly fixed the rendering of text glyphs. That change is primarily responsible for the great performance improvement. Remember that render loop still can be improved (I might do an update to the code) for extra FPS. One thing to note about FPS is that in a normal production system, FPS is ususally limited. In Flash/Silverlight, the default is about 60 FPS. A lot of developers/architects (including myself) limit the FPS even further. The human eye can't tell the difference between 40-60 FPS anyway, so trying to eke out 400 FPS is completely uncessary.
Silverlight 2 RTW Code: SilverlightHack_GUIMarkSilverlight2RTM.zip (795.85 kb)
10/23/2008 Update
I updated the code to use the new CompositionTarget.Rendering event which is new in Silverlight 2 RC0/RTW. This is the best practice for things such as gameplay loops. Some people noticed that Flash was performing siginigantly better than Silverlight. I thought it was the rendering loop being inefficient, however this change by itself did not change the FPS at all. This rendering loop is directly tied to the MaxFrameRate which can be set programatically at runtime by setting the Application.Current.Settings.MaxFrameRate property. Playing with this increased the Silverlight FPS by 15!
The default for the MaxFrameRate is 60. That means that if you have no code or little code if you just put a FPS counter you will get 60 FPS (I tested that and that works fine). Obviously, if you have code in your loop that code could potentially drop. So, I updatd the code/demo with a Frame Rate selector to show what is happening here.
- Setting the MaxFrameRate 10-40 the FrameRate increases. (for example if I set it to 10, I get 10 FPS)...all this makes sense
- Setting the MaxFrameRate 40-60 the FrameRate drops to 35 FPS. This is probably because of the increased overhead of the events. This kind of makes sense.
- Setting the MaxFrameRate 60-500 the FrameRate increases up to 46 FPS ??? This is really weird. I don't understand why setting the FrameRate to 500 actually nets the best results. To me this doesn't make sense.
I posted this question on the Silverlight.net forums here: http://silverlight.net/forums/p/41045/115696.aspx#115696 (When I get an answer, I will update this post)
This does some interesting questions on the MaxFrameRate setting. Oviously one thing I can say 100%...if you are writing a Silvelight game or heavy animations, you need to be very aware of this setting for performance. Furthermore, if writing any benchmarks for Silverlight you may want to play with the optimal MaxFrameRate setting in order to get the best possible results.
Silverlight and the Enterprise
Silverlight: Feature Complete
Silverlight 2 released and the feature set has been locked down for a while now. Many RIA experts, bloggers and developers have chimed in on forums or blogs on what features they would like to see in Silverlight and the direction it should take. Opinions vary greatly on this and by doing a simple search online you can see the vast differences. While I definitely agree this needs to be discussed, I feel that there is so much that Silverlight 2 currently offers that future features can be disucussed later.
Microsoft is taking a nice approach with Silverlight 2 in that they are going to be releasing additional Silverlight assemblies outside the core download. The nice result of this is that we don't have to wait any longer for the releases to come out [Silverlight 2 (1.1 Alpha) was announced March 2007!]. Furthermore, by not bloating the core with additional features, this keeps the Silverlight 2 client payload pretty small (around 4.6 megs). The first example of this "add-on" strategy is the new Silverlight controls project from Shawn Burke. Microsoft will also release "professional themes" for Silverlight the same way. Both of these and more will probably be released at the PDC 2008 this month. Instead of adding value in Silverlight by directly building features into the core, a lot of value can be built by building "around" Silverlight.
Competitive Environment: Next Generation Web
Many are already calling the end of Web 2.0. The internet is on the brink of new type of services and software that will be released under the Web 3.0 umbrella. Many companies including Google, Microsoft, Apple, Firefox, Adobe, etc., are positioning themselves in their offerings for the upcoming new generation of products. When Silverlight 2 is released, it will put Microsoft in a VERY unique position. Microsoft's main competitors in the technology are Adobe (Flash/Flex/AIR) and Sun (JavaFX). However, Microsoft has many more competitors especially with more and more core OS features moving to the web and the mobile space. Google and Apple would be Microsoft's big competitors there. However, neither Google nor Apple have a RIA technology that they own themselves (Apple's iPhone UI tech is proprietary to the device for now). Microsoft is a lot bigger than all of these companies individually; however, each of their individual companies can cause problems for Microsoft in their vertical strengths. There is one thing that Microsoft can do that none of these companies can do invidually: integrate a new UI/RIA technology in their vast horizontal of business & enterprise products (mainly because none of these companies has that enterprise product penetration). This not only would add value to Microsoft's products, but it also would add value to Silverlight indirectly. For example, this can position Silverlight as business RIA technology and Silverlight doesn't have to play catch-up in the graphical area with Adobe (PhotoShop, Illustrator, 3D acceleration, etc.).
Silverlight in the Enterprise
How can Silverlight be used in the Microsoft enterprise space? Here is a mix of existing and potential ideas where I think Silverlight can be a great addition to the presentation stack:
Parallel Computing
Silverlight is powered by the subset of .NET 3.5. Although Silverlight 2 will not allow everything in multithreading (i.e., true async delegates), it does have a decent baseline which a developer can utilize. Any current computer that has been purchased within the last couple of years includes a dual core processor. Intel is planning on releasing 6 core processors later this year. By not utilizing parallel computing, you're not maximizing the efficiency of the program and all the processing it could utilize. Microsoft is very aware of the shift to multiple cores and has invested in this with their parallel computing initiative. This library includes additions to make LINQ execute on multiple threads by simply adding the AsParallel() extension method on the end of your LINQ query. A parallel extensions library for Silverlight does not exist right now. However, adding this simple abstraction to Silverlight would be a huge boost to performance and would allow some enterprise level applications to be scaled down to the data level on the client. In my previous multithreading articles I mimicked some of the basic flow of the parallel tasks and gained up to 120% performance improvements! Enterprise architects will be able to take a serious look at Silverlight as a potential powerful "client tier" to potentially offload some simple to medium cost processing and reduce trips to the server or reduce service calls.
SharePoint 2007 Integration
SharePoint is one of Microsoft's fastest growing products in terms of adoption and revenue. In my opinion, allowing the developers to focus on designing/developing content and not focusing on "plumbing code" is probably the best feature of SharePoint. This allows businesses in the enterprise to quickly set up the SharePoint farm and deliver content quickly. Silverlight is a great UI technology to extend SharePoint. During the SharePoint 2008 Conference, Microsoft announced the Blue Print for SharePoint Services. These blue prints are meant to provide guidance for building SharePoint solutions that include Silverlight. This addition is huge for Silverlight because this technology can now be utilized in one of Microsoft's biggest enterprise offerings. I have done several solutions inside SharePoint 2007. One of the things that it missed was true AJAX integration until SP1. Even now, some things like cross web part communication cause postbacks and then one has to deal with the "statless web" workarounds. The Silverlight plug-in is a great way for extending the SharePoint experience in a more interactive way that AJAX can simply not do. Furthermore, Silverlight can access many of the SharePoint features such as Lists, work flows, etc., via SharePoint services. If you are a SharePoint developer, I am sure I don't have to go into the potential that Silverlight and SharePoint integration provides.
Windows Communication Foundation
WCF is a true SOA framework for building enterprise level services. Microsoft is one of the few companies that has a deep SOA framework such as this. Currently Silverlight only supports basic HTTP services, WCF REST services and a duplex version. Similarly to SharePoint, the biggest feature of WCF is that it allows you to focus on designing services rather than "plumbing code". WCF abstracts a lot of complexity of enterprise messaging while allowing you to make decisions in which you can stay in the "best practice" realm. WCF makes creating an enterprise service easy. For example, using the WSHttpBinding, binding the service is secure, faults propegate across services, integrates with authentication, reliability can be configured, etc. This is a truly powerful feature. A lot of WCF bindings are not available to be consumed in Silverlight because that would mean including a lot of the core .NET 3.0 libraries that would bloat the core payload. Hopefully external libraries are made available for Silverlight in the future that would allow consuming WS standard bindings. In my opinion, the further integration of Silverlight and WCF is going to help propel Silverlight as a powerful, interactive consumer of enterprise services.
SQL Server
SQL Server has come a long way since I first started using the 6.5 version. It now includes enterprise reporting (Reporting Services), a true ETL engine (SSIS) and a powerful Buiness Intelligence OLAP engine (SSAS); although it's not OLAP anymore. One of the things that has been lacking with Reporting Services and Analysis Services is the presentation layer for both the end user and the respective product administrators. Microsoft is aware of this which is shown with Microsoft's recent acquisition of ProClarity or SQL Server 2008 SSRS visualization additions. All of these products also have a "techy" look and feel with their tools because of the integration with the Visual Studio 200x shell which needs to be installed on the local workstation. This is where I think Silverlight can come in and extend a lot of the presentation or even the administration features of these SQL Server products. Silverlight is perfect because it is a web technology and it allows for deep interaction with the data. Therefore, there is nothing to install beyond the plug-in, but you can still enjoy a desktop experience. For example, imagine opening a Reporting Services report and going beyond static data and being able to do "what if" scenarios or bringing key insight to life with animations. Silverlight with SQL Server can definitely bring the data to life in the enterprise.
Mesh, Semantic Web and Cloud Computing
Silverlight RIA UI + Cloud Computing Data + Semantic Web =
Microsoft is making a big play in the new Web 3.0 realm: cloud computing, semantic web and bringing the dekstop experience via the web. Microsoft has a variety of services: Outlook Online, SharePoint Online, Exchancge Online, Mesh and other various data services. The problem with these are that they have the classic Microsoft business look and are not 100% intuitive for non-business users. This is where Microsoft has a huge edge with Silverlight. Merging the power of these services together with a super-rich and easy to use interface can make these services wildly popular. What other company can do this on a massive scale? Apple has shown that people en masse will go for an advanced UI. Microsoft can build on this with already popular products and services in the backend. This brings us a lot closer to the Minority Report type interface but with actual meaningful data behind it.
Who cares about a pretty UI if it's just an intro for a corporate site or a movie site? Silverlight and the Microsoft cloud computing platform can change this.
Bringing in data and the UI together is a very powerful combination that will bring a more dynamic UI and lets the user decide how the data is presented, viewed and analyzed. In my opinion, this is Microsoft's best shot at usurping Google in their game. This platform has the potential to be Web 3.0.
In conclusion, in this article I wanted to cover a couple of important concepts relating to Silverlight in the Enterprise. The main concept I wanted to describe is that just because Silverlight 2 is feature complete doesn't mean the technology cannot grow in value. Microsoft owns the enterprise market and this is where I think a technology like Silverlight cannot only add value to the enterprise offerings but the enterprise offerings can make Silverlight a first-class RIA technology for business. Silverlight does not have to play catchup with Adobe Flash/Flex and can lead in business/enterprise product innovation. In my opinion, "the Silverlight Enterprise Ace" is a card that Microsoft can play in the next few months and increase the popularity of Silverlight dramatically.