Silverlight und Push-Benachrichtigungen

Question

Ich bin ein Silverlight 2-Benutzeroberfläche zu einem entfernten Gerät zu schaffen. Es gibt zwei gleichzeitige Benutzer an verschiedenen Standorten mit dem Instrument (Operator am Gerät und Remote-Wissenschaftler) interagieren und eine beliebige Anzahl von Benutzern Beobachter nicht mit ihm interagieren, nur beobachten. Jedes Mal, wenn einer der beiden aktiven Nutzer ändert sich etwas diese Veränderungen müssen sofort in der UIs aller Nutzer widerspiegeln, beispielsweise Schwenken oder ein Bild ein- oder mit Anmerkungen versehen oder einen Teil eines Bildes auszuwählen, in einem Listenfeld angezeigten Elemente zu einer Sammlung hinzugefügt wird. Im Client verwende ich beobachtbaren Sammlungen, die leicht Änderungen durch den Benutzer gemacht reflektieren, aber es ist schwieriger, seeing Änderungen von einem anderen Benutzer gemacht. Ich kann für Änderungen von jedem Client abzufragen, sondern so etwas wie Push-Benachrichtigungen wäre besser. Ich habe Beispiele ausführlich gegoogelt aber nichts gefunden, was recht ist, was ich brauche. Es gibt alle Arten von Sicherheitsproblemen mit Silverlight mit WCF-Diensten interagieren, die gerade viele potentielle Beispiele bedeuten nicht funktionieren. Ich habe im Wesentlichen aus der Zeit an diesem Projekt laufen und müssen schnell helfen. Hat jemand irgendwelche Vorschläge für ein geeignetes einfaches Beispiel, das zeigt, wie dies zu tun? Ich bin ein erfahrener Entwickler haben aber hatte mich Silverlight und WCF-Dienste zu lehren, und es ist niemand in meinem Bereich, der etwas über diese kennt. Auch tho‘ich einen fairen Betrag von ASP.NET Arbeit getan haben, bin ich nicht ein Web / Javascript-Guru. Danke.

Answer 1

Push-Benachrichtigung wird in Silverlight 2 mit der neuen WCF PollingDuplexHttpBinding Unterstützung unterstützt. Es gibt zwei mit der Silverlight-SDK installiert Baugruppen ( ein für Silverlight-Anwendung einer für WCF-Server ).

Ich habe einen Beiträge und eine vollständige Beispielanwendung , die zeigen, wie man ‚Push‘ Stock Updates von einer Konsole-Anwendungsserver, der sich selbst Hosts einen WCF-Dienst an die angeschlossenen Clients. Es zeigt auch, wie jeder Client Notizen gegen eine Vektor hinzufügen und haben diese Notizen synchronisiert (vom Server geschoben) auf alle anderen angeschlossenen Clients.

Die neueste Version der Probe (Teil 4) zeigt, wie geschoben Updates zwischen den beiden Silverlight und WPF Clients mit zwei Server-Endpunkte wie folgt synchronisieren:

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 eine Verbindung mit dem WSDualHttpBinding Endpunkt und Silverlight-Clients an den PollingDuplexHttpBinding Endpunkt der gleichen WCF-Dienst verbinden. Die App zeigt auch, wie die Silverlight-Client-Zugriffsrichtlinienanforderungen behandeln.

Clients (Silverlight oder WPF) können in ihrer UI Noten gegen eine Vektor hinzufügen und diese Notizen propagieren zurück an den Server an alle anderen Clients übertragen werden. Dies zeigt die Kommunikation in beide Richtungen und hoffentlich führt alle notwendigen Kommunikation für Ihre Anwendung erforderlich ist.

Sie können einen Screenshot der

Answer 2

Nicht die Flex in Fan Junge Mode bin drängen, aber sachlich ist dies die Art von Architektur, die wir routinemäßig in alle unsere Flex-basierten Anwendungen zu bauen. Hier ist, was wir auf Flex tun - kein Zweifel könnte es passend zu Silverlight übersetzt werden:

Wir nehmen drei Zutaten und integrieren sie zusammen, um diese Fähigkeit zu erreichen:

1. Comet Muster (eine HTTP-kompatible Art und Weise Server-Push-Benachrichtigungen zu tun - schaut auf Wikipedia für weitere Informationen)
2. JMS-Messaging-Themen (Publish / Subscriber-Queues)
3. Die Adobe BlazeDS Servlet

Dieser Artikel implementiert das Comet-Muster, unterstützt AMF Objekt Serialisieren (Adobe binäre Serialisierung Format für ActionScript3 Objekte) und Brücken in einer JMS-Warteschlange oder Thema. Wenn zu einem Thema überbrückt, dann mehrere Flex-Clients in einem Browser ausgeführt wird, können Sie sich als Teilnehmer an ein JMS-Thema proxied werden. Also, wenn jeder Client eine Nachricht veröffentlicht (oder der serverseitigen Code veröffentlicht in das Thema), alle Client-Abonnenten haben die Nachricht, um sie über BlazeDS und der Comet-Muster Implementierung geschoben.

Effektiv müssen Sie lokalisieren oder eine Komponente zu schreiben, das leistet, was BlazeDS tut. Sie könnten auch einig Client-Code implementieren müssen, die mit den Comet-Mustern dieser serverseitige Komponente in Wechselwirkung tritt.

Unterstützt WCF das Comet-Muster und bidirektionalen Messaging? Insbesondere entspricht, in dem auf HTTP und Port 80 oder Port 443 für SSL. Sieht aus wie Sie bereits in das geschaut haben und nichts für die bidirektionale Nachrichten gefunden. Sie müssen also können Sie die Ärmel hoch rollen und einige Codierung tun.

Einige Dinge über das Tun Server Push-to-Web-App zu beachten:

BlazeDS unterstützt zwei primäre Modi des Kometen Muster der Umsetzung (es gibt tatsächlich eine dritte Wahl Option, aber es würde zu ignorieren):

1. long-Abfrage
2. HTTP-Streaming

Die Lang Abfrage, die Sie finden sollen universell erträglich zu den meisten Web-Browsern sein. Sie könnten also, dass zunächst nur die Unterstützung rationalisieren. Oder Sie könnten die Zeit aufwenden, um Ihren Client-Code zu machen versuchen, HTTP-Streaming ersten und wechseln Sie zu lange Polling, wenn nötig.

Wie zu einem Message-Broker, die / suscribe capatibility veröffentlichen zur Verfügung stellen kann, können Sie mit ActiveMQ JMS betrachten. Es ist Open Source und kostenlos mit aktiver Unterstützung der Gemeinschaft (können Sie Unterstützung kaufen). Darüber hinaus können Sie NMS verwenden als .NET-Client zu integrieren.

in der mittleren Ebene einen Message-Broker Nachdem sitzt, ist tatsächlich wichtig, weil es ein Ort sein wird für Nachrichten sicher gestellt werden. Wenn Ihre Kunden lange Polling tun, würden Sie nicht wollen, dass sie jede neue Nachricht während eines Intervalls verpassen, wenn sie nicht tatsächlich verbunden ist.

Ein andere Sache in hohem Verkehrsaufkommen Szenarien zu berücksichtigen (Hunderte oder Tausende von Kunden, wie eine Web-Seite im Internet), müssen Sie einen Ansatz für das Comet-Muster haben, die skalierbar ist.

In der Flex / Java-Welt, die BlazeDS Servlet (die Open Source) wird modifiziert mit asynchronem Modell zu arbeiten. In Java kann ein Socket-Listener NIO gebaut werden Kanäle und Java Concurrency Executor Thread-Pools zu verwenden. Der Tomcat Web-Server verfügt über einen NIO Hörer und Unterstützung für asynchrone Servlet 3.0 Veranstaltungen. BlazeDS insbesondere wurde geändert, aber mit dem Jetty Web-Server zu arbeiten. Unterm Strich ist, dass die Skalierbarkeit dieses asynchronen Ansatzes bedeutet ein einzelner physikalischer Webserver verbessert werden kann bis zu rund 20.000 gleichzeitigen Comet-style-Client-Verbindungen zu unterstützen.

Es ist schon eine Weile her, seit ich ernst .NET Programmierung getan habe, sondern auf die io-Fähigkeiten waren ähnlich wie Java 1.1, außer mit einer asynchronen Ergebnis Handler Fähigkeit verwendet. Dies ist aber nicht dasselbe wie das Erstellen asynchrone Socket-Listener über Java NIO-Kanäle. Eine NIO-Kanal-Implementierung kann Hunderte bis Tausende von Socket-Verbindungen mit einem relativ kleinen Thread-Pool unterstützen. Aber C # und .NET ist durch t gegangenwo oder drei signifikante Drehzahlen - vielleicht gibt es neue io-Funktionen hinzugefügt, die zu NIO Kanälen vergleichbar sind

.

Ich wollte nur klarstellen, dass die PollingDuplexHttpBinding nicht ‚wahr‘ Push-Benachrichtigungen nicht implementiert, wie der Name verrät (Polling). Aus dem Msdn Dokumentation :

  

Wenn Sie mit dieser Bindung konfiguriert, der Silverlight-Client den Dienst auf der Vermittlungsschicht regelmäßig Umfragen, und prüft, ob neue Nachrichten, die der Dienst will dich auf dem Callback-Kanal senden. Der Service-Warteschlangen alle Nachrichten auf dem Client-Callback-Kanal gesendet und liefert sie an den Client, wenn der Client fragt den Service.

Allerdings ist es effizienter, als die traditionelle Art der Abfrage eines Web-Service, da nach jeder Umfrage, wird der Server den Kanal für eine bestimmte Zeit (etwa 1 Minute) offen halten, und wenn eine Nachricht in dieser Zeit ankommt, wird es direkt ‚Push‘ die Meldung an den Client. Der Kunde hat immer wieder seine Verbindung zu erneuern, es so zu sagen Umfragen den Dienst.

Wenn Sie wollen echte Push-Benachrichtigungen mit Silverlight implementieren Ich glaube, Sie müssen mit Steckdosen arbeiten, und ich empfehle einige von Dan Wahlin Blog-Beiträge zum Thema zu lesen.

Alternativ

Wenn Sie eine native Silverlight-API ohne Proxies, Brücken oder webservers beteiligt Sie Nirvana von My-Channels als Messaging-Middleware nutzen könnten. Schauen Sie sich Nirvana von My-Channels und ihre Schaufenster Website. (Sorry, ich bin ein neuer Benutzer und kippt Links einreichen):

Alex

EDIT: es ist eigentlich gut funktioniert. Ich hatte schlecht von den „verborgenen Variablen“ in einem Verschluss gebissen: (

habe ich die PollingDuplex für SL2 und ich denke, dass es für die Produktion noch nicht bereit ist.

Mein Hauptproblem ist die Tatsache, dass es nicht auf den Clients auf der gleichen Maschine nicht diskriminieren. Wenn ich laufe 2-Clients dann einer von ihnen nicht in der Lage sein, den Server nicht mehr abgefragt wird und wird von Timeout sterben. Es gibt eine SessionId, die für die 2-Clients anders ist, aber es ist nur auf der Client-Seite ignoriert.

Auch wenn ich einen Klienten zu töten und dann einen neuen erstellen danach dann der neue Client wird das Push-Updates aus dem vorherigen Client für eine Weile erhalten.

Hat jemand die gleichen Probleme auftreten oder sind sie in SL3 fixiert?

Eigentlich lief ich noch ein paar Demo-Codes und erkannte, dass aus irgendeinem Grund die InstanceContextMode und InstanceMode angeben müssen, so dass die Service-Sitzung basiert und kein Singleton (soweit ich das beurteilen kann). Es gibt deutliche Performance-Probleme in dem einfachen Demo-Code, den ich gezogen.

Es ist sehr bedauerlich, dass dieses Verhalten nicht dokumentiert wurde.

Meine Organisation gefunden, die Silverlight 2.0 / WCF Push-Implementierung ein wenig „nicht bereit für die Prime Time“ zu sein, zumindest für das, was wir es nutzen wollten.

Wir landeten mit XMPP / Jabber gehen, weil es ein wohlgeformten Tier ist, und man kann es ziemlich leicht in Silverlight umgesetzt werden, indem nur einige Ressourcen immer aus dem Internet.

Ich glaube, dass Silverlight 3.0 wird eine neuere / mehr gut ausgebildet Push-Implementierung implementieren, von dem, was ich aus öffentlich zugänglichen Informationen berichten.

Das PollingDuplexHttpBinding ist wahrscheinlich die eleganteste Art und Weise, es zu tun.

Eine possilby weniger beteiligt Alternative ist, einen TCP-Socket von Silverlight-Client zu verwenden. Jedes Mal, wenn einer der Silverlight-Clients ein Update haben muss geschoben können Sie es eine TCP-Nachricht senden, die den Namen des WCF-Dienst enthält muss es nennen oder ein anderes Leichtgewichtler Stück Information.

Ich benutze diesen Ansatz für eine Anwendung und es funktioniert gut.

Eine wesentlich einfachere und leistungsfähigere Lösung auf der Website http: //www.udaparts .com / document / Tutorial / slpush.htm

Answer 3

Nicht die Flex in Fan Junge Mode bin drängen, aber sachlich ist dies die Art von Architektur, die wir routinemäßig in alle unsere Flex-basierten Anwendungen zu bauen. Hier ist, was wir auf Flex tun - kein Zweifel könnte es passend zu Silverlight übersetzt werden:

Wir nehmen drei Zutaten und integrieren sie zusammen, um diese Fähigkeit zu erreichen:

1. Comet Muster (eine HTTP-kompatible Art und Weise Server-Push-Benachrichtigungen zu tun - schaut auf Wikipedia für weitere Informationen)
2. JMS-Messaging-Themen (Publish / Subscriber-Queues)
3. Die Adobe BlazeDS Servlet

Dieser Artikel implementiert das Comet-Muster, unterstützt AMF Objekt Serialisieren (Adobe binäre Serialisierung Format für ActionScript3 Objekte) und Brücken in einer JMS-Warteschlange oder Thema. Wenn zu einem Thema überbrückt, dann mehrere Flex-Clients in einem Browser ausgeführt wird, können Sie sich als Teilnehmer an ein JMS-Thema proxied werden. Also, wenn jeder Client eine Nachricht veröffentlicht (oder der serverseitigen Code veröffentlicht in das Thema), alle Client-Abonnenten haben die Nachricht, um sie über BlazeDS und der Comet-Muster Implementierung geschoben.

Effektiv müssen Sie lokalisieren oder eine Komponente zu schreiben, das leistet, was BlazeDS tut. Sie könnten auch einig Client-Code implementieren müssen, die mit den Comet-Mustern dieser serverseitige Komponente in Wechselwirkung tritt.

Unterstützt WCF das Comet-Muster und bidirektionalen Messaging? Insbesondere entspricht, in dem auf HTTP und Port 80 oder Port 443 für SSL. Sieht aus wie Sie bereits in das geschaut haben und nichts für die bidirektionale Nachrichten gefunden. Sie müssen also können Sie die Ärmel hoch rollen und einige Codierung tun.

Einige Dinge über das Tun Server Push-to-Web-App zu beachten:

BlazeDS unterstützt zwei primäre Modi des Kometen Muster der Umsetzung (es gibt tatsächlich eine dritte Wahl Option, aber es würde zu ignorieren):

1. long-Abfrage
2. HTTP-Streaming

Die Lang Abfrage, die Sie finden sollen universell erträglich zu den meisten Web-Browsern sein. Sie könnten also, dass zunächst nur die Unterstützung rationalisieren. Oder Sie könnten die Zeit aufwenden, um Ihren Client-Code zu machen versuchen, HTTP-Streaming ersten und wechseln Sie zu lange Polling, wenn nötig.

Wie zu einem Message-Broker, die / suscribe capatibility veröffentlichen zur Verfügung stellen kann, können Sie mit ActiveMQ JMS betrachten. Es ist Open Source und kostenlos mit aktiver Unterstützung der Gemeinschaft (können Sie Unterstützung kaufen). Darüber hinaus können Sie NMS verwenden als .NET-Client zu integrieren.

in der mittleren Ebene einen Message-Broker Nachdem sitzt, ist tatsächlich wichtig, weil es ein Ort sein wird für Nachrichten sicher gestellt werden. Wenn Ihre Kunden lange Polling tun, würden Sie nicht wollen, dass sie jede neue Nachricht während eines Intervalls verpassen, wenn sie nicht tatsächlich verbunden ist.

Ein andere Sache in hohem Verkehrsaufkommen Szenarien zu berücksichtigen (Hunderte oder Tausende von Kunden, wie eine Web-Seite im Internet), müssen Sie einen Ansatz für das Comet-Muster haben, die skalierbar ist.

In der Flex / Java-Welt, die BlazeDS Servlet (die Open Source) wird modifiziert mit asynchronem Modell zu arbeiten. In Java kann ein Socket-Listener NIO gebaut werden Kanäle und Java Concurrency Executor Thread-Pools zu verwenden. Der Tomcat Web-Server verfügt über einen NIO Hörer und Unterstützung für asynchrone Servlet 3.0 Veranstaltungen. BlazeDS insbesondere wurde geändert, aber mit dem Jetty Web-Server zu arbeiten. Unterm Strich ist, dass die Skalierbarkeit dieses asynchronen Ansatzes bedeutet ein einzelner physikalischer Webserver verbessert werden kann bis zu rund 20.000 gleichzeitigen Comet-style-Client-Verbindungen zu unterstützen.

Es ist schon eine Weile her, seit ich ernst .NET Programmierung getan habe, sondern auf die io-Fähigkeiten waren ähnlich wie Java 1.1, außer mit einer asynchronen Ergebnis Handler Fähigkeit verwendet. Dies ist aber nicht dasselbe wie das Erstellen asynchrone Socket-Listener über Java NIO-Kanäle. Eine NIO-Kanal-Implementierung kann Hunderte bis Tausende von Socket-Verbindungen mit einem relativ kleinen Thread-Pool unterstützen. Aber C # und .NET ist durch t gegangenwo oder drei signifikante Drehzahlen - vielleicht gibt es neue io-Funktionen hinzugefügt, die zu NIO Kanälen vergleichbar sind

.

Answer 4

Ich wollte nur klarstellen, dass die PollingDuplexHttpBinding nicht ‚wahr‘ Push-Benachrichtigungen nicht implementiert, wie der Name verrät (Polling). Aus dem Msdn Dokumentation :

  

Wenn Sie mit dieser Bindung konfiguriert, der Silverlight-Client den Dienst auf der Vermittlungsschicht regelmäßig Umfragen, und prüft, ob neue Nachrichten, die der Dienst will dich auf dem Callback-Kanal senden. Der Service-Warteschlangen alle Nachrichten auf dem Client-Callback-Kanal gesendet und liefert sie an den Client, wenn der Client fragt den Service.

Allerdings ist es effizienter, als die traditionelle Art der Abfrage eines Web-Service, da nach jeder Umfrage, wird der Server den Kanal für eine bestimmte Zeit (etwa 1 Minute) offen halten, und wenn eine Nachricht in dieser Zeit ankommt, wird es direkt ‚Push‘ die Meldung an den Client. Der Kunde hat immer wieder seine Verbindung zu erneuern, es so zu sagen Umfragen den Dienst.

Wenn Sie wollen echte Push-Benachrichtigungen mit Silverlight implementieren Ich glaube, Sie müssen mit Steckdosen arbeiten, und ich empfehle einige von Dan Wahlin Blog-Beiträge zum Thema zu lesen.

Answer 5

Alternativ

Wenn Sie eine native Silverlight-API ohne Proxies, Brücken oder webservers beteiligt Sie Nirvana von My-Channels als Messaging-Middleware nutzen könnten. Schauen Sie sich Nirvana von My-Channels und ihre Schaufenster Website. (Sorry, ich bin ein neuer Benutzer und kippt Links einreichen):

Alex

Answer 6

EDIT: es ist eigentlich gut funktioniert. Ich hatte schlecht von den „verborgenen Variablen“ in einem Verschluss gebissen: (

habe ich die PollingDuplex für SL2 und ich denke, dass es für die Produktion noch nicht bereit ist.

Mein Hauptproblem ist die Tatsache, dass es nicht auf den Clients auf der gleichen Maschine nicht diskriminieren. Wenn ich laufe 2-Clients dann einer von ihnen nicht in der Lage sein, den Server nicht mehr abgefragt wird und wird von Timeout sterben. Es gibt eine SessionId, die für die 2-Clients anders ist, aber es ist nur auf der Client-Seite ignoriert.

Auch wenn ich einen Klienten zu töten und dann einen neuen erstellen danach dann der neue Client wird das Push-Updates aus dem vorherigen Client für eine Weile erhalten.

Hat jemand die gleichen Probleme auftreten oder sind sie in SL3 fixiert?

Eigentlich lief ich noch ein paar Demo-Codes und erkannte, dass aus irgendeinem Grund die InstanceContextMode und InstanceMode angeben müssen, so dass die Service-Sitzung basiert und kein Singleton (soweit ich das beurteilen kann). Es gibt deutliche Performance-Probleme in dem einfachen Demo-Code, den ich gezogen.

Es ist sehr bedauerlich, dass dieses Verhalten nicht dokumentiert wurde.

Answer 7

Meine Organisation gefunden, die Silverlight 2.0 / WCF Push-Implementierung ein wenig „nicht bereit für die Prime Time“ zu sein, zumindest für das, was wir es nutzen wollten.

Wir landeten mit XMPP / Jabber gehen, weil es ein wohlgeformten Tier ist, und man kann es ziemlich leicht in Silverlight umgesetzt werden, indem nur einige Ressourcen immer aus dem Internet.

Ich glaube, dass Silverlight 3.0 wird eine neuere / mehr gut ausgebildet Push-Implementierung implementieren, von dem, was ich aus öffentlich zugänglichen Informationen berichten.

Answer 8

Das PollingDuplexHttpBinding ist wahrscheinlich die eleganteste Art und Weise, es zu tun.

Eine possilby weniger beteiligt Alternative ist, einen TCP-Socket von Silverlight-Client zu verwenden. Jedes Mal, wenn einer der Silverlight-Clients ein Update haben muss geschoben können Sie es eine TCP-Nachricht senden, die den Namen des WCF-Dienst enthält muss es nennen oder ein anderes Leichtgewichtler Stück Information.

Ich benutze diesen Ansatz für eine Anwendung und es funktioniert gut.

Answer 9

Eine wesentlich einfachere und leistungsfähigere Lösung auf der Website http: //www.udaparts .com / document / Tutorial / slpush.htm