Ausführliche Informationen zum Azure Web PubSub-Dienst

Artikel
08/21/2024

Der Azure Web PubSub-Dienst bietet eine einfache Möglichkeit, um Nachrichten über WebSocket-Verbindungen zu veröffentlichen und zu abonnieren.

Clients können in einer beliebigen Sprache geschrieben werden, die über Websocket-Unterstützung verfügt.
Sowohl Text- als auch Binärnachrichten werden innerhalb einer Verbindung unterstützt.
Ein einfaches Protokoll ermöglicht es Kunden, Nachrichten direkt für einander zu veröffentlichen.
Der Dienst verwaltet die WebSocket-Verbindungen für Sie.

Begriffe

Dienst: Azure Web PubSub.

Verbindung: Eine Verbindung, die auch als Client oder Clientverbindung bezeichnet wird, ist eine logische Beziehung zwischen einem Client und dem Web PubSub-Dienst. Über eine „Verbindung“ führen der Client und der Dienst eine Reihe statusbehafteter Interaktionen aus. Verbindungen mit verschiedenen Protokollen verhalten sich möglicherweise auf unterschiedliche Weise. Beispielsweise sind einige Verbindungen auf die Dauer einer Netzwerkverbindung beschränkt, während sich andere über mehrere aufeinander folgende Netzwerkverbindungen zwischen einem Client und dem Dienst erstrecken können.
Hub: Ein Hub ist ein logisches Konzept für eine Gruppe von Clientverbindungen. In der Regel wird jeweils ein Hub für ein einzelnes Szenario verwendet – beispielsweise ein Chathub oder ein Benachrichtigungshub. Eine Clientverbindung wird mit einem Hub hergestellt und gehört während ihrer Lebensdauer zu diesem Hub. Sobald eine Clientverbindung mit dem Hub hergestellt wurde, ist der Hub vorhanden. Von verschiedenen Anwendungen können unterschiedliche Hubnamen verwendet werden, um gemeinsam einen einzelnen Azure Web PubSub-Dienst zu nutzen. Während es keine strikte Beschränkung für die Anzahl der Hubs gibt, verbraucht ein Hub mehr Dienstlast als eine Gruppe. Es wird empfohlen, einen vordefinierten Satz von Hubs zu verwenden, anstatt sie dynamisch zu generieren.
Gruppe: Eine Gruppe ist eine Teilmenge der Verbindungen mit dem Hub. Sie können einer Gruppe eine Clientverbindung hinzufügen und sie jederzeit wieder aus der Gruppe entfernen. Beispiel: Wenn ein Client einem Chatroom beitritt oder wenn ein Client den Chatroom verlässt, kann dieser Chatroom als Gruppe betrachtet werden. Ein Client kann mehreren Gruppen beitreten, und eine Gruppe kann mehrere Clients enthalten. Die Gruppe ist wie eine „Gruppensitzung“. Die Gruppensitzung wird erstellt, sobald jemand der Gruppe beigetreten ist, und die Sitzung wird entfernt, wenn sich niemand in der Gruppe befindet. Nachrichten, die an die Gruppe gesendet werden, werden an alle Clients übermittelt, die mit der Gruppe verbunden sind.
Benutzer: Verbindungen mit Web PubSub können zu einem einzelnen Benutzer gehören. Ein Benutzer kann über mehrere Verbindungen verfügen, etwa, wenn ein einzelner Benutzer über mehrere Geräte oder mehrere Browsertabs verbunden ist.
Nachricht: Wenn der Client verbunden ist, kann er Nachrichten an die Upstreamanwendung senden oder Nachrichten von der Upstreamanwendung über die WebSocket-Verbindung empfangen. Nachrichten können im Nur-Text-, Binär- oder JSON-Format vorliegen und eine maximale Größe von 1 MB aufweisen.
Clientereignisse: Ereignisse werden während des Lebenszyklus einer Clientverbindung erstellt. Eine einfache WebSocket-Clientverbindung erstellt z. B. ein connect-Ereignis, wenn versucht wird, eine Verbindung mit dem Dienst herzustellen, ein connected-Ereignis, wenn erfolgreich eine Verbindung mit dem Dienst hergestellt wurde, ein message-Ereignis, wenn Nachrichten an den Dienst gesendet werden und ein disconnected-Ereignis, wenn die Verbindung mit dem Dienst getrennt wird. Einzelheiten zu Clientereignissen finden Sie im Abschnitt Clientprotokoll.
Ereignishandler: Der Ereignishandler enthält die Logik zum Behandeln der Clientereignisse. Ereignishandler sollten vorab über das Portal oder über die Azure CLI im Dienst registriert und konfiguriert werden. Einzelheiten finden Sie im Abschnitt Ereignishandler.
Ereignislistener (Vorschau): Der Ereignislistener lauscht nur auf die Clientereignisse, kann aber die Lebensdauer Ihrer Clients nicht durch ihre Antwort beeinflussen. Ausführliche Informationen finden Sie im Abschnitt Ereignislistener.
Server: Der Server kann Clientereignisse verarbeiten, Clientverbindungen verwalten oder Nachrichten in Gruppen veröffentlichen. Sowohl der Ereignishandler als auch der Ereignislistener gelten als serverseitig. Einzelheiten zum Server finden Sie im Abschnitt Serverprotokoll.

Workflow

Darstellung des Web PubSub-Dienstworkflows.

Workflow wie in der Abbildung oben dargestellt:

Ein Client stellt über den WebSocket-Transport eine Verbindung mit dem /client-Endpunkt des Diensts her. Der Dienst leitet sämtliche WebSocket-Frames an den konfigurierten Upstream(server) weiter. Über die WebSocket-Verbindung kann eine Verbindung mit einem beliebigen benutzerdefinierten Unterprotokoll hergestellt werden, das der Server verarbeiten soll. Alternativ kann eine Verbindung mit dem vom Dienst unterstützten Unterprotokoll json.webpubsub.azure.v1 hergestellt werden, wodurch die Clients Nachrichten direkt veröffentlichen oder abonnieren können. Einzelheiten finden Sie unter Clientprotokoll.
Bei verschiedenen Clientereignissen ruft der Dienst den Server über das CloudEvents-Protokoll auf. CloudEvents ist eine standardisierte und protokollunabhängige Definition der Struktur und Metadatenbeschreibung von Ereignissen, die von der Cloud Native Computing Foundation (CNCF) gehostet werden. Die detaillierte Implementierung des CloudEvents-Protokolls basiert auf der Serverrolle, die unter Serverprotokoll beschrieben wird.
Der Web PubSub-Server kann den Dienst mithilfe der REST-API aufrufen, um Nachrichten an Clients zu senden oder die verbundenen Clients zu verwalten. Einzelheiten finden Sie unter Serverprotokoll.

Clientprotokoll

Über eine Clientverbindung wird unter Verwendung des WebSocket-Protokolls eine Verbindung mit dem /client-Endpunkt des Diensts hergestellt. Das WebSocket-Protokoll bietet Vollduplex-Kommunikationskanäle über eine einzelne TCP-Verbindung und wurde im Jahr 2011 durch die IETF als RFC 6455 standardisiert. Die meisten Sprachen bieten native Unterstützung für das Starten von WebSocket-Verbindungen.

Unser Dienst unterstützt zwei Arten von Clients:

den einfachen WebSocket-Client
und den PubSub-WebSocket-Client

Der einfache WebSocket-Client

Ein einfacher WebSocket-Client ist, wie der Name schon sagt, eine einfache WebSocket-Verbindung. Er kann zudem über ein eigenes Unterprotokoll verfügen.

Beispielsweise kann in JS ein einfacher WebSocket-Client mit dem folgenden Code erstellt werden.

// simple WebSocket client1
var client1 = new WebSocket("wss://test.webpubsub.azure.com/client/hubs/hub1");

// simple WebSocket client2 with some custom subprotocol
var client2 = new WebSocket(
  "wss://test.webpubsub.azure.com/client/hubs/hub1",
  "custom.subprotocol"
);

Bei einem einfachen WebSocket-Client wird eine Client<->Server-Architektur verwendet, wie im folgenden Ablaufdiagramm gezeigt: Diagramm mit dem Ablauf für eine Clientverbindung.

Wenn der Client einen WebSocket-Handshake startet, versucht der Dienst, den connect-Ereignishandler für den WebSocket-Handshake aufzurufen. Entwickler können diesen Handler verwenden, um den WebSocket-Handshake zu verarbeiten, das zu verwendende Unterprotokoll zu bestimmen, den Client zu authentifizieren und den Client in Gruppen einzubinden.
Wenn die Verbindung mit dem Client erfolgreich hergestellt wurde, ruft der Dienst einen connected-Ereignishandler auf. Dieser wird als Benachrichtigung eingesetzt und verhindert nicht, dass der Client Nachrichten senden kann. Entwickler können diesen Handler zum Speichern von Daten verwenden und Nachrichten als Antwort an den Client senden. Der Dienst pusht auch ein connected-Ereignis an alle betreffenden Ereignislistener, sofern vorhanden.
Wenn der Client Nachrichten sendet, löst der Dienst ein message-Ereignis für den Ereignishandler aus. Dieses Ereignis enthält die in einem WebSocket-Frame gesendeten Nachrichten. Ihr Code muss die Nachrichten innerhalb dieses Ereignishandlers verteilen. Wenn der Ereignishandler einen nicht erfolgreichen Antwortcode zurückgibt, trennt der Dienst die Clientverbindung. Der Dienst pusht auch ein message-Ereignis an alle betroffenen Ereignislistener, sofern vorhanden. Wenn der Dienst keine registrierten Server für den Empfang der Nachrichten findet, trennt der Dienst die Clientverbindung.
Wenn der Client die Verbindung trennt, versucht der Dienst, das disconnected-Ereignis für den Ereignishandler auszulösen, sobald er die Trennung der Verbindung erkennt. Der Dienst pusht auch ein disconnected-Ereignis an alle betreffenden Ereignislistener, sofern vorhanden.

Szenarien

Diese Verbindungen können in einer typischen Client-Server-Architektur verwendet werden, in der der Client Nachrichten an den Server sendet und der Server eingehende Nachrichten mithilfe von Ereignishandlern verarbeitet. Sie kann auch verwendet werden, wenn Kunden vorhandene Unterprotokolle in ihrer Anwendungslogik anwenden.

PubSub-WebSocket-Client

Der Dienst unterstützt auch das Unterprotokoll json.webpubsub.azure.v1, das es den Clients ermöglicht, Nachrichten direkt zu veröffentlichen/abonnieren, ohne einen Roundtrip zum Upstreamserver durchführen zu müssen. Die WebSocket-Verbindung mit dem json.webpubsub.azure.v1-Unterprotokoll wird auch „PubSub WebSocket-Client“ genannt. Weitere Informationen finden Sie in der Web PubSub-Clientspezifikation auf GitHub.

Beispielsweise kann in JS ein PubSub WebSocket-Client mit dem folgenden Code erstellt werden.

// PubSub WebSocket client
var pubsub = new WebSocket(
  "wss://test.webpubsub.azure.com/client/hubs/hub1",
  "json.webpubsub.azure.v1"
);

Ein PubSub-WebSocket-Client kann Folgendes:

Beitreten zu einer Gruppe, z. B.:

{
  "type": "joinGroup",
  "group": "<group_name>"
}

Verlassen einer Gruppe, z. B.:

{
  "type": "leaveGroup",
  "group": "<group_name>"
}

Veröffentlichen von Nachrichten für eine Gruppe, z. B.:

{
  "type": "sendToGroup",
  "group": "<group_name>",
  "data": { "hello": "world" }
}

Senden von benutzerdefinierten Ereignissen an den Upstreamserver, z. B.:

{
  "type": "event",
  "event": "<event_name>",
  "data": { "hello": "world" }
}

Das PubSub-WebSocket-Unterprotokoll beinhaltet die Details des json.webpubsub.azure.v1-Unterprotokolls.

Wie Sie gesehen haben, ist bei einem einfachen WebSocket-Client der Server eine zwingend erforderliche Rolle, um die message-Ereignisse von Clients zu empfangen. Eine einfache WebSocket-Verbindung löst beim Versenden von Nachrichten immer ein message Ereignis aus und verlässt sich immer auf den Server, um Nachrichten zu verarbeiten und andere Vorgänge durchzuführen. Mithilfe des json.webpubsub.azure.v1-Unterprotokolls kann ein autorisierter Client einer Gruppe beitreten und Nachrichten direkt in einer Gruppe veröffentlichen. Außerdem können Nachrichten an verschiedene Ereignishandler bzw. Ereignislistener gesendet werden, indem das Ereignis angepasst wird, zu dem die Nachricht gehört.

Szenarien

Diese Clients können für die Kommunikation zwischen Clients verwendet werden. Nachrichten werden von client2 an den Dienst gesendet, und der Dienst sendet die Nachricht direkt an client1 (sofern die Clients dazu autorisiert sind).

Client1:

var client1 = new WebSocket(
  "wss://xxx.webpubsub.azure.com/client/hubs/hub1",
  "json.webpubsub.azure.v1"
);
client1.onmessage = (e) => {
  if (e.data) {
    var message = JSON.parse(e.data);
    if (message.type === "message" && message.group === "Group1") {
      // Only print messages from Group1
      console.log(message.data);
    }
  }
};

client1.onopen = (e) => {
  client1.send(
    JSON.stringify({
      type: "joinGroup",
      group: "Group1",
    })
  );
};

Client2:

var client2 = new WebSocket("wss://xxx.webpubsub.azure.com/client/hubs/hub1", "json.webpubsub.azure.v1");
client2.onopen = e => {
    client2.send(JSON.stringify({
        type: "sendToGroup",
        group: "Group1",
        data: "Hello Client1"
    });
};

Wie im obigen Beispiel gezeigt, sendet client2 Daten direkt an client1, indem Nachrichten für die Gruppe Group1 veröffentlicht werden, zu der client1 gehört.

Zusammenfassung von Clientereignissen

Clientereignisse werden in zwei Kategorien unterteilt:

Synchrone Ereignisse (blockierend): Synchrone Ereignisse blockieren den Clientworkflow.
- connect: Dieses Ereignis betrifft nur den Ereignishandler. Wenn der Client einen WebSocket-Handshake startet, wird das Ereignis ausgelöst, und Entwickler können den connect-Ereignishandler verwenden, um den WebSocket-Handshake zu behandeln, das zu verwendende Unterprotokoll zu bestimmen, den Client zu authentifizieren und den Client in Gruppen einzubinden.
- message: Dieses Ereignis wird ausgelöst, wenn ein Client eine Nachricht sendet.
Asynchrone Ereignisse (nicht blockierend): Durch asynchrone Ereignisse wird der Clientworkflow nicht blockiert. Stattdessen senden sie eine Benachrichtigung an den Server. Wenn bei einem solchen Ereignisauslöser ein Fehler auftritt, protokolliert der Dienst die Fehlerdetails.
- connected: Dieses Ereignis wird ausgelöst, wenn ein Client erfolgreich eine Verbindung mit dem Dienst herstellt.
- disconnected: Dieses Ereignis wird ausgelöst, wenn ein Client die Verbindung mit dem Dienst trennt.

Maximale Größe für Clientnachrichten

Die maximal zulässige Nachrichtengröße für einen WebSocket-Frame beträgt 1 MB.

Clientauthentifizierung

Authentifizierungsworkflow

Der Client verwendet ein signiertes JWT-Token, um eine Verbindung mit dem Dienst herzustellen. Der Upstream kann den Client auch ablehnen, wenn es sich um einen connect-Ereignishandler des eingehenden Clients handelt. Der Ereignishandler authentifiziert den Client, indem er die userId- und role-Werte des Clients in der Webhookantwort angibt, oder der Client wird mit dem Fehler 401 abgelehnt. Einzelheiten zu diesem Vorgang finden Sie im Abschnitt Ereignishandler.

In der folgenden Abbildung wird der Workflow beschrieben.

Darstellung des Workflows zur Clientauthentifizierung.

Ein Client kann nur dann auf anderen Clients veröffentlicht werden, wenn er dazu autorisiert ist. Die role-Werte des Clients bestimmen seine anfänglichen Berechtigungen:

Role	Berechtigung
Nicht angegeben	Der Client kann Ereignisse senden.
`webpubsub.joinLeaveGroup`	Der Client kann einer beliebigen Gruppe beitreten/diese verlassen.
`webpubsub.sendToGroup`	Der Client kann Nachrichten in einer beliebigen Gruppe veröffentlichen.
`webpubsub.joinLeaveGroup.<group>`	Der Client kann der Gruppe `<group>` beitreten/diese verlassen.
`webpubsub.sendToGroup.<group>`	Der Client kann Nachrichten in Gruppe `<group>` veröffentlichen.

Auch serverseitig können über das Serverprotokoll Berechtigungen des Clients dynamisch erteilt oder widerrufen werden, wie in einem späteren Abschnitt gezeigt.

Serverprotokoll

Das Serverprotokoll stellt die Funktionen bereit, mit denen der Server Clientereignisse behandeln und die Clientverbindungen sowie die Gruppen verwalten kann.

Im Allgemeinen enthält das Serverprotokoll drei Rollen:

Ereignishandler
Connection manager
Ereignislistener

Ereignishandler

Der Ereignishandler verarbeitet die eingehenden Clientereignisse. Der Ereignishandler werden im Dienst über das Portal oder die Azure CLI registriert und konfiguriert. Wenn ein Clientereignis ausgelöst wird, kann der Dienst identifizieren, ob das Ereignis behandelt werden muss. Jetzt verwenden wir den PUSH-Modus, um den Ereignishandler aufzurufen. Der Ereignishandler auf der Serverseite stellt einen öffentlich zugänglichen Endpunkt für den Dienst zur Verfügung, der aufgerufen werden soll, wenn das Ereignis ausgelöst wird. Er fungiert als Webhook.

Der Web PubSub-Dienst übergibt Clientereignisse mithilfe des CloudEvents-HTTP-Protokolls an den Upstreamwebhook.

Für jedes Ereignis formuliert der Server eine HTTP-POST-Anforderung an den registrierten Upstream und erwartet eine HTTP-Antwort.

Die Daten, die vom Dienst an den Server gesendet werden, weisen immer das CloudEvents-Format binary auf.

Darstellung des Pushmodus für Web PubSub-Dienstereignisse.

Upstream und Überprüfung

Ereignishandler müssen im Dienst über das Portal oder die Azure CLI vor der ersten Verwendung registriert und konfiguriert werden. Wenn ein Clientereignis ausgelöst wird, kann der Dienst identifizieren, ob das Ereignis behandelt werden muss. Für die öffentliche Vorschau verwenden wir den PUSH-Modus zum Aufrufen des Ereignishandlers. Der Ereignishandler auf der Serverseite stellt einen öffentlich zugänglichen Endpunkt für den Dienst zur Verfügung, der aufgerufen werden soll, wenn das Ereignis ausgelöst wird. Er fungiert als Webhook-Upstream.

Die URL kann den {event}-Parameter verwenden, um eine URL-Vorlage für den Webhookhandler zu definieren. Der Dienst berechnet den Wert der Webhook-URL dynamisch, sobald er die Clientanforderung empfängt. Beispiel: Wenn die Anforderung /client/hubs/chat mit dem konfigurierten Ereignishandler-URL-Muster http://host.com/api/{event} für den Hub chat empfangen wird, wird beim Herstellen der Clientverbindung zunächst eine Nachricht für diese URL veröffentlicht: http://host.com/api/connect. Dieses Verhalten kann hilfreich sein, wenn ein PubSub WebSocket-Client benutzerdefinierte Ereignisse sendet, da der Ereignishandler dabei hilft, unterschiedliche Ereignisse an verschiedene Upstreams zu senden. Der {event}-Parameter ist im URL-Domänennamen unzulässig.

Beim Einrichten des Ereignishandler-Upstreams über das Azure-Portal oder die Azure CLI überprüft der Dienst den Upstreamwebhook mithilfe des CloudEvents-Schutzes gegen Missbrauch. Der WebHook-Request-Origin-Anforderungsheader ist auf den Dienstdomänennamen xxx.webpubsub.azure.com festgelegt, und es wird erwartet, dass der Antwortheader WebHook-Allowed-Origin diesen Domänennamen enthält.

Bei der Überprüfung wird der Parameter {event} in validate aufgelöst. Beim Versuch, die URL auf http://host.com/api/{event} festzulegen, versucht der Dienst z. B., einen OPTIONS-Vorgang für eine Anforderung an http://host.com/api/validate auszuführen. Nur wenn die Antwort gültig ist, kann die Konfiguration erfolgreich festgelegt werden.

Aktuell werden WebHook-Request-Rate und WebHook-Request-Callback nicht unterstützt.

Authentifizierung/Autorisierung zwischen Dienst und Webhook

Um eine sichere Authentifizierung und Autorisierung zwischen Ihrem Dienst und Webhook herzustellen, sollten Sie die folgenden Optionen und Schritte in Betracht ziehen:

Anonymer Modus
Einfache Authentifizierung, d. h. code wird über die konfigurierte Webhook-URL bereitgestellt.
Verwenden Sie die Microsoft Entra-Autorisierung. Weitere Informationen finden Sie unter Verwenden der verwalteten Identität.

Aktivieren Sie die Identität für den Web PubSub-Dienst.
Wählen Sie eine vorhandene Microsoft Entra-Anwendung aus, die für Ihre Webhook-Web-App steht.

Ziel-Editor für Dimensionsverarbeitung

Der Server ist naturgemäß ein autorisierter Benutzer. Durch die Ereignishandlerrolle kennt der Server die Metadaten der Clients (z. B. connectionId und userId) und kann mit diesen Informationen folgende Aufgaben ausführen:

Schließen einer Clientverbindung
Senden von Nachrichten an einen Client
Senden von Nachrichten an Clients, die demselben Benutzer gehören
Hinzufügen eines Clients zu einer Gruppe
Hinzufügen von Clients, die als derselbe Benutzer authentifiziert sind, zu einer Gruppe
Entfernen eines Clients aus einer Gruppe
Entfernen von Clients, die als derselbe Benutzer authentifiziert sind, aus einer Gruppe
Veröffentlichen von Nachrichten in einer Gruppe

Es können auch Berechtigungen zum Veröffentlichen/Beitreten für einen PubSub-Client erteilt oder widerrufen werden:

Erteilen von Berechtigungen zum Veröffentlichen/Beitreten für eine bestimmte Gruppe oder für alle Gruppen
Widerrufen von Berechtigungen zum Veröffentlichen/Beitreten für eine bestimmte Gruppe oder für alle Gruppen
Überprüfen, ob der Client über die Berechtigung zum Beitreten oder Veröffentlichen für eine bestimmte Gruppe oder für alle Gruppen verfügt

Der Dienst stellt der Dienst REST-APIs zur Verbindungsverwaltung für den Server zur Verfügung.

Darstellung des Verbindungs-Manager-Workflows des Web PubSub-Diensts.

Einzelheiten des REST-API-Protokolls finden Sie hier.

Ereignislistener

Hinweis

Das Ereignislistenerfeature befindet sich in der Vorschauphase.

Der Ereignislistener lauscht auf die eingehenden Clientereignisse. Jeder Ereignislistener enthält einen Filter, um anzugeben, um welche Arten von Ereignissen es sich handelt, und einen Endpunkt, an den die Ereignisse gesendet werden sollen.

Derzeit wird Event Hubs als Ereignislistener-Endpunkt unterstützt.

Ereignislistener müssen vorab registriert werden, damit der Dienst das Ereignis an die entsprechenden Ereignislistener pushen kann, wenn ein Clientereignis ausgelöst wird. Informationen zum Konfigurieren eines Ereignislisteners mit einem Event Hub-Endpunkt finden Sie in dieser Dokumentation.

Sie können mehrere Ereignislistener konfigurieren. Die Reihenfolge, in der Sie sie konfigurieren, wirkt sich nicht auf ihre Funktionalität aus. Wenn ein Ereignis mehreren Listenern entspricht, wird das Ereignis an alle übereinstimmenden Listener verteilt. Das folgende Diagramm zeigt ein Beispiel. Wenn Sie beispielsweise vier Ereignislistener gleichzeitig konfigurieren, verarbeitet jeder Listener, der eine Übereinstimmung empfängt, das Ereignis. Ein Clientereignis, das zu drei dieser Listener passt, wird an drei Listener gesendet, und der verbleibende Listener wird ignoriert.

Diagramm: Beispieldatenfluss für Ereignislistener

Sie können einen Ereignishandler und Ereignislistener für das gleiche Ereignis miteinander kombinieren. In diesem Fall wird das Ereignis sowohl vom Ereignishandler als auch von Ereignislistenern empfangen.

Der Web PubSub-Dienst übermittelt Clientereignisse mithilfe der AMQP-Erweiterung „CloudEvents“ für Azure Web PubSub an Ereignislistener.

Zusammenfassung

Die Ereignishandlerrolle ist für die Kommunikation vom Dienst zum Server und die Managerrolle für die Kommunikation vom Server zum Dienst verantwortlich. Sobald Sie beide Rollen kombiniert haben, sieht der Datenfluss zwischen Dienst und Server ähnlich wie die folgende Abbildung unter Verwendung des HTTP-Protokolls aus.

Darstellung des bidirektionalen Workflows beim Web PubSub-Dienst.