WPF Remoting vs. Silverlight
It is an interesting coincidence that Microsoft released Silverlight 1.0 Beta, a browser plug-in that utilizes WPF to provide a rich user experience, shortly after releasing Longhorn Beta 3, which does not include WPF Remoting for Terminal Services. Given this, I think that it is worthwhile to discuss the similarities and differences between these two technologies (other than the fact that one exists and the other, at least currently, doesn’t),.
The similarity between the two is that both are Microsoft proprietary technologies enabling server-driven applications to provide a high-grade user experience using WPF. In both cases XAML is generated or stored on the server, then transmitted to and rendered on the client. In addition, while some event handling and validation can be performed on the client, the brunt of the business logic is performed on the server.
The are also numerous differences between the two technologies:
- Silverlight contains a custom implementation of WPF and the CLR. It utilizes this implementation regardless of the capabilities of the client device. TS WPF Remoting, on the other hand, is dependant on WPF support being built into the client. This means that Silverlight can work on devices that do not have .NET (it can even work on devices that don’t run Windows) but WPF Remoting is better integrated into the local desktop.
- Silverlight transmits XAML over HTTP or HTTPS while WPF Remoting transmits the XAML through an RDP virtual channel (which can be tunneled through HTPS if TS Gateway is used),. While both RDP and HTTP are built on TCP/IP, they are very different in nature. HTTP is a stateless protocol where a client sends a request for particular data and the server sends a response specifically for that request. RDP, on the other hand, is a more symmetric stateful protocol.
- Silverlight has powerful built-in video streaming capabilities. Streaming video has always been a weak spot for RDP and I do not know if WPF Remoting address this weakness in any way.
Based these differences, in particular #2 and #3, it appears that despite relying on the same WPF/CLR technology WPF Remoting and Silverlight espouse very different usage patterns. Silverlight naturally follows the Web 2.0 pattern of handling as much user interaction as possible in the client, and requesting more data from the server only when it is required. Session context is also based on the client state. WPF Remoting is an extension of RDP, and as such it is the server that does almost all of the heavy lifting with the client primarily just doing the rendering.
While the approach used by Silverlight has the benefit of generally being more scalable, it is also more complicated to use than WPF Remoting. Creating Web 2.0 Ajax applications, with or without Silverlight, is certainly more difficult than developing a standalone WPF application. Given this I believe both approaches have merit, and I remain hopeful that Microsoft will eventually give WPF Remoting a chance.