Types de composition de services Web

La plupart des travaux portant sur la composition de services Web reconnaissent deux types de composition : l’orchestration et la chorégraphie de services. Cependant, selon les travaux, les définitions des types de composition diffèrent.

Pour Peltz [59] et Benatallah et al [58], l’orchestration et la chorégraphie sont des moyens de concevoir la composition, tandis que dans Barros et al [57], l’orchestration et la chorégraphie sont des points de vue de la composition de services.

Afin de choisir l’un ou l’autre de ces types de composition (orchestration ou chorégraphie), le concepteur de systèmes doit prendre en compte différents paramètres.

5.1 Orchestration

Pour type de composition, il existe plusieurs définitions parmi les quelles nous citons :

Barros et al définissent : « l’orchestration comme un ensemble de processus exécutés dans un ordre prédéfini afin de répondre à un but ». Ce type de composition permet de centraliser l’invocation des services Web composants. Chaque service est décrit en termes d’actions internes. Les contrats entre deux services sont constitués selon le processus à exécuter.

À l’instar de Barros et al [57], Benatallah et al [58] définissent l’orchestration comme un processus exécutable. Benatallah et al ajoutent que l’orchestration est un ensemble d’actions à réaliser par l’intermédiaire de services Web.

Un moteur d’exécution, un service Web jouant le rôle de chef d’orchestre, gère l’enchaînement des services Web par une logique de contrôle. Pour concevoir une orchestration de services Web, il faut décrire les interactions entre le moteur d’exécution et les services Web. Ces interactions correspondent aux appels, effectués par le moteur, d’action(s) proposée(s) par les services Web composants.

D’après Peltz [59], l’orchestration de services Web consiste en « la programmation d’un moteur qui appelle un ensemble de services Web selon un processus prédéfini ».

Ce moteur définit le processus dans son ensemble et appelle les services Web (tant internes qu’externes à l’organisation) selon l’ordre des tâches d’exécution. La [Figure II.8] illustre l’exécution du moteur permise par l’enchaînement de l’exécution de deux autres services Web. Cet enchaînement est possible via un opérateur d’ordonnancement (représenté par le losange dans la figure). L’exécution de la composition repose sur l’appel du Service Web 1, puis sur l’appel du Service Web 2, réalisés tous deux par le Service Web Moteur.

Figure II.7 Vue générale de l’orchestration [48]

En d’autres termes, l’orchestration de services Web exige de définir l’enchaînement des services web selon un canevas prédéfini, et de les exécuter selon un script d’orchestration. Ces derniers (le canevas et le script) décrivent les interactions entre services Web en identifiant les messages, et en spécifiant la logique et les séquences d’invocation. Le module exécutant le script d’orchestration de services Web est appelé un moteur d’orchestration. Ce moteur d’orchestration est une entité logicielle qui joue le rôle d’intermédiaire entre les services en les appelants suivant le script d’orchestration [48].

5.2 Chorégraphie

Ce type de composition de son tour a plusieurs définitions parmi les quelles nous citons : D’après Barros et al [57] la chorégraphie permet de décrire la composition comme un moyen d’atteindre un but commun en utilisant un ensemble de services Web. La collaboration entre chaque service Web de la collection (faisant partie de la composition) est décrite par des flots de contrôle. Le fait que la chorégraphie mette en œuvre un ensemble de services Web afin d’accomplir un but commun apparaît aussi dans les travaux de Benatallah et al [58]. Pour concevoir une chorégraphie, les

interactions entre les différents services doivent être décrites. La logique de contrôle est supervisée par chacun des services intervenant dans la composition. L’exécution du processus est alors distribuée.

D’après Peltz [59], la description de chaque service Web intervenant dans la chorégraphie inclut la description de sa participation dans le processus. De ce fait, ces services peuvent collaborer à l’aide de messages échangés afin de savoir si tel ou tel service peut aider dans l’exécution de la requête. Chaque service Web peut communiquer avec un autre service Web par l’intermédiaire d’échange de messages [48].

Figure II.8 vue générale de l’exécution d’une composition de service web de type chorégraphie [48]

6. Langage de composition de service web : BPEL4WS

BPEL4WS est le premier langage de composition de services Web adopté par la communauté des services Web. Ceci est principalement dû au fait que ce langage possède une grande expressivité dans la définition du processus exécutable [60]. Le but de ce langage est de remplacer les langages WSFL et XLANG de Microsoft pour l’orchestration des services Web et la gestion des processus d’affaires (Bussiness Process : processus

La première version du langage d’exécution des processus d’affaires (BPEL : Business Process Execution Language) a été crée par IBM, Microsoft et BEA en juillet 2002. La standardisation de langage BPEL4WS est effectuée en Mai 2003, par l’organisation de standardisation OASIS, et cette fois-ci avec l’association du Seibel et SAP [15],[16].

Le Langage BPEL est de format XML comme tous les autres langages et les spécifications reliées par les services Web. Et aussi, BPEL influx sur d'autres standards des services Web telles que WSDL et SOAP pour la description d'interface et le protocole de communication. BPEL décrit les interfaces des processus par des documents WSDL, ce qui permet à des clients d'un processus de contrôler et appeler un processus de BPEL juste comme n'importe quel autre service Web.

Le processus métier supporté par BPEL4WS peut spécifier la composition d’un ensemble de services Web, définir les données partagées entre ces services, spécifier les partenaires impliqués et le rôle qu’ils jouent dans le processus, et le gestionnaire commun de compensation de l'ensemble de services Web ...etc.

L’inconvénient principal de BPEL4WS est que la

• définition du processus est rigide. Si une activité du processus échoue, le processus dans son intégralité échoue. Aucun retour en arrière et aucune alternative au processus ne sont possibles.

• lors de la description du processus exécutable, la définition des flots de données ne permet pas de connecter des services dont les entrées/sorties ne correspondent pas exactement.

• BPEL4WS ne prévoit pas de mécanisme de transformation de données.

Les motivations derrière l’orchestration des services Web avec BPEL sont : l’augmentation de la productivité.

La réduction des dépenses.

L’amélioration des niveaux de service par l'automatisation de processus en utilisant des technologies standardisées [12], [48].