Silverlight et des notifications push

De notification Push est pris en charge dans Silverlight 2 à l'aide de la nouvelle WCF PollingDuplexHttpBinding de soutien. Il y a deux assemblées installé avec le kit de développement Silverlight (un pour application Silverlight pour un serveur WCF).

J'ai un quelques articles de blog et un exemple d'application qui montrent comment "pousser" mises à jour des Stocks à partir d'une Console de serveur d'Applications que l'auto-héberge un service WCF pour les clients connectés. Il montre également comment chaque client peut ajouter des notes à l'encontre d'un Stock et d'avoir ces notes synchronisées (poussé à partir du serveur) pour tous les autres clients connectés.

La dernière version de l'échantillon (Partie 4) montre comment synchroniser poussé les mises à jour entre Silverlight et WPF clients à l'aide de deux points de terminaison de serveur comme suit:

using System;
using System.ServiceModel;
using System.ServiceModel.Description;

namespace StockServer
{
    public class StockServiceHost : ServiceHost
    {
        public StockServiceHost(object singletonInstance, params Uri[] baseAddresses)
            : base(singletonInstance, baseAddresses)
        {
        }

        public StockServiceHost(Type serviceType, params Uri[] baseAddresses)
            : base(serviceType, baseAddresses)
        {
        }

        protected override void InitializeRuntime()
        {
            this.AddServiceEndpoint(
                typeof(IPolicyProvider),
                new WebHttpBinding(),
                new Uri("http://localhost:10201/")).Behaviors.Add(new WebHttpBehavior());

            this.AddServiceEndpoint(
                typeof(IStockService),
                new PollingDuplexHttpBinding(),
                new Uri("http://localhost:10201/SilverlightStockService"));

            this.AddServiceEndpoint(
                typeof(IStockService),
                new WSDualHttpBinding(WSDualHttpSecurityMode.None),
                new Uri("http://localhost:10201/WpfStockService"));

            base.InitializeRuntime();
        }
    }
}

WPF clients de se connecter à la WSDualHttpBinding d'extrémité et Silverlight clients de se connecter à la PollingDuplexHttpBinding point de terminaison du même service WCF. L'application montre comment gérer le client Silverlight l'accès des exigences de la politique.

Clients (Silverlight ou WPF) pouvez ajouter des notes à l'encontre d'un Stock dans leur INTERFACE utilisateur et ces notes se propager vers le serveur pour être poussé à tous les autres clients. Cela démontre de la communication dans les deux sens et nous espérons que joue la communication nécessaire requis pour votre application.

Vous pouvez voir une capture d'écran de la démo de l'application en cours d'exécution ici.

Je voulais juste préciser que le PollingDuplexHttpBinding ne pas mettre en œuvre le "vrai" notifications push, comme le révèle son nom (d'interrogation). À partir de la la documentation msdn:

Lorsqu'il est configuré avec cette liaison, le client Silverlight périodiquement des sondages le service de la couche réseau, et vérifie l'arrivée de nouveaux messages que le service souhaite envoyer sur le rappel de canal. Les files d'attente de service de tous les messages envoyés sur le rappel de client canal et les fournit au client lorsque le client interroge le service.

Cependant, il est plus efficace que la méthode traditionnelle de l'interrogation d'un service web, puisque, après chaque scrutin, le serveur va garder le canal ouvert pendant un certain temps (disons 1 minute), et si un message arrive en ce moment, il va directement à "pousser" le message au client. Le client a à plusieurs reprises renouveler sa connexion, il donc dire que les sondages le service.

Si vous souhaitez mettre en œuvre de véritables notifications push avec silverlight je crois que vous avez besoin de travailler avec des sockets, et je vous recommande la lecture de certains de Dan Wahlin blog posts sur le sujet.

EDIT: ça fonctionne réellement bien. J'ai eu mal mordu par la "variable cachée" dans une closure 🙁

J'ai utilisé le PollingDuplex pour SL2 et je pense qu'il n'est pas prêt pour la production de encore.

Mon principal problème est le fait qu'il ne fait pas de discrimination sur les clients sur la même machine. Si je run 2 clients, puis l'un d'eux ne sera pas en mesure d'interroger le serveur plus et va mourir de délai d'attente. Il y a un id de session qui est différent pour les 2 clients, mais c'est tout simplement ignorés sur le côté client.

De même, si je tue un client, puis en créer une nouvelle par la suite, puis le nouveau client obtiendra la pousser les mises à jour du client précédent pour un certain temps.

Quelqu'un rencontre les mêmes problèmes ou sont-ils résolus dans SL3?

En fait, j'ai couru quelques plus de demo codes et réalisé que pour une raison quelconque, vous devez spécifier le InstanceContextMode et InstanceMode afin que le service est basée sur la session et pas un singleton (autant que je puisse en dire). Il y a clairement des problèmes de performances dans la simple démonstration de code que j'ai tiré.

Il est tout à fait regrettable que ce comportement n'était pas documenté.

La PollingDuplexHttpBinding est probablement la façon la plus élégante de le faire.

Un possilby moins impliqués alternative est d'utiliser une socket TCP à partir de votre client Silverlight. Chaque fois que l'un des clients de Silverlight doit avoir une mise à jour poussé, vous pouvez envoyer un message TCP qui contient le nom de la WCF service qu'il doit appeler ou certains autres poids léger morceau de l'information.

- Je utiliser cette approche pour une application et il fonctionne bien.