Silverlight 2.0 Service Integration: Three Steps Forward, Two Steps Back

Rick G. Garibay - The more I learn, the less I kno — Fri, 07 Mar 2008 16:30:19 GMT

Every time a brand new technology comes out, the focus is always on the problems that it is specifically designed to solve. Beneath the patina of a sexy new technology are the result of compromises that had to be made for which very mature, sophisticated stories already exist.

Such is the case, in my opinion with Silverlight 2.0. While the new version boasts some significant improvements with new controls, improved designer tool support and richer FCL support, the integration story is still a bit weak. Although there are some very important key improvements since 1.1, including WCF support (which is limited as we'll see later), there are some aspects of integration that are confusing, if not downright frustrating.

WCF SOAP Support

Silverlight 2.0 now supports Windows Communication Foundation, and allows you to add a reference to a service endpoint using the same convention for any client. Unfortunately, the only binding currently supported for working with SOAP services is BasicHttpBinding. While embracing WS-I Basic Profile 1.0 is great from a standardization perspective, it is unfortunate that some of the WS-* features that I have come to take for granted including WS-AtomicTransactions and WS-Reliable Messaging are neither supported, nor officially planned for support. I am confident that this is coming; it is just not high enough on the team's product backlog.

What did very much interest me is that only asynchronous invocation of WCF proxies is supported. This is interesting to me on two levels. First, because Silverlight CLR runs on the browser thread, the team was rightfully concerned with long running synchronous calls that would essentially block the UI thread. However, when I asked the Product Manager leading the talk if the threads for doing background work come from the thread pool or are marshaled back and forth from the browser to native threads, he wasn't sure. This leads me to the second interesting point which is this. If Microsoft is prescribing an asynchronous programming model for WCF because it simply has an opportunity to do so, then I half-heartedly applaud them for doing so if it due to architectural limitation of Silverlight. What I mean is that I think it is time for all architects and developers to think more about pub-sub, and if this is Microsoft putting a stake in the ground, then that is fine, but you should still give developers the option to go synchronous. I'd be interested in anyone's thoughts on this because it is a bit irksome:

var proxy = new ShoppingServiceClient();
proxy.GetProductsCompleted += new EventHandler<GetProductsCompletedEventArgs>(proxy_GetProductsCompleted);

proxy.GetProductsAsync(“book”);

void proxy_GetProductsCompleted(object sender, GetProductsCompletedEventArgs e)
{
// Process response…
}

From an encoding perspective, WCF support is strictly SOAP based which makes sense. However, keep in mind that in Silverlight 1.1, JSON was the first-class seralization format and this is a clear departure from that. Again, this begs the question as to whether the choice to support SOAP natively was intentional, or a direct result of providing a WCF integration story. To be honest, JSON doens't make sense in pure Silverlight scenarios because there is no JavaScript interop happening. It’s all Silverlight CLR. That said, there are some significant performance benefits to JSON which leaves me guessing as to whether it will be supported as an alternative WCF encoding in the future.

Unfortunately, Faults are not supported, and I don't really understand why.

HTTP & REST Support

I have some opinions on REST that are probably quite bellicose, so I will save them for another post. That said, Silverlight 2.0 does support basic HTTP invocation via GET and POST for low-REST scenarios. The weapon of choice for "Human Readable Documentation" services is a class called WebClient in the System.Net namespace which basically takes a URL and returns a response. While there is no hard and fast rule about what a REST service provides, assuming that it is XML you can use XMLReader and XMLWriter along with Linq to XML to work with XML results. Now, if you are really a contortionist, are using REST and want serialization support, you can of course build out your entities to map to the XML coming back and deserialize the response stream using XmlSerializer, but I just don't understand why you would go through all this trouble when SOAP tooling does it all for you. OK, I slipped. I couldn't help myself, sorry.

Sockets/TCP Support

Scott Guthrie makes mention of support for sockets on his blog (http://weblogs.asp.net/scottgu/archive/2008/02/22/first-look-at-silverlight-2.aspx ), but this wasn't covered at any of the sessions I attended.

Security

This was the most vague aspect of the sessions I attended because the focus was not on authentication or authorization, but rather on a flavor of code access security that determines whether a service can be called from a client from another domain and vice-a-versa.

There was mention that if you enable ASP.NET Compatibility in your WCF service, you can glean the identity of the user running the browser via the canonical HttpContext.CurrentUser property, but it was unclear to me if the browser identity is that of the user logged in to the machine, what the implications of enabling/disabling Integrated Windows Authentication on IE browsers, and how this would work with non-IE browsers.

This is important to me from a resource access perspective. If I am using Silverlight to communicate with a service that isn't just wide open, I am going to want to perform some authorization to ensure that at the very least, I can support a trusted subsystem model, because I don't want to deal with n potential users.

Summary

To wrap up, I think there are exciting things to come with Silverlight 2.0, and I think it is going to challenge many of us to think about how we integrate with the cloud. I see a trade-off, if not a gamble happening between SOAP and REST within the Silverlight team, and the winner may depend on which standard is considered the most "weby". This concerns me because of how fickle the web can be, and I'd hate to see the tremendous gains made around integration and SOA, particularly with WCF, get lost in the hype. In the end, I think that this one will be ultimately decided by the constituents that make up this new landscape of information democratization known as Web 2.x.

.NET 3.5 (Rosario) November Ship Date Announced

Rick G. Garibay - The more I learn, the less I kno — Thu, 08 Nov 2007 18:30:08 GMT

This press release discusses plans announced by S. Somasegar to release .NET 3.5 and Visual Studio 2008 in November. In fact, last I heard the bits are essentially RTM and ready to go unless any last minute defects are found.

You can read more about this here: http://www.microsoft.com/presspass/press/2007/nov07/11-05TechEdDevelopersPR.mspx

Last year I talked about the .NET 3.0 release and how it affected the world. So what does 3.5 really mean?

From a Visual Studio perspective, it means designer support for WF, WCF and WPF, similar to what you get today in VS 2005 with the Orcas Extensions but obviously polished up quite a bit with new improvements.

From a framework perspective, Microsoft is staying true to its "red bits, green bits" approach to ensuring that red bits remain compatible with green bits. Red bits are the components and CLR we know and love today: .NET 2.0, .NET 3.0 and the 50727 build of the 2.0 CLR.

.NET 3.5 introduces new green bits for new features like LINQ and WMI, but they are all additive. This means that there are no core CLR changes save for optimizations and any defect corrections. Depending on your OS (Win XP, Vista, etc) you will notice distinct revision numbers, but this should otherwise be transparent as this is already the case today.

There are a number of new assemblies that make up the green bits. Specifically, the following assemblies are shipping in 3.5 (Moth 2007):

1. System.Data.Linq.dll – The implementation for LINQ to SQL.

2. System.Xml.Linq.dll – The implementation for LINQ to XML.

3. System.AddIn.dll, System.AddIn.Contract.dll – New AddIn (plug-in) model.

4. System.Net.dll – Peer to Peer APIs.

5. System.DirectoryServices.AccountManagement.dll – Wrapper for Active Directory APIs.

6. System.Management.Instrumentation.dll – WMI 2.0 managed provider (combined with System.Management namespace in System.Core.dll).

7. System.WorkflowServices.dll and System.ServiceModel.Web.dll – WF and WCF enhancements (for more on WF + WCF in v3.5 follow links from here).

8. System.Web.Extensions.dll – The implementation for ASP.NET AJAX (for more web enhancements, follow links from here) plus also the implementation of Client Application Services and the three ASP.NET 3.5 controls.

9. System.Core.dll – In addition to the LINQ to Objects implementation, this assembly includes the following: HashSet, TimeZoneInfo, Pipes, ReaderWriteLockSlim, System.Security.*, System.Diagnostics.Eventing.* and System.Diagnostics.PerformanceData.

10. System.Data.DataSetExtensions.dll – The implementation of LINQ to DataSet.

11. System.Windows.Presentation.dll –WPF support for the System.AddIn mentioned of point 3 above.

12. System.VisualC.STLCLR.dll – STL development in the managed world.

Additional References: http://blogs.msdn.com/somasegar/archive/2006/05/18/601354.aspx, http://www.danielmoth.com/Blog/2007/05/clr-v20-remains-at-same-version.html

Anytime a new framework release is announced, there is usually some natural anxiety and confusion that precedes it. Hopefully this post puts this release in perspective and highlight's Microsoft's continued commitment to backward compatability without stifling innovation.