Concepts de base d’Azure Web PubSub

  • Article

Le service Azure Web PubSub vous aide à générer des applications web de messagerie en temps réel. Les clients se connectent au service à l’aide du protocole WebSocket standard et le service expose des API REST et des kits de développement logiciel (SDK) qui vous permettent de gérer ces clients.

Conditions

Voici quelques termes importants utilisés par le service :

  • Connexion : une connexion, également appelée client ou connexion cliente, représente une connexion WebSocket individuelle connectée au service Web PubSub. Une fois la connexion réussie, un ID de connexion unique est affecté à cette connexion par le service Web PubSub.

  • Hub : un hub est un concept logique pour un ensemble de connexions clientes. En règle générale, vous utilisez un hub pour un scénario, par exemple, un hub de conversation ou un hub de notification . Lorsqu’une connexion cliente est établie, le client se connecte à un hub et, pendant toute sa durée de vie, il appartient à ce hub. Une fois qu’une connexion cliente se connecte au hub, le hub existe. Différentes applications peuvent partager un service Azure Web PubSub en utilisant différents noms de hubs. Bien qu’il n’existe aucune limite stricte sur le nombre de hubs, un hub consomme davantage de charge de service par rapport à un groupe. Il est recommandé d’avoir un ensemble prédéterminé de hubs plutôt que de les générer dynamiquement.

  • Groupe : un groupe est un sous-ensemble de connexions au hub. Vous pouvez ajouter une connexion cliente à un groupe, ou la supprimer du groupe, quand vous le souhaitez. Par exemple, quand un client rejoint une salle de conversation ou quand il la quitte, cette salle de conversation peut être considérée comme un groupe. Un client peut rejoindre plusieurs groupes, et un groupe peut contenir plusieurs clients. Le groupe est semblable à une « session » de groupe, la session de groupe est créée une fois qu’une personne rejoint le groupe et la session est terminée quand personne n’est dans le groupe. Les messages envoyés au groupe sont remis à tous les clients connectés au groupe.

  • Utilisateur : les connexions à Web PubSub ne peuvent appartenir qu’à un seul utilisateur. Un utilisateur peut avoir plusieurs connexions. C’est le cas, par exemple, quand un seul utilisateur est connecté sur plusieurs appareils ou plusieurs onglets de navigateur.

  • Message : quand le client est connecté, il peut envoyer des messages à l’application en amont, ou recevoir des messages de l’application en amont, par le biais de la connexion WebSocket. Les messages peuvent être au format texte brut, binaire ou JSON et avoir une taille maximale de 1 Mo.

  • Connexion cliente et ID de connexion : un client se connecte au point de terminaison /client. Lorsqu’il est connecté, un connectionId unique est généré par le service en tant qu’identité unique de la connexion cliente. Les utilisateurs peuvent ensuite gérer la connexion cliente à l’aide de ce connectionId. Des informations détaillées sont disponibles dans la section Protocole client.

  • Événements clients : les événements sont créés pendant le cycle de vie d’une connexion cliente. Par exemple, une connexion cliente WebSocket simple crée un événement connect lorsqu’il tente de se connecter au service, un événement connected quand il s’est correctement connecté au service, un événement message lorsqu’il envoie des messages au service et un événement disconnected lorsqu’il se déconnecte du service. Des informations détaillées sur les événements clients sont présentées dans la section Protocole client.

  • Gestionnaire d’événements : le gestionnaire d’événements contient la logique permettant de gérer les événements du client. Inscrivez et configurez les gestionnaires d’événements dans le service via le portail ou Azure CLI au préalable. Des informations détaillées sont disponibles dans la section Gestionnaire d’événements.

  • Écouteur d’événements(préversion) : l’écouteur d’événements écoute simplement les événements du client, mais ne peut pas interférer dans la durée de vie de vos clients via leur réponse. Des informations détaillées sont disponibles dans la section Écouteur d’événements.

  • Serveur : le serveur peut gérer les événements du client, les connexions du client et publier des messages pour des groupes. Le gestionnaire d’événements et l’écouteur d’événements sont considérés comme étant côté serveur. Des informations détaillées sur le serveur sont présentées dans la section Protocole serveur.

Important

HubUserId, Groupsont des rôles importants lorsque vous gérez les clients et envoyez des messages. Ils seront nécessaires dans différents appels d’API REST sous forme de texte brut. Ne placez donc pas d’informations sensibles dans ces champs. Par exemple, les informations d’identification ou les jetons du porteur qui présentent un risque élevé de fuite.

Workflow

Un flux de travail classique utilisant le service est illustré ci-dessous :

Diagram showing the Web PubSub service workflow.

Comme illustré par le graphique de workflow ci-dessus :

  1. Un client se connecte au point de terminaison /client du service à l’aide du transport WebSocket. Le service transfère chaque trame WebSocket vers le serveur en amont configuré. La connexion WebSocket peut se connecter à n’importe quel sous-protocole personnalisé à gérer par le serveur ou se connecter aux sous-protocoles pris en charge par le service (par exemple, json.webpubsub.azure.v1), ce qui permet aux clients d’effectuer des actions de publication/souscription directement. Des informations détaillées sont disponibles dans la section Protocoles client.

  2. Le service appelle le serveur à l’aide du Protocole CloudEvents sur différents événements client. CloudEvents est une définition standardisée et indépendante du protocole de la description de la structure et des métadonnées des événements hébergés par la Cloud Native Computing Foundation (CNCF). Des informations détaillées sont disponibles dans la section Protocole serveur.

  3. Le serveur peut appeler le service à l’aide de l’API REST pour envoyer des messages aux clients ou pour gérer les clients connectés. Des informations détaillées sont disponibles dans la section Protocole serveur.