Silverlight 2 introduces the ability to “push” data to the client with helper client and server duplex objects and with it opens doors to a much more responsive, scalable world of web applications.
Before Silverlight duplex, God made COMET. You can read more about COMET elsewhere but the important thing to note is that COMET has shortcomings. Because COMET was built on top of existing web technologies rather than designed from the ground up, it suffers problems with firewalls, proxy servers, & of course: browser compatibility. I’m not an expert in COMET technologies nor do I intend to knock it, but Silverlight solves these problems AND makes it a hell of of lot easier for programmers to implement pushing techniques from the server. Note: Microsoft WCF technology has introduced a number of other technologies that have made it more than possible to support push-style behavior for Windows applications already. The new thing here is that you can now do it in a cross platform web app.
Push vs. Pull. Of course there’s always the good ‘ol pull method where the client continues to ask the server if there’s anything new it should tell you about. This works well for scenarios where the server has something to tell the client about most of the time. For example, if the client needed to know what the stats of the ongoing Packers game is, it would be reasonable to just have the client check on a regular basis because you can almost assume that every minute something has changed. But what if the client needed to check if you had a new voice mail? Unless you’re far more popular than I am, 99% of the time that the client would check the server, nothing would different. In this scenario, a push would be a much better choice. Why?
Because it keeps your server scalable. If you have hundreds or thousands of clients all asking your server “is there anything new yet?” every minute, your server is going to be busy. And in scenarios where very little actually changes, it’s all unnecessary work. So give your server a break and let it tell the client when there’s actually something to say. Don’t call me; I’ll call you.
And its fast.There is no faster way for your client to get messages from the server. If you pull the server, you have to configure the client to pull every x seconds or minutes. This means that if something changes on the server right after you checked last, you have to wait until nest time. It’s like when you miss the mail man. Now you’ll have to wait until tomorrow to send that letter. And depending on how important the information is, the ability to tell the client virtually instantly could be a big deal.
We’ve got a problem Houston.With inventions like AJAX & RIAs, more and more web apps are shifting the burden from the server to the client and reducing round trips to the server. However, the drawback is its more likely that the client’s scope will increase and the client will be less likely to get updates from the server. Imagine you had a web page that showed you a list of contacts and allowed to edit info about each. In the old days with frequent round trips, you practically couldn’t do anything without a round trip and therefore a new version of that web page. The bonus was that if a new contact was added to the database, you’d suddenly see the new contact. But now, without extra work on the programmers part, the user is not likely to know about that new contact unless the users clicks back and next to reload the page.
The need isn’t special case. Almost all apps could benefit from push techniques. Not just chat clients and monitoring apps. Does your app support collaboration where another user can change the data they are looking at? In fact, any app where what the user sees information that could conceivably change could use this technique.
Programmers need to push changes to the client and it has to be easy to implement or the quality of our apps will suffer. Fortunately, the Silverlight 2 duplex features accomplish both of these objectives. So lets be good programmers and use these tools to help transform the web into a more scalable, responsive, place. They call it progress.
Programmer Payback 
tgreenfield,
I agree with this and am trying to implement it in a web application. But it is not clear to me how the server end of the duplex service can monitor the database. For instance, if there are 5 users connected to the app, and one of them creates a new “Product” which gets published to the database, this would mean that the server end of the app would have to monitor the database for any updates/changes to push out to the other 4 clients. Or am I thinking incorrectly here? The only other option I could see would be to have the server end of the duplex service register the updated “Product” independently of the database update, and just push it out to the other 4 clients as it is updated. Basically, what I am wondering overall is: Is it possible for the server end of the duplex service to have real time monitoring of the database changes, or does this need to be handled separately?
Good question Robert, When the request comes in to update the database, you could first write to the DB and then just broadcast that change back out to the other clients right from your web service that handled the request. Note: you would need to store all the client connection sessions in a shared variable or the Session object. That way your request handler would have access to them.
You would need to ensure that any changes to your database would need to go thru this single web service or they’d be missed. Of course it might be good practice anyway to restrict the db updates to a single gateway.
Another way if you’re using MS SQL (which I haven’t tried yet) is to create a trigger that calls out to a web service to broadcast the changes out to all connected clients.
Do you have any examples of doing true push behavior in silverlight?
Speak is easy, hard is to do. To use WCF to notify clientes is really confusing and hard and how WCF usually is asynchronous you never know if user changed the interface (made a new query for example) that WCF return isn’t necessary. I’m trying tell you that there is another ways but COMET is a more easy to implement, to maintainence and to understand.
I see a lot of people talking about “Another ways to get real-time clientes” but nobody don’t post any piece of code