The .NET Endpoint : Silverlight

New Web Services features in Silverlight 4 Beta

.NET Connected Framework Team — Wed, 18 Nov 2009 18:50:00 GMT

Cross-posted from the Silverlight Web Services Team Blog.

This morning at PDC ’09 ScottGu just announced the availability of Silverlight 4 Beta. Later on today I am going on to present the latest improvements around networking and web services and I’ll link to the full talk as soon as it is available online. In this post I’ll provide a quick summary of today’s announcements, with more detail to follow.

On the high level, we are announcing an exciting alignment between the different web services stacks in Silverlight. ADO.NET Data Services and .NET RIA Services are being rebranded as WCF Data Services and WCF RIA Services to reflect the fact that both technologies are being built out as programming models on top of WCF. In a way, this is not really major news; to you as a developer, pretty much everything stays the same, and you can continue using your favorite technology, whether it is straight WCF, or WCF RIA Services or WCF Data Services.

RIA Services and Data Services give you productive patterns for specific kinds of services and applications, hiding away some of the complexity of using WCF directly. The power of WCF is still there for you under the covers, if you need to modify some setting to your liking.

Specifically within the core WCF model, Silverlight 4 Beta has support for a brand new binding: NetTcp. This binding lets Silverlight talk to WCF services using a high-performance TCP pipe, using a duplex message pattern. In Silverlight, the binding is built on top of the sockets support that’s already there since Silverlight 2, so we inherit the security requirements of the Silverlight sockets API. More specifically, the service needs to be hosted in a given port range (4502 – 4534) and needs to expose a policy responder on port 943. One more thing to be aware of is that the security support and the streamed programming model for NetTcp available in WCF on the desktop framework are not available in Silverlight 4 Beta.

We’ll have a lot more content for you coming up soon, including the code from my talk today. If you want to get your hands dirty right away, go get the Silverlight 4 Beta, and then try the steps this how-to in our MSDN documentation, which has already been updated and show usage for NetTcp.

More information:

Thanks, and looking forward to your feedback!
Yavor Georgiev
Program Manager, Silverlight

Improving the performance of web services in Silverlight 3 Beta

.NET Connected Framework Team — Mon, 08 Jun 2009 06:32:17 GMT

Cross-posted from the Silverlight Web Services Team Blog.

Silverlight 3 Beta introduces a new way to improve the performance of web services. You have all probably used the Silverlight-enabled WCF Service item template in Visual Studio to create a WCF web service, and then used the Add Service Reference command in your Silverlight application project in order to access the web service. In SL3, the item template has undergone a small change that turns on the new binary message encoder, which significantly improves the performance of the WCF services you build. Note that this is the same binary encoder which has been available in .Net since the release of WCF, so all WCF developers will find the object model very familiar.

The best part is that this is done entirely in the service configuration file (Web.config) and does not affect the way you use the service. (Check out this post for a brief description of exactly what the change is.)

I wanted to share some data that shows exactly how noticeable this performance improvement is, and perhaps convince some of you to consider migrating your apps from SL2 to SL3.

When Silverlight applications use web services, XML-based messages (in the SOAP format) are being exchanged. In SL2, those messages were always encoded as plain text when being transmitted; you could open a HTTP traffic logger and you would be able to read the messages. However using plain text is far from being a compact encoding when sending across the wire, and far from being fast when decoding on the server side. When we use the binary encoder, the messages are encoded using a WCF binary encoding, which provides two main advantages: increased server throughput and decreased message size.

Increased server throughput

Let’s examine the following graph (hat tip to Greg Leake of StockTrader fame for collecting this data). Here is the scenario we measure: the client sends a payload, the server receives it and sends it back to the client. Many clients are used to load the service up to its peak throughput. We run the test once using the text-based encoding and once using the new binary encoding and compare the peak throughput at the sever. We do this for 2 message sizes: in the smaller size the payload an array with 20 objects, and in the bigger one the payload is an array with 100 objects.

Some more details for the curious: The service is configured to ensure no throttling is happening, and a new instance of the service is created for every client call (known as PerCall instancing). There are ten physical clients driving load, each running many threads hitting service in tight loop (but with small 0.1 second think time between requests) using a shared channel to reduce client load. The graph measures peak throughput on the service at 100% CPU saturation. Note that in this test we did not use Silverlight clients but regular .Net clients. Since we are measuring server throughput it is not significant what the clients are.

When sending the smaller message we see a 24% increase in server throughput, and with the larger message size we see a 71% increase in server throughput. As the message complexity continues to grow, we should see even more significant gains from using the binary encoder.

What does that mean to you? If you run a service that is being used by Silverlight clients and you exchange non-trivial messages, you can support significantly more clients if the clients use SL3’s binary encoding. As usage of your service increases, that could mean being able to save on buying and deploying extra servers.

Decreased message size

Another feature of the binary encoder is that since messages sent on the wire are no longer plain-text, you will see a reduction in their average size. Let’s clarify this point: the main reason you would use the binary encoding is to increase the service throughput, as discussed in the previous section. The decrease in message size is a nice side-effect, but let’s face it: you can accomplish the same effect by turning on compression on the HTTP level.

This test was far less comprehensive than the previous one and we did it ad-hoc on my co-worker’s office machine. We took various objects inside a Silverlight control, and turned them into the same kind of SOAP messages that get sent to the service. We did this using the plain-text encoding and using binary encoding and then we compared the size of the messages in bytes. Here are our results:

The takeaway here is that the reduction of message size depends on the nature of the payload: sending large instances of system types (for example a long String) will result in a modest reduction, but the largest gains occur when complex object graphs are being encoded (for example objects with many members, or arrays).

What does this mean to you? If you run a web service and you pay your ISP for the traffic your service generates, using binary encoding will reduce the size of messages on the wire, and hopefully lower your bandwidth bills as traffic to your service increases.

Conclusion

We are confident that binary encoding is the right choice for most backend WCF service scenarios: you should never see a regression over text encoding when it comes to server throughput or message size; hopefully you will see performance gains in most cases. This is why the binary encoder is the new default in the Silverlight-enabled WCF Service item template in Visual Studio.

An important note: binary encoding is only supported by WCF services and clients, and so it is not the right choice if you aren’t using WCF end-to-end. If your service needs to be accessed by non-WCF clients, using binary encoding may not be possible. The binary AMF encoding used by Adobe Flex is similarly restricted to services that support it.

Check us out at TechEd North America 2009

.NET Connected Framework Team — Mon, 20 Apr 2009 10:35:21 GMT

Cross-posted from the Silverlight Web Services Team blog.

I hope you enjoy the content we post on this blog. I’ll be giving a talk at the upcoming TechEd conference in LA, going through some Silverlight 3 content similar to what we have been posting here. If you’re attending TechEd, check out:

SOA03-INT Interacting with Web Services Using Microsoft Silverlight

Yavor Georgiev
Tue 5/12 | 4:30 PM-5:45 PM | Blue Theater 2
300 - Advanced, Middle Tier Platform and Tools, SOA and Business Processes, TLC Interactive Theater

Learn how easy it is to utilize POX, REST, RSS, ATOM, JSON, and SOAP services in your Silverlight 2 mash-up application. Hear best practices for developing and consuming secure services within and across domain boundaries. Experience new features in the upcoming Silverlight 3 release including optimized binary communication format, improved support for server- to-client "push" scenarios and new security features.

If you have not registered, you still have the opportunity to do so:

If you do attend, make sure you let me know you’re a reader of our blog… I’d love to hear any feedback you have.

Cheers,
-Yavor

Hosting WCF Services in Windows Azure

.NET Connected Framework Team — Wed, 08 Apr 2009 02:30:00 GMT

Hi folks,

Windows Azure is Microsoft's cloud services operating system, based on Windows Server 2008 and .Net Framework 3.5 SP1. Azure is currently in a Community Technology Preview stage and you can register and try it out for free on this page.

Many of you may have wondered what is the experience of hosting WCF services in the Azure cloud. We have created a full set of samples on our newly launched Code Gallery site:

WCF Azure Samples

The samples show hosting WCF services for use by Silverlight clients and ASP.NET AJAX clients, as well as REST WCF services built using the new WCF REST Starter Kit.

You may also find some useful workarounds on the WCF known issues page.

Cheers,
-Yavor Georgiev
Program Manager, Connected Framework Team

What's new with web services in Silverlight 3 Beta

.NET Connected Framework Team — Fri, 20 Mar 2009 23:09:00 GMT

Cross-posted from the Silverlight Web Services Team Blog.

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.

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, Connected Framework team

"Paste XML as Types" in REST Starter Kit

.NET Connected Framework Team — Mon, 16 Mar 2009 23:53:00 GMT

Cross-posted from the Silverlight Web Services Team Blog.

Just a quick announcement here of a release that will be interesting to Silverlight developers who want to access REST services. The WCF REST Starter Kit Preview 2 is now out, go grab it at http://msdn.com/wcf/rest. The release gives you a polished install/uninstall experience, so don't be afraid to try it on your box, it won't muck it up like "preview" software so frequently does.

This release gives you one interesting client-side feature that you may have heard me or Eugene speak about: Paste XML as Types. It's a VS menu item which helps you use XmlSerializer with REST services. Frequently these services use human-readable documentation to describe the XML shape, and it is difficult to hand-code a type to use with XmlSerializer, especially when the XML instance is complex. For example check out this sample XML response from the Yahoo BOSS API. With this new feature it takes one click to generate the type:

Another interesting feature in the release is HttpClient - a sort of specialized WebClient - which can be used to programmatically access REST services using an extensible model for sending HTTP requests and processing HTTP responses. The model enables you to complete common HTTP/REST development activities required to consume an existing service in a fraction of the time you normally spend. Some convenient time-savers include query string support (build URIs as name/value pairs) and serialization support (easily plug in types generated with Paste XML as Types to read the response).

Unfortunately in this release the starter kit only contains a .Net version of HttpClient, which will not compile in Silverlight. We are considering porting this prototype to Silverilght, and if you get a chance to try it on .Net, please let us know of any feedback you have.

Cheers,
Yavor Georgiev, Program Manager
Connected Framework Team

WCF Support in Silverlight 2

.NET Connected Framework Team — Mon, 09 Mar 2009 10:59:00 GMT

WCF services can be accessed by a variety of clients, and this post will talk briefly about accessing services from Silverlight. The same familiar programming model applies to Silverlight as any WCF client application.

The first step in developing Silverlight clients is to set up a development environment. If you already have Visual Studio 2008 SP1 on the box, all that is needed is to install the Microsoft Silverlight Tools for Visual Studio 2008, available on this page (among other resources). The package will install the Silverlight runtime (the piece required to run Silverlight apps in the browser), the Silverlight SDK (the libraries and tools needed to build apps), and the Visual Studio project templates and other supporting features.

To create your first WCF service and Silverlight client combination, follow the steps in this set of documentation topics. Note that only certain WCF bindings and features are supported in Silverlight, and you can consult this page for a full description.

A common pitfall for developers new to Silverlight is the cross-domain restriction in the networking stack. For security reasons, if the WCF service and Silverlight client live on different domains (for example http://fabrikam.com/service.svc and http://contoso.com/mysilverlightcontrol.html), the service domain needs to use a cross-domain policy file to explicitly opt in to be accessible by Silverlight clients (for example http://fabrikam.com/clientaccesspolicy.xml). For a description of the cross-domain restriction, see this topic. For an example cross-domain policy file, see this topic.

If you get stuck at any point in the process so far, this article explains how to easily debug the service-client pair.

After you have built your first Silverlight WCF solution, you can move on to some advanced scenarios. Here is a list of areas you may wish to explore:

Duplex communication - WCF services can "push" data to Silverlight clients, without the user having to manually poll the service. This is also known as a "notification" communication pattern, as opposed to a "request/reply" pattern. This topic walks you through implementing this scenario. The programming model for duplex services is rather complex, so our team has implemented a code sample which hides away some of that complexity. Check out the "Duplex Services" section of this blog post for more information and a link to the sample. In the next version of Silverlight, a greatly simplified duplex programming model is being considered.
REST services - this class of web services uses light-weight wire formats (such as plain XML or JSON) and clear URI conventions for a simple experience consuming services. This set of topics highlights how WCF in Silverlight can be used to access REST services.

Here are some good resources for follow-up:

Silverlight web services documentation - content from this resource was already referred to multiple times
Silverlight web services team blog
Silverlight web services code samples

Going forward, content from the Silverlight web services team blog (linked above) will be syndicated over here at the .NET Endpoint blog. Please keep an eye out for exciting new content coming up over the next month.

Yavor Georgiev
Program Manager
Connected Framework Team