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.