Udostępnij za pośrednictwem

What's new with web services in Silverlight 3 Beta

  • Artykuł

Silverlight 3 beta comes with a set of exciting web services features that address key customer requests.

Binary message encoding

In Silverlight 2 the only supported binding was BasicHttpBinding, which encodes outgoing messages as text and sends them over an HTTP transport. This binding is great for interoperability with SOAP 1.1 services and is also easily debuggable since messages can be viewed in plain text on the wire using HTTP debugging tools such as Fiddler.

However as Silverlight applications go into production and grow to scale, service developers start getting concerned with the cost of hosting services. Two things in particular that we are about:

  • Increased server throughput - more clients can be connected to a server, which means fewer servers need to be purchased.
  • Decreased message size - smaller message sizes exchanged on the wire means lower bandwidth bills

Silverlight 3 introduces a binary message encoder, which produces significant improvements in both of the above indicators. A follow-up post is coming with some specific data on the improvements that can be expected.

Binary encoding is implemented as a custom binding, there is no out-of-the-box binary binding.

<bindings>
<customBinding>
<binding name="binaryHttpBinding">
<binaryMessageEncoding />
<httpTransport />
</binding>
</customBinding>
</bindings>

<endpoint address="" binding="customBinding" bindingConfiguration="binaryHttpBinding" contract="Service" />

The BinaryMessageEncodingBindingElement can be used as part of any custom binding and so it composes easily to create things like a binary duplex binding.

The binary encoder offers performance gains over the text encoder, and there should never be any regressions. This is why binary is the new default in backend service scenarios, such as where the Silverlight-enabled WCF Service item template is used. Therefore the template has been modified to use binary. The interop cases is where binary should not be used (if the client is talking to a non-WCF service), since binary is a WCF-specific encoding: please continue to use BasicHttpBinding with text encoding in those scenarios (for example accessing ASMX services).

Duplex object model simplification 

Duplex is an innovative Silverlight 2 feature which allows the service to send data to the client without the client manually polling for the data ("smart" polling still occurs on the network layer, but the user does not need to know). However there were two significant limitations in the Silverlight 2 duplex object model:

  • Channel programming had to be used and
  • Serialization was not supported so a Message programming model had to be used.

Silverlight 3 lifts these restrictions and introduces Add Service Reference support for duplex services. Familiar-looking proxies are now generated, greatly reducing the amount of Silverlight code that is needed to access a duplex service. A simple stock ticker client implementation, which previously took 203 lines of code, can now be reduced to a mere 48 lines of code, a 76% reduction in code size. Not to mention that the channel-based code was complex and very error-prone due to its use of async patterns. Here is a snippet showing the crux of the new object model, in the context of the stock ticker example:

private void Button_Click(object sender, System.Windows.RoutedEventArgs e)

{

    ServiceClient proxy = new ServiceClient(binding, address);

    proxy.ReceiveCallbackCompleted += new EventHandler<ReceiveCallbackCompletedEventArgs>(proxy_ReceiveCallbackCompleted);

    proxy.StartAsync(symbol.Text);

}

void proxy_ReceiveCallbackCompleted(object sender, ReceiveCallbackCompletedEventArgs e)

{

    if (e.Error == null)

    {

        price.Text = e.price.ToString();

    }

}

Note that receiving the callback from the server is now just a matter of attaching a callback to an event. Also note the fact that we are working with CLR types and not Message objects, so serialization is now enabled. We have updated our documentation with a walkthrough of how to use the new object model. In addition, Eugene's duplex chat server implementation, which has proven very popular, has also been updated with the new OM.

Faults support

In Silverlight 2 if an unexpected exception occurred in the service, the fault would not be propagated to the Silverlight client. Instead of getting the exception propagated to the user, Silverlight would throw an unhelpful CommunicationException which carries no useful information. There were two reasons for this: (1) faults are returned with a 500 status code, and the browser networking stack prevents Silverlight from reading the body of such a response, and (2) Silverlight did not support he necessary client-side logic to convert the fault message into an exception that can be surfaced to the user. These limitation made it very difficult to debug services from Silverlight.

In Silverlight 3 Beta limitation (1) is unfortunately still present. To work around this issue our documentation provides a WCF endpoint behavior, which can be applied to your WCF service to switch the response code from 500 to 200. With this response code the message will be accessible to Silverlight and we can address limitation (2). In Silverlight 3, we have added the necessary client-side OM to surface faults to the user. Look out for helpful FaultException and FaultException<ExceptionDetail> exceptions which will help you debug your service. Also please see the documentation page linked earlier for a full description of the faults object model in Silverlight.

New security mode 

A common scheme used to secure services for use by Silverlight clients is browser-based authentication. However browser-based authetnication is not safe to use if your service is accessible from any domain via a cross-domain policy file. This would expose your service to CSRF type attacks, where cached browser credentials can be used by malicious apps to access your sercure service without the user's knowledge.

Silverlight 3 introduces a new security mode called TransportSecurityWithMessageCredential to address this configuration. In this mode, the credentials are included in every outgoing message to the service, and the service verifies those credentials on the SOAP layer. However since the credentials are in plain text inside the message the transport needs to be secure so we use HTTPS.

A more detailed walktrhough of valid Silverlight security configurations will follow.

Command-line proxy generation

In Silverlight 2 Add Service Reference as part of Visual Studio is the only way to generate proxies for Silverlight clients. In Silverlight 3 we are introducing a command-line tool called slsvcutil.exe, which allows customized command-line proxy generation. Using the tool, proxies can now be generated as part of your build process for greater robustness. The slsvcutil.exe tool is fully described in this documentation topic.

Thanks for reading through this, and please stay tuned for some in-depth posts about these new features.

Yavor Georgiev
Program Manager, Silverlight Web Services Team

Comments

  • Anonymous
    March 20, 2009
    PingBack from http://blogs.msdn.com/silverlightws/archive/2009/03/20/what-s-new-with-web-services-in-silverlight-3-beta.aspx

  • Anonymous
    March 20, 2009
    Synchronous calls are needed... I can understand why you are taking just Asynchronous calls but in some scenarios the need for Syn is better, the use of sync or async shoul be a decition of the application architec just like in WPF programming

  • Anonymous
    March 20, 2009
    The underlying networking stack in Silverlight does not support synchronous programming, so WCF cannot use the synchronous pattern in Silverlight. I do understand that the synchronous pattern is simpler in most case, unfortunately this is a limitation we have to live with. Are there any specific scenarios where you have a problem? Thanks, -Yavor

  • Anonymous
    March 22, 2009
    Hi Yavor, Thankyou for this post, there's some good stuff in here I was hoping you guys were working on Faults in particular are a pain point at the moment, and any improvements here are welcome. The other area of concern I have is security between Silverlight and WCF services, and the introduction of TransportSecurityWithMessageCredential is very welcome. However, currently, all security between Silverlight and web services hinges on the use of SSL. I and many other people I suspect would like to be able to take advantage of the WCF bindings that support message security and the WS-* standards. Are you guys working on that, is it in your plans, or do you not have any plans for it at all at present? Cheers, Greg

  • Anonymous
    March 24, 2009
    Hi Greg - thanks for your feedback. This is exactly the kind of dialog we're hoping to develop on our blog. I cannot make specific commitments but support for WS-Security is definitely on our list of big chunky features that we know are missing from SL3. Please consider your scenario and let me know why the current security mechanisms don't work for you. Any data you can give us about key scenarios that are currently blocked will help us argue the case for WS-Security in subsequent Silverlight releases. Thanks and keep the feedback coming! -Yavor

  • Anonymous
    April 01, 2009
    Hi Yavor, Sorry for the delay in responding, I've been playing with the new SL3 features! OK, I'll explain, and please anyone jump in and correct me if I'm wrong or misunderstand the situation we have. Broadly, we're creating a SL application which will communicate with WCF services hosted outside of the user's LAN, and could be accessing sensitive data. Whilst we can use SSL, this is only point-to-point secure. It is entirely feasible that there may be routers/intermediaries inbetween the client and the services. Unless we have encryption of the message content itself, it's possible that the contents could be intercepted and read at the point where the message is vunerable during the hop - when it's inbetween SSL connections from one server to the next. Now, on the WCF services side, we can implement wsHttpBinding, which gives us WS-Security, allowing for message security (encryption, message integrity, etc). If we were writing a WPF thick client then we could use this binding, giving us message security. However SL doesn't support this. For a number of our customers, this is potentially a problem. When it's explained that their data isn't as secure when using a SL app as when using a thick client, it can be a sticking point. Of course, the actual risk to their data may well be low, and SSL transport security may be actually good enough, but the perception of SL being "less secure" is enough to put people off. It may well be that we will have to roll our own encryption mechanism within our SOAP messages. Now this also gives us problems in that it's time consuming, probably won't give us the full spectrum of Ws-Security functionality, will mean that we will have to implement custom binding on the WCF side (therefore reducing our interoperability options with other clients in the future) and gives us issues with having to have security keys of some sort in the SL client code which of course is visible to the client (I'm aware it could be obfusticated). We'd much rather prefer to use the mechanism which is built into WCF! As well as security, there is also the issue of reliability. wsHttpBinding also gives us ws-Reliable messaging. Now, we've not looked too deeply at what the lack of this will mean for us, but looking at it briefly, we could potentially run into problems with messages being delivered out of order to our WCF service, or not at all. This may or may not be a problem for us, we need to investigate further. Now, I realise you guys are working within the constrains of the browser networking stack and implementation of full wsHttpBinding on the SL side may be tricky - but I hope you give it some serious thought. You've done such a good job of pushing the area of SL being secure within the browser and client machine environment due to the sandbox, it would be a pity if adoption for serious internet-based LOB applications is reduced once the perception is out there that the security between the client and server is lacking as SL can't support the full range of security features that WCF can. Cheers, Greg

  • Anonymous
    April 01, 2009
    The comment has been removed

  • Anonymous
    April 08, 2009
    Can you provide an example of how to setup TransportSecurityWithMessageCredential  to secure your wcf service with sl3

  • Anonymous
    April 26, 2009
    I could also really do with some example code for using SOAP authentication headers with an SSL layer. I use the following bindings, and the async service call silently fails. When I remove the TransportSecurityBindingElement, the service works perfectly. CustomBinding binding = new CustomBinding( TransportSecurityBindingElement.CreateUserNameOverTransportBindingElement(), new PollingDuplexBindingElement(), new BinaryMessageEncodingBindingElement(), new HttpsTransportBindingElement()  ); I'm also struggling to see how to access the SOAP authentication response headers, to assess login errors etc. Are there any good resources on error handling, debugging, and diagnostics when using the Async callback and duplex pattern with SL3? I think I'm missing out on something, but I seem to be blindly trying various options in the hope that one might work. I'm really excited about some of these new features, but it feels like the lack of example code is really holding me back.

  • Anonymous
    May 14, 2009
    One of the most common comments I hear form people when they start digging into Silverlight 3 Beta (and Silverlight 2) is the lack of WCF binding options. Some changes have been made to include binary encoding in Silverlight 3, so now we have: customBinding

  • Anonymous
    May 14, 2009
    One of the most common comments I hear form people when they start digging into Silverlight 3 Beta (and

  • Anonymous
    June 07, 2009
    Silverlight 3 Beta introduces a new way to improve the performance of web services. You have all probably

  • Anonymous
    June 07, 2009
    Cross-posted from the Silverlight Web Services Team Blog . Silverlight 3 Beta introduces a new way to

  • Anonymous
    June 07, 2009
    What's new with web services in Silverlight 3 Beta

  • Anonymous
    January 05, 2012
    In WCF, is this feature comes only with HTTP binding? If I want use net.Tcp means can we write any custum code to utlize this feature?.