Publication

La norme SIRI utilise un ensemble cohérent de protocoles de communication généraux pour échanger des informations entre un client et un serveur. Le même schéma d'échange de message peut être utilisé pour mettre en oeuvre différentes interfaces fonctionnelles spécifiques sous la forme d'un ensemble de types de contenus de message concrets. L'échange de données selon la norme SIRI fait appel à deux schémas spécifiques d'interaction client/serveur bien connus: Demande/Réponse et Edition/Abonnement. - Le schéma Demande/Réponse permet l'échange ad hoc de données sur demande du client. - Le schéma Edition/Abonnement permet d'émettre de façon répétée et asynchrone des notifications et des données afin de diffuser des événements et des situations identifiées par un service en temps réel. L'utilisation du schéma d'interaction Edition/Abonnement est fidèle aux spécifications de la norme « Publish-Subscribe Notification for Web Services » (WS-PubSub); la norme SIRI reprend autant que faire se peut la séparation des problématiques et la terminologie relative aux concepts et aux interfaces d'édition/d'abonnement de la norme WS-PubSub. Cette dernière décompose la partie serveur du schéma Edition/Abonnement en différents rôles et interfaces définis (Abonné, Editeur, Producteur ou Destinataire de notifications par exemple): dans le cadre d'une mise en oeuvre SIRI réelle, une même entité peut associer et fournir certaines de ces interfaces distinctes. Bien qu'aujourd'hui SIRI ne soit pas déployé comme un service web WS-PubSub intégral, l'utilisation d'une architecture WS-PubSub permet de simplifier cette action future. En général, le schéma Edition/Abonnement n'est pas destiné à prendre en charge un grand nombre d'appareils d'utilisateurs finaux. En matière de transmission de données en réponse à des demandes et des abonnements, SIRI prend en charge deux schémas communs d'échange de messages, similaires à ceux des systèmes nationaux existants: - Une Transmission « directe » en une seule étape conformément au paradigme traditionnel client-serveur avec édition et abonnement WS-PubSub ordinaires; et - Une transmission « fetched » en deux étapes, laquelle configure l'envoi de messages selon une séquence de deux alertes successives, la première visant à informer le client et la seconde à envoyer les données lorsque ce dernier est prêt. La Transmission Fetched constitue à elle seule un schéma connecté. En fonction des environnements cibles, chaque schéma de transmission implique différents compromis à respecter en vue de garantir l'efficacité du déploiement. L'un ou l'autre de ces modes de transmission (voire les deux) est applicable à une mise en oeuvre SIRI, l'objectif étant de garantir une utilisation optimale des ressources de calcul et de communication. Soit le mode de transmission peut être préconfiguré et statique de manière à correspondre à un déploiement donné, soit chaque demande ou abonnement peut faire état de ce dernier en fonction des exigences dynamiques du client énoncées dans le cadre de la politique correspondante, le serveur pouvant refuser une demande lorsque celle-ci ne prend pas en charge le mode choisi avant de générer un code d'erreur associé. Les schémas d'interaction et de transmission constituent des caractéristiques indépendantes du protocole SIRI, et peuvent être utilisés dans différentes mises en oeuvre, et ce quelle que soit la combinaison. Lorsqu'il s'agit d'un type de Service fonctionnel SIRI spécifique (Connection Monitoring ou Stop Monitoring p. ex.), le contenu des données utiles du message est identique, que les informations soient échangées avec un schéma Demande/Réponse ou Edition/Abonnement, ou que la transmission soit directe ou fetched. ....