Brevet FR2844414A1 — 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é d'analyse par un ordinateur client d'un réseau de communication d'un document de description d'un service. 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 15 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 20 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 sont fréquemment standardisés. Ainsi, le protocole SOAP est un protocole permettant d'échanger des 25 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 Markup Language"). La norme SOAP définit la structure générale des messages 30 échangés ainsi que les traitements devant être réalisés par un ordinateur envoyant ou recevant des messages SOAP. Le protocole SOAP est un protocole extensible, c'est-à-dire que la norme ne définit que le coeur du protocole, des fonctionnalités supplémentaires pouvant être ajoutées à ce protocole. Ces fonctionnalités supplémentaires sont appelées "features". La 5 norme SOAP version 1.2 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/2002IWD-soapi 2-parti 20020626/ En particulier, chaque propriété est décrite par son nom et par son type de données. 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 15 mise en oeuvre de cette fonctionnalité. Cette norme SOAP qui définit ainsi les échanges des informations 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 20 être utilisé. Cependant, comme un même protocole peut être utilisé de plusieurs 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 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 30 fourni par un ordinateur serveur du réseau de communication. On connaît ainsi un langage de description d'un service informatique 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.org/TR/2001/NOTE-wsdl-20010315. Un document électronique de description d'un service en langage WSDL comporte généralement deux parties. Une première partie, appelée "partie abstraite" est adaptée à décrire les messages échangés entre ordinateur 10 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 20 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 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 25 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 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 à 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. La présente invention a pour but de résoudre les inconvénients 10 précités et de permettre en particulier l'accès à des services fournis sur un réseau de communication via des protocoles de communication extensibles. 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, comprenant une étape d'envoi d'un document de description d'un service 15 comprenant des informations relatives à un protocole de communication incluant une description d'au moins une fonctionnalité mise en oeuvre par ledit protocole de communication lors de l'exécution du service sur le réseau de communication. La présente invention permet ainsi au sein même d'un document de 20 description d'un service d'inclure des informations sur une fonctionnalité mise en oeuvre par le protocole de communication, de telle sorte qu'il est possible de spécifier dans un même document quelles fonctionnalités d'un protocole sont supportées par l'ordinateur serveur. Cette fonctionnalité étant définie par un document de description 25 d'un service envoyé à un ordinateur client, il est possible, lors de la réception de ce document par l'ordinateur client, de déterminer s'il supporte tel ou tel autre protocole de communication proposé par l'ordinateur serveur pour mettre en oeuvre le service. L'invention permet ainsi de faciliter l'accès par un ordinateur client à 30 un service web proposé par un ordinateur serveur. Selon une caractéristique préférée de l'invention, la description de cette fonctionnalité est incluse par référence dans le document de description d'un service. Ainsi, une même fonctionnalité décrite dans un fichier séparé peut 5 être incorporée par référence dans plusieurs protocoles de communication utilisant cette même fonctionnalité. Cette caractéristique permet de limiter la taille du document de description d'un service dans lequel plusieurs protocoles de communication peuvent être proposés, en limitant ainsi la description des fonctionnalités mises 10 en oeuvre par chaque protocole de communication. De manière pratique, la description de la fonctionnalité comprend une liste de propriétés supportées par ladite fonctionnalité, de manière à décrire différentes options associées à cette fonctionnalité. De préférence, pour au moins une propriété supportée par la 15 fonctionnalité, la description de cette fonctionnalité comprend une liste de valeurs attribuables à cette propriété. Selon une autre caractéristique préférée, au moins une propriété est en outre associée à un attribut adapté à indiquer la compréhension ou l'utilisation obligatoire ou non de cette propriété par un ordinateur client lors de 20 la mise en oeuvre du protocole de communication pour l'exécution du service sur le réseau de communication. Ainsi, il est possible d'indiquer à l'ordinateur client dans le document de description d'un service si chaque propriété des fonctionnalités mises en oeuvre par le protocole doit être comprise et si son utilisation est optionnelle ou 25 non, de façon à faciliter le choix d'un protocole de communication par l'ordinateur client cherchant à mettre en oeuvre le service via le réseau de communication. Selon une autre caractéristique préférée de l'invention, la description d'une fonctionnalité est associée à un attribut adapté à indiquer la 30 compréhension ou 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. Comme précédemment, l'utilisation d'un tel attribut permet d'indiquer le caractère optionnel ou non de la compréhension ou de l'utilisation d'une fonctionnalité associée à un protocole de communication pour l'exécution du service sur le réseau de communication. Selon une caractéristique particulièrement bien adaptée au document de description d'un service du type WSDL, la description de ladite fonctionnalité est incluse dans la seconde partie d'un tel document, incluant les informations relatives à au moins un protocole de communication mis en oeuvre lors de l'exécution du service fourni par l'ordinateur serveur. Selon un autre aspect de l'invention, un procédé d'analyse par un ordinateur client d'un réseau de communication d'un document de description d'un service comprenant des informations relatives à un protocole de communication incluant une description d'au moins une fonctionnalité mise en oeuvre par ledit protocole de communication lors de l'exécution d'un service, 15 comprend, pour chaque protocole connu de l'ordinateur client du réseau de communication, les étapes suivantes: - extraction de la description des fonctionnalités mises en oeuvre par le protocole; - vérification que chaque fonctionnalité est supportée par 20 l'ordinateur client du réseau de communication; et - ajout de ce protocole à une liste de protocoles utilisables pour l'exécution du service fourni par l'ordinateur serveur si toutes les fonctionnalités associées à ce protocole de communication sont supportées par l'ordinateur client. Ainsi, le procédé d'analyse d'un document de description d'un service permet pour un ordinateur client d'identifier les protocoles de communication utilisables sur le réseau de communication et supportés par l'ordinateur serveur qu'il est à même d'utiliser pour l'exécution du service. Corrélativement, la présente invention concerne également un 30 dispositif de proposition d'un service fourni par un ordinateur serveur dans un réseau de communication. Ce dispositif comprend des moyens d'envoi d'un document de description d'un service comprenant des informations relatives à un protocole de communication incluant une description d'au moins une fonctionnalité mise en oeuvre par protocole de communication lors de l'exécution du service sur le réseau de communication. Elle concerne également un dispositif d'analyse par un ordinateur 5 client d'un réseau de communication d'un document de description d'un service comprenant des informations relatives à un protocole de communication incluant une description d'au moins une fonctionnalité mise en oeuvre par le protocole de communication lors de l'exécution dudit service. Ce dispositif d'analyse comprend: - des moyens d'extraction de la description des fonctionnalités mises en oeuvre par un protocole; - des moyens de vérification adaptés à vérifier si chaque fonctionnalité est supportée par l'ordinateur client du réseau de communication et - des moyens d'ajout dudit protocole à une liste de protocoles utilisables pour l'exécution du service fourni par l'ordinateur serveur si toutes les fonctionnalités associées au protocole de communication sont supportées par l'ordinateur client. Ce dispositif de proposition d'un service et ce dispositif d'analyse 20 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 d'analyse conformes à l'invention. Elle vise plus particulièrement un ordinateur serveur d'un réseau de 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é 30 d'analyse 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é d'analyse conformes à l'invention. Elle vise par ailleurs un moyen de stockage d'informations, 5 é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é d'analyse conformes à l'invention, lorsque ce programme est chargé et exécuté par le système informatique. Enfin, elle concerne un programme d'ordinateur lisible par un microprocesseur comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé de proposition d'un service et/ou le procédé d'analyse 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 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 20 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é d'analyse d'un 25 document de description d'un service conforme à un mode de réalisation de l'invention; - la figure 3 est un algorithme détaillant l'étape de test sur le support de la fonctionnalité par un ordinateur client; - la figure 4a illustre une liste de protocoles utilisables pour 30 l'exécution d'un service mise à jour par le procédé d'analyse conforme à l'invention; - la figure 4b est un exemple de fonctionnalités associées à un protocole; - la figure 4c illustre un exemple de propriétés supportées par une fonctionnalité; - la figure 5 est un algorithme illustrant une méthode d'accès à un service sur un réseau de communication; et - la figure 6 est un schéma bloc illustrant un dispositif adapté à mettre en oeuvre l'invention. On va décrire tout d'abord en référence à la figure 1 un procédé de 10 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 des données sous forme de documents à des ordinateurs clients. Très fréquemment, ces ordinateurs serveurs fournissent également 15 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 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 20 ordinateur serveur. A la réception El0 d'une telle requête de description, le procédé de proposition de services comprend une étape d'envoi El 1 d'un document de description d'un service. Dans la suite de la description, et de manière non limitative, on 25 considérera que ce document de description d'un service utilise le langage 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 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 la première partie du document WSDL. La déclaration de ces types est généralement réalisée au moyen de 10 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 l'invention de décrire plus avant les types utilisés. La seconde sous-partie de la première partie du document contient 15 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 contenu ou l'enchaînement. Elle consiste à définir de manière abstraite et de donner le type d'une 20 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 eux: a) un premier message permet de transmettre le nom d'une action 25 b) un second message permet de transmettre le prix associé à une action: il 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 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: Bien évidemment des formes plus élaborées d'opération, constitué 15 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 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 20 ordinateur serveur. Le document WSDL comprend en outre, comme expliqué précédemment, une seconde partie qui permet de préciser quel protocole est 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 25 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 30 de communication incluses dans cette seconde partie du document WSDL, comprennent la description d'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 un service, ainsi que les fonctionnalités de ce protocole. 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 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 15 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 WSDL. On obtient ainsi un document de description de service écrit dans un 20 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 25 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 30 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 protocolaire permettant ainsi de définir une 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 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 10 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 é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 15 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: 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 liste de propriétés supportées, toutes les propriétés obligatoires de la 10 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 15 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 20 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 ceuvre 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: 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 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 30 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 décrire de la manière suivante une fonctionnalité de corrélation de message: Ou encore une fonctionnalité de mode de transfert de message (binaire ou texte): binary text Ou encore une fonctionnalité de compression: 20 gzip tar Dans ce dernier exemple, cette fonctionnalité de compression 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é 30 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: 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 15 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: 30 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 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 15 anglais "binding") peut être décrit de la manière suivante: 20 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 mustUnderstand adapté à indiquer que la compréhension de cette fonctionnalité doit être obligatoire lors de la mise en ceuvre du protocole de 5 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 "mustUnderstand" est associé à une valeur vrai (true) qui signifie que l'ordinateur client doit supporter cette fonctionnalité "mep" ou "feature" et qu'il 10 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 15 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 20 courrier électronique, ou même par utilisation directe du protocole de communication HTTP: 25 10 Les éléments "protocol" ainsi définis peuvent être ainsi inclus dans un document de description d'un service, et plus particulièrement dans la partie 15 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 fonctionnalités sont décrites respectivement dans des balises filles incluses 20 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 25 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 30 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 "protocol" peut être référencé depuis le fichier contenant la description du 15 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 20 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 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 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. L'invention permet ainsi de décrire quels protocoles sont supportés par un serveur proposant des services web. Elle permet de décrire quelles fonctionnalités de ces protocoles sont supportées par le serveur et de préciser si ces fonctionnalités doivent être comprises ou utilisées par l'ordinateur client. Elle permet de décrire quelles propriétés d'une fonctionnalité sont supportées par le serveur, d'indiquer les valeurs possibles pour ces propriétés et de préciser si ces propriétés doivent être comprises ou utilisées par l'ordinateur client. Toutes ces capacités permettent de faciliter l'accès par un ordinateur 20 client à un service web proposé par un serveur. La description d'un protocole étant indépendante des éléments de couplage "binding", elle n'a pas à être répliquée dans chaque élément "binding". Ceci permet de diminuer la taille du fichier décrivant les services web et d'accélérer son temps de traitement par l'ordinateur client. En outre, la description d'un protocole peut être partagée par plusieurs serveurs ou par plusieurs services web d'un même serveur. Ceci permet également de diminuer la taille des informations transmises sur le réseau et d'accélérer le temps de traitement de ces informations par un ordinateur client. Le modèle de description de l'invention est commun à tous les protocoles. Ceci permet de simplifier l'ajout d'un protocole sur un serveur ou sur un ordinateur client. Ceci permet aussi de simplifier la mise en oeuvre de la partie client décodant la description d'un service web. On va décrire ainsi un procédé d'analyse par un ordinateur client d'un réseau de communication d'un document de description d'un service conforme à l'invention. Comme décrit précédemment, ce document de description d'un service comprend des informations relatives à un protocole de communication, ces informations incluant une description d'au moins une fonctionnalité mise en oeuvre par le protocole de communication lors de l'exécution du service. Comme décrit à la figure 2, ce procédé d'analyse comporte tout d'abord une étape de lecture E20 d'un fichier WSDL. Dans cet exemple de réalisation, le document de description d'un service est représenté dans un langage de balisage du type WSDL, complété et perfectionné par la description d'une ou plusieurs fonctionnalités comme décrit 1 5 précédemment. Une étape de lecture E21 est adaptée à lire spécifiquement la description d'un service telle que décrite dans un document de description WSDL. Une étape d'extraction E22 est ensuite mise en oeuvre afin d'extraire 20 un premier protocole de communication. Dans une étape d'obtention E23, la description du protocole de communication est obtenue par identification des informations relatives à ce protocole de communication et incluses dans le document WSDL. Lors d'une étape de test E24, l'ordinateur client mettant en oeuvre le 25 procédé d'analyse conforme à l'invention, vérifie si le protocole de communication ainsi décrit est connu. Dans la négative, on considère éventuellement un protocole suivant dans une étape de lecture E25. Ainsi, comme illustré à la figure 4a, pour un même service identifié 30 lors de l'étape de lecture E21, par exemple le service "StockQuoteService", il existe trois protocoles de communication utilisables pour la mise en oeuvre de ce service, identifiés par les noms suivants: - w3c-soap12-http1 1, - crf-soapl2-http1 1, - ieff-http 1. Lorsqu'un protocole connu est identifié à l'étape de test E24, on 5 extrait dans une étape d'extraction E26 une fonctionnalité décrite dans le document de description WSDL et associée à ce protocole. Ainsi comme illustré à la figure 4b, à titre d'exemple pour le protocole de communication w3c-soapl2-httpll, il existe trois fonctionnalités intitulées request-response, soap-response, et web-method. Une étape de test E27 est ensuite mise en oeuvre pour vérifier si la fonctionnalité ainsi extraite est supportée par l'ordinateur client. Cette étape de test est détaillée à la figure 3. Elle comprend tout d'abord une étape d'obtention E40 de la description de la fonctionnalité analysée. Dans une étape de test E41, on vérifie si cette fonctionnalité est connue de l'ordinateur client. Dans la négative, une étape de test E42 est adaptée à vérifier si cette fonctionnalité est associée à un attribut mU, c'est-à-dire à un attribut "mustUnderstand" ou "mustUse" comme décrit précédemment. Si un tel attribut a une valeur vrai ("true"), la réponse retournée à l'étape de test E27 est négative de telle sorte que la fonctionnalité n'est pas supportée par l'ordinateur client. Ainsi, comme illustré à la figure 4b, la fonctionnalité web-method peut être associée à un attribut mU ayant pour valeur vrai ("true"). En revanche, si la fonctionnalité, bien que non connue par l'ordinateur client, n'est pas associée à l'attribut mU, la réponse retournée pour cette fonctionnalité indique qu'elle est supportée par l'ordinateur client dès lors que sa mise en oeuvre lors de l'exécution d'un service n'est pas nécessaire. Si à l'issue de l'étape de test E41, la fonctionnalité est connue de 30 l'ordinateur client, une étape de test E43 permet de déterminer si la description du document WSDL contient des propriétés associées à cette fonctionnalité. Dans l'affirmative, une étape d'obtention E44 est adaptée à obtenir la description d'une première propriété associée à la fonctionnalité. Comme illustré à figure 4c, pour chaque fonctionnalité, une liste de propriétés peut être associée. A titre d'exemple, pour la fonctionnalité "request5 response", les propriétés suivantes sont décrites: - reqres: Role, - reqres:State, - reqres:OutboundMessage, - reqres: InboundMessage, - reqres: ImmediateDestination, - reqres:lmmediateSender, context:ExchangePatternName, - context:FailureReason. On vérifie dans une étape de test E45 si cette propriété est connue 15 de l'ordinateur client. Dans la négative, une seconde étape de test E46 est adaptée à déterminer si cette propriété est associée à un attribut mU dont la valeur est vrai (true). Dans l'affirmative, la réponse retournée à l'étape de test E27 est 20 négative, dès lors que cette propriété n'est pas supportée par l'ordinateur client. Sinon, on vérifie dans une étape de test E47 s'il existe une autre propriété associée à la fonctionnalité analysée. Dans l'affirmative, on considère la propriété suivante dans une étape E48 et on réitère pour cette propriété l'ensemble des étapes d'obtention E44 et 25 suivante. Si à l'issue de l'étape de test E45, la propriété analysée est connue de l'ordinateur client, une étape d'ajout E49 est adaptée à ajouter la propriété ainsi identifiée à une liste de propriétés P, en association avec la valeur vrai ("true") ou faux ("false") des attributs mU. L'étape de test E47 est mise en oeuvre afin d'identifier d'éventuelles autres propriétés associées à la fonctionnalité et l'ensemble des étapes E44 à E49 sont réitérées pour cette autre propriété. Lorsque toutes les propriétés ont été analysées, une étape d'ajout E50 est adaptée à ajouter le nom de la fonctionnalité associée à la liste de propriétés P dans une liste de fonctionnalité F. On identifie ainsi à l'étape d'ajout E50 une fonctionnalité supportée 5 par l'ordinateur client et associée à une ou plusieurs propriétés, également supportées par l'ordinateur client, permettant la mise en oeuvre du service. Si à l'issue de l'étape de test E43, la description analysée ne contient pas de propriétés associées à la fonctionnalité connue, une étape d'obtention E51 est adaptée à obtenir une liste de propriétés correspondant à une liste par 10 défaut de propriétés associées à cette fonctionnalité. Cette liste par défaut peut être établie de manière standardisée pour chaque fonctionnalité, dès lors que de nouvelles fonctionnalités n'ont pas été introduites dans le document de description d'un service par l'ordinateur serveur. Cette liste de propriétés correspondant en fait à une liste de propriétés mise en oeuvre par défaut dans la fonctionnalité connue de l'ordinateur client, est ajoutée dans l'étape d'ajout E50 à la liste F. En revenant à la figure 2, la réponse au test E27 est alors affirmative, dès lors que la fonctionnalité est supportée par l'ordinateur client. Si à l'issue de l'étape de test E27, la fonctionnalité n'est pas supportée, le protocole ne peut être mis en oeuvre par l'ordinateur client et un protocole suivant est éventuellement identifié dans l'étape de lecture E25. A contrario, si l'issue de l'étape E27, la fonctionnalité est supportée par l'ordinateur client, on vérifie dans une autre étape de test E28 s'il existe une 25 autre fonctionnalité associée au protocole connu. Dans l'affirmative, on considère, la fonctionnalité suivante dans une étape d'identification E29, et les étapes d'extraction E26 et de test E27 sont réitérées pour cette nouvelle fonctionnalité. Lorsque toutes les fonctionnalités associées au protocole ont été 30 analysées et déclarées supportées par l'ordinateur client comme décrit précédemment, une étape d'ajout E30 est adaptée à ajouter le protocole à une liste de protocoles utilisables U pour l'exécution du service fourni par l'ordinateur serveur. En pratique, cette liste U comprend pour chaque service, l'identification d'un protocole associé à la liste de fonctionnalité F telle que construite par la mise en oeuvre de l'algorithme décrit à la figure 3. Dans une étape de test E31, on vérifie s'il existe un autre protocole disponible et décrit dans le document de description d'un service pour la mise en oeuvre de celui-ci. Dans l'affirmative, on considère le protocole suivant dans une étape 10 de lecture E25 et on réitère pour ce protocole l'ensemble des étapes E22 à E31 décrites précédemment. Lorsque tous les protocoles ont été ainsi analysés, le procédé d'analyse du document prend fin. On obtient ainsi à l'issue de ce procédé d'analyse, une liste de 15 protocoles utilisables U, l'ordinateur client pouvant utiliser l'un ou l'autre des protocoles pour accéder aux services proposés par un ordinateur serveur du réseau de communication. Ainsi, comme illustré à la figure 5, un procédé d'accès à un service sur un réseau de communication peut être mis en oeuvre par l'ordinateur client. 20 Une étape d'obtention E60 permet d'obtenir la liste U de protocoles utilisables telle que construite lors la mise en oeuvre de l'algorithme d'analyse d'un document illustré à la figure 2. Parmi cette liste, une étape de choix E61 permet d'identifier un protocole de communication pour la mise en oeuvre d'un service. Dans une étape d'obtention E62, une fonctionnalité associée à ce protocole est obtenue. On vérifie dans une étape de test E63 si cette fonctionnalité est associée à un attribut mU. Dans la négative, on vérifie dans une étape de test E64 si cette 30 fonctionnalité est utilisée réellement par l'ordinateur client pour la mise en oeuvre du service. Dans l'affirmative, une étape d'initialisation E65 permet d'initialiser cette fonctionnalité. De même, si à l'étape de test E63, cette fonctionnalité est associée à l'attribut mU, l'étape d'initialisation de cette fonctionnalité est également mise en oeuvre. En pratique, une étape d'obtention E66 est adaptée à obtenir une propriété associée à cette fonctionnalité. En étape de test E67 permet de vérifier si cette propriété est associée à un attribut mU. Ces étapes de test E63 et E67 peuvent être mises en oeuvre directement à partir des informations mémorisées dans les listes P et F construites lors de la mise en oeuvre de l'algorithme illustré à la figure 3 et mémorisées dans la liste de protocoles utilisables U. Si à l'issue de cette étape de test E67, cette propriété n'est pas 15 associée à un attribut mU ayant pour valeur vrai ("true"), on vérifie dans une étape de test E68 si cette propriété est utilisée par l'ordinateur client pour la mise en oeuvre du service. Dans l'affirmative, une étape de définition E69 est adaptée à donner une valeur à cette propriété. De même, si à l'issue de l'étape de test E67, la propriété identifiée est associée à un attribut mU mis à la valeur vrai, l'étape de définition E69 est également mise en oeuvre sur cette propriété. Si à l'issue de l'étape de test E68, la propriété identifiée n'est pas utilisée par l'ordinateur client pour la mise en oeuvre du service, on vérifie, dans 25 une étape de test E70, s'il existe une autre propriété associée la fonctionnalité analysée. Cette étape de test E70 est également mise en oeuvre à l'issue de l'étape E69, après définition de la valeur d'une propriété. S'il existe une autre propriété, on considère dans une étape E71 une 30 propriété suivante et on réitère pour celle-ci l'ensemble des étapes E66 à E70. Lorsque toutes les propriétés associées à la fonctionnalité ont été ainsi traitées, on vérifie dans une autre étape de test E72 s'il existe une autre fonctionnalité associée au protocole analysé. Cette étape de test E72 est également mise en oeuvre directement à 5 l'issue de l'étape de test E64, lorsque la fonctionnalité analysée n'est pas utilisée par l'ordinateur client. Si une autre fonctionnalité existe, une étape d'identification E73 d'une fonctionnalité suivante est mise en oeuvre et l'ensemble des étapes E62 à E72 sont réitérées pour la fonctionnalité suivante associée au protocole de 10 communication. Lorsqu'à l'issue de l'étape E72, toutes les fonctionnalités ont été traitées, l'algorithme d'accès à un service se termine. On constate ainsi que selon l'invention, après analyse d'un document WSDL et construction de la liste de protocoles utilisables U incluant une liste de 15 fonctionnalités F, décrivant elle même une liste de propriétés P utilisables par l'ordinateur client, l'accès à un service via un protocole de communication est grandement simplifié. Afin de mettre en oeuvre le procédé de proposition d'un service tel que décrit en référence à la figure 1, un dispositif de proposition d'un service 20 comprend essentiellement des moyens d'envoi d'un document de description d'un service comprenant des informations relatives à un protocole de communication incluant la description d'une ou plusieurs fonctionnalités, ainsi que des propriétés associées. De même, un dispositif d'analyse par un ordinateur client d'un réseau 25 de communication d'un tel document de description comprend essentiellement des moyens d'extraction des fonctionnalités mises en oeuvre par un protocole. Des moyens de vérification sont adaptés à vérifier que chaque fonctionnalité est bien supportée par l'ordinateur client du réseau de communication et des moyens d'ajout sont adaptés à ajouter ce protocole à une liste de protocoles 30 utilisables pour l'exécution du service fourni par l'ordinateur serveur si et seulement si toutes les fonctionnalités associées au protocole de communication, et dont la compréhension ou l'utilisation sont obligatoires, sont bien supportées par l'ordinateur client. Ces dispositifs de proposition d'un service et d'analyse d'un document de description d'un service peuvent être incorporés dans un ordinateur tel qu'illustré à la figure 6. En particulier, le dispositif de proposition d'un service est incorporé dans un ordinateur serveur S d'un réseau de communication alors que le dispositif d'analyse d'un document WSDL est incorporé dans un ordinateur client C d'un réseau de communication. Plus précisément, les différents moyens identifiés ci-dessus peuvent être incorporés dans un microprocesseur 100, une mémoire morte 101 ("Readonly memory" ou ROM) étant adaptée à mémoriser un programme de proposition d'un service et/ou d'analyse. Bien entendu, ces dispositifs de proposition d'un service ou d'analyse 15 d'un document de description d'un service peuvent être mis en oeuvre dans un même ordinateur ou bien dans des stations différentes du 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 20 l'exécution du programme de proposition d'un service ou d'analyse d'un document de description d'un service. Le microprocesseur 100 est intégré à un ordinateur qui peut être connecté à différents périphériques et à d'autres ordinateurs d'un réseau de communication 10. En particulier, cet ordinateur correspond à un ordinateur 25 serveur S ou un ordinateur client C de ce réseau de communication 10. Cet ordinateur S, C comporte de manière connue une interface de communication 110 relié 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 7. Ces moyens de stockage fixes ou amovibles peuvent comporter le code du procédé de proposition ou d'analyse 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 ou d'analyse 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 103 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. Le 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 (S) dans un réseau de communication (10), caractérisé en ce qu'il 10 comprend une étape d'envoi (Ell) d'un document de description d'un service comprenant des informations relatives à un protocole de communication incluant une description d'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 1, caractérisé en ce que la description de ladite fonctionnalité est incluse par référence dans le document de description d'un service. 3. Procédé de proposition d'un service, caractérisé en ce que la description de ladite fonctionnalité comprend une liste de propriétés supportées 20 par ladite fonctionnalité. 4. Procédé de proposition d'un service conforme à la revendication 3, caractérisé en ce que pour au moins une propriété supportée par ladite fonctionnalité, la description de ladite fonctionnalité comprend une liste de valeurs attribuables à ladite propriété. 5. Procédé de proposition d'un service conforme à l'une des revendications 3 ou 4, caractérisé en ce que au moins une propriété est associée à un attribut adapté à indiquer la compréhension obligatoire ou non de ladite propriété par un ordinateur client (C) lors de la mise en oeuvre du protocole de communication pour l'exécution dudit service sur le réseau de communication (10). 6. Procédé de proposition d'un service conforme à l'une des revendications 3 à 5, caractérisé en ce que chaque propriété est associée à un attribut adapté à indiquer l'utilisation obligatoire ou non de ladite propriété par un ordinateur client (C) lors de la mise en oeuvre du protocole 5 de communication pour l'exécution dudit service sur le réseau de communication (10). 7. Procédé de proposition d'un service conforme à l'une des revendications 1 à 6, caractérisé en ce que la description d'une fonctionnalité est associée à un attribut adapté à indiquer la compréhension obligatoire ou 10 non de ladite fonctionnalité par un ordinateur client (C) lors de la mise en oeuvre du protocole de communication pour l'exécution dudit service sur le réseau de communication (10). 8. Procédé de proposition d'un service conforme à l'une des revendications là 7, caractérisé en ce que la description d'une fonctionnalité 15 est associée à un attribut adapté à indiquer l'utilisation obligatoire ou non de ladite fonctionnalité par un ordinateur client (C) lors de la mise en oeuvre du protocole de communication pour l'exécution dudit service sur le réseau de communication (10). 9. Procédé de proposition d'un service conforme à l'une des 20 revendications 1 à 8, caractérisé en ce que le document de description d'un service est écrit dans un langage de balisage, lesdites fonctionnalités étant décrites respectivement dans des balises filles incluses dans une balise référençant un protocole de communication. 10. Procédé de proposition d'un service conforme à l'une des 25 revendications 1 à 9, 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 SOAP. 11. Procédé de proposition d'un service conforme à l'une des revendications 1 à 10, dans lequel le document de description d'un service est 30 un document comprenant une première partie incluant des informations relatives aux messages échangés lors de l'exécution dudit service, et une 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 la description de ladite fonctionnalité est incluse dans ladite seconde partie de document de description d'un service. 12. Procédé de proposition d'un service conforme à l'une des 5 revendications 1 à 11, caractérisé en ce que ladite fonctionnalité est décrite par une référence locale de l'ordinateur serveur (S) ou par une URI. 13. Procédé d'analyse par un ordinateur client (C) d'un réseau de communication (10) d'un document de description d'un service comprenant des informations relatives à un protocole de communication incluant une description 10 d'au moins une fonctionnalité mise en oeuvre par ledit protocole de communication lors de l'exécution dudit service, caractérisé en ce qu'il comprend, pour chaque protocole connu dudit ordinateur client (C) du réseau de communication (10), les étapes suivantes: - extraction (E26) de la description des fonctionnalités mises en 15 oeuvre par ledit protocole; - vérification (E27) que chaque fonctionnalité est supportée par l'ordinateur client (C) du réseau de communication (10); et - ajout (E30) dudit protocole à une liste de protocoles utilisables (U) pour l'exécution du service fourni par un ordinateur serveur (S) si toutes les 20 fonctionnalités associées audit protocole de communication sont supportées par l'ordinateur client (C). 14. Dispositif de proposition d'un service fourni par un ordinateur serveur (S) dans un réseau de communication (10), caractérisé en ce qu'il comprend des moyens d'envoi (100, 101, 102) d'un document de description 25 d'un service comprenant des informations relatives à un protocole de communication incluant une description d'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 (10). 15. Dispositif de proposition d'un service conforme à la revendication 30 14, caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100) ; - une mémoire morte (101) adaptée à mémoriser un programme 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. 16. Dispositif d'analyse par un ordinateur client (C) d'un réseau de communication (10) d'un document de description d'un service comprenant des informations relatives à un protocole de communication incluant une description d'au moins une fonctionnalité mise en oeuvre par ledit protocole de communication lors de l'exécution dudit service, caractérisé en ce qu'il 10 comprend; - des moyens d'extraction (100, 101, 102) de la description des fonctionnalités mises en oeuvre par un protocole; - des moyens de vérification (100, 101, 102) adaptés à vérifier si chaque fonctionnalité est supportée par l'ordinateur client du réseau de 15 communication; et des moyens d'ajout (100, 101, 102) dudit protocole à une liste de protocoles utilisables (U) pour l'exécution du service fourni par un ordinateur serveur (S) si toutes les fonctionnalités associées au protocole de communication sont supportées par l'ordinateur client (C). 17. Dispositif d'analyse conforme à la revendication 16, caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100) - une mémoire morte (101) adaptée à mémoriser un programme d'analyse d'un document de description 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. 18. Ordinateur, caractérisé en ce qu'il comporte un dispositif de proposition d'un service conforme à l'une des revendications 14 ou 15. 19. Ordinateur, caractérisé en ce qu'il comporte un dispositif 30 d'analyse conforme à l'une des revendications 16 ou 17. 20. 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 à 12. 21. Ordinateur client d'un réseau de communication, caractérisé en 5 ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'analyse conforme à la revendication 13. 22. 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 à 12. 23. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'analyse conforme à la revendication 13. 24. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, caractérisé en ce 15 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 à 12 lorsque ce programme est chargé et exécuté par le système informatique. 25. Moyen de stockage d'informations, éventuellement totalement ou 20 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é d'analyse conforme à la revendication 13, lorsque ce programme est chargé et exécuté par le système informatique. 26. Programme d'ordinateur lisible par un microprocesseur, 25 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 à 12, lorsqu'il est chargé et exécuté par le microprocesseur. 27. Programme d'ordinateur lisible par un microprocesseur, caractérisé ce qu'il comprend des portions de code logiciel adaptées à mettre 30 en oeuvre le procédé d'analyse conforme à la revendication 13, lorsqu'il est chargé et exécuté par le microprocesseur.