Silverlight Web Services Team

PollingDuplex scaling in Windows Azure

SLWSTeam — Tue, 24 Nov 2009 19:58:58 GMT

One of the great sessions at this year’s PDC talked about a collaboration between Invensys and Microsoft’s DPE team to build a solution that can deliver energy pricing information to a variety of clients, using a duplex message pattern.

Effectively Invensys used a WCF service hosted in a Windows Azure web role to tunnel bi-directional HTTP traffic from the Windows Azure platform AppFabric service bus capability to Silverlight clients. Unfortunately this workaround is needed since the TCP-based relay binding that service bus offers is not supported in Silverlight at this point.

Once Invensys was using PollingDuplex in Azure, they needed to scale to a large number of clients, so they needed to enable scale out between multiple web role instances. This capability is not available out-of-the-box in Silverlight 3, so some hackery was required, as described in these blog posts:

The relevant content starts at around minute 38 in the video below.

While getting PollingDuplex to scale in Azure in Silverlight 3 requires some manual steps, the team is considering supporting this scenario out-of-the-box in Silverlight 4. It is not available in Silverlight 4 Beta, but please use the comments to submit your feedback.

Thanks,
Yavor Georgiev
Program Manager

WCF net.tcp protocol in Silverlight 4 Beta

SLWSTeam — Wed, 18 Nov 2009 20:55:47 GMT

Support for the WCF net.tcp protocol is the key feature addition in the core of WCF offering in Silverlight 4 Beta.

Read more about the benefits and limitations of the net.tcp protocol in Silverlight 4 to decide if it is a good fit for your application. You can also check out a walk-through of adding net.tcp support to a pub\sub Silverlight application or inspect the code of the sample to get a better idea of what’s involved in creating an end to end solution using net.tcp in Silverlight.

Tomasz Janczuk
Development Manager
WCF Team

New Web Services Features in Silverlight 4 Beta

SLWSTeam — Wed, 18 Nov 2009 18:43:00 GMT

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

Adoption of Silverlight serialization and communication technologies in web applications – October 2009

SLWSTeam — Fri, 16 Oct 2009 20:47:55 GMT

We have repeated the research of the adoption of communication and serialization technologies in Silverlight applications that was originally done in February 2009. The new report is based on a research done in October 2009 and will give you an idea of the changing preferences of Silverlight developers. Enjoy and let us know what you think.

Tomasz Janczuk
Development Manager
WCF Team

Having a PollingDuplex service and any other WCF service in the same website causes Silverlight calls to be slow

SLWSTeam — Wed, 30 Sep 2009 23:50:00 GMT

After polling duplex support for WCF was released in Silverlight 2 (http://msdn.microsoft.com/en-us/library/dd470105(VS.95).aspx), some customers reported the issue that when a polling duplex service co-exists with normal WCF service on the same IIS web application, the WCF service might be significantly slowed sometimes.

In this post we will show you the process the team followed to resolve the issue. Hopefully you will find this useful in debugging your own SL apps when you encounter a problem. Please see the end of the post for the solution.

The first thing we have to do is to create some code that reproduces the issue. After contacting customers to get there scenarios and settings, we are able to create a test Silverlight application and ASP.Net web application that consistently reproduce this issue (see attached probject). Our test application has two client proxies, one polling duplex based stock ticker and one normal BasicHttpBinding-based calculator. Once the xap is loaded, calculator proxy will start continuously calling the “Add” method of the calculator. The app also has a checkbox which will cause the stock ticker service to start sending periodic stock price updates to the SL client, so at this point the SL all will be using both the regular WCF service and the polling duplex service.

By doing some research we identified that the following features could be influencing the observed slow behavior:

· Using WCF’s ASP.Net Compatibility Mode

· Using ASP.Net sessions

· Selecting between the Silverlight BrowserHttp or ClientHttp stack

We then ran a series of tests to determine when we could observe the slowness reported by our customers.

	Browser Http	Client Http
ASP.Net compat mode enabled Session enabled.	Slow	Normal
ASP.Net compat mode enabled Session disabled	Normal	Normal
No ASP.Net compat	Normal	Normal

As it shows above, the slowdown of the WCF call happens when the services are hosted in ASP.Net compat mode AND when user enabled ASP.Net sessions. The ASP.Net session is enabled when your web application has a global.asax file and it contains a session_start method. It turns out when the ASP.Net session state is enabled, requests for the same session will be processed sequentially. So the calls to the responses for the regular WCF service will get queued up behind the long polls made to the polling duplex service.

Using Fiddler, we can capture the HTTP packages and see the mechanism that ASP.Net uses to enable the session. It is enabled by setting the ASP.NET_SessionId cookie from service side.

POST /PollingWcfServices/ServiceWcf.svc HTTP/1.1

Accept: */*

Content-Length: 564

Content-Type: application/soap+xml; charset=utf-8

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0

Host: foo

Connection: Keep-Alive

Pragma: no-cache

Cookie: ASP.NET_SessionId=iyr4sf55rm1kypafjdvlhm55

This is why the client stack can work around the concurrent requests issue. By default when you use client stack, cookies are not automatically maintained between requests so the cookie set on the server is not returned in the subsequent request. Without the cookie ASP.Net doesn’t know which session to lock and it doesn’t lock it.

To work around the slowness, the user can switch to using the client stack to access both services. If the user wants to take advantage of ASP.Net sessions for the regular WCF service, they can use the browser stack for the regular service and the client stack for the polling duplex service. Currently the polling duplex service cannot be used with the browser stack if ASP.Net sessions are enabled. Here is the documentation page on how to register the browser or client stack for a given service.

All WCF services require read/write session state access if you enable ASP.Net sessions, which causes the replies to be queued sequentially. Ideally user should be able configure the WCF handler to be read only, which would allow polling duplex services to work with sessions. Unfortunately this is unsupported at this point.

Instruction for running the sample

1. Run Visual Studio as administrator

2. Enable anonymous authentication on the web application created by the project

Scale-out of Silverlight HTTP polling duplex WCF service in a web farm scenario

SLWSTeam — Thu, 17 Sep 2009 04:08:20 GMT

The recent post about performance of Silverlight HTTP polling duplex protocol pointed out scalability challenges associated with deploying a WCF service using the protocol in a web farm scenario. This follow up article introduces one possible solution to the scale-out problem, enabling applications utilizing the protocol to accommodate an arbitrary number of concurrent clients through scale-out of the backend infrastructure.

Let us know what you think!

Tomasz Janczuk
Development Manager
WCF Team

Channel9 WCF duplex demo

SLWSTeam — Thu, 27 Aug 2009 10:30:56 GMT

Recently I spent some time with Robert Hess over at Channel9 discussing Silverlight 3 and giving a short demo of our duplex binding. If you haven’t seen PollingDuplex in action, this might be of interest.

Cheers,
-Yavor Georgiev
Program Manager, Connected Framework

Using web service faults with the new SL3 client HTTP stack

SLWSTeam — Mon, 17 Aug 2009 20:31:42 GMT

Carlos, one of our team members, has posted an quick blog post on how to use SOAP faults with the new client HTTP stack, introduced in SL3. This makes configuring faults significantly easier: there is no need to write custom code in your WCF service, and all you need to do is add one line of code to the Silverlight client.

Enjoy!

-Yavor Georgiev
Program Manager

AJAX client for HTTP polling duplex WCF channel in Microsoft Silverlight 3

SLWSTeam — Thu, 06 Aug 2009 03:33:10 GMT

If you are interested in coding an AJAX client application that consumes asynchronous data notifications from a WCF backend service using the Microsoft Silverlight 3 HTTP polling duplex channel, check out the AJAX client for HTTP polling duplex sample. It contains a JavaScript library with client side implementation of the polling duplex protocol implemented in the PollingDuplexHttpBinding from Microsoft Silverlight 3. It has been tested with Internet Explorer 8, Firefox 3.5, and Chrome 2.0. Let us know what you think.

Tomasz Janczuk
Development Manager
WCF Team

Pub/sub sample using HTTP polling duplex WCF channel in Microsoft Silverlight 3

SLWSTeam — Sat, 25 Jul 2009 03:26:31 GMT

We now have a sample implementation of a pub/sub scenario that uses the HTTP polling duplex WCF channel shipped in Silverlight 3. The sample demonstrates some of the best practices for implementing performance-conscious duplex scenarios using the PollingDuplexHttpBinding, as well as the usability benefits of duplex WCF proxies generated using the Add Service Reference feature of Visual Studio in Silverlight 3. Check out the full description of the polling duplex sample and access the source code, then let us know what you think.

Tomasz Janczuk
Development Manager
WCF Team

Adoption of WCF technologies in Silverlight 2 applications on the web

SLWSTeam — Fri, 10 Jul 2009 02:32:46 GMT

If you are interested in what communication and serialization technologies are being used by others in Silverlight 2 applications, check out the post at http://tomasz.janczuk.org/2009/07/adoption-of-wcf-technologies-in.html. It is a summary of a research of over 700 actual Silverlight 2 applications conducted in February 2009. It compares the adoption numbers of several communication and serialization technologies, including WCF, in Silverlight 2 applications as well as provides basic analysis of backend service technology.

Tomasz Janczuk
Development Manager
WCF Team

Improving the performance of web services in SL3 Beta

SLWSTeam — Mon, 08 Jun 2009 06:30:04 GMT

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

SLWSTeam — Mon, 20 Apr 2009 10:32:01 GMT

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

Using WCF services from Silverlight in Azure

SLWSTeam — Thu, 09 Apr 2009 02:15:00 GMT

With all the buzz around Windows Azure, you may have wondered how to host your Silverlight application in the cloud. Since Silverlight controls are essentially static content, hosting them is as easy as uploading some files to the cloud.

When it comes to building WCF services to provide data to your Silverlight control, the story gets a little more complicated. The fact that the Azure cloud is a load-balanced environment as well as the deployment mechanism for setting up a service in Azure pose some unique challenges to hosting WCF services.

To help with this, our team has posted a Code Gallery site with 3 Silverlight-specific samples that you can run in the cloud and also on your local machine. The samples exercise the following features:

Sample #2: binary encoding
Sample #4: message credentials authentication over HTTPS
Sample #5: duplex (server “push”)

The third example hosts our chat sample in Azure for a massively-distributed free-for-all chat experience, and you can try it here. Try opening up this link across multiple machines and browsers and watch them all chat together.

Which brings me to probably the most useful thing we published: a list of known issues with hosting WCF services and Silverlight clients in Azure. Check out this page, and especially the sections “Hosting WCF Services” and “Hosting Silverlight Clients”. The page contains some workarounds we gathered from across the web, and is guaranteed to save you a bunch of head-scratching if you try WCF on Azure for yourself.

Cheers,
-Yavor

Some known issues in SL3 Beta

SLWSTeam — Mon, 06 Apr 2009 08:21:00 GMT

We've run across some issues with our web services features in the Silverlight 3 Beta and I want to share these here to hopefully save folks some time and frustration.

Issue: On Windows 7 Beta, you might encounter the following error when generating a proxy: "The element 'httpTransport' cannot contain child element 'extendedProtectionPolicy' because the parent element's content model is empty".

Workaround: On Windows 7, when you use the Silverlight-enabled WCF Service item template, an <extendedProtectionPolicy /> element may be generated in Web.config. This element is not supported by Silverlight. Simply remove the element from Web.config and try regenerating the Silverlight proxy.

Issue: If you use the Silverlight-enabled WCF Service template and you try generating a Silverlight proxy using Add Service Reference on a machine with both Silverlight 2 and Silverlight 3 Beta SDKs, you may get warnings at proxy generation time and errors at runtime. The warnings can include a variety of "Cusom tool" warnings which state that the endpoints found are "not compatible with Silverlight 2" or "No endpoints compatible with Silverlight 2 were found."

Workaround: If you are using Add Service Reference to generate proxies, side-by-side installation of the Silverlight 2 and Silverlight 3 Beta SDKs is not supported. Please uninstall the Silverlight 2 SDK to use Silverlight 3 features. After uninstalling, ensure that the assembly Microsoft.Silverlight.ServiceReference is not present in the machine GAC.

Issue: When using Add Service Reference to generate a proxy to a WCF duplex service (a service built with the System.ServiceModel.PollingDuplex.dll assembly provided in the Silverlight SDK), the generated proxy may not compile and may complain about a missing assembly reference.

Workaround: The proxy for the duplex service is generated correctly, however Add Service Reference will sometimes forget to reference th System.ServiceModel.PollingDuplex.dll assembly in the Silverlight client. Simply add a reference to the assembly (right-click in the Silverlight project, select Add Reference, find the assembly in the list on the .Net tab), and the proxy should now compile.

Hope this is helpful!
-Yavor Georgiev