FR2919141A1 - Procede d'obtention de donnees applicatives - Google Patents

Procede d'obtention de donnees applicatives Download PDF

Info

Publication number
FR2919141A1
FR2919141A1 FR0756607A FR0756607A FR2919141A1 FR 2919141 A1 FR2919141 A1 FR 2919141A1 FR 0756607 A FR0756607 A FR 0756607A FR 0756607 A FR0756607 A FR 0756607A FR 2919141 A1 FR2919141 A1 FR 2919141A1
Authority
FR
France
Prior art keywords
server
session
data
token
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR0756607A
Other languages
English (en)
Inventor
Philippe Dussaume
Eric Paillet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to FR0756607A priority Critical patent/FR2919141A1/fr
Priority to PCT/FR2008/051358 priority patent/WO2009013441A1/fr
Publication of FR2919141A1 publication Critical patent/FR2919141A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4541—Directories for service discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/147—Signalling methods or messages providing extensions to protocols defined by standardisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de transmission de données, dans le cadre d'une communication établie entre au moins deux entités.Selon l'invention, un tel procédé comprend :- une étape de réception par une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant :- un identifiant de typologie, désignant un type de message prédéfini ;- une information représentative desdites données applicatives à obtenir ;- une étape d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.

Description

Procédé d'obtention de données applicatives La présente invention se
rapporte au domaine de la gestion de communication et plus particulièrement de session dans un serveur de session partie prenante à des interconnexions entre au moins deux dispositifs de communication, une session comprenant d'une part des informations de constitution décrivant la session et des données de session. Par session, on entend, Session d'usage . Une session d'usage se différencie d'une session de communication par le fait qu'elle intègre une notion de service. Pour sa part une session de communication est liée à l'établissement d'une communication entre un utilisateur et un dispositif auquel il est connecté. Ainsi, une session de communication est fermée quand l'utilisateur se déconnecte du dispositif. Au contraire, une session d'usage contient des données persistantes, qui subsistent après que la session de communication ait expiré. Ainsi une session d'usage peut contenir plusieurs sessions de communication, plusieurs identifiants d'utilisateurs, plusieurs données de services. Les sessions d'usage sont par exemple mises en oeuvre dans le cadre d'extensions du couplage téléphonie/informatique dans des réseaux de communication. L'invention concerne la structuration des échanges avec un serveur de session.
La présente invention se rapporte plus particulièrement au domaine des transmissions de données applicatives dans des systèmes de télécommunication, et notamment sur la distinction de données au sein du système. Dans l'état actuel de la technique, un système de télécommunication mettant en oeuvre un procédé d'échange de données de session inclut un réseau de communication principal, tel un réseau téléphonique commuté, apte à mettre en relation un terminal mis à disposition d'un utilisateur avec au moins un premier moyen de communication mis en oeuvre par un premier client, dit client amont, identifié par exemple comme premier destinataire d'une communication qu'aura initiée l'utilisateur, par exemple en composant un code prédéterminé sur un clavier alphanumérique dont est muni son terminal. Ce premier moyen de communication pourra par exemple être un serveur vocal d'accueil apte à recevoir de la part de l'utilisateur une requête, par exemple verbale, et à orienter cette requête, et donc la communication en cours, vers un deuxième moyen de communication mis en oeuvre par un autre client situé au sein d'un second réseau de communication, dit client aval, lequel aura été identifié par le client amont comme fournissant un service apte à satisfaire la requête formulée par l'utilisateur. Le terme "client" doit être compris ici et dans la suite de l'exposé comme désignant une entité qui sollicite directement ou indirectement les ressources d'une autre entité pour exécuter une tâche, un client pouvant être matérialisé par un serveur autonome, par un groupe de serveurs, une plateforme de services ou par divers éléments répartis au sein de divers moyens de communication inclus dans le système. Le terme serveur doit être compris ici et dans la suite de l'exposé comme désignant une entité qui fournit directement ou indirectement des ressources (par exemple données ou service) à une autre entité pour exécuter une tâche. Une transmission de données entre les moyens de communication d'un système de communication, tels ceux mis en oeuvre par la demanderesse, induit généralement une identification de ces données afin de s'assurer qu'elles sont transmises conformément à l'exécution d'applications liées à des actions initiées par un utilisateur ou par un élément du système. L'identification de ces données est mise en oeuvre par l'implémentation de sessions de communication, lesquelles sont utilisées tout au long des interactions entre un utilisateur d'un service et les moyens de communication utilisés dans l'exécution de ce service. Le mécanisme de session, bien connu de l'homme du métier, permet, notamment dans la mise en oeuvre de systèmes d'information n-tiers , de conserver des informations afin de permettre une continuité de service. Une telle session est donc susceptible de contenir un important volume de données. Plus généralement, une session possède des informations de constitution et des données qui lui sont propres. Ces données de session sont routées entre les différentes plateformes de services. Une plateforme de service est une entité du réseau de communication en charge de la fourniture de services applicatifs à un client qui en fait la demande. Ainsi, une plateforme de services peut mettre en oeuvre plusieurs services applicatifs qui vont chacun rendre un ou plusieurs services. Des techniques communément employées de l'art antérieur appliquées à ces données de session d'usage permettent de réaliser un échange applicatif de données en deux étapes. En effet, les données applicatives des sessions d'usage contiennent de nombreux paramètres et de nombreuses informations de sorte que l'échange des données d'une session d'usage entre un serveur de données de session (qui gère ces données de manière centralisée) et des plateformes de services (qui ont successivement besoin de ces données) est difficilement réalisable d'un seul tenant. Ainsi, il a été développé un mécanisme permettant d'échanger des données par le biais d'une première phase d'interrogation, par la plateforme de service, d'un serveur de données de session qui permet à la plate forme de demander la structure de la session d'usage puis au moins une deuxième phase de transmission des données de la session en fonction des besoins de la plateforme de service. Ainsi, les échanges entre les plateformes de services et le serveur de données de session sont réduits en fonction des besoins des plateformes. Les travaux des inventeurs ont cependant permis de découvrir que ces transferts applicatifs en deux phases ne résolvent pas tous les problèmes liés à des échanges de données trop volumineuses. En effet, les données de session d'usage (données applicatives et descriptions) sont par exemple routées du serveur de données de session à une plateforme de services en utilisant un mécanisme dit de jeton (également appelé corrélant réseau). Un tel mécanisme est déjà mis en oeuvre au sein de protocoles réseaux ( anneau à jeton de l'anglais token ring ) et fonctionne sur les couches Physique et Liaison du modèle OSI. Ce mécanisme a fait l'objet d'une transposition nouvelle et inventive au 30 niveau applicatif par les inventeurs et a permis d'obtenir un mécanisme de routage des données par le biais d'un corrélant réseau applicatif. Or un tel corrélant réseau ne permet de transporter qu'une quantité limitée de données avant de devenir caduque (en effet, un tel corrélant réseau à une durée de vie limitée, au delà de laquelle il ne peut plus être utilisé). Ainsi, les travaux des inventeurs portants sur les corrélants réseaux applicatifs ont permis de découvrir que la durée de vie d'un tel corrélant est le résultat d'une fonction directement liée au nombre d'appels (ou de sollicitations) d'une plateforme applicative (telle qu'une plateforme vocale) par seconde. En effet, un jeton applicatif est codé sur seize bits (soit deux octets). Ce codage permet donc d'obtenir une plage de valeur d'identifiant de jeton de l'ordre de soixante cinq mille. Ainsi, si l'on considère une plateforme de test qui reçoit environ cinquante appels par secondes, la durée de vie d'un corrélant est de mille trois cent secondes, soit environ vingt et une minutes. Or une telle fréquence d'appel n'est valable que pour une plateforme de test. En production, une plateforme de ce type peut aisément recevoir jusqu'à cinq cent sollicitations par secondes. On comprend donc l'absolue nécessité de réaliser des traitements rapides et efficaces. De plus, en l'état actuel, la structuration des échanges en deux phases (structure puis données) combinée à un échange sous la forme de jeton entraîne une complexité importante, tant au niveau des plateformes de service que du serveur de données de sessions. Du point de vue des plateformes de services, la gestion des données de session et la gestion des échanges de messages pèse inutilement sur les performances globales de la plateforme et entraîne des retards de mise en oeuvre des services en tant que tels. En effet, les missions dédiées aux plateformes de services sont bien d'exécuter des services en tant que tels et non de gérer la pertinence de données en provenance d'un serveur central, d'en déduire le traitement à effectuer ou encore de gérer un stock de jetons prêt à être attribué à telle ou telle session d'usage liée à un utilisateur. Afin de décrire les protocoles d'échanges de message entre les serveurs de 30 données de session et leurs clients, du point de vue de ces clients, et de faciliter le travail des développeurs informatiques sur les plates-formes de services pour la gestion applicative de ces échanges, des API sont définies. Cependant, la richesse des protocoles d'échanges de message entre les serveurs de données de session et leurs clients, et leur nécessaire prise en compte des aléas sur des réseaux inter-applicatifs ouverts, rendent malgré tout la gestion des échanges complexe pour les plates-formes de services. L'invention offre une solution qui ne présente pas les inconvénients de l'art antérieur, grâce à un procédé de transmission de données, dans le cadre d'une communication établie entre au moins deux entités.
Selon l'invention, un tel procédé comprend : - une étape de réception par une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : - un identifiant de typologie, désignant un type de message prédéfini ; - une information représentative desdites données applicatives à obtenir ; - une étape d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie. Ainsi, le procédé selon l'invention permet d'identifier un serveur de localisation, au sein d'un ensemble de serveurs d'un réseau de communication dédié à la fourniture de services, tels que ceux mis en oeuvre par la demanderesse, et qui peuvent se présenter sous la forme d'Intranet, c'est-à-dire de réseaux dédiés caractérisés par leur utilisation du protocole IP. Un serveur de localisation est un serveur qui peut fournir une localisation de l'information recherchée par le serveur émetteur. L'entité émettrice (par exemple un serveur) cherchant à obtenir des données contacte donc l'entité réceptrice (par exemple un autre serveur) pour obtenir l'information. La localisation d'une information est donc réalisée dans un premier temps par l'identification d'un serveur qui pourrait indiquer cette information. Selon un mode de mise en oeuvre particulier de l'invention, l'entité réceptrice peut s'identifier elle-même, c'est-à-dire qu'elle peut se déclarer apte à rendre elle-même le service de localisation.
Selon un mode de réalisation particulier de l'invention, ledit procédé comprend, postérieurement à ladite étape d'identification, une étape d'émission d'un deuxième message à destination dudit serveur de localisation, ledit deuxième message comprenant : - un deuxième identifiant de typologie, définissant un type dudit deuxième message parmi au moins deux types prédéfinis ; - ladite information représentative des dites données applicatives à localiser ; Ainsi, après avoir identifié un serveur pouvant répondre au besoin exprimé par le serveur émetteur, le procédé selon l'invention permet au serveur récepteur de relayer la demande à un serveur de localisation qui peut lui répondre. Selon une caractéristique particulière de l'invention ledit procédé comprend, postérieurement à ladite étape d'émission dudit deuxième message, une deuxième étape de réception d'un message de localisation, en provenance dudit serveur de localisation, ledit message de localisation comprenant au moins une adresse applicative représentative d'une entité apte à délivrer lesdites données applicatives. Ainsi, le procédé selon l'invention permet d'obtenir une adresse, qui permet de localiser le serveur dont on cherche à obtenir des données. Selon un mode de réalisation particulier de l'invention, ladite adresse applicative comprend au moins une interface d'entrée/sortie qui est fonction dudit au moins un traitement applicatif à réaliser. Ainsi, l'adresse applicative n'est pas une adresse de réseau, mais bien une adresse d'un applicatif de service qui peut être en charge de la réalisation du service ou de la fourniture des données applicatives escomptées. Il s'agit donc ici d'une approche nouvelle de la notion d'adresse qui peut être variable en fonction du service à rendre. Ainsi, une plateforme applicative qui supporterait deux applicatif de service peut disposer de plusieurs adresses applicatives alors même qu'elle ne dispose que d'une seule adresse IP, dans le cas par exemple, de l'utilisation de ce protocole.
Selon une caractéristique particulière de l'invention, ledit procédé comprend, postérieurement à ladite deuxième étape de réception de ladite adresse applicative : - une étape de vérification d'une autorisation de ladite entité émettrice à requérir lesdites données applicatives ; - une étape d'interrogation de ladite entité apte à fournir lesdites données applicatives en fonction de ladite adresse applicative lorsque ladite autorisation est accordée. Ainsi, le procédé selon l'invention permet de vérifier que les entités qui en font la demande disposent bien des autorisations nécessaires à l'obtention des données applicatives qu'elles requièrent. Selon un mode de réalisation original de l'invention, ladite typologie de message comprend des types de messages appartenant au groupe comprenant au moins : - des messages de service ; - des notifications ; -des commandes ; - des requêtes. Ainsi, l'invention permet de trier les messages en fonction de leur type et de séparer les traitements applicatifs de ceux-ci. Par exemple, lors de la réception d'un message de type message de service , l'entité qui reçoit ce message peut activer un module logiciel rapide pour le traitement de ce message. Par exemple, si l'entité qui reçoit ce message de service est un fournisseur de services, ce fournisseur de services n'est pas obligé de mettre en oeuvre un service applicatif pour répondre à ce message, mais peut directement y répondre en activant un module spécifique de réponse à ces messages de service.
En d'autres termes, grâce à l'invention, il n'est pas nécessaire, pour une plateforme de service de mettre en oeuvre des modules applicatifs lourds et consommateurs de ressources pour répondre à des messages de services simples, concernant notamment les couches applicatives basses. Ainsi, la réponse peut être réalisée dans des temps très courts, qui ne nécessitent pas l'utilisation de plusieurs corrélants réseaux (plusieurs jetons). En conséquence, l'invention permet de réaliser des traitements plus rapides des types de message relevant de la compétence de modules logiciels applicatifs (qui sont gourmands en termes de mémoire et d'utilisation de puissance de calcul). En effet, l'utilisation de modules spécifiques rapides pour répondre à des messages simples permet de diminuer le nombre d'instances des modules applicatifs à un instant donné et donc d'allouer à chaque instance une quantité de mémoire plus importante et un temps CPU plus long. L'invention concerne également un système de transmission de données 15 incluant au moins deux entités. Selon l'invention, un tel système comprend : - des moyens de réception inclus dans une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : 20 - un identifiant de typologie, désignant un type de message prédéfini ; - une information représentative desdites données applicatives à obtenir ; - des moyens d'identification d'au moins un serveur, dit serveur de 25 localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie. L'invention concerne également un dispositif de transmission. Selon l'invention, un tel dispositif inclut : 30 - des moyens de réception d'un message requérant des données applicatives, ledit message comprenant : -un premier identifiant de typologie, désignant un type de message prédéfini ; - une information représentative desdites données applicatives à obtenir ; - des moyens d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.
Dans au moins un mode de réalisation particulier de l'invention, un tel dispositif de transmission peut se présenter sous la forme d'un serveur, tel qu'un serveur de données de sessions. Selon un autre aspect, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, et comprenant des instructions de code de programme pour l'exécution du procédé de transmission tel que décrit précédemment. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 est un diagramme de blocs décrivant le principe du procédé d'obtention selon l'invention ; - la figure 2 est un diagramme de séquence présentant un accès des applicatifs de services aux différents serveurs uniquement par le biais d'un serveur de données de session auxquels ils sont attachés ; -la figure 3 est un diagramme de séquence présentant un accès direct des applicatifs de services aux différents serveurs ; - la figure 4 est un diagramme de séquence dans lequel des applicatifs de services ont un accès aux différents serveurs après un accès initial à un serveur de données de session propre pour la localisation du jeton ; - la figure 5 est un diagramme de séquence dans lequel des applicatifs de services ont un accès aux différents serveurs après un accès initial à un serveur de données de session propre pour la localisation du jeton et l'obtention de celui-ci ; - la figure 6 est un diagramme de séquence dans lequel des applicatifs de services ont un accès aux différents serveurs après un accès initial à un serveur de données de session propre pour la localisation du jeton, la localisation de la session et l'obtention de ces données, par l'intermédiaire d'une vérification des droits ; - la figure 7 est un diagramme de séquence présentant un exemple d'un système où les applicatifs service clients ont un accès direct aux différents serveurs, dans le cadre d'un Scénario simplifiés par utilisation d'URLs et d'adresses simplifiées pour les jetons, et des passeports numériques. - la figure 8 est un diagramme de séquence présentant un exemple d'un système où les AS clients accèdent aux différents serveurs, après un accès initial via un serveur de données de session propre, dans le cadre d'un Scénario simplifiés par utilisation d'URLs et d'adresses simplifiées pour les jetons, et des passeports numériques ; - la figure 9 est un diagramme de blocs présentant le fonctionnement d'un serveur de localisation de jetons actif ; - la figure 10 est un diagramme de blocs présentant le fonctionnement d'un serveur de localisation de jetons passif ; - la figure 11 est un diagramme de séquence présentant un exemple d'un système où les AS clients ont un accès direct aux différents serveurs dans le cadre d'un scénario simplifié, avec franchissement de passerelle ; - la figure 12 est un diagramme de séquence présentant un exemple d'un exemple d'un système où les AS clients accèdent aux différents serveurs, après un accès initial via un SDS propre, pour l'obtention du jeton, avec franchissement de passerelle ; - la figure 13 est un diagramme de séquence présentant un exemple d'un exemple d'un système où les AS clients accèdent aux différents serveurs, après un accès initial via un SDS propre, pour l'obtention du jeton et de la session, avec franchissement de passerelle ; - la figure 14 décrit une architecture simplifiée d'un serveur d'obtention de données applicatives selon l'invention. Le procédé selon l'invention permet la recherche et la localisation des informations utiles, c'est-à-dire la recherche des données applicatives impliquées dans une session d'usage. Comme cela a déjà été évoqué, des données concernant la session d'usage peuvent se trouver dans de nombreux endroits : dans une entité de gestion de données de session (tel qu'un serveur de données de sessions), bien évidemment puisqu'elle a pour objet la centralisation des données de session, mais également au sein de services applicatifs, qui peuvent être situés dans la même plateforme de service qu'un applicatif voisin cherchant justement à obtenir les données en question. Dans d'autres cas de figure, les données de session peuvent se trouver dans un autre réseau de communication que celui de l' applicatif de service qui souhaite y accéder (réseau d'un opérateur concurrent par exemple). Le procédé d'obtention selon l'invention permet d'identifier, au sein du réseau de communication voisin, l'entité qui possède et qui est apte à fournir, les données applicatives requises. Le procédé d'obtention selon l'invention peut être mis en oeuvre sur les plates-formes de services (PFS) supportant les applicatifs de services (AS) clients de Serveurs de Données de Sessions (SDS), et sur ces Serveurs de Données de Sessions eux-mêmes ou sur des systèmes additionnels. Les mécanismes particuliers permettant la recherche et la localisation des informations utiles, selon l'invention, peuvent être implémentés sous la forme d'un enrichissement des protocoles déjà définis, eux-mêmes supportés par des dispositifs logiciels et matériels ad hoc. En effet, dans un espace dédié à aux échanges de données de contexte de 30 session d'usage non pas fermé mais ouvert, où sont gérés ou manipulés des serveur de données de session, des applicatifs de services, des groupes fermés de clients ( Groupe fermé de clients ) regroupant certains de ces applicatifs de services, des jetons, des sessions et des données, ils faut que les acteurs en présence, applicatifs de services et serveur de données de session, soient assurés de pouvoir chercher les informations aux bon endroit, ou de les délivrer à qui de droit. En première approche, le contexte d'une session d'usage peut mettre en présence les éléments suivants : - un ou plusieurs serveurs de données de session hébergeant la description 10 du contexte de la session d'usage ; - un ou plusieurs serveurs délivrant des jetons (unicité des jetons sur les réseaux) ; - un ou plusieurs serveurs applicatifs contribuant à cette session ; - un ou plusieurs serveurs auprès desquels sont enregistrés ces AS en tant 15 que clients ; - un ou plusieurs serveurs auprès desquels sont enregistrés les Groupe fermé de clients contribuant à cette session ; - un ou plusieurs serveurs auprès desquels sont enregistrées les données interservices de cette session. 20 Parallèlement, afin de permettre aux entités de gestion de données de session et applicatifs de services d'accéder aux autres "bonnes" entités de service (serveurs) et entités de gestion de données de session et à ces entités d'authentifier les "bons" clients, applicatifs de services et entités de gestion de données de session, on peut mettre en oeuvre un système nouveau de serveurs de localisation 25 de ces éléments, permettant aux acteurs de n'avoir pas à connaître ou mémoriser systématiquement et à priori toutes les adresses nécessaires à la recherche des informations utiles : - un ou plusieurs serveurs de localisation des entités de gestion de données de session ; 30 - un ou plusieurs serveurs de localisation des clients ; - un ou plusieurs serveurs de localisation des Groupe fermé de clients ; - un ou plusieurs serveurs de localisation des sessions ; - un ou plusieurs serveurs de localisation des jetons ; - un ou plusieurs serveurs de localisation des données.
Dans un deuxième mode de réalisation de l'invention, on peut préférer une approche différente, et placer l'adresse des entités (qui peuvent être des serveurs) détenant les informations dans l'étiquette même de ces informations, à la façon des URL, pour tout ou partie des ces informations. Ces différentes approches sont décrites ci-après, au travers de quelques scénarios de mise en oeuvre.
Parallèlement à la mise en oeuvre du procédé de d'obtention des données applicatives selon l'invention, les inventeurs ont proposé de hiérarchiser et de distribuer les messages applicatifs échangés entre les serveurs de données de session et la plateformes de service selon deux axes : l'utilisation de canaux de communications applicatifs spécifiques, par exemple en définissant plusieurs adresses IP pour un même serveur applicatif, chacune de ces adresses étant utilisée pour un type de message particulier. Il a été également proposé de définir des modules logiciels clients, présents sur les plateformes de services qui permettent de répondre à certains besoins d'échanges applicatifs spécifiques sans qu'il soit nécessaire de mettre en oeuvre un service applicatif dans son intégralité.
On évite ainsi une surcharge de la plateforme de service en ne créant pas l'instance de l'applicatif de service pour réaliser de simples échanges applicatifs. Ainsi, une interface d'entrée sortie comprend, de manière générale : - Une adresse IP ; - Un port spécifique de cette adresse IP ; -Un module logiciel client qui est connecté au couple adresse IP/port spécifique. Le procédé d'obtention selon l'invention tire parti de ces interfaces d'adressage et des modules logiciels applicatifs qui y sont associées. On décrit, en relation avec la figure 1, les étapes du procédé d'obtention selon l'invention : Une communication est établie entre une entité 10 et une entité 11. L'entité 10 cherche à obtenir des données applicatives, qui sont situées sur une entité en charge d'un traitement applicatif (non représenté). L'entité 10 et l'entité 11 sont situées au sein d'un réseau de communication comprenant une pluralité d'entité, des serveurs et des clients. L'entité 11, en charge d'obtenir les données, reçoit (1000) un message 101 en provenance de l'entité 10 qui demande les données. Ce message 101 comprend : - un identifiant de typologie, définissant un type dudit message parmi au moins deux types prédéfinis (non représenté) ; - une information représentative des dites données applicatives à localiser (102) ; - L'entité 11 identifie 1001, en fonction de ladite information représentative et dudit identifiant de typologie, un serveur 12 du réseau de communication apte à réaliser ladite localisation. Ce serveur 12 est appelé serveur de localisation. Par la suite, dans un mode de réalisation de l'invention, l'entité llemet (1002) un deuxième message à destination du serveur de localisation 12, ce deuxième message 103 comprenant : - un deuxième identifiant de typologie, définissant un type dudit deuxième message (non représenté) ; - l'information représentative 102 des données applicatives à localiser ; On présente par la suite les différentes fonctions des serveurs de localisation mettant en oeuvre un mode de réalisation du procédé d'obtention selon l'invention. On appelle serveur de localisation d'une information d'une nature donnée (jeton, session, Groupe fermé de clients , client) un système à même de fournir l'adresse d'un serveur capable de fournir l'information demandée , quelque soit la structure de ce système, monolithique ou composite, pour des raisons de facilité. Le serveur de localisation ne fourni pas l'information en tant que telle. De cette façon, on considérera qu'un client ou un serveur ayant accès à un élément d'un serveur de localisation obtiendra toujours, s'il en a le droit, la localisation de la source d'information souhaitée, l'élément contacté se chargeant de rechercher l'information de localisation au sein du système de localisation de façon transparente pour le requérant, que cette l'information de localisation soit hébergée de façon centralisée ou distribuée, et accessible de façon maillée ou hiérarchisée. 1. Serveurs de localisation des serveurs de données de session Ces serveurs permettent aux serveurs de données de session et aux AS clients de ces serveur de données de session, ainsi qu'aux aux serveurs de localisation et autres serveurs mentionnés précédemment, de localiser un serveur de données de session, c'est-à-dire d'obtenir l'adresse de ses interfaces d'Entrée/Sortie déclinées par services, à savoir requêtes, messages de service et notifications (échanges entre serveur de données de session et clients). Un serveur de localisation de serveur de données de session permet donc de retrouver un serveur de données de session, par exemple lorsque celui-ci n'est pas situé sur le même réseau de communication que le serveur qui souhaite y accéder.
Les paramètres passés en interrogation de ce type de serveur sont : -identifiant de l'auteur de la requête, - désignation du ou des serveurs de données de session concernés. Paramètres passés en réponse : - Adresses du ou des serveurs de données de session concernés. 2. Serveurs de localisation des clients Ces serveurs permettent aux serveurs de données de session et aux AS clients, ainsi qu'aux serveurs de localisation et autres serveurs mentionnés précédemment de localiser les serveurs applicatifs clients des serveurs de données de session, c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/Sortie des serveurs auprès desquels ces clients sont enregistrés et à même de les authentifier.
Les paramètres passés en interrogation de ce type de serveur sont : -identifiant de l'auteur de la requête, - désignation du ou des clients concernés. Paramètres passés en réponse - Adresses du ou des serveurs d'enregistrement des clients concernés. 3. Serveurs de localisation des Groupe fermé de clients Ces serveurs permettent aux serveurs de données de session et aux AS clients, ainsi qu'aux serveurs mentionnés précédemment de localiser les Groupe fermé de clients , c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/Sortie des serveurs auprès desquels ces Groupe fermé de clients sont enregistrés avec la liste des clients et des sous-groupes fermés de clients membres de ces Groupe fermé de clients . Les paramètres passés en interrogation de ce type de serveur sont : - identifiant de l'auteur de la requête, -désignation du ou des Groupe fermé de clients concernés. Paramètres passés en réponse - Adresses du ou des serveurs d'enregistrement des Groupes fermés de clients concernés. 4. Serveurs de localisation des sessions Ces serveurs permettent aux serveurs de données de session et aux AS clients de localiser les sessions, c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/Sortie des serveurs de données de session auprès desquels ces sessions sont enregistrées. Les paramètres passés en interrogation de ce type de serveur sont : - identifiant de l'auteur de la requête, - désignation de la ou des sessions concernées. Paramètres passés en réponse - Adresses du ou des serveurs de données de session concernés. 5. Serveurs de localisation des jetons Ces serveurs permettent aux serveurs de données de session et aux applicatifs de services clients de localiser les jetons, c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/Sortie des serveurs auprès desquels ces jetons sont enregistrés. Les paramètres passés en interrogation de ce type de serveur sont : -identifiant de l'auteur de la requête, - désignation du ou des jetons concernés. Paramètres passés en réponse : - Adresses du ou des serveurs d'enregistrement des jetons concernés. 6. Serveurs de localisation des données Ces serveurs permettent aux serveurs de données de session et aux applicatifs de services clients de localiser les données, c'est-à-dire d'obtenir l'adresse des interfaces d'Entrée/Sortie des serveurs auprès desquels ces données sont enregistrées. Les paramètres passés en interrogation de ce type de serveur sont : - identifiant de l'auteur de la requête, - désignation du ou des données concernées. Paramètres passés en réponse : - Adresses du ou des serveurs d'enregistrement des données concernés. 7. Description d'un mode de réalisation On présente ci-après différents modes de mise en oeuvre du procédé d'obtention selon l'invention. On présente également des exemples de séquences d'échanges entre les différentes entités de réseau de communication utilisant des systèmes mettant en oeuvre le procédé selon l'invention. Pour des raisons de simplicité dans la description, on n'illustre ici l'utilisation du procédé que pour le cas d'un client recevant un jeton dans la signalisation et cherchant à obtenir les données de la session associée à ce jeton, mais le procédé est également destiné à être mis en oeuvre à tous les moments de la relation entre les serveurs de données de sessions et leurs clients, notamment pour la création ou la modification de session ou des droits associés, la définition de groupes fermés de clients, les échanges de notifications ou de messages de service. 7.1. Échanges au sein du système proposé Le tableau suivant détaille les messages correspondant aux requêtes des entités (serveurs) et aux réponses apportées par les entités destinatrices (serveurs de localisation) des messages, comme par exemple la demande de localisation de jeton suivi de la réponse de localisation de jeton. La colonne message contient l'abrégé des messages qui seront utilisés lors des descriptions des figures suivantes. Il ne s'agit que d'une représentation. Les messages, lors de leur mise en oeuvre pourront avoir des formulations différentes. Message utilisation paramètres dLJ(j) demande de localisation de jeton - jeton - historique de l'appel rLJ(sj) réponse de localisation de jeton - nom du serveur ayant délivré le jeton dLC(c) demande de localisation de client - identifiant du client rLC(c) réponse de localisation de client - nom d'un serveur auprès duquel est enregistré le client dLS(s) demande de localisation de session - identifiant de la session rLS(s) réponse de localisation de session nom du serveur de données de session qui gère la session dLG(g) demande de localisation de Groupe - identifiant du Groupe fermé fermé de clients de clients rLG(g) réponse de localisation de Groupe nom du serveur sur lequel est fermé de clients défini le contenu de ce Groupe fermé de clients dAC(c) demande d'autorisation client - identifiant du client rAC réponse d'autorisation client - OK ou NOK dSA ' demande identifiant de la session jeton ~) associée au jeton rSA(s) réponse identifiant de la session associée identifiant de la session au jeton dDS(s) demande de description de la session - identifiant de la session rDS(s) réponse de description de la session - description de la session dAG(c,g) demande des droits d'un client dans un - identifiant du client groupe - identifiant du groupe rAG réponse droits d'un client dans un groupe - droits du client dRS(s) demande de lecture des données de la identifiant de la session session rRS(ds) réponse de lecture des données de la données de la session session dRD demande de lecture des données - identifiant des données rRD réponse de lecture des données - données 7.1.1. Scénarios de base Dans ces scénarios, on illustre différents modes de mise en oeuvre sans optimisation, c'est-à-dire sans qu'il soit mis en oeuvre de système de simplification, par exemple de création d'adresse. 7.1.1.1. Exemple d'un système où les serveurs applicatifs clients n'ont qu'un accès indirect aux différents serveurs, chacun via un serveur de données de session donné Dans un tel mode de mise en oeuvre, l'espace d'échange bien qu'ouvert, apparaît comme fermé pour un serveur applicatif client, et ce client ne peut accéder qu'indirectement, via un serveur de données de session auprès duquel il est enregistré, aux différents serveurs de localisation des informations et serveurs détenteurs de ces informations. On présente, en relation avec la figure 2, un exemple de séquencement permettant l'obtention de données applicatives auprès d'un serveur de données de session (SDSS) par un applicatif de service (C2) client d'un serveur de données de session (SDS2) lui-même considéré comme étant un client des autres entités du réseau (le serveur de localisation de jeton SLJ, etc.). Ici, le serveur de données de session SDS1 intervient pour la fourniture de l'identifiant de la sessions associée au jeton. Le serveur de données de session SDS3 intervient pour la fourniture de la description de la session. Le serveur de données de session SDS4 intervient pour la fourniture de données relatives aux groupes (fermé) de client. Le serveur de données de session SDSS intervient pour la fourniture des données applicatives de session en tant que telles. Les messages échangés sont ceux décrits dans le tableau précédent.
Dans cet exemple, le serveur de données de session (SDS2) agit comme un intermédiaire du client (C2) auprès d'un des serveurs de localisation d'une information (jeton, session, ou groupe fermé de client ), ou d'un serveur à même de délivrer cette information. Le serveur cible n'a pas à vérifier que le client est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, puisqu'il fait confiance au serveur (SDS2) qui l'interroge, qui est celui auprès duquel le client (C2) est enregistré. On suppose que, préalablement aux requêtes de l'applicatif de service C2, d'autres applicatifs de service ont renseigné des données, ou ont permis l'enregistrement de données au sein d'au moins certain des serveurs de données de session SDS1, SDS2, SDS3, SDS4 et SDSS. Tous les échanges doivent passer par le serveur de données de session (SDS2) de rattachement utilisé, quelque soit le volume des données. Mais le protocole client/serveur de données de session reste simple, toute la problématique de la localisation des données étant gérée par le serveur de données de session. Les références utilisées dans les figures 3 à 8, 11, 12 et 13, ainsi que les hypothèses préalables de renseignement de données sont les mêmes que dans cette figure 2. 7.1.1.2. Exemple d'un système où les serveurs applicatifs clients ont un accès direct aux différents serveurs Dans un tel mode de mise en oeuvre, l'espace d'échange est totalement ouvert, et le client peut accéder directement aux différents serveurs de localisation des informations et serveurs détenteurs de ces informations. Il n'est donc pas nécessaire, que le client (C2) passe par le serveur de données de session (SDS2) auquel il est attaché pour obtenir les informations dont il a besoin. On présente, en relation avec la figure 3, un exemple de séquencement des échanges au niveau applicatif. Les rôles des différents serveurs sont les mêmes que dans la figure 2. Dans cet exemple, les serveurs obtiennent auprès du serveur de données de session (SDS2) où le client (C2) est enregistré, les autorisations (messages dAC et messages rAC) permettant de savoir si le client (C2) dispose des autorisations nécessaires à l'obtention des données qu'il réclame. Ainsi, à chaque fois que le client (C2) accède à un serveur de localisation d'une information (jeton, session, ou Groupe fermé de clients ), ou à un serveur à même de délivrer cette information, ce serveur doit vérifier que le client est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients et du serveur auprès duquel ce client est enregistré.
7.1.1.3. Exemples d'un système où les serveurs applicatifs clients accèdent aux différents serveurs, après un accès initial via un serveur de données de session propre Dans un tel mode de mise en oeuvre, l'espace d'échange est ouvert, mais la navigation d'un serveur applicatif client (C2) en son sein est pilotée de manière à ce que ce client ne puisse accéder aux différents serveurs détenteurs des informations qu'après un accès initial via un serveur de données de session particulier (SDS2). Des exemples de séquencement sont présentés en relation avec les figures 4 et 5. Les rôles des différents serveurs sont les mêmes que dans la figure 2. Ce serveur de données de session particulier (SDS2) peut être un serveur de données de session auprès duquel ce client est enregistré. Il peut être unique. Ici aussi, à chaque fois que le client accède directement à un serveur de localisation d'une information (jeton, session, ou Groupe fermé de clients ), ou à un serveur à même de délivrer cette information, ce serveur doit vérifier que le client (C2) est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients et du serveur auprès duquel ce client est enregistré.
7.1.1.3.1. Accès initial pour la localisation du jeton On présente, en relation avec la figure 4, un cas où le serveur de données de session (SDS2) auquel le client (C2) accède initialement est utilisé pour obtenir la localisation du jeton.
A chaque fois que le client (C2) accède à un serveur de localisation d'une information (session, ou Groupe fermé de clients ), ou à un serveur à même de délivrer cette information, ce serveur doit vérifier que le client (C2) est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients (SLC) et du serveur auprès duquel ce client est enregistré (SDS2). Les différents serveurs de localisation sont donc utilisés tant par le serveur de données de session (SDS2) et le client (C2) pour retrouver la localisation d'informations que par les autres entités du réseau pour retrouver, par exemple, des informations sur le client (C2). 7.1.1.3.2. Accès initial pour l'obtention de l'identifiant de session On présente, en relation avec la figure 5, un cas où le serveur de données de session (SDS2) auquel le client (C2) accède initialement est utilisé pour obtenir directement la session associée au jeton, la localisation du jeton étant gérée par ce serveur de données de session (SDS2). Dans ce cas, à chaque fois que le client (C2) accède à un serveur de localisation d'une information (session, ou Groupe fermé de clients ), ou à un serveur à même de délivrer cette information, ce serveur doit vérifier que le client (C2) est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients (SLC) et du serveur (SDS2) auprès duquel ce client est enregistré. 7.1.1.3.3. Accès initial pour l'obtention de la description de la session On présente, en relation avec la figure 6, un cas où le serveur de données de session (SDS2) auquel le client (C2) accède initialement est utilisé pour obtenir directement la session associée au jeton et la localisation de celle-ci, la localisation du jeton étant gérée par ce serveur de données de session (SDS2). A chaque fois que le client (C2) accède à un serveur de localisation de session (SLS) ou au serveur de données de session à même de délivrer l'information de session (SDS3), ce serveur doit vérifier que le client est bien celui qu'il prétend être et qu'il a le droit d'accéder au système, en obtenant ici ces informations auprès d'un serveur de localisation des clients et du serveur auprès duquel ce client est enregistré. 7.1.2. Scénarios simplifiés par utilisation d'URLs et d'adresses simplifiées pour les jetons, et des passeports numériques On présente, dans les exemples qui suivent des modes de réalisation du procédé de l'invention basé sur l'utilisation d'URLs et d'adresses abrégées. Dans ces scénarios, on illustre différents modes de mise en oeuvre de la simplification des échanges avec les options de simplification suivantes concernant l'adressage : - utilisation d'étiquettes de type URL pour la désignation des sessions, Groupe fermé de clients et clients : leur localisation est donc implicite. -utilisation d'étiquettes de type <Identifiant émetteur>+<jeton> pour la désignation des jetons : leur localisation est donc implicite, tout en limitant la taille des jetons à un minimum acceptable pour leur transport sûr et conservant la confidentialité de la session d'usage sur différents réseaux. - On présente ici un exemple de telles adresses élémentaires. Ainsi, le valeur "331038400567" en décimal est décomposée comme suit : - "33" : désigne la France, "10" : désigne un opérateur, - "384" : désigne un porteur d'association jetons/session, - "00567" : est le jeton. La simple consultation d'une table en mémoire permet à chacune des parties de retrouver le porteur d'une association jetons/session, du moins dans les situations courantes.
Dans les réseaux utilisés couramment, l'information <Identifiant émetteur>+<jeton> peut être par exemple portée par les champs suivants de la signalisation : - RTC : paramètre "données de contexte" au sein de la "demande de reroutage" de la Signalisation Usager-PCS (spécification France Télécom), dans un message "facilité" du protocole D de commande d'appel pour les accès RNIS, - Web : cookie dans un message http de redirection; - VoIP/SIP : header "history info" - utilisation d'un système de type passeport numérique pour la mémorisation de l'information de validation de l'identification/authentification du client pour son parcours auprès des différents serveurs. Le cas où les serveurs applicatifs clients n'ont qu'un accès indirect aux différents serveurs n'a alors plus de sens.
7.1.2.1. Exemple d'un système où les serveurs applicatifs clients ont un accès direct aux différents serveurs On présente, en relation avec la figure 7, le cas d'un client qui n'est plus dans l'obligation de s'adresser à un serveur de localisation de jeton pour obtenir la localisation du jeton. En effet c'est le serveur de données de session (SDS1) porteur de l'association jeton/session, premier système touché, qui vérifie les droits du client C2 (par exemple par l'utilisation d'un passeport numérique) avant de pouvoir lui répondre. On simplifie donc les échanges par rapport aux cas présentés dans la figure 3 et la figure 4. Ainsi, la simplification de l'adressage conduit à une suppression, au sein du réseau, des entités de localisation de jeton, de localisation de session et de localisation de groupe.
7.1.2.2. Exemple d'un système où les serveurs applicatifs clients accèdent aux différents serveurs, après un accès initial via un serveur de données de session propre On présente, en relation avec la figure 8, le cas où le serveur de données de session SDS2 auquel le client C2 accède initialement est utilisé pour obtenir l'identifiant de la session associée au jeton. Cet identifiant de session est ensuite, utilisé par la suite pour obtenir les données de la session d'usage. Ceci correspond à la simplification du cas présenté dans la figure 5, grâce à la réduction de la structure des adresses.
Ainsi, la simplification de l'adressage conduit à une suppression, au sein du réseau, des entités de localisation de jeton, de localisation de session, de localisation de client et de localisation de groupe. 7.1.3. Cas des appels avec franchissement de passerelles entre opérateurs ou entre réseaux Dans certains cas, il n'est pas aisé au client qui reçoit un appel, au sens large, c'est-à-dire une demande d'ouverture ou de continuation d'une session de communication, de déterminer d'emblée le porteur d'une association jeton/session, ne serait-ce que parce que l'appel a franchi une passerelle entre deux opérateurs, ou entre deux réseaux de nature différente. En effet, dans ce cas, il est fort probable que l'information soit transformée en termes de support (champs non strictement équivalents dans les signalisations utilisées) et en termes de contenu (codages différents). L'utilisation de systèmes permettant de retrouver l'information originelle 15 s'impose alors, un tel système mettant en oeuvre un serveur de localisation de jetons dotés de fonctionnalités particulières et opérant comme suit. 7.1.3.1. Fonctionnement d'un serveur de localisation des jetons Deux types de serveur de localisation de jetons peuvent être imaginés. Un premier type, que nous qualifierons d'actif, est capable de stocker en 20 interne les informations décrivant le changement de forme d'un jeton lors de la traversée d'une passerelle, sans que le serveur de données de session en charge de la session en soit informé. Lorsqu'un tel serveur de localisation de jetons est interrogé, il est capable de restituer le jeton originel et le serveur de données de session porteur de l'association jeton/session. 25 Un second type de serveur de localisation de jetons, que nous qualifierons de passif, utilise le serveur de données de session pour stocker les informations décrivant le changement de forme d'un jeton lors de la traversée d'une passerelle. Lorsqu'un tel serveur de localisation de jetons est interrogé, il est capable à partir du jeton courant de désigner le serveur de données de session porteur de 30 l'association jeton/session. 7.1.3.1.1. Serveur de localisation des jetons actif Le serveur de localisation des jetons actif, supposé ici unique, se comporte comme un serveur de données de session aux fonctionnalités réduites et a les fonctions suivantes : - Sur la demande d'une passerelle inter-réseau, recevant une demande d'appel sur un réseau et souhaitant la propager sur un autre réseau mais devant pour cela changer certaines informations constitutives de ce que l'on peut appeler un "contexte de jeton", par exemple : - Jeton, ou <adresse porteur de l'association J/S>+<jeton>, ou <type de jeton>+<jeton>, - réseau sur lequel est reçu le jeton, ou <adresse de la dernière passerelle inter-réseau empruntée>, - identifiant d'appel ou de session de communication sur le réseau, - adresses "demandeur" et "demandé" de l'appel, - données d'historique d'appel (signalisation). - stocke en interne le contexte de jeton entrant, 20 - stocke également en interne le nouveau jeton utilisé par la passerelle, demandé auparavant par elle à un serveur de données de session (le SLJ pourrait le faire, dans une autre option de mise en oeuvre), - associe ce nouveau jeton au contexte de jeton et à l'ancien jeton, 25 - retrouve une adresse d'un porteur d'une association jetons/session avec l'ancien jeton à partir du jeton courant et du contexte de jeton auparavant mémorisés, - restitue à un client porteur du nouveau jeton cette adresse, avec les deux jetons, afin que ce client puisse retrouver la session associée. 15 On présente, en relation avec la figure 9, un enchaînement d'action conduisant à l'échange de données de session entre des plateformes de services PFS A et PFS B communicant par le biais d'un intranet entre les plateformes de services et les serveurs de données de sessions PFS-SDS . Les plateformes de services PFS A et PFS B sont situées sur des réseaux de télécommunications différents et sont interconnectées par le biais d'une passerelle P . Ces actions se produisent selon la séquence suivante : 1) demande (901) de jeton [dj(1)] de la plateforme de services PFS A vers le serveur de données de session SDS1 , pour 1 jeton ; 2) réponse (902) à la demande de jeton [rJ(j')] fournissant un jeton j', ensuite association du jeton à la session S' ; 3) transmission (903) par la plateforme de services PFS A du jeton j' dans la signalisation, reçu par la passerelle inter-réseau P ; 4) la passerelle P informe (904) le serveur de localisation de jeton SLJ que le jeton j' est associé au contexte de jeton cj', par le message [iCJ(j', cj')] ; 5) la passerelle P demande (905) un jeton [dJ(1)] au serveur de données de session SDS 2 , pour 1 jeton ; 6) le serveur de données de session SDS 2 répond (906) à la demande 20 de jeton [rJ(j ")], j" (ce jeton n'est pas ensuite associé à la session S', car il est utilisé comme alias) ; 7) la passerelle P informe (907) le serveur de localisation de jetons SLJ que le jeton Pest un alias du jeton j', par le message iCJ(j" = j') (le serveur de localisation de jetons SLJ les associe en interne) ; 25 8) transmission (908) par la passerelle P du jeton j" dans la signalisation, reçu par la plateforme de services PFS B ; 9) la plateforme de services PFS B demande (909) au serveur de localisation de jeton SLJ la localisation du jeton j", par le biais du message dLJ(j ") ; 10) le serveur de localisation de jeton SLJ répond (910) à la plateforme de services PFS B , par le biais du message rLJ(j"= j', SDS 1), que le jeton j" est un alias du jeton j' et que le porteur de l'association de j' a une session est le serveur de données de session 1, qu'elle peut maintenant interroger. Ainsi, si les passerelles inter-réseau ne peuvent transporter sans modification certaines informations du contexte de jeton, dont notamment le jeton, elles peuvent faire appel au serveur de localisation de jetons pour qu'il conserve la trace de cette modification et puisse restituer au client immédiatement en aval les informations de localisation correcte. Cela demande cependant un enrichissement du protocole d'échanges entre le serveur de localisation de jeton et les passerelles et clients. 7.1.3.1.2. Serveur de localisation des jetons passif Le serveur de localisation des jetons passif, supposé ici unique, a les fonctions suivantes : - Sur la demande d'une passerelle inter-réseau, recevant une demande d'appel sur un réseau et souhaitant la propager sur un autre réseau mais devant pour cela changer certaines informations constitutives de ce que l'on peut appeler un "contexte de jeton" (mais sans modification du jeton), par exemple : - Jeton, ou <adresse porteur de l'association J/S>+<jeton>, ou <type de jeton>+<jeton>, - réseau sur lequel est reçu le jeton, ou <adresse de la dernière passerelle inter-réseau empruntée>, -identifiant d'appel ou de session de communication sur le réseau, -adresses "demandeur" et "demandé" de l'appel, - données d'historique d'appel (signalisation). 30 - stocke en interne le contexte de jeton entrant, - retrouve le contexte de jeton à partir du jeton mémorisé, -restitue à un client porteur du jeton le contexte de jeton contenant l'adresse du serveur de données de session porteur de l'association J/S, afin que ce client puisse retrouver la session associée. On présente, en relation avec la figure 10, un enchaînement d'action conduisant à l'échange de données de session entre des plateformes de services PFS A et PFS B . Les plateformes de service PFS A et PFS B communiquent par le biais d'un intranet PFS-SDS avec les serveurs de données de sessions. Les plateformes de services PFS A et PFS B sont situées sur des réseaux de télécommunications différents et sont interconnectées par le biais d'une passerelle P . Ces actions se produisent selon la séquence suivante : 1) demande (1001) de jeton [dj(1)] de la plateforme de services PFS A vers le serveur de données desession SDS1 , pour 1 jeton ; 2) réponse (1002) à la demande de jeton [rJ(j')] fournissant un jeton j', suivi d'une association du jeton à la session S' ; 3) transmission (1003) par la plateforme de services PFS A du jeton j' dans la signalisation, reçu par la passerelle inter-réseau P ; 4) la passerelle P informe (1004) le serveur de localisation de jeton SLJ que le jeton j' est associé au contexte de jeton cj', par le message [iCJ(j', cj')] ; 5) transmission (1005) par la passerelle P du jeton j' dans la signalisation, reçu par la plateforme de services PFS B ; 6) la plateforme de services PFS B demande (1006) au serveur de localisation de jeton SLJ la localisation du jeton j', par le message [dLJ(j')] ; 7) le serveur de localisation de jeton SLJ répond (1007) à la plateforme de services PFS B que le porteur de l'association de j' a une session est le serveur de données de session SDS1 , par le message [rLJ(j', SDS1)] et qu'elle peut maintenant l'interroger. Ainsi, si les passerelles inter-réseau ne peuvent transporter sans modification certaines informations du contexte de jeton, mais sans altération cependant du jeton, elles peuvent faire appel au SLJ pour qu'il conserve la trace de cette modification et puisse restituer au client immédiatement en aval les informations de localisation correcte. Cela demande cependant qu'un enrichissement du protocole d'échanges entre le serveur de localisation de jetons et les passerelles, mais pas entre le 10 serveur de localisation de jeton et les clients.
7.1.3.2. Scénarios simplifiés avec serveur de localisation de jetons 7.1.3.2.1. Exemple d'un système où les serveurs applicatifs clients ont un accès direct aux différents serveurs Cet exemple est présenté en relation avec la figure 11. 15 Le client C2 doit ici s'adresser au serveur de localisation de jetons SLJ pour obtenir la localisation du jeton, en lui indiquant par exemple le réseau d'où provient le jeton et les paramètres réseau reçus (adresses départ et arrivée, ou information d'historique par exemple). De son côté, le serveur de localisation de jetons SLJ, qui est le premier 20 système touché, doit vérifier les droits du client C2 avant de pouvoir lui répondre. Ici, les serveurs de localisation de session et les serveurs de localisation de groupes deviennent inutiles.
7.1.3.2.2. Exemples d'un système où les serveurs applicatifs clients accèdent aux différents serveurs, après un accès initial via un serveur de données de session 25 propre Dans un tel mode de mise en oeuvre, le client ne peut accéder aux différents serveurs détenteurs des informations qu'après un accès initial via un serveur de données de session particulier auprès duquel ce client est enregistré. Ce serveur de données de session peut être unique. 30 7.1.3.2.2.1. Accès initial pour la localisation du jeton En relation avec la figure 12, le serveur de données de session SDS2 auquel le client C2 accède initialement est utilisé pour obtenir la localisation du jeton. C'est ce serveur de données de session SDS2 qui doit s'adresser au SLJ pour obtenir la localisation du jeton, en lui indiquant par exemple le réseau sur lequel le client C2 a reçu et les paramètres réseau (adresses départ et arrivée, ou information d'historique par exemple) et que le client lui a retransmis. Ici, les serveurs de localisation de client, de session et de groupe de clients deviennent inutiles. 7.1.3.2.2.2. Accès initial pour l'obtention de l'identifiant de session En relation avec la figure 13, le serveur de données de session SDS2 auquel le client C2 a accédé initialement est utilisé pour obtenir l'identifiant de la session associée au jeton, la localisation du jeton étant recherchée par le serveur de données de session SDS2 de rattachement qui doit s'adresser au serveur de localisation de jeton SLJ pour obtenir la localisation du jeton, en lui indiquant par exemple le réseau sur lequel le client a reçu et les paramètres réseau reçus (adresses départ et arrivée, ou information d'historique par exemple) et que le client lui a retransmis. Ici, les serveurs de localisation de client, de session et de groupe de clients deviennent inutiles. 7.2. Architecture d'un dispositif d'obtention On présente, en relation avec la figure 14, une architecture simplifiée d'un serveur de données de session selon l'invention. Il comprend une mémoire 141, et une unité de traitement 140 équipée d'un microprocesseur, qui est piloté par un programme d'ordinateur (ou application) 142. L'unité de traitement 140 reçoit en entrée, via un module d'interface d'entrée réseau 143, des réponses (adresses ou données) et des notifications 144. Ces informations sont traitées par le microprocesseur, selon les instructions du programme 142, pour : - émettre des messages de service 146a ; - émettre des requêtes 146b, par exemple des requêtes d'obtention de données de session ou d'adresses de localisation ; Ces données sont transmises via un module d'interface de sortie réseau 145 à destination des dispositifs du réseau de communication qui en ont la charge.5

Claims (9)

REVENDICATIONS
1. Procédé de transmission de données, dans le cadre d'une communication établie entre au moins deux entités, caractérisé en ce qu'il comprend : -une étape de réception par une entité réceptrice d'un message requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : un identifiant de typologie, désignant un type de message prédéfini ; - une information représentative desdites données applicatives à obtenir ; une étape d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.
2. Procédé de transmission selon la revendication 1, caractérisé en ce qu'il comprend, postérieurement à ladite étape d'identification, une étape d'émission d'un deuxième message à destination dudit serveur de localisation, ledit deuxième message comprenant : - un deuxième identifiant de typologie, définissant un type dudit deuxième message parmi au moins deux types prédéfinis ; - ladite information représentative des dites données applicatives à localiser.
3. Procédé de transmission selon la revendication 2, caractérisé en ce qu'il comprend, postérieurement à ladite étape d'émission dudit deuxième message, une deuxième étape de réception d'un message de localisation, en provenance dudit serveur de localisation, ledit message de localisation comprenant au moins une adresse applicative représentative d'une entité apte à délivrer lesdites données applicatives.
4. Procédé de transmission selon la revendication 3, caractérisé en ce que ladite adresse applicative comprend au moins une interface d'entrée/sortiequi est fonction d'au moins un traitement applicatif à réaliser.
5. Procédé de transmission selon l'une quelconque des revendications 3 et 4, caractérisé en ce qu'il comprend, postérieurement à ladite deuxième étape de réception de ladite adresse applicative : - une étape de vérification d'une autorisation de ladite entité émettrice à requérir lesdites données applicatives ; une étape d'interrogation de ladite entité apte à fournir lesdites données applicatives en fonction de ladite adresse applicative lorsque ladite autorisation est accordée.
6. Procédé de transmission selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite typologie de message comprend des types de messages appartenant au groupe comprenant au moins : des messages de service ; - des notifications ; - des commandes ; - des requêtes.
7. Système de transmission de données incluant au moins deux entités, caractérisé en ce qu'il comprend : - des moyens de réception inclus dans une entité réceptrice d'un message 20 requérant des données dites applicatives, émis par une entité émettrice, ledit message incluant : un identifiant de typologie, désignant un type de message prédéfini ; - une information représentative desdites données applicatives à 25 obtenir ; -des moyens d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie. 30
8. Dispositif de transmission incluant :des moyens de réception d'un message requérant des données applicatives, ledit message comprenant : un premier identifiant de typologie, désignant un type de message prédéfini ; une information représentative desdites données applicatives à obtenir ; des moyens d'identification d'au moins un serveur, dit serveur de localisation, apte à localiser lesdites données applicatives à obtenir en fonction de ladite information représentative et dudit identifiant de typologie.
9. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de transmission selon l'une au moins des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur.
FR0756607A 2007-07-19 2007-07-19 Procede d'obtention de donnees applicatives Pending FR2919141A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0756607A FR2919141A1 (fr) 2007-07-19 2007-07-19 Procede d'obtention de donnees applicatives
PCT/FR2008/051358 WO2009013441A1 (fr) 2007-07-19 2008-07-17 Procede d'obtention de donnees applicatives

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0756607A FR2919141A1 (fr) 2007-07-19 2007-07-19 Procede d'obtention de donnees applicatives

Publications (1)

Publication Number Publication Date
FR2919141A1 true FR2919141A1 (fr) 2009-01-23

Family

ID=39322500

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0756607A Pending FR2919141A1 (fr) 2007-07-19 2007-07-19 Procede d'obtention de donnees applicatives

Country Status (2)

Country Link
FR (1) FR2919141A1 (fr)
WO (1) WO2009013441A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001042966A2 (fr) * 1999-12-13 2001-06-14 Novient, Inc. Synchronisation d'attributs et d'applications dans un environnement reseau reparti
US20030031164A1 (en) * 2001-03-05 2003-02-13 Nabkel Jafar S. Method and system communication system message processing based on classification criteria
WO2005059746A1 (fr) * 2003-12-17 2005-06-30 Telefonaktiebolaget Lm Ericsson (Publ) Systeme et procede de traitement de messages optimise de façon dynamique
US20050289096A1 (en) * 2004-06-23 2005-12-29 Nokia Corporation Method, system and computer program to enable SIP event-based discovery of services and content within a community built on context information
US20060047814A1 (en) * 2004-08-27 2006-03-02 Cisco Technology, Inc. System and method for managing end user approval for charging in a network environment

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001042966A2 (fr) * 1999-12-13 2001-06-14 Novient, Inc. Synchronisation d'attributs et d'applications dans un environnement reseau reparti
US20030031164A1 (en) * 2001-03-05 2003-02-13 Nabkel Jafar S. Method and system communication system message processing based on classification criteria
WO2005059746A1 (fr) * 2003-12-17 2005-06-30 Telefonaktiebolaget Lm Ericsson (Publ) Systeme et procede de traitement de messages optimise de façon dynamique
US20050289096A1 (en) * 2004-06-23 2005-12-29 Nokia Corporation Method, system and computer program to enable SIP event-based discovery of services and content within a community built on context information
US20060047814A1 (en) * 2004-08-27 2006-03-02 Cisco Technology, Inc. System and method for managing end user approval for charging in a network environment

Also Published As

Publication number Publication date
WO2009013441A1 (fr) 2009-01-29

Similar Documents

Publication Publication Date Title
EP1473904B1 (fr) Procédé et système d&#39;accès à un réseau poste à poste
EP1376410B1 (fr) Procédé de gestion d&#39;informations de contexte par serveur intermédiaire
WO2016001502A1 (fr) Orchestration de ressources physiques et virtuelles pour la livraison de contenus numériques
US20110161654A1 (en) Peer-to-peer telephony recording
EP1469660B1 (fr) Procédé pour contrôler l&#39;établissement de communications entre terminaux choisis par un utilisateur
EP1204044A1 (fr) Procédé et système d&#39;optimisation de consultations d&#39;ensembles de données par une pluralité de clients
EP1921819A1 (fr) Marqueur pour systèmes de communication composés d&#39;une pluralité de serveurs SIP
US20140317061A1 (en) System and method for distributed interaction media storage and retrieval
FR2855691A1 (fr) Securisation de la distribution de documents numeriques dans un reseau pair a pair
FR2802373A1 (fr) Systeme et methode pour personnaliser la qualite des services en fonction des clients dans un environnement informatique collaboratif
US11611492B2 (en) Conversational bots platform
EP1637989A1 (fr) Procédé et système de séparation de comptes de données personnelles
WO2007033814A2 (fr) Procédé d&#39;accès à des informations relatives à au moins un utilisateur permettant d&#39;entrer en contact avec lui ultérieurement
FR2919141A1 (fr) Procede d&#39;obtention de donnees applicatives
EP3123700B1 (fr) Procede de mise en cache d&#39;un contenu dans un reseau de distribution de contenus
FR2879868A1 (fr) Procede et systeme de rencontres par visiophonie dans un reseau de telecommunication
WO2015181462A1 (fr) Procédé de synchronisation de données entre différents équipements par l&#39;intermédiaire d&#39;un serveur
EP2171966B1 (fr) Gestion de sessions multi-flux entre un terminal et un serveur
FR2955682A1 (fr) Procede de fourniture d&#39;un code dynamique par l&#39;intermediaire d&#39;un telephone
FR2883685A1 (fr) Procede et systeme de partage d&#39;attributs personnels, module de partage/d&#39;insertion/de terminal, fournisseur d&#39;acces internet, serveur proxy, fournisseur de services et programme d&#39;ordinateur pour ce procede
FR3121808A1 (fr) Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation
WO2009013440A1 (fr) Procede d&#39;echange de messages entre serveur de donnees de session et des services clients
FR2918527A1 (fr) Procede et dispositif d&#39;insertion d&#39;une adresse dans une requete
EP1193946B1 (fr) Procéde et réseau de communication
FR3129504A1 (fr) Procédés, terminal et serveur de gestion de données personnelles