Asynchronous (or multi-threaded) applications are common place on the desktop and have been for decades. Without this ability, most of our favorite productivity tools would be non-existent. As soon as one moves off the desktop and onto the Internet, the standard changes to one that is highly, if not exclusively synchronous (or single-threaded). Of course, since Internet-based applications have historically served as simple content delivery mechanisms, the need for more robust, asynchronous-based applications didn't exist. However, as more and more businesses move online with each passing day, the pressure for Internet-based applications to narrow the desktop gap is higher than ever before. To the IT professional, this means not only the creation of a new development platform, but the establishment of a new era of software development. Enter Silverlight.
Simply put, Microsoft Silverlight (http://silverlight.net) is a platform which enables the development of Rich Internet Applications (RIA's). With its third release now in Beta, it combines the usability of a desktop application with the interoperability and deployment advantages of one that is web-based. The Silverlight runtime, similar to Flash, adds itself as a plug-in into your browser (about a 4MB download). Where Silverlight is significantly different from Flash is in how the applications are constructed. It relies heavily on two technologies: XAML and the .NET Framework.
XAML is a declarative, XML-based language used for the development of user interfaces. It has the distinction of being standards-based and web designer friendly via tools such as Microsoft Expression Blend (http://www.microsoft.com/expression). The .NET Framework is used for the creation of application logic itself, along with the web services required on the server tier. This allows businesses who have invested in C# and VB.NET developers to continue to leverage their investment.
Although there are slight differences across browsers (there are in standard HTML too), Silverlight is able to leverage the power of the client machine to deliver a highly-functional and highly-performing user experience. While this seems like we're regressing back to an old-school client/server mentality, the reality is that it's more of a hybrid. User interface controls and code-behind logic that can run independent of a server are pushed to the client. These run inside a security sandbox to limit any operations that could pose an unnecessary risk. Any dynamic content retrieved from backend databases or more sophisticated business logic is performed through web services on the server. In fact, one could argue that we are seeing web services reach their maturity through the capability offered by Silverlight.
Although we won't go into detail on it here, it is highly encouraged that developers follow the Model-View-ViewModel (MVVM) pattern when developing in Silverlight. For more information on this pattern, reference http://msdn.microsoft.com/en-us/magazine/dd458800.aspx.
Most importantly, Silverlight's architecture is inherently asynchronous. To the average end-user, this provides the type of non-blocking behaviors they take for granted today in their desktop applications. To businesses, it means doing more with less. Software as a Service (SaS) scenarios are now more realistic for them to invest in with the knowledge that it will decrease the large amount of capital historically invested in hardware and hardware support. In the up and down markets of today, that can only have a positive impact.
The gap between desktop and web-based applications is as narrow as it has ever been. Realistically, it will take time for the IT community to adjust to this capability. Asynchronous applications are different animals that pose unique challenges to architects and developers alike. If technology has taught us anything, there's no such thing as a free ride. But, make no mistake, the potential benefits outweigh the impending challenges and the industry will no-doubt adapt quickly.
I was building a Silverlight 2.0 application for a Tricension client and determined that it was appropriate to utilize SSL to secure the site. In particular, to secure communications back-and-forth between the WCF services which were handling a lot of sensitive financial data. Although I had setup SSL on several sites before, I didn't realize how difficult it was to find a good reference on how to do this for WCF. After a very long day, thought I'd share how I got this to work. Of course, now that I know, it's not that tough.
Step 1 - Install your SSL Certificate
I'm not going into the details on how to setup SSL in IIS7 here other than to say GoDaddy.com is awesome. They're cheap (in a good way) and for those of you who need a little extra help, they've got really easy instructions on how to get your cert up and running in a hurry.
Step 2 - Configure your WCF Service
In order for a service to communicate over SSL, a few adjustments must be made to your service's web.config settings that VS.NET will setup for you by default. Here's how I set mine up. I've highlighted a couple of the enhancements that were important to getting the service to run properly. In particular, the specification of the "transport" security binding tells the service to utilize secure communication.
<system.serviceModel>
<services>
<service behaviorConfiguration="Namespace.MyServiceBehavior" name="Namespace.MyService">
<endpoint address="https://www.tricension.com/MyService.svc" binding="basicHttpBinding" bindingConfiguration="Binding" contract="Namespace.IMyService"/>
<host>
<baseAddresses>
<add baseAddress="https://www.tricension.com/MyService.svc"/>
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="Namespace.MyServiceBehavior">
<serviceMetadata httpsGetEnabled="true"
httpsGetUrl="https://www.tricension.com/MyService.svc" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="Binding">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
</configuration>
Oh, you probably know this already (pretty well documented), but just in case...Silverlight 2.0 applications only support basicHttpBinding. VS.NET will not set this option by default, so make sure you change it or your service reference will not add correctly.
Step 3 - Test the service
I found that trying to troubleshoot services from the Silverlight client can be a bit tricky. Once the configuration is setup, I recommend you open up the service definition in a browser and validate that the service comes up correctly before moving on.
Step 4 - Configure the Silverlight Client
When WCF services are added as references in a Silverlight 2.0 project, VS.NET 2008 will create a file called ServiceReferences.clientconfig which defines the service endpoints that the client is consuming. If you setup your service from the beginning using SSL, VS.NET will add the proper settings in this file to communicate over SSL. If you are like me, you don't use SSL anywhere but production (and sometimes test). In this case, the original end point configuration must be changed upon moving to the secure environment.
Similar to the service configuration, the client specifies a security binding of "transport".
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IMyService" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
The definition of the endpoints is basically the same, with the exception of the https:// designation in the URL.
<client>
<endpoint address="https://www.tricension.com/MyService.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IMyService"
contract="Namespace.IMyService" name="BasicHttpBinding_IMyService" />
</client>
Step 5 - Cross-domain Support
In the event your application requires cross-domain support, you will also have to modify the clientaccesspolicy.xml file to something like this:
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Assuming I'm not completely full of it, which is entirely possible, you should be ready to go.