Résumé
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 œuvre 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 Édition/Abonnement.
• Le schéma Demande/Réponse permet l'échange ad hoc de données sur demande du client,
• Le schéma Édition/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 Édition/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 Édition/Abonnement en différents rôles et interfaces définis (Abonné, Éditeur, Producteur ou Destinataire de notifications, par exemple) : dans le cadre d'une mise en œuvre 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 Édition/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.
[...]
Panier
