FR 2799326 A1 20010406 FR 9912352 A 19991004 Protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité de service Avec l'avènement de l'échange d'informations de toute nature, par l'intermédiaire des réseaux de transmission, le problème de la configuration, de l'occupation et de l'utilisation rationnelle de ces derniers est devenu d'une importance majeure, afin d'assurer une transmission de ces informations dans des conditions satisfaisantes. D'une manière générale, la transmission de ces informations peut être effectuée, par l'intermédiaire de ces réseaux, en mode connecté ou en mode non connecté. Lors d'une transmission en mode connecté, une entité appelante ne peut émettre d'informations vers une entité appelée sans avoir, au préalaole, demandé à cette dernière la permission de lui transmettre des blocs d'informations. Le processus de transmission en mode connecté implique donc la mise en #uvre d'un établissement de la connexion, succession de connexions multiples, d'un échange des blocs d'informations puis de la libération de la connexion. C'est le cas, par exemple, de la communication par le réseau téléphonique commuté, RTC, ou par le réseau numérique à intégration de services RNIS. Lors d'une transmission en mode non connecté, les informations sont transmises par routage vers une entité lointaine qui peut se trouver en état d'activité ou de non-activité. En cas de non-activité, cette dernière est remplacée par une boîte à lettres. Pour un tel mode de transmission, les caractéristiques des blocs de données transmises doivent être connues et à chaque transmission il est nécessaire de oreciser les informations de contrôle qui seront nécessaires pour que ces données transmises, et les Informations véhiculées car ces dernières, arrivent à destination. En particulier, l'adresse de l'entité lointaine, réceptrice, et de l'entité émettrice, doivent dans ce but être insérées dans le bloc de données transmises. C'est le cas en particulier de la transmission de messagerie électronique, de fichiers et d'applications pour lesquelles la communication en tempos réel n'est pas nécessaire. A l'heure actuelle, les travaux publiés sur le thème de la programmation, et la configuration, des réseaux connectés ont essentiellement concerné les processus de programmation et de configuration avec signalisation. On rappelle, en particulier, que ces processus avec signalisation consistent, essentiellement, à transporter les commandes de connexion, encore appelées signalisation, par l'intermédiaire d'un réseau de signalisation dit réseau sémaphore. Plus récemment, les Universités de Kansas et de Columbia (New York) aux Etats-Unis d'Amérique ont publié des travaux relatifs à la réservation de bande passante dans un réseau de transmission à l'aide du protocole de réservation de ressources GSMP, pour Gneric Switch Management Protoccl. Parmi ces travaux, on peut citer les articles ci-après : 1) "Realizing the MPEG-4 Multimédia Delivery Framework", IEEE Network Magazine pp.35-45, Novembre/décembre 1998. Spécial Issue on Transmission and Distribution of Digital Vidée, puolié par J.F. HUARD, A.A. LAZAP, K. S. LIM et G.S. TSELIKIS ; 2:' "A Programmable Transport Architecture with QOS Guarantee", IEEE Communications Magazine, Vol.36, No.lO, pp. 54-62, octobre 1998 publié par J.F. HUARD et A.A. LAZAR ; 3) "The IEEE p. 1520 Standards initiative for Programmable Network Interfaces", IEEE Communications Magazine, Vol.36, No.10, pp. 64-70, octobre 1998, publié par J. BISWAS, A. A. LAZAR, J.F. HUARD, K.S. LIM, S. MAHJOUB, L. F. PAU, M. SUZUKI, S. TORTENSSON, W.WANG et S. WEINSTEIN ; 4) "Programming Télécommunication Networks", IEEE Network Magazine pp. 8-18, septembre/octobre 1997, publié par A.A.LAZAR. En outre, des procédures de demande d'établissement d'une connexion à travers un réseau par l'intermédiaire d'un navigateur "web" ont fait l'objet ce travaux. Parmi ceux-ci, on peut citer : 5) l'article intitulé "Session Ccntrol for Broadband Multimédia Services using the HTT P Protocol", ATM Forum, février 1997, publié par GOTA LEIJONHUFVUD Ericsson Telecom AB. Enfin, les procédures RMI (.Revote Method Invocation) et HTML (Hyper Text Marked Language) sont connues en environnement JAVA pour lancer des applications dans une architecture client-serveur sur un réseau non connecté. Les procédures mentionnées précédemment donnent satisfaction, mais elles doivent utiliser le même réseau pour assurer la transmission des flux d'informations de l'application. A titre d'exemple, il n'existe pas dans les procédures précitées de moyens d'indiquer vers le réseau utilisé la valeur et le type de qualité de service requis. En outre, dans les procédures précitées, il n'existe a priori aucun couplage permettant d'assurer le lancement d'une connexion d'un réseau connecté, ni a fortiori une application, ce dernier étant distinct et indépendant du réseau non connecté. La présente invention a pour objet de remédier aux inconvénients e: limitations ces procédures de l'art antérieur par la mise en #uvre d'un protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité de service, un terminal appelant étant ainsi mis en mesure de lancer une application à distance sur un terminal appelé lorsque ces terminaux sont reliés sur un réseau connecté. Un autre objet de la présente ir.vention est en outre la mise en #uvre d'un protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité ce service dans lequel, préalablement au lancement effectif de l'application, le terminal appelant a effectué, par réservation, des connexions à partir d'un réseau non connecté. Un autre objet de la présente invention est également, après réalisation de la connexion par le réseau connecté entre le terminal appelant et le terminal appelé, la mise en #uvre d'un protocole permettant la mise en #uvre d'une communication avec un débit à qualité de service garanti sur le réseau connecté. Un autre objet de la présence invention est enfin la mise en #uvre d'un protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité de service plus particulièrement destiné à la gestion de communications visiophoniques à partir d'un même ensemble intégré au niveau du terminai appelant. Le protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité de service encre un terminal appelant et un terminal appelé, objet de la présente invention, est remarquable en ce qu'il consiste à transmettre, à partir du terminal appelant vers le terminai appelé, une requête de réservation de connexion, par l'intermédiaire d'un serveur et d'une transmission par réseau non connecté et à établir, entre le terminal appelant et le terminal appelé, un processus de réservation de ressources réseau avec qualité de service, par échange de messages par l'intermédiaire de la transmission par le réseau non connecté. Sur acceptation de la réservation de ressources réseau par le serveur est établi, sur le même réseau physique support du réseau non connecté, par l'intermédiaire d'un réseau de commande, un réseau connecté entre le terminal appelant et le terminal appelé. Le réseau connecté constitue la ressource réseau avec qualité de service pour exécuter l'application logicielle à distance entre le terminal appelant et le terminal appelé. Le protocole objet de la présente invention est destiné à la mise en #uvre à distance d'applications logicielles de tout type avec réservation de qualité de service, mais il est plus particulièrement destiné à des applications de visioconférence pour lesquelles la gestion de l'occupation de bande cessante des reseaux connectésen assurant l'exécution est primordiale. Le protocole objet de la présence invention sera maintenant exposé dans la description ci-après en liaison avec les figures en facilitant la compréhension dans lesquelles : la figure la représente, sous la forme d'un organigramme fonctionnel, les étapes de mise en #uvre du protocole objet de la présente invention ; la figure 1b représente un mode de réalisation particulier préférentiel du protocole objet de la présente invention dans le cas où le réseau non connecté est le réseau IP, pour Internet Protocol, et où le réseau connecté est le réseau ATM ; la figure le représente à titre illustratif l'architecture relative des réseaux connecté et non connecté dans le mode de réalisation de la figure 1b ; - la figure représente, à titre d'exemple illustratif, un détail ce mise en #uvre du protocole objet de la présente invention, dans un mode de mise en #uvre préférentiel dans lequel les messages de requête de réservation de connexion et de processus de réservation sont établis en environnement JAVA ; les figures 3a et 3b représentent des pages écrans affichées par le moniteur du terminal appelant respectivement du terminal appelé dans le cas d'une application de visioconférence. Le protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité de service, objet de la présente invention,. sera maintenant décrit en liaison avec la figure la et les figures suivantes. D'une manière générale, on indique que le protocole objet de la présente invention est destiné à être mis en #uvre entre un terminal appelant, noté TA, et un terminal appelé, noté TB. Bien entendu, le terminal appelant et le terminal appelé sont équipés des ressources nécessaires afin d'échanger des messages d'informations sous forme de fichiers et de préférence sous forme de pages écrans permettant l'instauration d'un dialogue interactif entre le terminal appelant TA et le terminal appelé TB. En référence à la figure la, on indique que, suite à une étape de début dans laquelle le terminal appelant TA et le terminal appelé TB sont nécessairement physiquement interconnectés à un réseau susceptible de mettre en communication ces derniers, le terminal appelé TB étant fonctionnellement indépendant du terminal appelant TA, le protocole objet de la présente invention consiste, à l'étape A, à transmettre à partir du terminal appelant TA vers le terminal appelé TB une requête de réservation de connexion, cette requête étant notée RRC et étant transmise par l'intermédiaire d'un serveur S et d'une transmission par un réseau non connecté. De par la transmission de cette requête par réseau non connecté, cette transmission implique les conditions de transmission précédemment mentionnées dans la description, relativement à la transmission de données ou de messages d'information sur le réseau non connecté. Suite à l'étape A précitée, le protocole objet de la présente invention consiste, en une étape B, à établir entre le terminal appelant TA et le terminal appelé TB, un processus de réservation de ressources réseau avec qualité de service. D'une manière générale, on indique que ce processus de réservation permet à l'utilisateur du terminal TA de définir certains paramètres relatifs aux ressources réseau avec qualité de service, ainsi qu'il sera décrit ultérieurement dans la description. Conformément à un aspect remarquable du protocole objet de la présente invention, on indique que le processus de réservation est établi par échange de messages par l'intermédiaire du serveur et de la transmission par réseau non connecté précédemment mentionné relativement à l'étape A. Sur acceptation de la réservation de ressources réseau par le serveur, le terminal appelé précité ou l'utilisateur de ce dernier étant susceptible d'accepter l'exécution de l'application, le protocole objet de la présente invention consiste, à l'étape C, à établir, de préférence sur le même réseau physique support du réseau non connecté, par l'intermédiaire d'un réseau de commande RC, un réseau connecté entre le terminal appelant TA et le terminal appelé TB. On rappelle ainsi que, lorsque le réseau connecté est établi, la transmission de messages d'information entre le terminal appelant TA et le terminal appelé TB satisfait aux conditions préalablement mentionnées dans la description relativement à la transmission de messages d'information sur un réseau connecté. Ainsi, le réseau connecté constitue la ressource réseau avec qualité de service permettant d'exécuter l'application logicielle à distance entre le terminal appelant et le terminai appelé. D'une mar.ière générale, en indique que pour réaliser la mise en #uvre du protocole objet de la présente invention, il est nécessaire que le réseau connecté destiné à transporter les flux d'informations avec qualité de service soit commandé de manière externe, la notion de commande externe couvrant à la fois la mise en #uvre d'un réseau de commande, le réseau RC, permettant de configurer les connexions successives du réseau connecté ou, le cas échéant, d'un système de traduction entre les messages transmis par le réseau non connecté afin d'effectuer la réservation des ressources et une signalisation existante telle que définie précédemment dans la description. Différents modes de réalisation spécifiques seront maintenant décrits en liaison avec les figures lb et lc, lesquelles visent à définir une architecture préférentielle des systèmes de réseaux connectés, respectivement de réseaux non connectés mis en #uvre pour assurer la conduite du protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité de service conforme à l'objet de la présente invention. D'une manière générale, en référence à la figure lb, on indique que les étapes consistant à transmettre la requête de réservation de connexion Rrc et à établir entre le terminal appelant et le terminal appelé un processus de réservation de ressources réseau avec qualité de service sont de préférence réalisées à partir du serveur. De même, en référence à la figure le, on indique que de manière particulièrement avantageuse, le serveur peut être constitué par un serveur "web". Dans ces conditions, les étapes consistant à transmettre la requête de réservation de connexion et à établir entre le terminal appelant TA et le terminal appelé TB un processus de réservation de ressources réseau avec qualité de service peut consister alors en l'envoi de messages HTML, pour Hyper Text Marked Language. En référence aux figures 1b et le, on indique que dans ce mode de réalisation préférentiel, le protocole objet de la présente invention permet de contrôler des liens d'un réseau ATM à partir d'un réseau IP, le réseau ATM constituant le réseau connecté et le réseau IP le réseau non connecté. Ainsi que représenté en figure 1b, on indique que des terminaux, terminal appelant TA et terminal appelé TB, disposent bien entendu d'une carte d'interconnexion en réseau de type IP et d'une carte d'interconnexion en réseau de type ATM, afin d'effectuer le transport des flux d'informations à qualité de service ou, le cas échéant, de disposer des deux piles de protocole sur la même carte d'interconnexion ATM ainsi qu'il est représenté sur la figure lb. Dans ce cas, les deux réseaux, réseau IP non connecté et réseau ATM connecté, sont constitués sur le même support physique. Er. particulier, les applications IP, c'est-à-dire les messages HTML ou analogue, sont transportées sur une émulation d'un réseau local LAN, pour Local Area Network, et les messages ATM peuvent être transmis dans la machine directement ou après la couche d'adaptation AAL. Ainsi, en référence à la figure ib, on indique que les deux piles de protocole sont supportées par le même support physique. En référence à la figure le, lorsque la connexion vers un serveur, tel qu'en particulier un serveur "web", est établie à partir du terminal appelant TA, le dialogue peut s'établir entre le terminal appelant précité et le serveur par l'intermédiaire du protocole HTTP d'un navigateur "web" pour le transfert des messages et le cas échéant de programmes, sous-programmes d'exécution ainsi qu'il sera décrit ultérieurement dans la description. Ensuite, le serveur peut alors lancer des ordres de connexion, ainsi que représenté sur la figure lc, les ordres de connexion étant lancés à un réseau de commande par l'intermédiaire d'un protocole IP CORBA, le réseau de commande comportant un BUS CORBA vers des stations génératrices de liens ATM. On indique que, de manière non limitative, en référence à la figure lc, la configuration du réseau ATM est réalisée à partir d'une plate-forme de programmation répartie, toute autre solution telle que la signalisation par un agent tiers pouvant être également envisagée. En référence à la figure le, on indique que, pour réaliser les connexions sur le réseau ATM, c'est-à-dire pour configurer le réseau connecté ainsi que représenté sur la figure précitée, le protocole utilisé entre le réseau de commande précédemment mentionné RC et le réseau ATM, constituant en fait le réseau de transport de l'application avec qualité de service, peut être réalisé par l'intermédiaire d'un protocole GSMP, pour Generic Switch Management Protocol. On comprend ainsi qu'au niveau du réseau connecté constituant le réseau de transport précité, ce réseau peut être constitué en différents sous-réseaux, sous-réseau 1, sous-réseau 2, de manière non limitative, les liens ATM entre terminal appelant TA et terminal appelé TB permettant bien entendu de réaliser l'interconnexion de ces derniers en des lieux quelconques. Une description plus détaillée d'un exemple spécifique de mise en #uvre du protocole objet de la présente invention, dans le cas où le réseau non connecté est un réseau IP et où le serveur est un serveur "web" par exemple, sera maintenant donnée en liaison avec la figure 2. Ainsi que représenté sur la figure précitée, les étapes consistant à transmettre la requête de réservation de connexion et à établir le processus de réservation de ressources réseau avec qualité de service, c'est-à-dire les étapes représentées en figure la aux points A, B, peuvent consister au moins à transmettre 1) du terminal appelant TA au serveur "web" une demande de connexion et, sur connexion du terminal appelant TA au serveur précité, à fournir 2) au terminal appelant TA une page d'entrée. La fourniture d'une page d'entrée au terminal appelant TA n'est pas décrite en détail figure 2, car une telle opération est une opération classique, lors d'un accès par un terminal à un serveur, selon le protocole de transmission par réseau IP. Suite à la fourniture de la page d'entrée, le protocole objet de la présente invention consiste en une étape 3) dans laquelle le terminal appelant procède à un téléchargement dans les mémoires constitutives de ce dernier à partir du serveur, et en particulier du serveur "web", d'un sous-programme de sélection de paramètres de qualité de service. Ainsi, le terminal appelant, à partir de ce sous-programme, sera en mesure, par l'intermédiaire du guidage de l'utilisateur de ce terminal appelant, de sélectionner les paramètres de transmission des informations relatives à l'application à exécuter. L'étape 3) précitée est alors suivie d'une étape 3a) représentée par une flèche en boucle fermée au niveau du terminal appelant TA consistant à établir, à partir du terminal appelant précité et du sous-programme de sélection, un choix de paramètres de qualité de service. Les étapes 3) et 3a) précédemment mentionnées sont alors suivies d'une étape 4) consistant, après avoir saisi les paramètres de la communication et de qualité de service désirés, à transmettre du terminal appelant TA au serveur, serveur "web", le choix des paramètres de qualité de service retenu. Suite à l'étape 4), il est alors possible d'établir, à partir du choix des paramètres de qualité de service retenu, la réservation des ressources de réseau connecté constituant les ressources réseau avec qualité de service précédemment mentionnées dans la description. La réservation des ressources précitée est établie à partir du serveur, serveur "web", vers le réseau ATM précédemment décrit en liaison avec les figures lb et lc par l'intermédiaire du réseau de commande RC. Ainsi, à la fin de l'étape 4), le réseau de commande RC établit une réservation de ressources sur le réseau ATM entre le terminal appelant TA et le terminal appelé TB. Suite à l'établissement de la réservation des ressources de réseau connecté, le protocole objet de la présente invention peut consister avantageusement à transmettre, en une étape 5a), à partir du terminal appelant TA vers le terminal appelé TB, une requête d'exécution d'application, cette requête d'exécution d'application comportant au moins un code d'identification du terminal appelant TA. On comprend bien sûr que l'étape de transmission de la requête d'exécution d'application peut alors être réalisée sur le réseau non connecté bien que la réservation des ressources de réseau connecté ait effectivement été effectuée et le réseau connecté ait ainsi été établi. D'une manière générale, on indique que la requête d'exécution d'application comporte au moins un code d'identification du terminal appelant TA. Suite à l'étape 5a) précitée, le protocole objet de la présente invention consiste, en une étape 5b), à établir au niveau du terminal appelé TB un processus de gestion de la requête d'exécution d'application. Sur la figure 2, pour cette raison, le processus de gestion réalisé à l'étape 5b) est représenté par une boucle fermée au niveau du terminal TB. Dans un mode de réalisation particulier préférentiel non limitatif, le processus de gestion représenté à l'étape 5b) peut comporter avantageusement, sur refus par le terminal appelé TB de la requête d'exécution de l'application, une étape de transmission par l'intermédiaire du circuit non connecté vers le terminal appelant TA d'un message de rejet de la requête d'exécution d'application et d'incitation du terminal appelant TA à libérer la réservation de connexion. Sur la figure 2, on indique que l'étape de transmission du message de rejet de la requête d'exécution est référencée 5c) . Au contraire, sur acceptation par le terminal appelé TB de la requête d'exécution, une étape de transmission par l'intermédiaire du circuit non connecté au terminal appelant d'un message d'acceptation de la requête d'exécution d'application et de lancement de cette application est réalisée. Sur la figure 2, l'étape précitée de transmission d'un message d'acceptation de la requête d'exécution d'application est notée 5d). Au contraire, en l'absence de réponse du terminal appelé TB pendant une durée prédéterminée, absence de réponse à la requête d'exécution d'application, le protocole objet de la présente invention consiste à effectuer la transmission, en une étape 5e), suite à la durée prédéterminée précitée par l'intermédiaire du circuit connecté vers le terminal appelant TA d'un message d'absence du terminal appelé TB. D'une manière générale, on indique que sur la figure 2, les étapes 5c), 5d) et 5e) sont globalement désignées par réponse de visio, visio désignant de manière générique une application dédiée à la visioconférence ainsi qu'il sera décrit ultérieurement dans la description. Le protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité de service, objet de la présente invention, peut être mis en #uvre, en ce qui concerne la requête de réservation de connexion et le sous-programme de sélection de paramètres de qualité de service, au moyen de sous-programmes, désignés communément par appliquettes ou encore applets en environnement JAVA. Dans ces conditions, on indique que l'étape de téléchargement dans le terminal appelant à partir du serveur d'un sous-programme de sélection de paramètres de qualité de service, peut consister avantageusement en le chargement d'une appliquette JAVA. Enfin, lors de la fin de l'exécution de l'application, c'est-à-dire lors de la fin de la transmission de messages d'information par le réseau ATM, le terminal appelant TA et le terminal appelé TB terminent leur application localement de manière semblable à la terminaison d'un appel téléphonique classique par exemple ou d'une communication sur le réseau RNIS. Suite à la terminaison de cette communication, le terminal appelant TA, lequel a établi la connexion, est alors incité à effectuer une opération de déconnexion permettant en fait de libérer à l'étape 7) les ressources auprès du serveur "web" précité du réseau ATM. La gestion de l'ensemble est donc complète, le réseau ATM étant alors totalement libéré et prêt pour une nouvelle reconfiguration ultérieure. Une description plus détaillée d'éléments spécifiques du protocole, objet de la présente invention, lorsque l'application est dédiée à une application de visioconférence, sera maintenant donnée en liaison avec les figures 3a et 3b. Dans une telle situation, on comprend que les informations vidéo relatives à la visioconférence sont transmises par le réseau ATM et que dans ce but, le sous- crogramme de sélection de paramètres de qualité de service constitué par une appliquette JAVA permet le choix des paramètres d'abonné, de bande passante et de multidiffusion pour Multicast. En ce qui concerne la mise en #uvre et la transmission d'appliquettes JAVA, on préférera le mécanisme RMI, pour Remote Method Invocation, créé par la société JAVASOFT, en raison de l'inadaptation du protocole RPC, pour Remcte Procedure Code, des systèmes objet distribués. Ce mécanisme RMI a pour objectif : - de supporter l'invocation distante des objets JAVA ; - d'intégrer le modèle objet distribué dans l'environnement JAVA de façon naturelle tout en gardant la sémantique objet du langage ; - de rendre simple le développement d'applications distribuées ; - de préserver la sécurité et la sûreté fournies par l'environnement JAVA précité. On indique que le mécanisme RMI précité fait appel aux notions client/serveur valables pour un appel. Le mécanisme RMI permet en fait d'invoquer à distance un objet JAVA, ce qui permet de satisfaire à deux des trois points critiques mentionnés précédemment, à savoir : - la dépendance de la mise en #uvre de ce mécanisme, ce mécanisme RMI utilisant en fait l'adresse IP pour retrouver le serveur RMI distant ; - en outre, un service de visioconférence impose, au niveau de chaque terminal, terminal appelant TA et terminal appelé TB, que le terminal appelé TB soit sous tension et connecté et. qu'un serveur RMI existe en tâche de fond sur chacun des terminaux précités. Au cours d'une communication, le terminal appelant TA est à la fois client et serveur RMI, et le terminal appelé TB est serveur RMI, même si le code est le même sur chacun des terminaux précités. Dans ces conditions, le service de visioconférence précédemment mentionné n'est donc pas complètement indépendant du terminal mais il a l'avantage d'être sécurisé car les seules actions possibles sur chaque terminal distant sont celles définies dans l'interface côté serveur. Afin de mettre en #uvre le service de visioconférence précité, il est toutefois nécessaire de prévenir le terminal appelé TB de la requête d'exécution d'application précédemment mentionnée dans la description. Dans le cadre de la mise en #uvre du protocole, objet de la présente invention, en environnement JAVA, une solution satisfaisante consiste à introduire, au niveau du terminal appelé, une boîte de dialogue JAVA invoquée à distance. Dans ces conditions, les mêmes références chiffrées correspondant aux étapes de mise en #uvre du protocole objet de la présente invention telles que représenté en figure 2 maintenant dédiées à une application de visioconférence, les étapes successives correspondantes sont données ci-après : 1) le terminal appelant TA se connecte au serveur "web" de ressources ; 2) une page HTML est fournie par ce dernier au terminal appelant TA. Le serveur "web" contient les informations nécessaires au service. Il assure la correspondance entre le nom et l'adresse IP du terminal appelant TA de manière similaire aux listes de diffusion dans les courriers électroniques ; 3) le terminal appelant TA télécharge l'appliquette JAVA, laquelle permet de choisir les paramètres de communication tels que abonné B, bande passante, multidiffusion pour multicast ainsi que mentionné précédemment, cette liste n'étant pas limitative. L'appliquette JAVA précitée, ainsi que représenté en figure 3a, comporte une page écran affichée au niveau du terminal appelant TA et comportant au moins deux boutons de sélection, un bouton de sélection "Connexion"/"Déconnexion" ainsi qu'un bouton de réglage du débit voulu pour assurer la transmission des données de visioconférence. Les autres paramètres peuvent servir pour la commande externe. Le bouton de réglage de débit est désigné par "Débit Kb" sur la figure 3a. De manière particulièrement avantageuse, on indique que le bouton de sélection "Connexion"/ "Déconnexion" est un bouton à fonction réattribuable. Selon un aspect particulièrement avantageux, au bouton de sélection "Connexion" est allouée, suite à la réservation de ressources de réseau avec qualité de service, une fonction de synchronisation entre la commande externe du réseau et le lancement de l'application de visioconférence. Un tel mode opératoire permet une synchronisation entre la commande externe de réseau et le lancement proprement dit de l'application de visioconférence car elle évite ainsi de lancer l'application précitée avant la réservation des ressources du réseau ATM sans lesquelles l'application ne peut bien entendu fonctionner. 4) L'appui sur le bouton "Connexion" à l'étape 4) déclenche le retour vers le serveur "web" de l'ordre d'établissement de la connexion. Dans ces conditions, le serveur "web" passe l'ordre de réservation au réseau de commande RC et ce dernier établit une réservation de ressources ATM entre le terminal appelant TA et le terminal appelé TB par allocation d'un chemin virtuel VP, pour Virtual Path, et d'un canal virtuel VC, pour Virtual Cnannel, par terminal après calcul de l'opération de routage. Dans l'exemple précité, la gestion du réseau est distribuée en référence à la figure lc à l'aide du protocole CORBA afin d'obtenir une meilleure efficacité lors de la commande des commutateurs assurant la connexion pour constituer le réseau connecté. 5a) lors de l'étape considérée, l'appliquette JAVA précédemment mentionnée comporte en outre une page écran affichée au niveau du terminal appelé TB. Cette page écran comportant deux boutons, un bouton d'acceptation, noté "Accepté", et un bouton de refus de lancement de l'application, bouton noté "refusé". L'action réalisée à l'étape 5a) précitée met ainsi en attente le terminal appelant avec un message du type "Appel en cours" et prévient de cette manière le terminal appelé TB d'une demande de visioconférence par l'intermédiaire de la boîte de dialogue, le cas échéant combinée à une sonnerie, cette boîte de dialogue lui indiquant l'identité du demandeur. Sur la figure 3b, on indique que le mot "Visio" désigne l'application de visioconférence de manière générique, "Karnak" désignant arbitrairement l'identité du terminal appelant. La boite de dialogue précitée telle que représentée en figure 3b peut avantageusement être constituée par une application JAVA lancée au moyen du mécanisme RMI précité et permet ainsi au terminal appelé TB de répondre au terminal appelant TA en fonction de sa décision. On comprend bien sûr que dans de telles conditions, la décision est prise par l'utilisateur du terminal appelé TB. La gestion de l'acceptation ou du refus peut alors être réalisée selon plusieurs choix à l'aide des deux boutons précédemment mentionnés en liaison avec la figure 3b, boutons d'acceptation ou de refus. L'utilisateur du terminal appelé peut ainsi réaliser les actions suivantes : a) il peut refuser la visioconférence demandée par appui sur le bouton "Refusé", cette action ayant pour effet de retourner alors un code permettant d'indiquer au demandeur que son correspondant ne désire pas la visioconférence et que l'utilisateur du terminal appelant TA a en charge de libérer les ressources précédemment réservées. C'est l'étape 5c) de la figure 2. b) Le terminal appelé peut accepter la visioconférence demandée par appui sur le bouton "Accepté", le code retour correspondant étant renvoyé et les applications de visioconférence étant alors lancées simultanément sur les deux terminaux, terminal appelant, terminal appelé, au moyen du mécanisme RMI. C'est l'étape 5d) de la figure 2. c) Le terminal appelé TB est connecté, mais il ne répond pas après la fin d'un module retardateur "timer" dont la durée peut être fixée de 15 à 20 secondes par exemple. Dans de telles conditions, on indique alors l'absence de l'utilisateur du terminal appelé TB au terminal appelant TA. Le timer précité peut avantageusement être déclenché au niveau du terminal appelé TB lors du lancement de la boîte de dialogue JAVA. C'est l'étape 5e) de la figure 2. 6) Lors de la fin de la communication, c'est-à-dire lors de la fin de l'application de visioconférence, les deux abonnés utilisateurs des terminaux, terminal appelé TA et terminal appelé TB, terminent leur application localement comme au téléphone par exemple. Le terminal appelant qui a établi la connexion doit alors terminer celle-ci par un appui sur le bouton "Déconnexion" ; L'appui par l'utilisateur au niveau du terminal appelant TA sur le bouton "Déconnexion" dont la fonction n'a pas été réattribuée permet alors de libérer les ressources après la fin de la visioconférence et de la fin de la communication. Le mécanisme de déconnexion peut alors être similaire à celui de la connexion mais avec l'ordre de libérer les ressources au lieu de les réserver. REVENDICATIONS 1. Protocole de lancement d'une application logicielle à distance et de réservation de ressources réseau avec qualité de service, entre un terminal appelant et un terminal appelé, caractérisé en ce qu'il consiste : - à transmettre, à partir du terminal appelant vers le terminal appelé, une requête de réservation de connexion, par l'intermédiaire d'un serveur et d'une transmission par réseau non connecté ; - à établir, entre le terminal appelant et le terminal appelé, un processus de réservation de ressources réseau avec qualité de service, par échange de messages par l'intermédiaire de ladite transmission par réseau non connecté, et sur acceptation de ladite réservation de ressources réseau par ledit serveur, - à établir, sur le même réseau physique support du réseau non connecté, par l'intermédiaire d'un réseau de commande, un réseau connecté entre ledit terminal appelant et ledit terminal appelé, ledit réseau connecté constituant ladite ressource réseau avec qualité de service pour exécuter ladite application logicielle à distance entre ledit terminal appelant et ledit terminal appelé. 2. Protocole selon la revendication 1, caractérisé en ce que ledit serveur étant constitué par un serveur "web", lesdites étapes consistant à transmettre la requête de réservation de connexion et à établir entre le terminal appelant et le terminal appelé un processus de réservation de ressources réseau avec qualité de service consiste en l'envoi de messages HTML. 3. Protocole selon l'une des revendications 1 ou 2, caractérisé en ce que lesdites étapes consistant à transmettre la requête de réservation de connexion et à établir ledit processus de réservation de ressources réseau avec qualité de service consiste au moins : - à transmettre dudit terminal appelant audit serveur une demande de connexion ; et, sur connexion dudit terminal appelant audit serveur, - à fournir audit terminal appelant une page d'entrée ; - à charger dans ledit terminal appelant, à partir dudit serveur, un sous-programme de sélection de paramètres de qualité de service ; - à établir, à partir dudit terminal appelant et dudit sous-programme de sélection, un choix de paramètres de qualité de service ; - à transmettre, dudit terminal appelant audit serveur ledit choix de paramètres de qualité de service ; - à établir, à partir du choix des paramètres de qualité de service, la réservation des ressources de réseau connecté, constituant les ressources réseau avec qualité de service. 4. Protocole selon l'une des revendications 1, 2 ou 3, caractérisé en ce que, suite à l'établissement de la réservation des ressources de réseau connecté, celui-ci consiste en outre : - à transmettre, à partir du terminal appelant, vers le terminal appelé, une requête d'exécution d'application, ladite requête d'exécution d'application comportant au moins un code d'identification du terminal appelant ; à établir, au niveau dudit terminal appelé, un processus de gestion de la requête d'exécution d'application. 5. Protocole selon la revendication 4, caractérisé en ce que ledit processus de gestion comporte : - sur refus, par ledit terminal appelé, de la requête d'exécution de l'application, une étape de transmission, par l'intermédiaire dudit circuit non connecté, audit terminal appelant d'un message de rejet de ladite requête d'exécution d'application et d'incitation du terminal appelant à libérer ladite réservation de connexion ; - sur acceptation par ledit terminal appelé de la requête d'exécution, une étape de transmission, par l'intermédiaire dudit circuit non connecté, audit terminal appelant d'un message d'acceptation de ladite requête d'exécution d'application et de lancement de cette application ; - sur absence de réponse dudit terminal appelé pendant une durée prédéterminée, transmission, suite à cette durée déterminée par l'intermédiaire du circuit non connecté, vers ledit terminal appelant d'un message d'absence du terminal appelé. 6. Protocole selon l'une des revendications 2 à 5, caractérisé en ce que la requête de réservation de connexion et le sous-programme de sélection de paramètres de qualité de service sont constitués par des appliquettes en environnement JAVA. 7. Protocole selon la revendication 6, caractérisé en ce que, pour une application logicielle constituée par une session de visioconférence, transmise par le réseau ATM, ledit sous-programme de sélection de paramètres de qualité de service constitué par une appliquette JAVA permet le choix des paramètres d'abonné, de bande passante, de multidiffusion. 8. Protocole selon la revendication 7, caractérisé en ce que ladite appliquette JAVA comporte une page écran affichée au niveau du terminal appelant comportant au moins deux boutons de sélection, un bouton de sélection "connexion"/"déconnexion" et un bouton de réglage du débit de transmission. 9. Protocole selon la revendication 8, caractérisé en ce que ledit bouton de sélection "connexion"/"déconnexion" est un bouton à fonction réattribuable, au bouton de sélection "connexion" étant alloué, suite à la réservation de ressources de réseau avec qualité de service, une fonction de synchronisation entre la commande externe du réseau et le lancement de l'application de visioconférence. 10. Protocole selon la revendication 8 ou 9, caractérisé en ce que ladite appliquette JAVA comporte en outre une page écran affichée au niveau dudit terminal appelé comportant deux boutons, un bouton d'acceptation et un bouton de refus de lancement de l'application.