Brevet FR2865088A1 — publié le 20050715

La présente invention concerne un procédé de création d'un document d'ordonnancement d'invocations de tâches. Elle concerne également un procédé d'exécution d'un tel document. Un document d'ordonnancement d'invocations de tâches permet de spécifier le déroulement de tâches ou processus mise en oeuvre sur un réseau de communication. Ce type de document est représenté sous forme de graphe, dans un langage appelé workflow, permettant la description de l'enchaînement des tâches. De plus en plus fréquemment, les tâches à exécuter intègrent des services Web fournis par un serveur d'un réseau de communication. Des langages de workflow permettent ainsi d'invoquer des services décrits par un document de description d'un service tel qu'un document en langage WSDL (acronyme du terme anglais "Web Service Description Language"). Les tâches à invoquer et à exécuter sont ainsi des opérations décrites dans un tel document de description d'un service. Jusqu'à présent, les langages de workflow utilisables pour décrire les invocations de services Web sont des langages du type BPML, BPEL4WS et XPDL. Une définition de ces langages de workflow peut être consultée à l'adresse électronique http:llwww.e-workflow.org. Ainsi, ces langages possèdent des éléments permettant d'interagir avec différents systèmes, notamment au moyen d'invocations de services Web. Les invocations de services Web sont effectuées grâce à un pointeur pointant vers un document décrivant une opération du service Web choisi. Ce document décrivant l'opération est généralement un document au format WSDL. Ce document WSDL est lui-même une application du langage de balisage XML (acronyme du terme anglais "eXtended Markup Language"). On trouvera une description d'un tel document WSDL sur le site informatique à l'adresse http:/lwww.w3.org/TR/2001/NOTE-wsdl-20010315. Lorsque le document de description d'un service est conforme à la norme WSDL1.1., les seuls paramètres d'une opération à exécuter sont des données abstraites qui sont définies et mémorisées dans une partie abstraite du document de description d'un service WSDL. La connaissance d'un tel document de description d'un service, associé à l'opération à invoquer, et des données abstraites nécessaires, mémorisées dans ce même document, permet l'exécution de l'opération telle que définie dans le document d'ordonnancement d'invocations de tâches. Cependant, des documents de description d'un service plus élaborés sont aujourd'hui disponibles dans les réseaux de communication. Ces documents de description d'un service comprennent en particulier des extensions qui sont définies par exemple par le serveur fournissant le service Web. Ces extensions peuvent être des fonctionnalités (en anglais "features") définies dans une partie concrète du document de description d'un service. L'utilisation d'une telle fonctionnalité peut être optionnelle ou obligatoire. Ces extensions peuvent aussi être des polices (en anglais "policy"). Les polices sont une alternative aux fonctionnalités, ont une syntaxe différente mais s'utilisent de la même manière. Cette fonctionnalité possède généralement un certain nombre de propriétés dont les valeurs peuvent être choisies par l'utilisateur parmi un ensemble de valeurs attribuables à cette fonctionnalité. De même, le document de description d'un service peut comporter des extensions définissant un ou plusieurs noeuds intermédiaires du réseau de communication par lesquels seront adaptés à transiter les messages lors de la mise en oeuvre de l'opération. D'une manière générale, les documents de description d'un service défini par la norme WSDL1.2. en cours d'élaboration ont un contenu ouvert et requièrent la prédéfinition, avant l'exécution d'un service, d'un certain nombre de valeurs, notamment lorsqu'ils comportent des extensions obligatoires. Actuellement, les langages de workflow utilisés lors de la création d'un document d'ordonnancement d'invocations des tâches n'offrent aucun moyen de décrire les extensions présentes dans les documents de description d'un service du type WSDL. La présente invention a pour but de résoudre les inconvénients précités et de permettre la description complète d'un service décrit par un document de description d'un service au moyen d'un document d'ordonnancement d'invocations de tâches. Selon un premier aspect, la présente invention concerne un procédé de création d'un document d'ordonnancement d'invocations de tâches, les tâches étant en partie des opérations décrites par un document de description d'un service fourni par un serveur d'un réseau de communication. Ce procédé de création d'un document comprend les étapes suivantes: sélection du document de description d'un service associé à une opération à invoquer; - extraction d'au moins une extension obligatoire associée à l'opération et d'un ensemble de valeurs attribuables à l'extension; acquisition d'une valeur déterminable parmi l'ensemble de valeurs attribuables; et - stockage de ladite extension obligatoire et de la valeur déterminable attribuée à l'extension. Ainsi, lors de la création d'un document d'ordonnancement d'invocations de tâches, le procédé de création permet de mémoriser et stocker des informations permettant de préciser le document de description d'un service WSDL associé à l'opération à invoquer. Ces informations stockées, concernant une extension obligatoire et une valeur déterminable attribuée à cette extension, sont ensuite utilisées lors de l'exécution du document d'ordonnancement d'invocations des tâches. Selon un premier mode de réalisation de l'invention, à l'étape de stockage, la valeur déterminable attribuée à l'extension obligatoire est stockée dans un document modifié de description d'un service, associé à l'opération à invoquer. Cette solution présente l'avantage de ne nécessiter aucune modification du langage utilisé pour l'ordonnancement d'invocations de tâches, ni du langage de description d'un service. Lors de l'exécution du document d'ordonnancement d'invocations de tâches, le procédé utilise directement le document modifié de description d'un service. Alternativement, le document modifié de description d'un service est stocké dans une version compilée par un processeur WSDL. On stocke ainsi un programme. On passe alors d'un document WSDL à une classe de type JAVA, C++... et chaque fonctionnalité proposée par le service Web devient une méthode de la classe. Selon un autre mode de réalisation de l'invention, à l'étape de stockage, l'extension obligatoire et la valeur déterminable attribuée à l'extension obligatoire sont stockées dans le document d'ordonnancement d'invocations de tâches. Une telle solution évite de modifier le document de description d'un service préalablement, au risque que ce document ne corresponde plus, au moment de l'exécution, au document original de description d'un service. Selon une autre caractéristique préférée de l'invention, la valeur déterminable est une valeur spécifique choisie parmi l'ensemble des valeurs attribuables à l'extension obligatoire. Alternativement, la valeur déterminable peut être représentée par un procédé d'obtention d'une valeur spécifique parmi l'ensemble des valeurs attribuables à l'extension obligatoire. De préférence, l'extension obligatoire est soit une fonctionnalité définie dans une partie concrète d'un document de description d'un service, soit encore un noeud intermédiaire du réseau de communication défini dans une partie concrète d'un document de description d'un service. De préférence, le procédé de création comprend en outre les étapes suivantes: - extraction d'au moins un schéma XML définissant des données en langage XML; - restriction de l'ensemble des valeurs attribuables auxdites données; et - stockage dudit schéma XML modifié par restriction de l'ensemble desdites valeurs attribuables auxdites données en langage XML. Un message XML est défini via un schéma XML. Il s'agit alors de modifier le schéma initial de données XML en un nouveau schéma qui recouvre un sous-ensemble des données XML couvertes par le schéma initial. La norme XML-Schema prévoit un tel scénario appelé sous le nom de dérivation par restriction. On restreint ainsi les valeurs possibles pour les données échangées par modification des schémas XML. Selon un second aspect, la présente invention concerne un procédé d'exécution d'un document d'ordonnancement d'invocations de tâches, les tâches étant en partie des opérations décrites par un document de description d'un service fourni par un serveur d'un réseau de communication. Ce procédé d'exécution comprend les étapes suivantes: - identification d'une opération décrite par un document de description d'un service; et exécution de l'opération à partir d'un document de description de service associé à l'opération et d'une valeur déterminable attribuée à une extension obligatoire associée à l'opération et stockée lors de la création du document d'ordonnancement d'invocations de tâches. Selon une caractéristique préférée de l'invention, préalablement à ladite étape d'exécution, ce procédé d'exécution comprend une étape d'obtention d'un document description d'un service modifié adapté à stocker ladite valeur déterminable associée à l'extension obligatoire de l'opération à invoquer. Selon un premier mode de réalisation, un document modifié de description d'un service et stocké lors de la création du document d'ordonnancement d'invocations des tâches est obtenu à ladite étape d'obtention. De préférence, dans ce premier mode de réalisation, une étape de test de compatibilité entre le document modifié de description d'un service et le document original de description d'un service est mise en oeuvre. Selon un deuxième mode de réalisation de l'invention, préalablement à ladite étape d'exécution, le procédé d'exécution comprend une étape d'obtention d'un document original de description d'un service et une étape de modification dudit document original de description d'un service à partir d'une valeur déterminable associée une extension obligatoire stockée dans le document d'ordonnancement d'invocations de tâches. Selon un troisième mode de réalisation de l'invention, préalablement à l'étape d'exécution, le procédé d'exécution comprend une étape d'obtention d'un document original de description d'un service, et une étape de configuration d'un processeur de traitement du document original de description d'un service à partir d'une valeur déterminable associée à une extension obligatoire stockée dans le document d'ordonnancement d'invocations de tâches. Ainsi, le processeur de traitement implémentant l'exécution de l'opération est directement configuré, le document de description d'un service n'étant pas modifié avant l'exécution proprement dite de l'opération. La présente invention concerne également un dispositif de création d'un document d'ordonnancement d'invocations de tâches, les tâches étant en partie des opérations décrites par un document de description d'un service fourni par un serveur d'un réseau de communication, comprenant: - des moyens de sélection d'un document de description d'un service associé à une opération à invoquer; - des moyens d'extraction d'au moins une extension obligatoire associée à l'opération et d'un ensemble de valeurs attribuables à l'extension; - des moyens d'acquisition d'une valeur déterminable parmi l'ensemble des valeurs attribuables; et - des moyens de stockage de l'extension obligatoire et de la valeur déterminable attribuée à l'extension. Elle concerne aussi un dispositif d'exécution d'un document d'ordonnancement d'invocations de tâches, les tâches étant en partie des opérations décrites par un document de description d'un service fourni par un serveur d'un réseau de communication, comprenant: - des moyens d'identification d'une opération décrite par un document de description d'un service; et - des moyens d'exécution de l'opération à partir d'un document de description d'un service associé à l'opération et d'une valeur déterminable attribuée à une extension obligatoire associée à l'opération et stockée lors de la création du document d'ordonnancement d'invocations de tâches. Ces dispositifs de création et d'exécution d'un document d'ordonnancement d'invocations de tâches présentent des caractéristiques et des avantages analogues aux procédés qu'ils mettent en oeuvre. Enfin, la présente invention concerne un ordinateur ou un réseau de communication adapté à mettre en oeuvre le procédé de création et/ou le procédé d'exécution d'un document d'ordonnancement d'invocations de tâches. Elle concerne également un programme d'ordinateur lisible par un microprocesseur comprenant des portions de code logiciel adaptées à mettre en oeuvre les procédés de création et/ou d'exécution conformes à l'invention, lorsque ledit programme est chargé et exécuté par un ordinateur. Ces ordinateur, réseau de communication et programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec les procédés de création et d'exécution d'un document d'ordonnancement d'invocations de tâches. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après. Aux dessins annexés, donnés à titre d'exemples non limitatifs: - la figure 1 est un algorithme illustrant un procédé de création d'un document d'ordonnancement d'invocations de tâches conforme à un mode de réalisation de l'invention; - la figure 2 est un algorithme détaillant l'étape d'ajout d'informations d'extension illustrée à la figure 1; - la figure 3 est un algorithme illustrant le procédé d'exécution d'un document d'ordonnancement d'invocations de tâches conforme à un mode de réalisation de l'invention; - la figure 4 est un algorithme illustrant l'étape de test de compatibilité telle qu'illustrée à la figure 3; et - la figure 5 est un schéma bloc illustrant un ordinateur adapté à mettre en oeuvre les procédés conformes à l'invention. On va décrire tout d'abord en référence à la figure 1 un procédé de création d'un document d'ordonnancement d'invocations de tâches. Dans la suite de la description, un tel document d'ordonnancement d'invocations de tâches, rédigé à partir d'un langage de workflow, sera appelé en abrégé un document workflow. Lors de la création d'un tel document workflow, une étape de test E10 est adaptée à vérifier si un service Web (Web Service ou WS) doit être 20 ajouté au document workflow. Dans l'affirmative, une étape de sélection E11 est mise en oeuvre afin de sélectionner un document de description d'un service WSDL. Ce document WSDL comprend la description d'au moins une opération. Cette opération à exécuter est également sélectionnée dans une étape de sélection E12. Conformément à l'invention, le procédé de création comporte en outre une étape d'ajout E13 d'informations d'extension, informations qui seront nécessaires à l'exécution de l'opération. Cette étape d'ajout E13 sera décrite en détail en référence à la figure 2. A l'issue de l'étape de l'étape de test E10, en l'absence de service Web à préciser dans le document workflow, une étape d'ajout E14 d'autres données est mise en oeuvre afin d'obtenir le document workflow complété. Ces autres données n'ont pas besoin d'être détaillées ici, elles correspondent à des données classiques intégrées dans ce type de documents workflow. On va décrire à présent en référence à la figure 2 l'étape d'ajout E13 des informations d'extension. En pratique, une étape d'acquisition E130 permet d'acquérir le document de description d'un service WSDL tel que sélectionné à l'étape E11. Une étape d'extraction E131 est adaptée à extraire du document WSDL à la fois la description abstraite et concrète de l'opération sélectionnée à l'étape de sélection E12. On rappelle en effet qu'un document de description d'un service défini selon la norme WSDL contient principalement deux parties. Une première partie, appelée partie abstraite, adaptée à décrire de manière abstraite les messages qui sont échangés entre ordinateurs. Cette première partie est elle-même divisée en trois sous-parties: 1. Une première sous-partie contient des déclarations de types. Ces types sont utilisés pour décrire la structure abstraite des messages. En général, ils sont référencés par la deuxième sous-partie. Cette partie n'étant pas essentielle à la description de l'invention ne sera pas décrite plus avant. ... 2. Une seconde sous-partie contient des déclarations de messages élémentaires. Elle représente les messages qui seront échangés entre les ordinateurs, sans en décrire précisément le contenu ou l'enchaînement (ce dernier point sera le sujet de la troisième sous-partie). Dans l'exemple suivant, on définit trois messages qui seront échangés entre les ordinateurs, sans dire quel lien existe entre ces différents messages. a. Le premier message correspond à une demande d'obtention de 30 la quantité d'un produit en stock. Le produit est identifié par son numéro d'inventaire ("PartNumber"). b. Le second message véhicule la quantité disponible d'un produit actuellement en stock: c. Le troisième message correspond à une demande de mise à jour d'une quantité de produit en stock: 3. Une troisième sous-partie regroupe les messages élémentaires en opérations logiques. Une opération peut donc être vue comme un service élémentaire, lui-même implémenté par un ou plusieurs messages. Dans l'exemple ci-dessous, les deux premiers messages élémentaires introduits plus haut sont regroupés en une même opération ("getQuantitylnStock"). Cette opération permet d'obtenir la quantité de produit actuellement disponible. De plus, le message élémentaire "getQuantitylnStocklnput" est déclaré comme étant de type requête ("input"), et le message élémentaire "getQuantitylnStockOutput" comme étant de type réponse ("output"). Enfin, les messages sont liés comme l'un étant la réponse à l'autre (puisqu'il font partie de la même opération, et sont placés dans l'ordre "input", "output". Par ailleurs, une seconde opération logique est déclarée comme consistant en un unique message de requête "setQuantitylnStocklnput". Bien évidemment, des formes plus élaborées d'opérations, consistant en un ensemble complexe d'échange de messages, pourraient être décrites dans ce langage. Une deuxième partie, appelée partie concrète, décrit comment un message abstrait est effectivement transmis sur le réseau. Pour cela, cette deuxième partie précise quel protocole est effectivement utilisé, et quel codage est mis en oeuvre pour représenter les données sous une forme adaptée au réseau de communication. Dans l'exemple suivant, la deuxième partie du document WSDL indique que: 1. Les messages élémentaires définis plus haut seront au format SOAP. Ceci est indiqué par la présence en plusieurs endroits du préfixe ou de 10 l'espace de nommage ("namespace") "soap:". 2. Le protocole pour véhiculer les messages sera le protocole HTTP, pour toutes les opérations de cette partie concrète. Ceci est indiqué par l'attribut "transport" de la balise (en anglais "tag") "soap:binding". 3. Pour le message de requête, l'enveloppe SOAP contiendra, dans un bloc de corps, le numéro d'inventaire du produit désiré ("PartNumber"). 4. Pour le message de réponse, l'enveloppe SOAP contiendra, dans un bloc de corps, le numéro d'inventaire du produit ainsi que la quantité de produit disponible. 5. L'option protocolaire SOAP "SOAPAction" a pour valeur 20 http://example.com/go . On donne ci-après un exemple d'extraction d'une description abstraite, délimitée par la balise "portType" et d'une partie concrète, délimitée par la balise "binding" d'une opération: En revenant à la figure 2, une étape de test E132 est mise en oeuvre à partir de cette description pour déterminer l'existence ou non d'une extension obligatoire décrite dans ce document de description d'un service WSDL. Ainsi, dans l'exemple précédent, une extension constituée d'une fonctionnalité "wsdl:feature uri" est associée à un attribut "wsdl:required" mis à la valeur vraie ("true"). Une étape d'extraction E133 permet ainsi d'extraire cette extension obligatoire associée à l'opération "myOperation". On extrait également l'ensemble des valeurs attribuables à cette fonctionnalité. L'ensemble des valeurs attribuables à cette fonctionnalité est défini par la spécification décrivant cette fonctionnalité. Généralement une fonctionnalité a un ensemble de propriétés. Chaque propriété peut avoir une valeur. Cette valeur est prise dans un ensemble de valeurs défini généralement par XML-Schema. Une étape de sélection E134 permet d'acquérir une valeur déterminable parmi l'ensemble des valeurs attribuables à cette fonctionnalité. Cette sélection peut être réalisée par le créateur du document workflow ou bien déterminée par défaut par le système créant le document workflow. On stocke alors la fonctionnalité obligatoire extraite et la valeur déterminable attribuée à cette fonctionnalité. Cette valeur déterminable peut être une valeur spécifique choisie dans l'ensemble des valeurs attribuables. Elle peut également être représentée par un procédé d'obtention qui, lorsqu'il est mis en oeuvre, a pour résultat une valeur spécifique appartenant également à l'ensemble des valeurs attribuables. On réitère l'étape de test E132 afin d'identifier éventuellement une autre extension obligatoire associée à l'opération. Dans l'affirmative, on réitère 15 l'ensemble des étapes E133 et E134. Sinon, on vérifie dans une étape de test E135 s'il existe également une extension optionnelle. Dans l'affirmative, une étape de sélection E136 permet de sélectionner le type d'informations à préciser. Une étape d'ajout E137 est adaptée à mémoriser et stocker les valeurs de ces informations optionnelles dans une liste. Le type d'informations optionnelles pouvant être ainsi ajoutées peut comprendre par exemple une liste de fonctionnalités, une liste d'intermédiaires ou encore une liste de transformations standard. Lorsqu'à l'issue de l'étape de test E135, il n'existe plus d'extensions optionnelles à préciser, une étape de stockage E138 est mise en oeuvre pour stocker la ou les extensions obligatoires associées à leurs valeurs déterminables attribuées à l'étape de sélection E134, ainsi que la ou les extensions optionnelles et la valeur de ces extensions. Cette étape de stockage E138 peut être mise en oeuvre selon différents modes de réalisation. Dans un premier mode de réalisation, la valeur déterminable attribuée à chaque extension obligatoire est stockée dans un document modifié de description d'un service, associé à l'opération à invoquer. On modifie ainsi directement le document de description d'un service associé à l'opération. Dans l'exemple précédent, un tel document modifié peut se présenter de la manière suivante: http://example.com/my-XSLT-Script Il Dans cet exemple, une valeur spécifique déterminée parmi un ensemble de valeurs attribuables a été associée à la fonctionnalité URI, en définissant la valeur de la propriété "ScriptRef'. En outre, un intermédiaire défini par son adresse "Il" sur le réseau de communication a été précisé dans le document modifié de description d'un service, comme une information optionnelle pour le transfert des messages lors de la mise en oeuvre de l'opération "myOpération". Ce document peut en outre être stocké sous forme compilée. Le fichier de document de description d'un service WSDL est compilé par un processeur WSDL pour être transformé en un programme en langage de type JAVA, C++. Chaque fonction proposée par le service Web devient une méthode de la classe. On notera toutefois qu'il n'est pas nécessaire d'avoir une notion de classe et que un langage de type C ou assembleur peut également être utilisé pour la compilation de ce document. La version compilée est un programme qui intègre directement les informations ajoutées lors de la mise en oeuvre du procédé tel que décrit en référence à la figure 2. Ce programme permet d'appeler directement toutes les fonctions du service Web. Selon un autre mode de mise en oeuvre de l'étape de stockage E138, les informations relatives à chaque extension obligatoire et à la valeur déterminable attribuée à cette extension peuvent être stockées directement dans le document workflow. Comme cela sera décrit précisément en référence à la figure 3, ces informations peuvent être utilisées soit pour modifier le document de description d'un service WSDL juste avant l'exécution de l'opération, soit pour configurer un processeur de traitement du document de description d'un service WSDL. Ce procédé d'ajout des informations peut comporter en outre une étape d'extraction E139a d'au moins un schéma XML définissant des données en langage XML échangées lors de l'envoi de message. En pratique, on extrait les types des messages abstraits associés à l'opération extraite à l'étape E131. Une étape de restriction E139b est adaptée à restreindre l'ensemble des valeurs attribuables à ces données. Ce choix de valeurs restreintes peut être mis en oeuvre directement par l'utilisateur et correspond aux valeursdes messages qui seront échangés lors de l'exécution de l'opération. Enfin, une étape de stockage E139c est adaptée à stocker un schéma XML modifié par restriction de l'ensemble des valeurs attribuables aux 30 données en langage XML. Ainsi, on peut connaître par avance la valeur de telle ou telle autre partie d'un message et stocker cette valeur directement dans le document définissant le type de message. On va décrire à présent en référence à la figure 3 un procédé d'exécution d'un document workflow tel que décrit précédemment. L'exécution du workflow est déclenchée à moment donné, par exemple au moyen d'une minuterie ou d'un évènement généré par le système, par exemple au niveau du réseau de communication. Une étape d'exécution E20 des différentes tâches telles que spécifiées dans le document workflow est mise en oeuvre, jusqu'à ce qu'on identifie une opération décrite par un document de description d'un service. Dans ce cas, une étape de test optionnel E21 est mise en oeuvre afin de vérifier la compatibilité du document de description d'un service associé à l'opération identifiée précédemment et le contenu du document workflow. En cas d'incompatibilité, une étape de génération E25 d'une erreur est mise en oeuvre afin de signaler à l'utilisateur l'impossibilité d'exécuter le workflow, dès lors que le document de description d'un service associé à l'opération invoquée n'est pas compatible avec ce document workflow. Ce test de compatibilité sera décrit ultérieurement en référence à la figure 4. Ensuite, on exécute l'opération à partir du document de description d'un service associé à cette opération et d'au moins une valeur déterminable attribuée à une extension obligatoire associée à cette opération et stockée lors de création du document workflow. Cette exécution de l'opération peut être réalisée selon trois alternatives décrites ci-après. Dans un premier mode de réalisation, l'exécution de l'opération est mise en oeuvre à partir d'un document modifié de description d'un service stocké au moment de la création du workflow. Le document workflow est alors adapté à pointer directement sur le document modifié de description d'un service. Le schéma de ce premier mode de réalisation peut se présenter de la façon suivante: implementation="http://example.com/myW S2"> implementation="httpi/example.com/myVVS2"> type="myType"/> Property Value Processeur WSDL Ce premier mode de réalisation peut être optimisé en stockant directement la version du document de description d'un service WSDL telle que compilée par un processeur WSDL. L'invocation du service Web consiste alors à récupérer la version compilée du document WSDL (qui peut être par exemple sous la forme, d'une classe) et à exécuter une opération (une méthode de la classe). Après une étape d'obtention E22a du document modifié de description d'un service, une étape de vérification de compatibilité E23a est mise en oeuvre afin de vérifier la compatibilité entre le document de description d'un service modifié obtenu à l'étape E22a et le document original de description d'un service tel qu'il est accessible sur le réseau de communication au moment de l'exécution du document workflow. En effet, il est nécessaire de vérifier que le document original de description d'un service n'a pas été modifié, notamment par le serveur adapté à mettre en oeuvre le service, et de s'assurer que le document modifié de description d'un service est toujours compatible avec le document original de description d'un service. Un tel test de compatibilité est illustré à la figure 4. Ce test de compatibilité est adapté à délivrer différents messages d'erreur ayant différents niveaux d'importance. Des mécanismes de gestion d'erreurs peuvent ensuite être mis en oeuvre afin de corriger ces erreurs. Dans une étape d'obtention E230, la description originale et la description modifiée du document de description d'un service sont obtenues. Une étape de test E231 permet de vérifier si les descriptions abstraites sont compatibles, et en particulier si la définition des messages abstraits et des MEP (acronyme du terme anglais "Message Exchange Pattern") décrivant l'échange des messages sur le réseau, n'ont pas été modifiés. Si les descriptions abstraites ne sont pas compatibles, un message d'erreur est généré dans une étape E232, pour signaler la modification de la description abstraite. Cette erreur est critique dès lors que la définition abstraite de l'opération ayant changée, sa sémantique est certainement modifiée. La mise en oeuvre de l'opération selon le résultat qui était escompté au moment de la création du document workflow n'est pas certaine. En revanche, si le test E231 est positif, on vérifie dans une seconde étape de test E233 si le type de protocole n'a pas changé. S'il a été modifié, par exemple le protocole HTTP a été remplacé par le protocole SOAP, un message d'erreur est généré dans une étape E234 afin de signaler la modification de protocole. Un programme de gestion d'erreurs peut alors être adapté à envisager les protocoles disponibles et à exécuter l'opération avec le nouveau protocole spécifié. Si le test E233 est positif, une étape de test E235 est adaptée à identifier des extensions obligatoires et à vérifier qu'elles sont à la fois présentes dans le document original de description d'un service et dans le document modifié de description d'un service. En pratique, pour chaque extension, une étape d'extraction E236 permet d'extraire l'extension obligatoire et les informations associées. On vérifie si ces informations sont valides et suffisantes dans une étape E237. En pratique, on vérifie que les valeurs déterminables associées à chaque extension obligatoire appartiennent bien à un ensemble de valeurs attribuables à cette extension. Si à l'issue de l'étape E237, une extension obligatoire n'est pas spécifiée dans le document modifié de description d'un service, ou encore si la valeur déterminable n'appartient pas l'ensemble de valeurs attribuables à cette extension, un message d'erreur est généré dans une étape E238 afin d'indiquer qu'une extension obligatoire n'est pas totalement spécifiée dans le document modifié de description d'un service. Dans un tel cas, l'opération peut être exécutée sans la fonctionnalité, mais il n'est pas assuré que l'exécution de l'opération se déroule correctement. Lorsque toutes les extensions obligatoires ont été identifiées et validées, une autre étape de test E239 permet d'identifier les extensions optionnelles ajoutées au document modifié de description d'un service. Une étape de test E240 permet de vérifier si cette extension optionnelle ajoutée est bien décrite dans le document de description d'un service original. Dans la négative, un message d'alerte est émis dans une étape de génération d'un message E241 afin de signaler à l'utilisateur l'existence d'une extension utilisée dans le document modifié de description d'un service mais non déclarée dans le document original de description d'un service. Ce message peut alerter l'utilisateur sur la possibilité d'une erreur qui surviendrait au moment de l'exécution de l'opération. Si l'extension optionnelle ajoutée est bien décrite dans le document de description d'un service, on vérifie dans une étape de test E242 si les informations associées à cette extension sont valides, c'est-à-dire en d'autres termes, on vérifie que les valeurs attribuées dans le document modifié de description d'un service sont en cohérence avec les valeurs attribuables telles que définies dans le document original de description d'un service. Dans la négative, un message d'alerte est également adressé lors d'une étape de génération E243 à l'attention de l'utilisateur pour signaler que certaines extensions peuvent ne pas être utilisées correctement. Le procédé de test de compatibilité entre les documents prend ainsi fin. En revenant à la figure 3, une étape d'exécution E24a peut ensuite être mise en oeuvre de manière classique à partir du document workflow pour exécuter l'opération telle que définie dans le document modifié de description d'un service, au moyen d'un processeur classique de traitement d'un document de description d'un service. On va décrire à présent deux autres modes de réalisation pour l'exécution d'une opération associée à un document de description d'un service, évitant d'utiliser un document modifié de description d'un service au moment de la création d'un document workflow, nécessitant comme précédemment la mise en oeuvre d'un test de compatibilité au moment de l'exécution de l'opération. Selon un deuxième mode de réalisation de l'invention, à l'issue d'une étape d'obtention E22b d'un document original de description d'un service tel qu'associé à l'opération à exécuter, une étape de modification E23b est mise en oeuvre pour modifier le document original de description d'un service à partir des informations stockées dans le document workflow au moment de sa création. Le principe de ce deuxième mode de réalisation est illustré ci-dessous: Property Value Property Value Processeur WSDL Ainsi, les extensions obligatoires associées à l'opération intitulée dans cet exemple "myOp" sont stockées directement dans le document workflow de telle sorte que la modification du document original de description d'un service est mise en oeuvre juste avant l'exécution de l'opération. Après l'étape de modification E23b du document original de description d'un service, une étape d'exécution E24b peut être mise en oeuvre afin d'exécuter l'opération au niveau d'un processeur classique de traitement d'un document de description d'un service, à partir du document modifié de description d'un service. Ce deuxième mode de réalisation permet de conserver inchangé le document de description d'un service WSDL associé à l'opération. Ainsi, si ce document est modifié, notamment par le serveur mettant en oeuvre l'opération, cette modification est prise en compte automatiquement au moment de l'exécution du document workflow, lors de l'étape d'obtention E22b du document original de description d'un service. 10 Property Value Enfin, on va décrire un troisième mode de réalisation de l'invention dans lequel il n'est plus nécessaire de modifier le document de description d'un service WSDL associé à une opération. Les éléments d'informations stockés dans le document workflow sont 5 adaptés à piloter directement le processeur de traitement d'un document de description d'un service, au moment de l'exécution de l'opération. Le principe de ce troisième mode de réalisation est illustré ci-dessous: Processeur WSDL EXAMPLE PROPERTY VALUE EXAMPLE PROPERTY VALUE Ainsi, après l'étape d'obtention E22c du document original de description d'un service associé à l'opération à exécuter, une étape de configuration E23c est mise en oeuvre afin de configurer le processeur de traitement d'un document de description d'un service WSDL à partir des informations mémorisées directement dans le document workflow. Après cette étape de configuration E23c, une étape d'exécution E24c est mise en oeuvre afin d'exécuter l'opération telle que décrite dans le document original de description d'un service au moyen du processeur de traitement configuré précédemment. Ce troisième mode de réalisation permet de faciliter la description lors de la création du document workflow. Elle peut s'appliquer à des extensions très courantes telles que les fonctionnalités ("feature"). Par ailleurs, ce troisième mode de réalisation s'adapte parfaitement à des informations non descriptibles dans un document de description d'un service, correspondant à des appels d'applications d'un processeur de traitement d'un document de description d'un service WSDL. Ainsi, grâce à l'invention, lors de la création d'un document workflow, il est possible de spécifier l'utilisation précise d'extensions décrites dans un document de description d'un service WSDL. Ainsi, lorsque des mécanismes d'extension sont utilisés dans le document de description, des valeurs précises associées à ces extensions peuvent être stockées soit directement dans un document modifié de description d'un service, soit au niveau du document workflow afin de modifier le document de description d'un service avant l'exécution de l'opération, ou afin de configurer un processeur de traitement avant l'exécution de l'opération. Afin de mettre en oeuvre le procédé de création d'un document workflow décrit en référence aux figures 1 et 2, un dispositif de création comprend essentiellement des moyens de sélection d'un document WSDL, des moyens d'extraction d'au moins une extension obligatoire et de ses valeurs attribuables, des moyens d'acquisition d'une valeur déterminable et des moyens de stockage de l'extension obligatoire et de sa valeur déterminable. De même, un dispositif d'exécution adapté à mettre en oeuvre le procédé d'exécution décrit en référence aux figures 3 et 4 comprend des moyens d'identification d'une opération décrite par un document WSDL et des moyens d'exécution de l'opération à partir du document WSDL associé et d'une valeur déterminable attribuée à une extension obligatoire de l'opération et stockée lors de la création du document workflow. Ces dispositifs de création et d'exécution peuvent être incorporés dans un ordinateur tel qu'illustré à la figure 5. En particulier, les différents moyens identifiés ci-dessus peuvent être incorporés dans un microprocesseur 100, une mémoire morte 101 ("Read-only memory" ou ROM) étant adaptée à mémoriser un programme de création et/ou d'exécution d'un document workflow conforme à l'invention. Bien entendu, ces dispositifs de création d'un document workflow ou d'exécution peuvent être mis en oeuvre dans un même ordinateur ou bien dans des stations différentes du réseau de communication. La mémoire vive 102 ("Random access memory" ou RAM) est adaptée à mémoriser dans des registres les valeurs modifiées lors de l'exécution du programme de création et d'exécution. Le microprocesseur 100 est intégré à un ordinateur qui peut être connecté à différents périphériques et à d'autres ordinateurs du réseau de communication. Cet ordinateur comporte de manière connue une interface de 15 communication 110 reliée au réseau de communication 10 pour recevoir ou transmettre des messages L'ordinateur comporte en outre des moyens de stockage de documents, tel qu'un disque dur 106, ou est adapté à coopérer au moyen d'un lecteur de disque 107 (disquettes, disques compacts ou cartes informatiques) avec des moyens de stockage de documents amovibles, tels que des disques 700. Ces moyens de stockage fixes ou amovibles peuvent comporter le code du procédé de création ou d'exécution conforme à l'invention. Ils sont également adaptés à mémoriser un document original ou modifié de description d'un service tel que défini par la présente invention, ainsi 25 qu'un document d'ordonnancement d'invocations de tâches. A titre de variante, le programme permettant au dispositif de création ou d'exécution 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é 30 comme décrit précédemment par l'intermédiaire du réseau de communication 10. L'ordinateur 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 à 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 création d'un document d'ordonnancement d'invocations de tâches, les tâches étant en partie des opérations décrites par un document de description d'un service fourni par un serveur d'un réseau de communication, caractérisé en ce qu'il comprend les étapes suivantes: sélection (El 1) du document de description d'un service associé à une opération à invoquer; - extraction (E133) d'au moins une extension obligatoire associée à ladite opération et d'un ensemble de valeurs attribuables à ladite extension; - acquisition (E134) d'une valeur déterminable parmi l'ensemble de valeurs attribuables; et - stockage (E138) de ladite extension obligatoire et de ladite valeur déterminable attribuée à l'extension. 2. Procédé de création conforme à la revendication 1, caractérisé en ce qu'à l'étape de stockage, ladite valeur déterminable attribuée à l'extension obligatoire est stockée dans un document modifié de description d'un service, associé à ladite opération à invoquer. 3. Procédé de création conforme à la revendication 2, caractérisé en ce qu'à l'étape de stockage, le document modifié de description d'un service est stocké dans une version compilée. 4. Procédé de création conforme à la revendication 1, caractérisé en ce qu'à l'étape de stockage, ladite extension obligatoire et ladite valeur déterminable attribuée à l'extension obligatoire sont stockées dans le document d'ordonnancement d'invocations de tâches. 5. Procédé de création conforme à l'une des revendications 1 à 4, caractérisé en que ladite valeur déterminable est une valeur spécifique choisie parmi l'ensemble des valeurs attribuables à ladite extension obligatoire. 6. Procédé de création conforme à l'une des revendications 1 à 4, caractérisé en ce que ladite valeur déterminable est représentée par un procédé d'obtention d'une valeur spécifique parmi l'ensemble des valeurs attribuables à ladite extension obligatoire. 7. Procédé de création conforme à l'une des revendications 1 à 6, caractérisé en que l'extension obligatoire est une fonctionnalité définie dans une partie concrète d'un document de description d'un service. 8. Procédé de création conforme à l'une des revendications 1 à 6, caractérisé en ce que l'extension obligatoire est un noeud intermédiaire du réseau de communication défini dans une partie concrète d'un document de description d'un service. 9. Procédé de création conforme à l'une des revendications 1 à 8, caractérisé en ce qu'il comprend en outre les étapes suivantes: extraction (E139a) d'au moins un schéma XML définissant des données en langage XML; - restriction (E139b) de l'ensemble des valeurs attribuables auxdites données; et - stockage (E139c) dudit schéma XML modifié par restriction de l'ensemble desdites valeurs attribuables auxdites données en langage XML. 10. Procédé d'exécution d'un document d'ordonnancement d'invocations de tâches, les tâches étant en partie des opérations décrites par un document de description d'un service fourni par un serveur d'un réseau de communication, caractérisé en ce qu'il comprend les étapes suivantes: identification (E20) d'une opération décrite par un document de description d'un service; et - exécution (E24a, E24b, E24c) de l'opération à partir d'un document de description de service associé à ladite opération et d'une valeur déterminable attribuée à une extension obligatoire associée à ladite opération et stockée lors de la création du document d'ordonnancement d'invocations de tâches. 11. Procédé d'exécution conforme à la revendication 10, caractérisé en ce que préalablement à ladite étape d'exécution (E24a, E24b), il comprend une étape d'obtention (E22a, E23b) d'un document modifié de description d'un service, adapté à stocker ladite valeur déterminable associée à l'extension obligatoire associée à ladite opération à exécuter. 12. Procédé d'exécution conforme à la revendication 11, caractérisé en ce qu'à ladite étape d'obtention (E22a), un document modifié de description d'un service stocké lors de la création d'un document d'ordonnancement d'invocations de tâches est obtenu. 13. Procédé d'exécution conforme à la revendication 12, caractérisé en ce qu'il comprend une étape de test de compatibilité (E23a) entre ledit document modifié de description d'un service stocké et le document original de description d'un service. 14. Procédé d'exécution conforme à la revendication 11, caractérisé en ce que, préalablement à ladite étape d'exécution (E24b), il comprend les étapes suivantes: - obtention (E22b) d'un document original de description d'un service associé à ladite opération; et - modification (E23b) du document original de description d'un service à partir de ladite valeur déterminable associée à ladite extension obligatoire stockée dans le document d'ordonnancement d'invocations de tâches. 15. Procédé d'exécution conforme à la revendication 10, caractérisé en ce qu'il comprend, préalablement à ladite étape d'exécution (E24c), les étapes suivantes: - obtention (E22c) du document original de description d'un service associé à ladite opération; et - configuration (E23c) d'un processeur de traitement du document de description d'un service à partir d'une valeur déterminable associée à une extension obligatoire stockée dans le document d'ordonnancement d'invocations de tâches. 16. Dispositif de création d'un document d'ordonnancement d'invocations de tâches, les tâches étant en partie des opérations décrites par un document de description d'un service fourni par un serveur d'un réseau de communication, caractérisé en ce qu'il comprend: - des moyens de sélection (100, 101, 102) d'un document de description d'un service associé à une opération à invoquer; - des moyens d'extraction (100, 101, 102) d'au moins une extension obligatoire associée à ladite opération et d'un ensemble de valeurs attribuables à ladite extension; - des moyens d'acquisition (100, 101, 102) d'une valeur déterminable parmi l'ensemble des valeurs attribuables; et - des moyens de stockage (100, 101, 102) de ladite extension obligatoire et de ladite valeur déterminable attribuée à l'extension. 17. Dispositif d'exécution d'un document d'ordonnancement d'invocations de tâches, les tâches étant en partie des opérations décrites par un document de description d'un service fourni par un serveur d'un réseau de communication, caractérisé en ce qu'il comprend: - des moyens d'identification (100, 101, 102) d'une opération décrite par un document de description d'un service; et - des moyens d'exécution (100, 101, 102) de l'opération à partir d'un document de description d'un service associé à ladite opération et d'une valeur déterminable attribuée à une extension obligatoire associée à ladite opération et stockée lors de la création du document d'ordonnancement d'invocations de tâches. 18. Dispositif d'exécution conforme à la revendication 17, caractérisé en ce qu'il comprend des moyens d'obtention (100, 101, 102) d'un document modifié de description d'un service adapté à stocker ladite valeur déterminable associée à l'extension obligatoire de l'opération à exécuter. 19. Dispositif d'exécution conforme à la revendication 18, caractérisé en ce qu'il comprend des moyens de test de compatibilité (100, 101, 102) d'un document modifié de description d'un service et d'un document original de description d'un service. 20. Dispositif d'exécution conforme à la revendication 17, caractérisé en ce qu'il comprend des moyens de configuration (100, 101, 102) d'un processeur de traitement d'un document de description d'un service à partir d'une valeur déterminable associée à une extension obligatoire stockée dans le document d'ordonnancement d'invocations de tâches. 21. Ordinateur, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé de création conforme à l'une des revendications 1 à 9. 22. Ordinateur, caractérisé en ce qu'il comprend des moyens 5 adaptés à mettre en oeuvre le procédé d'exécution conforme à l'une des revendications 10 à 15. 23. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé de création conforme à l'une des revendications 1 à 9. 24.. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'exécution conforme à l'une des revendications 10 à 15. 25. Programme d'ordinateur lisible par un microprocesseur, caractérisé en ce qu'il comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé de création conforme à l'une des revendications 1 à 9, lorsqu'il est chargé et exécuté par le microprocesseur. 26. Programme d'ordinateur lisible par un microprocesseur, caractérisé en ce qu'il comprend des portions de code logiciel adaptées à mettre en oeuvre le procédé d'exécution conforme à l'une des revendications 10 à 15, lorsqu'il est chargé et exécuté par le microprocesseur.