Channel Register

Original URL: http://www.channelregister.co.uk/2008/03/06/silverlight_two_data_services/

Silverlight 2.0 data and web services explained

By Tim Anderson in Las Vegas
Published Thursday 6th March 2008 17:39 GMT

Mix 08 Microsoft Silverlight team member Eugene Osovetsky has explained to a packed Mix 08 session how Silverlight 2.0, released as beta (http://www.microsoft.com/silverlight/resources/installationfiles.aspx?v=2.0) on Wednesday, interacts with external data and web services.

No surprise: the first thing we saw was based on the Windows Communication Foundation (WCF) (http://msdn2.microsoft.com/en-us/netframework/aa663324.aspx), Microsoft's universal .NET web services API.

Presuming you use ASP.NET and Visual Studio, this involves creating a WCF service by marking up .NET code with attributes such as ServiceContract and DataContract, then consuming the service in a Silverlight application by adding a Service Reference and coding against it. Silverlight requires AJAX-style asynchronous calls to a proxy class, with the results processed in a callback event handler. Silverlight has rich bindable data controls including a listbox and a datagrid.

That's all well and good, but not everyone wants or can use end-to-end .NET. Fortunately Silverlight also supports standard SOAP by importing a WSDL (http://www.w3schools.com/wsdl/wsdl_intro.asp), or generic web services using XML or JSON (http://www.json.org/), though a little more code is needed. Once again, the Silverlight code involves asynchronous calls, this time using a generic WebClient class that will already be familiar to .NET programmers.

There are complications with REST (http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci823682,00.html), though. The problem is that Silverlight, like Adobe Systems' Flash, does not have its own networking stack but relies on the browser's plug-in API. This gets you benefits like sharing the browser's authenticated connections, but also brings limitations.

Apparently it is simply not possible to use HTTP PUT or DELETE methods, a problem that leads to hacks like HTTP POSTs that delete data, breaking the HTTP specification. This is not the fault of Silverlight, but it is unfortunate. For similar reasons, there is no access to SOAP fault messages.

There is also a big issue with cross-domain data sources, which poses a problem for mash ups. Cross-domain access is prevented by default for security reasons. Otherwise, a bad Silverlight application might hijack an existing authenticated connection to some other site.

Cross-domain data is the essence of mash ups, though. The solution with Silverlight is that services can opt in to being called cross domain by including a policy file. Silverlight has its own, or will observe a Flash policy file. Therefore, public services that work with Flash should also work with Silverlight. Cross-domain access over SSL is promised, but not supported in the current beta.

Osovetsky remarked that Silverlight 2.0 has moved away from JSON towards SOAP, saying that JSON has little advantage if the client code is not JavaScript, though he admitted that JSON has a smaller message size. Microsoft is investigating binary XML for Silverlight, but it seems unlikely this will make the first release.

This puts Silverlight at a disadvantage to Flash for downloading large amounts of data, since Flash can use Adobe's efficient ActionScript Message Format. In mitigation, Silverlight is inherently flexible and there is plenty of scope for custom solutions.®

© Copyright 2008