FR2844414A1 - Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service. - Google Patents
Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service. Download PDFInfo
- Publication number
- FR2844414A1 FR2844414A1 FR0210989A FR0210989A FR2844414A1 FR 2844414 A1 FR2844414 A1 FR 2844414A1 FR 0210989 A FR0210989 A FR 0210989A FR 0210989 A FR0210989 A FR 0210989A FR 2844414 A1 FR2844414 A1 FR 2844414A1
- Authority
- FR
- France
- Prior art keywords
- service
- protocol
- computer
- communication
- description
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Un procédé de proposition d'un service fourni par un ordinateur serveur dans un réseau de communication, comprend une étape d'envoi (E11) 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.
Description
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 <types>...</types>.
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 <message name="GetStockQuoteInput"> <part name="Name" type="string"/> </message> b) un second message permet de transmettre le prix associé à une action: <message name="GetStockQuoteOutput"> <part name="Price" type="float"/> </message> 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: <operation name="GetStockQuote"> <input message="tns:GetStockQuoteInput"/> <output message="tns:GetStockQuoteOutput"/> </operation> 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: <feature name="web-method" id="http://www.w3.org/2002/06/soap/features/web-method" xmlns:webmeth="http://www.w3.org/2002/06/soap/features/we b-method"> <property name="webmeth:Method"> <values> <value>GET</value> <value> POST</value> <value>PUT</value> <value>DELETE</value> </values> </property> </feature> 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: <feature name="web-method" id="http://www.w3.org/2002/06/soap/features/web-method"> <property name="Webmeth Method" type="MethodType"/> </feature> <simpleType name="MethodType" finale="extension"> <restriction base="xsd:string"> <enumeration value="GET" /> <enumeration value="POST" /> <enumeration value="PUT" /> <enumeration value="DELETE" /> </restriction> </simpleType> 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: <feature name="web-method"id="http://www.w3.org/2002/06/soap/features/web-method" xmlns:webmeth="http://www.w3.org/2002/06/soap/features/we b-method"> <property name="webmeth:Method" mustUnderstand="true"> <values> <value> GET</value> <value>POST</value> <value >PUT</value> <value>DELETE</value> </values> </property> </feature>
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: <feature name="web-method" id="http://www.w3. org/2002/06/soap/features/web-method" xmlns:webmeth="http://www.w3. org/2002/06/soap/features/we b-method"> <property name="webmeth:Method" mustUse="true"> <values> <value>GET</value> <value>POST</value> <value> PUT</value> <value>DELETE</value> </values> </property> </feature> 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: <feature name="attachment" id="http://www.crf.canon.fr/2002/05/soap/features/attachm ent"> </feature> <feature name="mime-attachment" id="http://www.crf.canon. fr/2002/05/soap/features/attachm 10 ent/mime"> <implements name="attachment"/> </feature> 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: <feature name="emailcorrelation" id="http://www.example.org/2001/12/soap/bindings/Email/co rrelation" xmlns:correlation="http://www.example.org/2001/12/soap/bi ndings/Email/correlation"> <property name="correlation:requestMessageID"/> </feature> Ou encore une fonctionnalité de mode de transfert de message (binaire ou texte): <feature name="binary" 30 id="http://www.crf.canon. fr/2002/05/soap/bindings/FTP/bin ary" xmlns:binary="http://www.crf.canon. fr/2002/05/soap/bindin gs/FTP/binary"> <property name="binary:TransferMode"> <values> <value>binary</value> <value> text</value> </values> </property> </feature> Ou encore une fonctionnalité de compression: <feature name="compression" id="http://www. crf.canon.fr/2002/05/soap/bindings/HTTP/co 15 mpression" xmlns:compression="http://www.crf.canon.fr/2002/05/soap/b indings/HTTP/compression"> <property name="compression:CompressionAlgorithm"> 20 <values> <value>gzip</value> <value>tar</value> </values> </property> </feature> 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: <feature name="return-path" id="http://www.crf.canon.fr/2002/05/smtp/return-path" xmlns:returnpath="http://www.crf.canon.fr/2002/05/smtp/return-path"> <property name="return-path:Address"> </property> </feature> 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: <mep name="request-response" id="http://www.w3.org/2002/06/soap/mep/request20 response" xmlns:context="http://www.w3.org/2002/06/soap/bindingFram ework/ExchangeContext/" xmlns:reqres="http://www.w3. org/2002/06/soap/mep/requestresponse"> <property name="reqres:Role"/> <property name="reqres:State"/> <property name="reqres:OutboundMessage"/> 30 <property name="reqres:InboundMessage"/> <property name="reqres:ImmediateDestination"/> <property name="reqres:ImmediateSender"/> <property name="context:ExchangePatternName"/> <property name="context:FailureReason"/> </mep>
On peut également utiliser ce même mécanisme de description pour
décrire un module, par exemple un module d'authentification: <module name="basic-auth" id="http://www.crf.canon.fr /modules/basic-auth"> <property name="bauth:Username" type="xsd:string"/> <property name="bauth:Password" type="xsd:string"/> </module> 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:
<protocol name="w3c-soapl2-httpll" id="http://www.w3. org/2002/06/soap/bindings/HTTP"> <mep name="request-response"/> <mep name="soap-response"/> 20 <feature name="web-method"/> </protocol>
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: <protocol name="crf-soapl2-httpll" id="http://www.crf. canon.fr/2002/05/soap/bindings/HTTP"> 25 <mep name="request-response"/> <feature name="email-correlation"/> <feature name="compression"/> <feature name="web-method"/> </protocol> <protocol name="w3c-soapl2- email" id="http://www.example.org/2002/02/soap/bindings/Email"> <mep name="request-response"/> <feature name="email-correlation"/> </protocol> <protocol nbame="ietf-httpll" id="http://www.crf.canon. fr/2002/05/ieft/bindings/HTTP"> 10 <mep name="request-response"/> <feature name="web-method"/> </protocol> 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: <binding name="StockQuoteBinding" type="tns:StockQuotePortType"> <protocol name="w3c-soapl2-httpll"/> <operation name="GetStockQuote"> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> 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: <group name="MyMep"> <feature name="Web-Method"/> <choice> <mep name="request-response"/> <mep name="soap-response"/> </choice> </group> <protocol name="CRF"> <choice> <mep name="requestNresponses"/> <mep name="request-Noresponse"/> <group name="MyMep"/> </choice> </protocol> 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.
<protocol name="CRF"> <group> <choice name="MEP"> <mep name="requestresponse"/> <mep name="soap-response"/> </choice> <choice name="Authentication"> <feature name="basicAuth "/> <feature name="sslAuth"/> <feature name="xmlSigAuth"/> </choice> </group> </protocol>
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 <set number = "1"> et que l'élément "group" est équivalent à l'élément <set number = "aila"l>. 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.
Claims (27)
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.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0210989A FR2844414B1 (fr) | 2002-09-05 | 2002-09-05 | Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service. |
| US10/654,003 US8051188B2 (en) | 2002-09-05 | 2003-09-04 | Method of proposing a service via a description document of such a service |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0210989A FR2844414B1 (fr) | 2002-09-05 | 2002-09-05 | Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2844414A1 true FR2844414A1 (fr) | 2004-03-12 |
| FR2844414B1 FR2844414B1 (fr) | 2005-03-11 |
Family
ID=31725855
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0210989A Expired - Fee Related FR2844414B1 (fr) | 2002-09-05 | 2002-09-05 | Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service. |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR2844414B1 (fr) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7171454B2 (en) * | 2003-08-13 | 2007-01-30 | Siemens Energy & Automation, Inc. | Method for providing real-time production information using in-situ web services embedded in electronic production equipment |
| US10440066B2 (en) * | 2013-11-15 | 2019-10-08 | Microsoft Technology Licensing, Llc | Switching of connection protocol |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002001833A1 (fr) * | 2000-06-28 | 2002-01-03 | Microsoft Corporation | Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau |
| EP1221818A1 (fr) * | 2001-01-05 | 2002-07-10 | Nokia Corporation | Provision de services dans un système de communication |
| EP1229442A2 (fr) * | 2001-01-22 | 2002-08-07 | Sun Microsystems, Inc. | Architecture de calcul point à point |
-
2002
- 2002-09-05 FR FR0210989A patent/FR2844414B1/fr not_active Expired - Fee Related
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002001833A1 (fr) * | 2000-06-28 | 2002-01-03 | Microsoft Corporation | Commande a distance de services de systeme d'exploitation universel via un protocole homologue de commande de dispositif de reseau |
| EP1221818A1 (fr) * | 2001-01-05 | 2002-07-10 | Nokia Corporation | Provision de services dans un système de communication |
| EP1229442A2 (fr) * | 2001-01-22 | 2002-08-07 | Sun Microsystems, Inc. | Architecture de calcul point à point |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7171454B2 (en) * | 2003-08-13 | 2007-01-30 | Siemens Energy & Automation, Inc. | Method for providing real-time production information using in-situ web services embedded in electronic production equipment |
| US10440066B2 (en) * | 2013-11-15 | 2019-10-08 | Microsoft Technology Licensing, Llc | Switching of connection protocol |
| US11075962B2 (en) * | 2013-11-15 | 2021-07-27 | Microsoft Technology Licensing, Llc | Switching of connection protocol |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2844414B1 (fr) | 2005-03-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9929984B2 (en) | Method and computer program product for establishing real-time communications between networked computers | |
| FR2844370A1 (fr) | Document electronique de description d'un service informatique | |
| EP1994724B1 (fr) | Procede et systeme de caracterisation de noeuds de communication heterogenes | |
| FR2882164A1 (fr) | Procede et dispositif de transfert de donnees numeriques a format progressif | |
| WO2006037865A1 (fr) | Procede et systeme de resolution dns distribuee | |
| FR2847406A1 (fr) | Procede et dispositif modulaire de tracage d'un message multimedia a travers un reseau de telecommunications | |
| EP1381978A1 (fr) | Dispositif et procede d'echange de flux entre un dispositif client et un serveur | |
| FR2844414A1 (fr) | Procede de proposition d'un service et procede d'analyse d'un document de description d'un tel service. | |
| FR2994782A1 (fr) | Procede et systeme d'execution de protocoles de chargement de donnees | |
| US8051188B2 (en) | Method of proposing a service via a description document of such a service | |
| FR2929480A1 (fr) | Procede de determination de donnees complementaires relatives a au moins un contenu, procede pour transmettre ces donnees complementaires, dispositif de traitement et serveur d'applications associes | |
| EP2365680A1 (fr) | Dispositif de gestion dynamique des pages de sites internet dont les fréquentations et audience doivent être analysées | |
| FR2844369A1 (fr) | Procede de proposition d'un service, de test d'acces a un service et de verification de comptabilite | |
| WO2004056071A1 (fr) | Procede de communication entre serveurs avec conversion de format des donnees et dispositif pour sa mise en oeuvre | |
| FR2918527A1 (fr) | Procede et dispositif d'insertion d'une adresse dans une requete | |
| EP1370045B1 (fr) | Système d'accès à des données disponibles sur réseau actif | |
| EP1031926A1 (fr) | Procédé de communication entre objects distants | |
| EP4028888A1 (fr) | Procédé de communication entre des entités logicielles via une api | |
| FR2857191A1 (fr) | Systeme de transmission de parametres caracteristiques d'une session de communication d'un terminal vers un serveur distant | |
| EP2068243A1 (fr) | Procédé de composition automatique de services web et système informatique pour la mise en oeuvre d'un tel procédé | |
| WO2009050391A1 (fr) | Procede de reduction de charge de serveurs, terminal, dispositif, et produit programme d'ordinateur correspondants | |
| FR2786348A1 (fr) | Systeme multimedia de transmission de donnees | |
| FR2819965A1 (fr) | Procede de creation et d'envoi de messages electroniques et systeme de messagerie associe | |
| FR2816416A1 (fr) | Procede d'obtention de donnees par lots | |
| EP1723772A2 (fr) | Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20140530 |