Brevet FR2844369A1 — publié le 20040312

La présente invention concerne un procédé de proposition d'un 10 service fourni par un ordinateur serveur dans un réseau de communication. Elle concerne également un procédé de test d'accès à un service par un ordinateur client d'un réseau de communication à partir d'un document de description d'un service, ainsi qu'un procédé de vérification de compatibilité d'un protocole de communication à partir d'un document de description d'un service. 15 Au sein d'un réseau de communication informatique du type Internet, des ordinateurs serveurs offrent de plus en plus souvent des services à d'autres ordinateurs, appelés ordinateurs clients, de ce réseau de communication. En pratique, l'ordinateur client envoie des données à l'ordinateur serveur qui les traite et retourne un résultat. De tels services sont appelés services Web. Un service Web est un service identifié par une URI et accessible via XML et un protocole Internet. Du fait de l'augmentation de ces services disponibles sur un réseau de communication, les protocoles d'échange de données entre des ordinateurs 25 sont fréquemment standardisés. Ainsi, le protocole SOAP est un protocole permettant d'échanger des informations structurées au-dessus du réseau Internet. Selon ce protocole SOAP, les informations échangées sont structurées au moyen de balises XML (acronyme du terme anglais "eXtended 30 Markup Language"). La norme SOAP définit la structure générale des messages échangés ainsi que les traitements devant être réalisés par un ordinateur envoyant ou recevant des messages SOAP. Cette norme SOAP qui définit ainsi les échanges des informations 5 n'impose pas de protocole pour le transport des messages SOAP sur un réseau de communication. Tout protocole capable de transporter un message SOAP peut ainsi être utilisé. Cependant, comme un même protocole peut être utilisé de plusieurs 10 manières pour transporter un même message SOAP, il est nécessaire de définir un couplage (en anglais "binding") entre la norme SOAP et le protocole de transport afin de pouvoir utiliser ce protocole de transport. Ce couplage décrit en particulier comment le protocole de transport est utilisé pour transporter un message SOAP. Il peut en outre définir des 15 fonctionnalités complémentaires en fonction des besoins liés au protocole de transport. Ce type de couplage est notamment utilisé lorsqu'un service est fourni par un ordinateur serveur du réseau de communication. On connaît ainsi un langage de description d'un service informatique 20 WSDL (acronyme du terme anglais "Web Service Description Language") qui est particulièrement bien adapté à décrire un service sur un réseau de communication. Ce langage WSDL est lui-même une application du langage de balisage XML. On trouvera une description du langage WSDL 1.1 sur le site informatique à l'adresse http://www.w3.orcq/TR/2001 i/NOTE-wsdl-200 10315. Un document électronique de description d'un service en langage WSDL comporte essentiellement deux parties. Une première partie, appelée "partie abstraite" est adaptée à décrire les messages échangés entre ordinateur 30 du réseau de communication lors de la fourniture d'un service. En particulier, cette première partie permet de définir le type de données échangées, le type de message utilisé lors de l'exécution du service, ainsi que les opérations mises en oeuvre, définies par les messages qui sont échangés lors de l'exécution du service. Le document de description d'un service WSDL comporte également une seconde partie adaptée à définir des informations relatives à la transmission des messages sur le réseau de communication. Cette deuxième partie, appelée "partie concrète" précise notamment via un couplage (binding) le protocole de communication qui est effectivement utilisé pour le transfert des messages, ainsi que le format dans lequel les données seront représentées pour leur communication au sein du réseau de 10 communication. Ainsi, un tel document de description d'un service WSDL permet de spécifier quel protocole est utilisé par un service Web. En particulier, ce document peut spécifier comment ce protocole doit être utilisé ou quelles options de ce protocole peuvent ou doivent être utilisées. Par exemple, pour le 15 protocole HTTP (acronyme du terme anglais "HyperText Transfer Protocol"), un document de description d'un service permet de préciser quelle méthode (par exemple GET ou POST) permet d'accéder à un tel service. Cependant, un document de description d'un service tel que WSDL est limité à la description d'un protocole prédéfini et il ne peut pas s'adapter à 20 l'utilisation d'un protocole extensible dans lequel des fonctionnalités supplémentaires peuvent être incorporées. Un document WSDL ne permet pas non plus de décrire un protocole modulaire, c'est-à-dire comportant des fonctionnalités optionnelles, dont l'utilisation est laissée au libre arbitre de chaque ordinateur client. Il en résulte qu'un protocole tel que SOAP 1.2 ne peut tout simplement pas être décrit par un document WSDL, ce protocole étant à la fois modulaire et extensible. Tel est le cas notamment du protocole SOAP 1.2 qui est un protocole extensible, c'est-à-dire que la norme ne définit que le coeur du protocole, des 30 fonctionnalités supplémentaires pouvant être ajoutées à ce protocole. Ces fonctionnalités supplémentaires sont appelées "features". La norme SOAP propose une convention pour décrire ces fonctionnalités supplémentaires, cette convention reposant sur l'utilisation de propriétés associées à chaque fonctionnalité. On trouvera une description de la norme SOAP 1.2 à l'adresse électronique suivante: http://www.w3.org/TR/2002/WD-soapl 2-parti 20020626/ En particulier, chaque propriété est décrite par son nom et par les valeurs qu'elle peut prendre. La description de chaque fonctionnalité comprend, outre les propriétés, un modèle décrivant comment ces propriétés sont utilisées lors de la 10 mise en oeuvre de cette fonctionnalité. La présente invention a pour but de résoudre les inconvénients précités et de permettre en particulier l'accès à des services fournis sur un réseau de communication via un protocole de communication extensible tel que SOAP 1.2. A cet effet, la présente invention vise un procédé de proposition d'un service fourni par un ordinateur serveur dans un réseau de communication, mettant en oeuvre au moins un protocole de communication. Ce procédé comprend une étape d'envoi d'un document de description d'un service comprenant des informations relatives à des valeurs 20 impératives associées à au moins une fonctionnalité mise en oeuvre par ledit protocole de communication lors de l'exécution dudit service sur le réseau de communication. La présente invention permet ainsi au sein même d'un document de description d'un service de décrire complètement un protocole de 25 communication extensible en spécifiant quelles fonctionnalités doivent être utilisées et avec quelles valeurs impératives. Les fonctionnalités à utiliser et leur mode d'utilisation sont ainsi imposés par le serveur et indiqués à un ordinateur client. Cette description définie à l'intérieur même d'un document de 30 description d'un service envoyé à un ordinateur client, rend possible l'utilisation des extensions d'un protocole tel que SOAP 1.2. On peut ainsi spécialiser le protocole pour telle ou telle fonction et pour tel ou tel client du réseau de communication. Selon une caractéristique préférée de l'invention, ladite fonctionnalité supporte au moins une propriété et le document de description d'un service 5 comprend des informations relatives à au moins une valeur impérative associée respectivement à chaque propriété de ladite fonctionnalité. Le document de description d'un service permet ainsi de définir les valeurs impératives prises par une propriété d'une fonctionnalité, soit par une valeur unique, soit par une restriction du choix parmi des valeurs potentielles 10 prises par cette propriété. Selon une autre caractéristique préférée, ladite fonctionnalité est en outre associée à un attribut adapté à indiquer l'utilisation obligatoire ou non de cette fonctionnalité par un ordinateur client lors de la mise en oeuvre du protocole de communication pour l'exécution du service sur le réseau de 15 communication. L'utilisation d'un tel attribut permet d'indiquer le caractère optionnel ou non de l'utilisation d'une fonctionnalité associée à un protocole de communication pour l'exécution du service sur le réseau de communication. Lorsqu'un client utilise une fonctionnalité optionnelle, il doit suivre les 20 règles d'utilisation décrites dans le document via les valeurs des propriétés, comme dans le cas d'une fonctionnalité obligatoire. Dans un mode de réalisation pratique de la présente invention, le document de description d'un service est écrit dans un langage de balisage, les informations relatives à des valeurs impératives étant incluses dans une balise 25 référençant une fonctionnalité du protocole de communication. De préférence, les fonctionnalités sont choisies parmi des types de fonctionnalité (MEP, feature, module ou champ protocolaire) définis par un protocole d'échanges d'informations, tel que le protocole d'échanges d'informations SOAP. Lorsque le document de description d'un service est un document du type WSDL, comprenant une première partie incluant des informations relatives aux messages échangés lors de l'exécution du service et une seconde partie incluant des informations relatives à au moins un protocole de communication mis en oeuvre lors de l'exécution du service, les informations relatives à des valeurs impératives sont de préférence incluses dans la seconde partie de document de description d'un service. En pratique, ces informations relatives à des valeurs impératives sont incluses dans une balise référençant une opération comprenant un ou plusieurs messages échangés lors de l'exécution du service. Selon un autre aspect de l'invention, un procédé de test d'accès à un service par un ordinateur client d'un réseau de communication, à partir d'un 10 document de description d'un service comprenant des informations relatives à un protocole de communication comprend les étapes suivantes: - extraction des informations relatives à au moins une fonctionnalité mise en oeuvre par ledit protocole; - acquisition d'au moins une valeur impérative associée à ladite 15 fonctionnalité lors de l'exécution du service sur le réseau de communications; et - vérification si ladite valeur impérative associée à ladite fonctionnalité est supportée par l'ordinateur client du réseau de communication. Ainsi, le procédé de test d'accès à un service permet à un ordinateur client de vérifier directement à partir d'un document de description d'un service 20 s'il supporte les différentes fonctionnalités mises en oeuvre par un protocole de communication. De préférence, le procédé de test d'accès comporte, préalablement à l'étape d'acquisition, une étape de test adaptée à vérifier si la fonctionnalité est implémentée par l'ordinateur client et si l'utilisation de la fonctionnalité est 25 obligatoire ou non lors de la mise en oeuvre du protocole de communication pour l'exécution du service sur le réseau de communication. En pratique, ce test est mis en oeuvre à partir d'un attribut associé à la fonctionnalité et adapté à indiquer l'utilisation obligatoire ou non de la fonctionnalité par l'ordinateur client lors de la mise en oeuvre du protocole de 30 communication pour l'exécution du service sur le réseau de communication. Ainsi, le procédé de test d'accès, et plus particulièrement l'étape de vérification n'est mise en oeuvre que pour les fonctionnalités devant être utilisées de façon obligatoire par l'ordinateur client pour la mise en couvre du service sur le réseau de communication. En pratique, l'étape d'acquisition du procédé de test d'accès comprend les sous-étapes suivantes: - acquisition d'au moins une propriété associée à la fonctionnalité; et - acquisition d'au moins une valeur impérative associée à la propriété lors de la mise en couvre du protocole de communication pour l'exécution du service sur le réseau de communication. On peut ainsi vérifier pour chaque fonctionnalité si l'ensemble des propriétés décrivant cette fonctionnalité est bien supporté par l'ordinateur client du réseau de communication. Selon un troisième aspect de l'invention, un procédé de vérification de compatibilité d'un protocole de communication à partir d'un document de 15 description d'un service comprenant des informations relatives à un protocole de communication, comprend les étapes suivantes: - extraction du document de description d'un service d'une fonctionnalité mise en couvre par ledit protocole de communication lors de l'exécution du service sur le réseau de communication; - acquisition d'au moins une valeur impérative associée à ladite fonctionnalité dans le document de description d'un service; - acquisition d'une description de ladite fonctionnalité; et - vérification si ladite valeur impérative est incluse dans une liste de valeurs attribuables à une propriété supportée par ladite fonctionnalité. Lorsqu'un protocole de communication et ses fonctionnalités optionnelles sont décrites par exemple dans une représentation XML, il est possible de vérifier à partir du document de description d'un service si le protocole avec les valeurs particulières associées à chaque fonctionnalité est conforme à la description générale du protocole. Corrélativement, la présente invention concerne un dispositif de proposition d'un service fourni par un ordinateur serveur dans un réseau de communication mettant en couvre au moins un protocole de communication. Ce dispositif comprend des moyens d'envoi d'un document de description d'un service comprenant des informations relatives à des valeurs impératives associées à au moins une fonctionnalité mise en oeuvre par le protocole de communication lors de l'exécution du service sur le réseau communication. Elle concerne également un dispositif de test d'accès à un service par un ordinateur client d'un réseau de communication, à partir d'un document de description d'un service comprenant des informations relatives à un protocole de communication. Ce dispositif de test d'accès comprend des moyens d'extraction des informations relatives à au moins une fonctionnalité mise en oeuvre par le protocole, des moyens d'acquisition d'au moins une valeur impérative associée à cette fonctionnalité lors de l'exécution du service sur le réseau de communication, et des moyens de vérification adaptés à vérifier si la valeur 15 impérative associée à la fonctionnalité est supportée par l'ordinateur client du réseau de communication. Enfin, l'invention concerne un dispositif de vérification de compatibilité d'un protocole de communication à partir d'un document de description d'un service comprenant des informations relatives à un protocole 20 de communication. Ce procédé de vérification de compatibilité comprend des moyens d'extraction du document de description d'un service, d'une fonctionnalité mise en oeuvre par le protocole de communication lors de l'exécution du service sur le réseau de communication, des moyens d'acquisition d'au moins une valeur 25 impérative associée à la fonctionnalité dans le document de description d'un service, des moyens de description de la fonctionnalité, et des moyens de vérification adaptés à vérifier si la valeur impérative est incluse dans une liste de valeurs attribuables à une propriété supportée par la fonctionnalité. Ces dispositifs de proposition d'un service, de test d'accès à un 30. service et de vérification de compatibilité d'un protocole présentent des caractéristiques et avantages analogues à ceux des procédés qu'ils mettent en oeuvre. Par ailleurs, la présente invention concerne un ordinateur comportant un dispositif de proposition d'un service, ou un dispositif de test d'accès, ou un dispositif de vérification de compatibilité d'un protocole conformes à l'invention. Elle vise plus particulièrement un ordinateur serveur d'un réseau de 5 communication comprenant des moyens adaptés à mettre en oeuvre le procédé de proposition d'un service conforme à l'invention. Corrélativement, elle vise un ordinateur client d'un réseau de communication comprenant des moyens adaptés à mettre en oeuvre le procédé de test d'accès à un service conforme à l'invention. Plus généralement, la présente invention concerne un réseau de communication comprenant des moyens adaptés à mettre en oeuvre le procédé de proposition d'un service et/ou le procédé de test d'accès à un service et/ou le procédé de vérification de compatibilité d'un protocole conformes à l'invention. Elle vise par ailleurs un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant des instructions pour un programme informatique adaptées à mettre en oeuvre le procédé de proposition d'un service et/ou le procédé de test d'accès à un service et/ou le procédé de vérification de 20 compatibilité d'un protocole conformes à l'invention, lorsque ce programme est chargé et exécuté par le système informatique. Enfin, la présente invention concerne un programme d'ordinateur lisible par un microprocesseur comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé de proposition d'un service et/ou le procédé de 25 test à un service et/ou le procédé de vérification de compatibilité d'un protocole conformes à l'invention lorsque ce programme d'ordinateur est chargé et exécuté par le microprocesseur. Les ordinateur, ordinateur serveur, ordinateur client, réseau de communication, moyen de stockage d'informations, et programme d'ordinateur 30 présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après. Aux dessins annexés, donnés à titre d'exemples non limitatifs: - la figure 1 est un algorithme illustrant un procédé de proposition d'un service conforme à l'invention; - la figure 2 est un algorithme illustrant le procédé de test d'accès à un service conforme à un deuxième aspect de l'invention; - la figure 3 est un algorithme illustrant le procédé de vérification de compatibilité conforme à un troisième aspect de l'invention; - la figure 4 est un algorithme illustrant un procédé de construction d'un message; - la figure 5 est un algorithme illustrant l'étape de sélection d'une fonctionnalité à la figure 4; et - la figure 6 est un schéma bloc illustrant un dispositif adapté à 15 mettre en oeuvre l'invention. On va décrire tout d'abord en référence à la figure 1 un procédé de proposition d'un service fourni par un ordinateur serveur dans un réseau de communication. Dans un réseau d'ordinateur tel qu'lnternet, des serveurs fournissent 20 des données sous forme de documents à des ordinateurs clients. Très fréquemment, ces ordinateurs serveurs fournissent également des services, appelés services Web, permettant à un ordinateur client d'envoyer des données au serveur qui les traite et retourne un résultat. En pratique, lorsqu'un ordinateur client d'un réseau de 25 communication souhaite utiliser les services fournis par un ordinateur serveur, il envoie un message afin de requérir une description des services fournis par cet ordinateur serveur. A la réception E10 d'une telle requête de description, le procédé de proposition de services comprend une étape d'envoi El d'un document de 30 description d'un service. Dans la suite de la description, et de manière non limitative, on considérera que ce document de description d'un service utilise le langage il WSDL (acronyme du terme anglais "Web Service Description Language"), qui est un langage permettant de décrire des services Web. Ce langage WSDL est un langage XML perfectionné, permettant à l'aide de balises XML de décrire un service Web. Un document WSDL contient principalement deux parties. Une première partie, appelée partie abstraite, décrit de manière abstraite les messages qui sont échangés entre ordinateurs du réseau de communication lors de la mise en oeuvre du service. Une seconde partie est adaptée à comporter les informations concrètes, définissant la transmission des messages 10 sur le réseau de communication. La première partie est elle-même divisée en trois sous-parties. La première sous-partie de cette première partie contient des déclarations de types, permettant de décrire la structure abstraite des messages. Ces types sont ensuite référencés dans la deuxième sous-partie de 15 la première partie du document WSDL. La déclaration de ces types est généralement réalisée au moyen de balises ... . Cette déclaration de types est bien connue dans les documents écrits en langage XML et il n'est pas nécessaire pour la compréhension de 20 l'invention de décrire plus avant les types utilisés. La seconde sous-partie de la première partie du document contient des déclarations de messages élémentaires. Elle définit ainsi les messages qui seront échangés entre les ordinateurs lors de la mise en oeuvre du service, sans en décrire précisément le 25 contenu ou l'enchaînement. Elle consiste à définir de manière abstraite et de donner le type d'une donnée transmise (entrée ou sortie). A titre d'exemple, et uniquement pour faciliter la compréhension de la présente invention, les messages suivants peuvent être définis, sans lien entre 30 eux: a) un premier message permet de transmettre le nom d'une action b) un second message permet de transmettre le prix associé à une action: Une troisième sous-partie de la première partie du document WSDL permet de regrouper les messages élémentaires ainsi définis dans les deux 10 premières sous-parties en opérations logiques. Une opération peut être considérée comme un service élémentaire, ce dernier étant lui-même implanté par un ou plusieurs messages. Elle est ainsi définie par ses entrées et sorties, c'est-à-dire par les messages qu'elle échange. Par exemple, une opération retournant la valeur d'une action lors de la réception du nom de cette action peut être définie comme suit: 20 Bien évidemment des formes plus élaborées d'opération, constitué d'un ensemble complexe d'échanges de messages, pourraient être décrites dans ce langage. Cette première partie du document WSDL permet ainsi de définir le 25 type, le contenu et l'ordonnancement des messages échangés entre ordinateurs du réseau lors la mise en oeuvre d'un service proposé par un ordinateur serveur. Le document WSDL comprend en outre, comme expliqué précédemment, une seconde partie qui permet de préciser quel protocole est 30 effectivement utilisé pour transmettre les messages et quel encodage ou format de représentation est mis en oeuvre pour représenter ces données sous une forme adaptée au réseau de communication. Cette seconde partie correspond ainsi à un couplage (binding) consistant à spécifier un protocole concret et un format de données pour une opération définie dans la première partie du document WSDL. Conformément à l'invention, les informations relatives à un protocole 5 de communication incluses dans cette seconde partie du document WSDL, comprennent des valeurs impératives associées à au moins une fonctionnalité mise en oeuvre par le protocole de communication lors de l'exécution du service proposé sur le réseau de communication. La présente invention permet ainsi de définir un protocole utilisé par 10 un service, les fonctionnalités de ce protocole et les valeurs impératives prises par les fonctionnalités. Un tel document de description d'un service peut ainsi s'appliquer à n'importe quel protocole, et par exemple au protocole connu HTTP (acronyme du terme anglais "HyperText Transfer Protocol") ou encore SMTP (acronyme 15 du terme anglais "Simple Mail Transfer Protocol"), ou bien encore via un protocole de communication tel que SOAP 1.2. Cette description de fonctionnalité consiste généralement à définir une fonctionnalité par une liste de propriétés supportées par cette fonctionnalité. Il s'agit alors de donner une description, par exemple dans un langage de balisage du type XML, des fonctionnalités afin d'identifier chaque fonctionnalité et de décrire les propriétés associées à cette fonctionnalité. Ces éléments ou fonctionnalités ainsi définis, elles peuvent être utilisées pour être inclus dans une description d'un protocole de communication via un document 25 WSDL. On obtient ainsi un document de description de service écrit dans un langage WSDL perfectionné. On va donner ci-après des exemples de description en langage XML de fonctionnalités. Une fonctionnalité peut être identifiée par une URI (acronyme du terme anglais "Unique Resource Identifier"), et définie par une liste de propriétés. La fonctionnalité peut également être identifiée par une référence locale propre à l'ordinateur serveur hébergeant le document WSDL. La description XML d'une fonctionnalité est encapsulée dans un élément XML. Le nom de cet élément diffère suivant la nature de la fonctionnalité. On distingue plusieurs types de fonctionnalité, parmi lesquelles les éléments "features" qui représentent un feature; l'élément "mep" qui représente une MEP (acronyme du terme anglais "Message Exchange Pattern"); l'élément "module" qui représente un module et l'élément "field" qui représente un champ 10 protocolaire permettant ainsi de définir un en-tête protocolaire (en anglais "Header"). Un module correspond à la mise en oeuvre d'un ou plusieurs features. Cet élément comporte un attribut obligatoire "name" permettant de 15 référencer ultérieurement la description de la fonctionnalité et un second attribut obligatoire "id", identifiant de façon unique la fonctionnalité. L'identification de la fonctionnalité peut être réalisée par exemple via une URI. En outre, la liste des propriétés supportées par cette fonctionnalité est insérée à l'intérieur de l'élément. Chaque propriété est définie par un 20élément que l'on nomme "property". Cet élément a un attribut obligatoire "name". Pour chaque propriété, la description de la fonctionnalité comprend une liste de valeurs attribuables à cette propriété. Ainsi, à titre d'exemple, la fonctionnalité "Web Method" définie par la norme SOAP peut être décrite comme suit: 25 GET POST PUT DELETE Ainsi, dans cet exemple, la fonctionnalité "Web Method" a une propriété qui a pour nom "Method" et qui peut prendre comme valeur, les valeurs GET, POST, PUT et DELETE. La description de cette fonctionnalité comprend ainsi la liste des propriétés supportées par cette fonctionnalité. Cela permet de décrire des fonctionnalités possédant des options proposées sous forme de propriétés. Par défaut, si la description d'une fonctionnalité ne comporte pas de 15 liste de propriétés supportées, toutes les propriétés obligatoires de la fonctionnalité sont supportées, mais aucune propriété optionnelle n'est supportée. Dans l'exemple précédent, la propriété "Method" est supportée par la fonctionnalité "Web Method". La description de chaque fonctionnalité comporte, pour chaque propriété supportée, la liste des valeurs acceptées pour cette propriété. Par défaut, si la liste des valeurs acceptées pour une propriété n'est pas précisée, toutes les valeurs non optionnelles sont acceptées, tandis qu'aucune valeur optionnelle n'est acceptée. Comme cela est bien connu en langage XML, la description de la propriété "Method" pourrait également être réalisée grâce à un langage de schéma tel que XML-Schéma, de telle sorte que la description de cette propriété soit insérée par référence dans la description de la fonctionnalité. L'exemple précédent serait alors décrit de la manière suivante: Dans ce mode de réalisation, au lieu de préciser la valeur de la propriété, on associe un type à l'élément "property", ce type étant défini par un langage de schéma tel que XML-Schéma. Par ailleurs, il est possible d'ajouter à la description d'une propriété 5 d'une fonctionnalité un attribut spécifique, noté "mustUnderstand" adapté à indiquer la compréhension obligatoire ou non de la propriété en question par un ordinateur client lors de la mise en oeuvre du protocole de communication pour l'exécution du service proposé. Lorsque cet attribut "mustUnderstand" est associé à une valeur vrai 10 (true), cela signifie que l'ordinateur client doit obligatoirement comprendre la propriété associée pour pouvoir accéder à un service utilisant la fonctionnalité décrite. Il doit en outre obligatoirement utiliser cette propriété lorsqu'elle s'applique. La fonctionnalité "Web Method" peut ainsi être définie comme suit: 15 GET POST PUT DELETE De même, il est possible d'ajouter à la description d'une propriété d'une fonctionnalité un attribut spécifique, noté "mustUse" adapté à indiquer l'utilisation obligatoire ou non de la propriété en question par un ordinateur client lors de la mise en oeuvre du protocole de communication pour l'exécution 10 du service proposé. Lorsque cet attribut "mustUse" est associé à une valeur vrai (true), cela signifie que l'ordinateur client doit obligatoirement utiliser la propriété associée pour pouvoir accéder à un service utilisant la fonctionnalité décrite. La fonctionnalité "Web Method" peut ainsi être définie comme suit: GET POST PUT DELETE Enfin, une fonctionnalité "feature" peut être une réalisation concrète d'une autre fonctionnalité abstraite "feature". Dans ce cas, une relation entre les deux fonctionnalités peut être décrite à l'aide d'un élément "implements" inséré * dans la description de la fonctionnalité concrète. Dans l'exemple ci-après, on définit une fonctionnalité abstraite d'inclusion de pièces jointes et une réalisation de ce protocole à l'aide de la norme MIME Multipart/related: On peut ainsi décrire différents types de fonctionnalité de la même manière. Par ailleurs, à titre d'exemple, on peut également décrire une fonctionnalité de corrélation de message: 30 Ou encore une fonctionnalité de mode de transfert de message (binaire ou texte): binary 10 text Ou encore une fonctionnalité de compression: gzip 25 tar Dans ce dernier exemple, cette fonctionnalité de compression 30 supporte uniquement les algorithmes GZIP et TAR, et par exemple ne supporte pas d'autres algorithmes du type ZIP, BZIP ou SIT. Bien que l'on ait décrit ci-dessus des exemples de fonctionnalité utilisant le protocole SOAP, n'importe quel type de fonctionnalité, s'appliquant à d'autres protocoles, peuvent être décrits de la même manière. Ces fonctionnalités peuvent correspondre à des fonctionnalités optionnelles d'un protocole ou à des extensions de ce protocole. Ainsi, à titre d'exemple, une fonctionnalité d'insertion d'une adresse électronique de retour pour un protocole de courrier électronique peut s'écrire de la manière suivante: 10 Il existe également des fonctionnalités de type particulier, tel que un MEP (acronyme du terme anglais "Message Exchange Pattern"). Cet élément MEP est utilisé pour définir un modèle d'échange de message entre plusieurs noeuds d'un réseau de communication. Par exemple, ce modèle MEP peut être du type requête-réponse de telle sorte qu'un premier ordinateur envoie un message à un second ordinateur qui lui retourne un message de réponse. Un tel élément MEP peut être décrit de la manière suivante: On peut également utiliser ce même mécanisme de description pour décrire un module, par exemple un module d'authentification: Ces différents éléments décrits précédemment permettent ensuite de décrire un protocole de communication. De manière générale, la description 10 d'un protocole s'effectue à l'aide d'un élément "protocol". Un attribut "name" donne un nom au protocole, ce nom permettant de référencer le protocole dans la description d'un service Web, c'est-à-dire dans un document WSDL. Un attribut "id" permet d'identifier de manière unique ce protocole à l'aide d'une adresse électronique URI. Conformément à l'invention, la description du protocole inclus au moins la description d'une fonctionnalité supportée par ce protocole. Ainsi, le protocole SOAP associé au protocole de transport HTTP via un couplage (en anglais "binding") peut être décrit de la manière suivante: Une telle description signifie que le protocole SOAP associé au protocole de transport HTTP supporte les fonctionnalités MEP du type requêteréponse et réponse SOAP, ainsi que la fonctionnalité Web Method. Dans ce mode de réalisation préféré, la description de chaque fonctionnalité est incluse par référence à l'intérieur de l'élément "protocol". Chaque élément "mep" ou "feature" ou encore "module" inclus dans un élément protocole peut en outre être associé à un attribut du type 5 mustUnderstand adapté à indiquer que la compréhension de cette fonctionnalité doit être obligatoire lors de la mise en oeuvre du protocole de communication par un ordinateur client pour l'exécution d'un service sur le réseau de communication. En pratique, comme décrit précédemment, cet attribut 10 "mustUnderstand" est associé à une valeur vrai (true) qui signifie que l'ordinateur client doit supporter cette fonctionnalité "mep" ou "feature" et qu'il doit obligatoirement l'utiliser lorsque cette fonctionnalité s'applique. Comme précédemment, un attribut "mustUse" pourrait également être utilisé pour indiquer l'utilisation obligatoire ou non de la fonctionnalité. Dans le cas particulier de la fonctionnalité "mep", cet attribut "mustUse" est utile car il oblige un ordinateur client à utiliser autant que possible un élément mep qui ne peut pas s'appliquer à toutes les opérations (par exemple, un mep de requête simple, sans réponse, qui ne peut pas être utilisé pour accéder à un service retournant une réponse). On donne ci-après d'autres exemples d'utilisation du protocole SOAP, par exemple avec un autre couplage HTTP, ou avec un couplage de courrier électronique, ou même par utilisation directe du protocole de communication HTTP: 30 Les éléments "protocol" ainsi définis peuvent être ainsi inclus dans 15 un document de description d'un service, et plus particulièrement dans la partie concrète de ce document comprenant des informations relatives à un protocole de communication. Lorsque, le document de description d'un service utilise un langage de balisage tel que XML, par exemple dans un document WSDL, les différentes 20 fonctionnalités sont décrites respectivement dans des balises filles incluses dans une balise référençant un protocole de communication. On peut ainsi étendre un protocole de communication en définissant plusieurs fonctionnalités, optionnelles de ce protocole, directement dans un document de description d'un service du type WSDL. Comme décrit précédemment, les fonctionnalités peuvent être définies indépendamment, avec une liste de propriétés de valeurs supportées par ces propriétés, et ces fonctionnalités peuvent notamment être choisies parmi des fonctionnalités définies par le protocole d'échange d'informations SOAP. Dans un document WSDL, l'élément de couplage "binding" décrit précédemment sera ainsi écrit conformément à l'invention Dans l'exemple précédent, on considère que l'élément "protocol" décrivant le protocole de communication et le document de description WSDL, décrivant un service Web utilisant ce protocole, se trouvent dans un même fichier. Si tel n'est pas le cas, le fichier contenant la description de l'élément 15 "protocol" peut être référencé depuis le fichier contenant la description du service WSDL à l'aide d'un élément "import". Afin de perfectionner encore la description d'un protocole, et notamment l'utilisation optionnelle ou non de différentes fonctionnalités, d'autres types de balise peuvent être définis. En particulier, un élément "choice" peut être utilisé pour indiquer qu'une fonctionnalité ne doit pas être utilisée avec telle autre fonctionnalité. De même, un élément "group" peut au contraire être utilisé pour indiquer qu'une fonctionnalité doit être utilisée avec telle autre fonctionnalité. L'écriture d'un élément "protocol" pourrait alors se présenter de la 25 manière suivante: On peut définir ainsi un protocole CRF, qui laisse le choix entre trois possibilités exclusives, identifiées grâce à l'élément "choice". Les deux premières possibilités sont des éléments MEP. La dernière possibilité "MYMEP" correspond à la somme de deux fonctionnalités, à l'aide de l'élément "group": - utilisation de la fonctionnalité MEP Method; - utilisation de l'élément MEP requête-response ou SOAP réponse. Un autre exemple de l'utilisation de ces éléments "choice" et "group" est illustré ci-dessous. Dans ce dernier exemple, la description du protocole indique à un 10 client qu'il doit choisir un élément MEP parmi deux possibilités et un mécanisme d'authentification parmi trois possibilités. De même, la définition d'un protocole pourrait être complétée en utilisant un élément "set" qui permettrait à un client de choisir un certain nombre de fonctionnalités parmi les balises enfant de cet élément "set". Le nombre de fonctionnalités à choisir pourrait être fixé à l'aide d'un attribut "number" de l'élément "set". On notera à cet égard que l'élément défini ci-dessus "choice" est équivalent à l'élément et que l'élément "group" est équivalent à l'élément . Un attribut "number" associé à la valeur "unlimited" permettrait de 10 spécifier à un ordinateur client la possibilité d'utiliser autant de fonctionnalités qu'il le souhaite parmi les fonctionnalités proposées dans le protocole de communication. Ainsi, un document de description d'un service WSDL peut utiliser pour décrire un protocole de communication une description permettant 15 d'identifier chaque fonctionnalité associée au protocole et de décrire les propriétés de ces fonctionnalités. En particulier, il est possible de définir une fonctionnalité via une liste de propriétés, c'est-à-dire de définir les propriétés qui existent et les valeurs pouvant être prises par ces propriétés. Conformément à l'invention, on utilise une telle description de 20 fonctionnalité dans un document de description d'un service WSDL en incluant des informations relatives à des valeurs impératives associées aux fonctionnalités mises en oeuvre par le protocole de communication pour l'exécution du service sur le réseau de communication. En pratique, pour chaque fonctionnalité utilisée par le protocole de 25 communication, le document de description d'un service précise comment la fonctionnalité est utilisée c'est-à-dire, quelles valeurs impératives seront prises respectivement par chaque propriété associée à la fonctionnalité. En pratique, la description en langage XML des fonctionnalités permet de déclarer ces fonctionnalités dans un document de description de 30 service du type WSDL. Les informations relatives aux valeurs impératives prises par la fonctionnalité sont incluses dans la seconde partie du document de description d'un service, c'est-à-dire dans la partie concrète du document de description d'un service WSDL. Dans un document de description d'un service écrit en langage de balisage du type WSDL, les informations relatives aux valeurs impératives sont 5 incluses dans une balise référençant une fonctionnalité du protocole de communication. Plus précisément, on déclare et on décrit l'utilisation des fonctions à l'intérieur de chaque élément "opération" qui peut contenir un ou plusieurs messages échangés lors de l'exécution du service. Afin de faciliter la compréhension de l'invention, et de manière nullement limitative, on donne ci-dessous deux exemples d'une partie concrète d'un document de description d'un service WSDL dans lequel des informations relatives à des valeurs impératives associées à des fonctionnalités mises en oeuvre par le protocole sont incluses. Dans le premier exemple, les informations sont incluses dans un élément "protocol binding" et ne comporte que des informations relatives au protocole de communication, à l'exclusion de toute autre information sur le format de représentation des messages. GET Cet élément "protocol binding" particulier ne nécessite pas d'être 20 décrit plus en détails ici pour la compréhension de la présente invention. Dans le second exemple, les informations relatives à des valeurs impératives sont incluses directement dans l'élément "binding" conformément au protocole de description d'un service normalisé WSDL 1.1. Chaque fonctionnalité est choisie parmi des types de fonctionnalité 5 (MEP, feature, module ou champ protocolaire) définis par un protocole d'échanges d'informations. Pour déclarer qu'une fonctionnalité doit être comprise et utilisée, on ajoute à la description un élément du type feature, MEP, ou module qui contient un pointeur vers une description en langage XML de la fonctionnalité. De préférence, ce pointeur correspond à un attribut "Name" de l'élément qui permet ainsi de définir de manière unique la fonctionnalité. Comme bien illustré dans les exemples précédents, les informations relatives à des valeurs impératives sont incluses dans une balise "opération" référençant une opération comprenant un ou plusieurs messages échangés lors 15 de l'exécution du service. Ici, les informations sont ainsi incluses dans la balise référençant l'opération "GetQuantitylnStock". Conformément à l'invention, à l'intérieur de chaque élément, et par exemple à l'intérieur de l'élément "feature", la valeur des propriétés associée à la fonctionnalité est précisée. Ainsi, dans le premier exemple, la propriété "method" peut prendre les valeurs GET, POST, PUT et DELETE. Dans le premier exemple de réalisation, une valeur impérative, ici égale à GET, est associée à la propriété "method" de la fonctionnalité "webmethod". Alternativement, il est également possible non pas d'indiquer une 10 unique valeur impérative associée à une propriété mais également plusieurs valeurs impératives, c'est-à-dire en d'autres termes, de restreindre le choix des valeurs que peut supporter une propriété. Dans le second exemple, la valeur de la propriété "method" a été restreinte aux valeurs GET et POST. Dans ce second exemple, l'ordinateur client peut alors choisir une valeur exacte de la propriété "method" dans le sous-ensemble de valeurs spécifiées dans la description WSDL. Ainsi, grâce à l'invention, il est possible de définir exactement les extensions que doit utiliser un ordinateur client pour accéder à un service. Un ordinateur client d'un réseau de communication peut ainsi, à partir de l'analyse d'un document de description d'un service, tester facilement un accès possible ou non à un service fourni par un ordinateur serveur du réseau de communication. On va décrire à présent en référence à la figure 2 un procédé de test 25 d'accès à un tel service. Ce procédé comporte tout d'abord une étape de lecture El 10 d'un fichier comprenant un document de description d'un service WSDL. Une étape d'extraction El 1l est adaptée à extraire de la description concrète de ce document des informations sur un échange de données. Une étape de test E112 permet de vérifier si le protocole de communication mis en oeuvre correspond à un protocole extensible tel que SOAP 1.2. Dans la négative, on vérifie dans une étape de test E113 s'il existe une autre description concrète incluse dans le document de description d'un fichier WSDL. Dans la négative, l'algorithme de test d'accès retourne une réponse 5 négative de telle sorte que l'accès au service est impossible pour l'ordinateur client. A contrario, si à l'issue de l'étape de test E113, une nouvelle description est présente dans le document de description d'un service, l'étape de test E112 est réitérée. Lorsque que le protocole décrit correspond au 10 protocole de communication SOAP 1.2, une étape d'extraction El 14 est mise en oeuvre pour extraire une première fonctionnalité décrite dans le document de description d'un service comme expliqué précédemment. On extrait ainsi les informations relatives à une fonctionnalité mise en oeuvre par le protocole. On vérifie dans l'étape de test E115 que cette fonctionnalité est implémentée par l'ordinateur client. L'étape de test E115 est ensuite adaptée à vérifier si l'utilisation de cette fonctionnalité est obligatoire ou non lors de la mise en oeuvre du protocole de communication pour l'exécution du service sur le réseau de communication. 20 Le test E115 est ainsi mis en oeuvre à partir d'un attribut mustUse associé à la fonctionnalité adapté à indiquer l'utilisation obligatoire ou non de cette fonctionnalité par un ordinateur client pour l'exécution du service sur le réseau de communication. En pratique, on vérifie si la description de cette fonctionnalité est 25 associée à un attribut mustUse dont la valeur est vrai (true). Dans l'affirmative, une étape d'acquisition E116 permet d'acquérir au moins une valeur impérative associée à la fonctionnalité lors de l'exécution du service sur le réseau de communication. L'étape d'acquisition E116 comporte en pratique l'acquisition d'au 30 moins une propriété associée à la fonctionnalité, par exemple la propriété "method" et l'acquisition d'au moins une valeur impérative associée à cette propriété lors de la mise en oeuvre du protocole de communication pour l'exécution du service. On peut ainsi acquérir la valeur des propriétés qui ont été incluses dans le document de description d'un service WSDL. A titre d'exemple, en se référençant au premier exemple de document décrit précédemment, la valeur GET va être acquise pour la propriété "method". Dans une étape de test E117, on vérifie si la valeur impérative associée à la fonctionnalité est supportée par l'ordinateur client du réseau de 1 0 communication. Si la réponse à ce test est négative, l'algorithme de test d'accès retourne en réponse à l'ordinateur client un message lui indiquant que l'accès au service est impossible. A contrario, si à l'issue de l'étape de test E117, l'ordinateur client 15 supporte la fonctionnalité avec les valeurs de propriétés impératives fixées, on vérifie dans une étape de test E118 s'il existe d'autres fonctionnalités dans la description du service. Cette étape de test E118 est également directement mise en oeuvre lorsqu'à l'issue du test El 15, la fonctionnalité n'est pas associée à un attribut 20 indiquant son utilisation obligatoire pour la mise en oeuvre du service. S'il existe une nouvelle fonctionnalité, l'ensemble des étapes El 14 à El 17 est réitéré. Lorsque toutes les fonctionnalités ont été examinées, c'est-à-dire qu'à l'issue de l'étape de test E118, la réponse est négative, l'étape de test 25 El 13 est mise en oeuvre afin d'identifier éventuellement une nouvelle description d'un protocole de communication inséré dans le document de description d'un service. L'ensemble des étapes E111 à El 18 décrites précédemment sont alors mises en oeuvre pour un second protocole. Ainsi, la présente invention permet de faciliter l'accès par un ordinateur client à un service proposé par un ordinateur serveur du réseau decommunication. Par l'analyse d'un unique document de description, l'ordinateur client peut de manière automatique connaître le ou les protocoles de communication susceptibles d'être utilisés par lui-même pour accéder à un service sur le réseau de communication. On va décrire à présent en référence à la figure 3, un procédé de vérification de compatibilité d'un protocole de communication conforme à l'invention. Comme précédemment, ce procédé de vérification de compatibilité est mis en oeuvre à partir d'un document de description d'un service tel que 10 décrit précédemment, et par exemple un document permettant pour la fonctionnalité "web-method" de définir une valeur impérative "GET" à une propriété "method" associée à cette fonctionnalité. En pratique, ce procédé de vérification de compatibilité comporte tout d'abord une étape de lecture E120 du fichier comprenant un document de 15 description WSDL. Une étape d'extraction E121 est adaptée à extraire de la description un échange de données. On vérifie dans une étape de test E122 s'il s'agit du protocole défini par la norme SOAP 1.2. Dans la négative, une étape de test E123 est adaptée à déterminer s'il existe une autre description dans le document WSDL. Dans l'affirmative, on réitère sur cette nouvelle description les étapes d'extraction E121 et de test E122. Lorsque le protocole de communication est un protocole défini par la 25 norme SOAP 1.2, une étape d'extraction E123 est adaptée à extraire, à partir du document de description d'un service, une fonctionnalité mise en oeuvre par le protocole de communication lors de l'exécution du service sur le réseau de communication. Une étape d'acquisition E124 permet ensuite d'acquérir la description 30 de cette fonctionnalité, par exemple à partir d'une description en langage XML de cette fonctionnalité telle que décrite précédemment. Cette description en langage XML permet de manière générale de définir la fonctionnalité, la ou les propriétés associées à cette fonctionnalité, ainsi que les valeurs attribuables à ces propriétés. On acquiert ensuite à partir du document de description WSDL au 5 moins une valeur impérative associée à cette fonctionnalité dans le document de description d'un service. En pratique, cette étape d'acquisition E125 est adaptée à acquérir au moins une valeur impérative associée à une propriété, cette propriété étant ellemême associée à la fonctionnalité analysée. Une étape de test E126 permet, à partir de cette valeur impérative, de vérifier si cette dernière est incluse dans liste de valeurs attribuables à cette propriété supportée par la fonctionnalité. Dans la négative, une réponse est retournée à l'ordinateur mettant en oeuvre le procédé de vérification de compatibilité, afin d'indiquer que le 15 document WDSL ainsi analysé n'est pas valable, dès lors qu'une des valeurs impératives associées à une fonctionnalité ne correspond pas à une valeur attribuable à cette fonctionnalité. Si à l'issue de l'étape du test E126, la valeur impérative associée à la fonctionnalité, et plus particulièrement à une propriété, est incluse dans une 20 liste de valeurs attribuables à cette propriété, on vérifie dans une étape de test E127 s'il existe une autre propriété et on réitère sur celle-ci les étapes d'acquisition E125 et de test E126. Dans la négative, une étape de test E128 permet de déterminer si d'autres fonctionnalités sont incluses dans la description. Dans l'affirmative, on réitère sur cette nouvelle fonctionnalité l'ensemble des étapes E123 à E127 décrites précédemment. Dans la négative, lorsque toutes les fonctionnalités du protocole ont été analysées, l'étape de test E123 est mise en oeuvre afin d'identifier éventuellement une nouvelle description de protocole insérée dans le document 30 de description d'un service. Lorsque toutes les descriptions ont ainsi été vérifiées, un message est retourné à l'ordinateur mettant en oeuvre le procédé de vérification de compatibilité afin de valider le document de description d'un service WSDL. Grâce à la définition des fonctionnalités en langage XML, il est 5 possible d'insérer dans un protocole de communication, de nombreuses fonctionnalités particulières. Le procédé de vérification de compatibilité permet ensuite de vérifier pour n'importe quel type de protocole de communication si celui-ci est correctement décrit et utilisé dans le document de description d'un service. A titre d'exemple d'utilisation de l'invention, on va décrire en référence aux figures 4 et 5, un exemple de construction d'un message par un ordinateur client après réception d'un document de description de service tel qu'envoyé lors du procédé de proposition d'un service décrit en référence à la figure 1, et après la mise en oeuvre du procédé de test d'accès tel que décrit à 15 la figure 2. Une étape de lecture E140 permet tout d'abord d'identifier un document de description d'un service dans un fichier WSDL. Une étape de sélection E141 est adaptée à choisir une opération parmi les opérations prédéfinies dans le document de description d'un service. 20 Une étape de sélection E142 d'un protocole de communication est ensuite mise en oeuvre. Cette étape de sélection peut avantageusement utiliser les résultats du test d'accès permettant de déterminer les protocoles supportés par l'ordinateur client. Les données devant être insérées dans le message sont ensuite codées dans une étape de codage E143 puis ajoutées au message dans une étape d'ajout E144. Une étape de sélection E145 est adaptée à sélectionner une fonctionnalité associée au protocole de communication sélectionné à l'étape de 30 sélection E142. En pratique, dans l'exemple de réalisation décrit précédemment, la ou les fonctionnalités sélectionnables sont insérées à l'intérieur de l'élément "protocol binding". Cette étape de sélection d'une fonctionnalité est détaillé à la figure 5. 5 A partir d'une étape de lecture E300 du document WSDL, on extrait dans une étape d'extraction E301 la description concrète d'un échange de données. Une étape d'extraction E302 permet d'identifier une première fonctionnalité. On vérifie dans une étape de test E303 si cette fonctionnalité est obligatoire. Dans l'affirmative, on ajoute la fonctionnalité lors d'une étape d'ajout E305 dans la liste des fonctionnalités à utiliser. Dans le cas contraire, on vérifie dans une étape de test E304 si le 15 client souhaite utiliser cette fonctionnalité. Si tel est le cas, on ajoute la fonctionnalité à la liste de fonctionnalités à utiliser lors de l'étape d'ajout E305. Ce test peut être mis en oeuvre à partir d'un choix direct du client, des préférences client ou d'un test ad hoc du programme. On vérifie dans une étape de test E307 s'il existe une fonctionnalité 20 suivante. Dans l'affirmative, on réitère les étapes E302 à E305 pour cette fonctionnalité. Lorsque toutes les fonctionnalités ont été traitées, une étape de réponse E306 retourne la liste des fonctionnalités à utiliser. Une étape de choix E146 permet ensuite, pour chaque fonctionnalité 25 de la liste ainsi construite, de déterminer les valeurs impératives associées à chaque propriété. Si une unique valeur impérative est associée à la propriété, le choix de cette valeur est obligatoire. A contrario, si plusieurs valeurs sont attribuables à la propriété, un 30 choix peut être effectué parmi ces valeurs attribuables. Une étape d'utilisation E147 de la fonctionnalité est ensuite mise en oeuvre à partir des valeurs choisies précédemment. Dans une étape de test E148, on identifie éventuellement une nouvelle fonctionnalité parmi celles sélectionnées à l'étape de sélection E145 et on réitère pour celle-ci, l'étape de choix E146 et l'étape d'utilisation E147 décrites précédemment. Lorsque toutes les fonctionnalités ont ainsi été utilisées, une étape d'envoi E149 du message ainsi construit est mise en oeuvre à destination de l'ordinateur serveur proposant le service en question sur le réseau de communication. Afin de mettre en oeuvre le procédé de proposition d'un service décrit 10 en référence à la figure 1, un dispositif de proposition d'un service comprend essentiellement des moyens d'envoi d'un document de description d'un service comprenant des informations relatives à des valeurs impératives associées à au moins une fonctionnalité mise en oeuvre par un protocole de communication pour l'exécution du service sur réseau de communication. * De même, un dispositif de test d'accès à un service adapté à mettre en oeuvre le procédé de test d'accès décrit en référence à la figure 2 comprend des moyens d'extraction des informations relatives à au moins une fonctionnalité mise en oeuvre par le protocole, des moyens de test adaptés à vérifier si l'utilisation de cette fonctionnalité est obligatoire ou non, des moyens 20 d'acquisition d'au moins une valeur impérative associée à la fonctionnalité, permettant de préférence d'acquérir une valeur impérative associée à une propriété de cette fonctionnalité, et des moyens de vérification permettant de vérifier si la valeur impérative associée à la fonctionnalité est supportée par l'ordinateur client du réseau de communication. Enfin, un dispositif de vérification de compatibilité adapté à mettre en oeuvre le procédé de vérification de compatibilité tel que décrit à la figure 3 comprend des moyens d'extraction d'une fonctionnalité mise en oeuvre par le protocole de communication, des moyens d'acquisition d'au moins une valeur impérative associée à cette fonctionnalité, des moyens d'acquisition et de 30 description de cette fonctionnalité et des moyens de vérification adaptés à vérifier si la valeur impérative est incluse dans une liste de valeurs attribuables à une propriété supportée par la fonctionnalité. Ces dispositifs de proposition, de test d'accès et de vérification de compatibilité peuvent être incorporés dans un ordinateur tel qu'illustré à la figure 6. En particulier, les différents moyens identifiés ci-dessus peuvent être 5 incorporés dans un microprocesseur 100, une mémoire morte 101 ("Read-only memory" ou ROM) étant adaptée à mémoriser un programme de proposition d'un service et/ou de test et/ou de vérification de compatibilité conformes à l'invention. Bien entendu, ces dispositifs de proposition d'un service, de test 10 d'accès ou de vérification de compatibilité, peuvent être mis en oeuvre dans un même ordinateur ou bien dans des stations différentes du réseau de communication. En particulier, le dispositif de proposition d'un service peut être incorporé dans un ordinateur serveur d'un réseau de communication, alors que 15 le procédé de test d'accès peut être incorporé dans un ordinateur client d'un réseau de communication. Une mémoire vive 102 ("Random access memory" ou RAM) est adaptée à mémoriser dans des registres les valeurs modifiées lors de l'exécution du programme de proposition d'un service, de test d'accès ou de 20 vérification de compatibilité. Le microprocesseur 100 est intégré à un ordinateur qui peut être connecté à différents périphériques et à d'autres ordinateurs du réseau de communication 10. En particulier, cet ordinateur correspond à un ordinateur serveur S de ce réseau ou à un ordinateur client C de ce réseau de 25 communication 10. Cet ordinateur S, C comporte de manière connue une interface de communication 110 reliée au réseau de communication pour recevoir ou transmettre des messages. L'ordinateur comporte en outre des moyens de stockage de 30 documents, tel qu'un disque dur 106, ou est adapté à coopérer au moyen d'un lecteur de disque 107 (disquettes, disques compacts ou cartes informatiques) avec des moyens de stockage de documents amovibles, tels que des disques 700. Ces moyens de stockage fixes ou amovibles peuvent comporter le code des procédés conformes à l'invention. Ils sont également adaptés à mémoriser un document électronique de description d'un service tel que défini par la présente invention. A titre de variante, le programme permettant au dispositif de proposition d'un service, de test d'accès ou de vérification de compatibilité de mettre en oeuvre l'invention peut être stocké dans la mémoire morte 101. En seconde variante, le programme pourra être reçu pour être stocké comme décrit précédemment par l'intermédiaire du réseau de communication 10 10. L'ordinateur S, C possède également un écran 1003 permettant par exemple de servir d'interface avec un opérateur à l'aide du clavier 104 ou de la souris 105 ou de tout autre moyen. L'unité centrale 100 (CPU) exécutera alors les instructions relatives à 15 la mise en oeuvre de l'invention. Lors de la mise sous tension, les programmes et méthodes relatives à l'invention stockés dans une mémoire non volatile, par exemple la mémoire 101, sont transférés dans la mémoire 102 qui contiendra alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en oeuvre de l'invention. Un bus de communication 112 permet la communication entre les différents sous-éléments de l'ordinateur ou liés à lui. La représentation de ce bus 112 n'est pas limitative et notamment le microprocesseur 100 est susceptible de communiquer des instructions à tout sous-élément directement ou par l'intermédiaire d'un autre sous-élément. Bien entendu, de nombreuses modifications peuvent être apportées aux exemples de réalisation décrits précédemment sans sortir du cadre de l'invention. REVENDICATIONS 1. Procédé de proposition d'un service fourni par un ordinateur serveur dans un réseau de communication, mettant en oeuvre au moins un protocole de communication, caractérisé en ce qu'il comprend une étape 10 d'envoi d'un document de description d'un service comprenant des informations relatives à des valeurs impératives associées à au moins une fonctionnalité mise en oeuvre par ledit protocole de communication lors de l'exécution dudit service sur le réseau de communication. 2. Procédé de proposition d'un service conforme à la revendication 15 1, ladite fonctionnalité supportant au moins une propriété, caractérisé en ce que le document de description d'un service comprend des informations relatives à au moins une valeur impérative associée respectivement à chaque propriété de ladite fonctionnalité. 3. Procédé de proposition d'un service conforme à l'une des 20 revendications 1 ou 2, caractérisé en ce que ladite fonctionnalité est associée à un attribut adapté à indiquer l'utilisation obligatoire ou non de ladite fonctionnalité par un ordinateur client lors de la mise en oeuvre du protocole de communication pour l'exécution dudit service sur le réseau de communication. 4. Procédé de proposition d'un service conforme à l'une des 25 revendications 1 à 3, caractérisé en ce que le document de description d'un service est écrit dans un langage de balisage, lesdites informations relatives à des valeurs impératives étant incluses dans une balise référençant une fonctionnalité dudit protocole de communication. 5. Procédé de proposition d'un service conforme à l'une des 30 revendications 1 à 4, caractérisé en ce que les fonctionnalités sont choisies parmi des types de fonctionnalités (MEP, feature, module ou champ protocolaire) définis par un protocole d'échange d'informations. 6. Procédé de proposition d'un service conforme à l'une des revendications 1 à 5, dans lequel le document de description d'un service est un document comprenant une première partie incluant des informations relatives aux messages échangés lors de l'exécution dudit service, et une 5 seconde partie incluant des informations relatives à au moins un protocole de communication mis en oeuvre lors de l'exécution dudit service, caractérisé en ce que lesdites informations relatives à des valeurs impératives sont incluses dans ladite seconde partie de document de description d'un service. 7. Procédé de proposition d'un service conforme à la revendication 10 6, caractérisé en ce que lesdites informations relatives à des valeurs impératives sont incluses dans une balise référençant une opération comprenant un ou plusieurs messages échangés lors de l'exécution dudit service. 8. Procédé de proposition de service conforme à l'une des 15 revendications 1 à 7, caractérisé en ce que ladite fonctionnalité est définie par une référence locale associée à l'ordinateur serveur ou par une URI. 9. Procédé de proposition de service conforme à l'une des revendications de 1 à 8, caractérisé en ce que ledit document de description de service est représenté dans un langage de balisage de type WSDL. 10. Procédé de test d'accès à un service par un ordinateur client d'un réseau de communication, à partir d'un document de description d'un service comprenant des informations relatives à un protocole de communication caractérisé en ce qu'il comprend les étapes suivantes: - extraction (E114) des informations relatives à au moins une 25 fonctionnalité mise en oeuvre par ledit protocole; - acquisition (E116) d'au moins une valeur impérative associée à ladite fonctionnalité lors de l'exécution du service sur le réseau de communication; et - vérification (E117) si ladite valeur impérative associée à ladite 30 fonctionnalité est supportée par l'ordinateur client du réseau de communication; 11. Procédé de test d'accès à un service conforme à la revendication , caractérisé en ce que, préalablement à ladite étape d'acquisition, une étape de test (El 15) est adaptée à vérifier si la fonctionnalité est implémentée par l'ordinateur client et si l'utilisation de ladite fonctionnalité est obligatoire ou non lors de la mise en oeuvre du protocole de communication pour l'exécution dudit service sur le réseau de communication. 12. Procédé de test d'accès à un service conforme à la revendication 11, caractérisé en ce que ledit test est mis en oeuvre à partir d'un attribut associé à ladite fonctionnalité et adapté à indiquer l'utilisation obligatoire ou non de ladite fonctionnalité par l'ordinateur client lors de la mise en oeuvre du protocole de communication pour l'exécution dudit service sur le réseau de 10 communication. 13. Procédé de test d'accès à un service conforme à l'une des revendications 10 à 12, caractérisé en ce que l'étape d'acquisition comprend les sous-étapes suivantes: - acquisition d'au moins une propriété associée à ladite 15 fonctionnalité; et - acquisition d'au moins une valeur impérative associée à ladite propriété lors de la mise en oeuvre du protocole de communication pour l'exécution dudit service sur le réseau de communication. 14. Procédé de vérification de compatibilité d'un protocole de 20 communication à partir d'un document de description d'un service comprenant des informations relatives à un protocole de communication caractérisé en ce qu'il comprend les étapes suivantes: - extraction du document de description d'un service, d'une fonctionnalité mise en oeuvre par ledit protocole de communication lors de 25 l'exécution du service sur le réseau de communication; - acquisition d'au moins une valeur impérative associée à ladite fonctionnalité dans le document de description d'un service; - acquisition d'une description de ladite fonctionnalité; et - vérification si ladite valeur impérative est incluse dans une liste 30 de valeurs attribuables à une propriété supportée par ladite fonctionnalité. 15. Dispositif de proposition d'un service fourni par un ordinateur serveur dans un réseau de communication, mettant en oeuvre au moins un protocole de communication, caractérisé en ce qu'il comprend des moyens d'envoi (100, 101, 102) d'un document de description d'un service comprenant des informations relatives à des valeurs impératives associées à au moins une fonctionnalité mise en oeuvre par ledit protocole de communication lors de l'exécution dudit service sur le réseau de communication. 16. Dispositif de proposition d'un service conforme à la revendication , caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100); - une mémoire morte (101) adaptée à mémoriser un programme 10 de proposition d'un service; et - une mémoire vive (102) comprenant des registres adaptés à mémoriser les variables modifiées lors de l'exécution dudit programme. 17. Dispositif de test d'accès à un service par un ordinateur client d'un réseau de communication, à partir d'un document de description d'un 15 service comprenant des informations relatives à un protocole de communication, caractérisé en ce qu'il comprend: - des moyens d'extraction (100, 101, 102) des informations relatives à au moins une fonctionnalité mise en oeuvre par un protocole; - des moyens d'acquisition (100, 101, 102) d'au moins une valeur 20 impérative associée à ladite fonctionnalité lors de l'exécution du service sur le réseau de communication; et - des moyens de vérification (100, 101, 102) adaptés à vérifier si ladite valeur impérative associée à ladite fonctionnalité est supportée par l'ordinateur client du réseau de communication. 18. Dispositif de test d'accès à un service conforme à la revendication 16, caractérisé en ce qu'il comprend en outre des moyens de test (100, 101, 102) adaptés à vérifier si ladite fonctionnalité est implémentée par l'ordinateur client et si l'utilisation de ladite fonctionnalité est obligatoire ou non lors de la mise en oeuvre du protocole de communication pour l'exécution dudit 30 service sur le réseau de communication. 19. Dispositif de test d'accès conforme à l'une des revendications 17 ou 18, caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100); - une mémoire morte (101) adaptée à mémoriser un programme de test d'accès à un service; et - une mémoire vive (102) comprenant des registres adaptés à mémoriser les variables modifiées lors de l'exécution dudit programme. 20. Dispositif de vérification de compatibilité d'un protocole de communication à partir d'un document de description d'un service comprenant des informations relatives à un protocole de communication, caractérisé en ce qu'il comprend: - des moyens d'extraction (100, 101, 102) du document de description d'un service, d'une fonctionnalité mise en oeuvre par le protocole de communication lors de l'exécution du service sur le réseau de communication; - des moyens d'acquisition (100, 101, 102) d'au moins une valeur impérative associée à ladite fonctionnalité dans le document de description d'un 15 service; - des moyens d'acquisition (100, 101, 102) d'une description de ladite fonctionnalité; et - des moyens de vérification (100, 101, 102) adaptés à vérifier si ladite valeur impérative est incluse dans une liste de valeurs attribuables à une 20 propriété supportée par ladite fonctionnalité. 21. Dispositif de vérification de compatibilité conforme à la revendication 20, caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100); - une mémoire morte (101) adaptée à mémoriser un programme 25 de vérification de compatibilité d'un protocole de communication; et - une mémoire vive (102) comprenant des registres adaptés à mémoriser les variables modifiées lors de l'exécution dudit programme. 22. Ordinateur caractérisé en ce qu'il comporte un dispositif de proposition d'un service conforme à l'une des revendications 15 ou 16. 23 Ordinateur, caractérisé en ce qu'il comporte un dispositif de test d'accès conforme à l'une des revendications 17 à 19. 24. Ordinateur, caractérisé en ce qu'il comporte un dispositif de vérification de compatibilité conforme à l'une des revendications 20 ou 21. 25. Ordinateur serveur d'un réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé de proposition d'un service conforme à l'une des revendications 1 à 9. 26. Ordinateur client d'un réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé de test d'accès conforme à l'une des revendications 10 à 13. 27. Réseau de communication, caractérisé en ce qu'il comprend des 10 moyens adaptés à mettre en oeuvre le procédé de proposition d'un service conforme à l'une des revendications 1 à 9. 28. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé de test d'accès conforme à l'une des revendications 10 à 13. 29. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé de vérification de compatibilité conforme à la revendication 14. 30. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, caractérisé en ce 20 qu'il comprend des instructions pour un programme informatique adaptées à mettre en oeuvre le procédé de proposition d'un service conforme à l'une revendications 1 à 9, lorsque ce programme est chargé et exécuté par le système informatique. 31. Moyen de stockage d'informations, éventuellement totalement ou 25 partiellement amovible, lisible par un système informatique, caractérisé en ce qu'il comprend des instructions pour un programme informatique adaptées à mettre en oeuvre le procédé de test d'accès conforme à l'une des revendications 10 à 13, lorsque ce programme est chargé et exécuté par le système informatique. 32. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, caractérisé en ce qu'il comprend des instructions pour un programme informatique adaptées à mettre en oeuvre le procédé de vérification de compatibilité conforme à la revendication 14, lorsque ce programme est chargé et exécuté par le système informatique 33. Programme d'ordinateur lisible par un microprocesseur, 5 caractérisé en ce qu'il comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé de proposition d'un service conforme à l'une des revendications 1 à 9, lorsqu'il est chargé et exécuté par le microprocesseur. 34. Programme d'ordinateur lisible par un microprocesseur, caractérisé ce qu'il comprend des portions de code logiciel adaptées à mettre 10 en ceuvre le procédé de test d'accès conforme à l'une des revendications 10 à 13, lorsqu'il est chargé et exécuté par le microprocesseur. 35. Programme d'ordinateur lisible par un microprocesseur, caractérisé ce qu'il comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé de vérification de compatibilité conforme à l'une la 15 revendication 14, lorsqu'il est chargé et exécuté par le microprocesseur.