Consuming WCF in Silverlight 3 Session at MIX ‘09

This session covers three separate scenarios for Silverlight and WCF interactions. The basic functionality of adding a service reference, creating proxy class and calling method hasn’t changed. However, they are trying to address some of the common pain points related to WCF

It’s now possible to remove the network traffic associated with ‘fat’ SOAP/XML messages by using a binary XML format to send the message. The demo reduced message size by 30%. But size was not the main design goal for binary XML. While compression is possible at the HTTP level, apparently binary XML reduces effort on the client and server as messages are compressed and decompressed. Binary XML is intended to improve speed. And while not every message is affected significantly (small messages and strings don’t really benefit), there is no case that MS is aware of where it gets worse. So binary XML becomes an appropriate default formatting standard.

Also included in this section was a description of why server-side error information is not accessible from within Silverlight. Specifically, if you have a server-side HTTP 500 code, the information related to the error does not get pushed to Silverlight. This is a fairly hard limitation related to how browsers pass HTTP information to plug-ins. And Silverlight is really a plug-in. The solution is an HTTP hack, there internal server errors get returned as HTTP 200 codes. And Silverlight 3 is built to pull the error information off of the response and surface it through the normal SOAP faulting mechanism.

When it comes to security WCF calls in Silverlight 3, there are two choices: browser-based and manual. The browser-based approach depends on cookies and Forms authentication at the browser level. This is easy to implement, but is open to cross-domain threats IF you have enable cross-domain access for every Web site. The manual approach has identity managed by Silverlight. When the credentials are added by Silverlight (instead of the browser), the cross-domain thread is eliminated. SL3 provides an out-of-the-box mechanism for creating the SOAP headers associated with the manual mechanism. It’s the ‘out-of-the-box’ that is new in SL3, not the technique itself.

The big gotcha in the manual mode is found in the method that WCF uses to prevent replay attacks. There is the concept of a MaxClockSkew. In indicates how far apart the client and server clocks can be. The default value if 5 minutes. which is to say that if the server system has a time of 11:05 and the client system has a time of 11:11, all messages will be rejected. This is the kind of situation that I’m sure will bedevil developers. MS is still trying to decide what the default value of MaxClockSkew will be when SL3 is released.

The second scenario covered in this session involved pushing messages to Silverlight. It was possible in SL2 to push message to the Silverlight application, but the knowledge required by the developer to implement it has been reduced. Because I’m very familiar with WCF, the technique does not seem advanced. Basically, the idea is to have the SL3 client make a one-way WCF call with a callback contract. The OneWay mode means that there is no calling context hanging around on the client. The callback allows the service to call back to the Silverlight application. In the Silverlight application, there is an event raised when the callback method is invoked from the service.

The third and final scenario talked about REST in Silverlight 3. As it turns out, SL3 doesn’t have much added in this area. Mostly because “the REST story in SL2 was pretty complete” This is actually pretty true about WCF in Silverlight in general. It’s not that there aren’t things that people would like to do with WCF in Silverlight (different bindings, for example). But the reality is that the limiting factor for most new feature requests is the HTTP stack from within the browser. It was mentioned that it’s possible to roll your own HTTP stack by going out to JavaScript through the HTTP DOM, but that technique will probably not work if the Silverlight application is running on off-browser mode.