Concepts de base d’Azure Web PubSub
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, est une relation logique entre un client et le service Web PubSub. Sur une « connexion », le client et le service s’engagent dans une série d’interactions avec état. Les connexions utilisant différents protocoles peuvent se comporter différemment. Par exemple, certaines connexions sont limitées à la durée d’une connexion réseau, tandis que d’autres peuvent s’étendre sur plusieurs connexions réseau successives entre un client et le service.
Hub : un hub est un concept logique pour un ensemble de connexions clientes. En règle générale, vous utilisez un hub dans un seul 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. Nous vous recommandons 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.
É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énementconnected
quand il s’est correctement connecté au service, un événementmessage
lorsqu’il envoie des messages au service et un événementdisconnected
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
Hub
UserId
, Group
sont des rôles importants lorsque vous gérez des clients et envoyez des messages. Ce sont des paramètres 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 :
Comme illustré par le graphique de workflow ci-dessus :
Un client se connecte à un hub dans le service à l’aide du transport WebSocket. Le service peut transférer les messages vers le serveur en amont configuré ou gérer les messages par lui-même et permettre aux clients d’effectuer des tâches pub/sub directement, en fonction du protocole utilisé par le client. Des informations détaillées sont disponibles dans la section Protocoles client.
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.
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.