rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 300, comments - 180, trackbacks - 35

My Links

News

Archives

Post Categories

Published Works

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

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.

 

 

Print | posted on Friday, March 07, 2008 9:30 AM | Filed Under [ WCF Misc. .NET 3.5 ]

Feedback

Gravatar

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

> "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."

> "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."

> "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."

Silverlight's HttpWebRequest (which is used by webservices) is built on top of the browser's networking API. This API is fairly limited, which unfortunately means Silverlight inherits those limitations. One of those limitations is that the browser's networking API only supports asynchronous operations.

To work around these limitations, Silverlight would need to use the OS' networking stack directly. This would have several advantages (we're no longer limited by what the browser provides), but one of the disadvantages is that we'd no longer be automatically sharing the browser's security context, etc. (Note that this is also the answer to the last quote above - requests from HttpWebRequest should basically be identical from a security pov. to ordinary page requests. In other words, if you logged in using forms authentication or windows authentication, then requests sent via HttpWebRequest should also be correctly authenticated - no matter what browser you're using.)

As for the threading question: this is all taken care of by the browser as well. All we "know" is that we can only invoke requests on the UI thread, and the callbacks will always be invoked on the UI thread as well. (Internally the browser may be firing a synchronous request on a separate thread, or use IOCPs, or whatever. As long as it invokes callbacks on the UI thread, which is part of the contract.)

> "Sockets/TCP Support"

No idea why there weren't any sessions on this, but FWIW, socket support is available in Silverlight 2. Again, there are a few limitations (you can only connect to sockets - you can't listen on a port yourself, and you can only connect to ports in a certain range), but besides that it should be fairly straightforward to use. If you have any specific questions or asks, please share those.

Hope this helps.
3/7/2008 7:33 PM | Wilco Bauwer
Gravatar

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

Wilco, my man!

Thanks for the comments. I thought of you while at MIX this year. Did you make the journey this time around?

And by the way, your manager needs to promote you (at least) to Senior SDE- your messaging is very effective and highly relevant, both in person and in writing. Please feel free to reference this during your next review :-)

Keep in touch bud,

Rick

For anyone reading this that wants to connect with someone who has the answers to the really deep Silverlight, CLR and ASP.NET questions, check out his blog: http://www.wilcob.com/Wilco/Default.aspx

3/14/2008 10:37 PM | Rick
Gravatar

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

I can't believe that Silverlight, in it's WCF-native implementation, won't support Faults. I mean, faults are a detail of SOAP, so if you're going to support SOAP, you'd better do it better than halfway. I wonder what the rationale behind this is?
3/25/2008 10:57 AM | David Barrett
Gravatar

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

At least the net # of steps gained is 1 :-)
4/4/2008 9:29 AM | Ryan Haney
Comments have been closed on this topic.

Powered by: