IRS-III

IRS-III (Internet Reasoning Service, version III) [Cabral et al., 2006] est un cadre de travail pour

l’implémentation d’applications à base de services Web sémantiques. Afin d’implémenter ce type

d’application, IRS-III propose quatre étapes : l’annotation sémantique des services Web, la recherche

et la sélection des services, et leur composition. Les deux premières étapes ont été étudiées dans la

section 3.3.4 du chapitre 3. Dans cette section, nous nous consacrons à l’étude de la mise en œuvre de

la composition.

L’architecture de IRS-III est composée de cinq composants mettant en œuvre la composition de

services Web sémantiques (cf. Figure 4.20) : la bibliothèque de services Web sémantiques (SWS

Library), l’interpréteur de chorégraphie (Choreography Interpreter), l’interpréteur d’orchestration

(Orchestration Interpreter), le gestionnaire de médiation (Mediation Handler) et le module

d’invocation (Invoker).

Mediation

Handler ^{Orchestration}Interpreter

Choreography Interpreter Invoker SWS Library OCML

IRS-III Server

Figure 4.20 Architecture de IRS-III [Cabral et al., 2006].

La bibliothèque de services Web sémantiques (SWS Library). Dans cette bibliothèque sont

stockées les descriptions sémantiques formalisées en OCML (Operational Conceptual

Modelling Language, langage de représentation sémantique issu des travaux de l’institut KMI –

Knowledge Media Institute

⁶⁰

) [Motta, 1999]. La bibliothèque est structurée en modèles de

connaissances des objectifs, des services Web et des médiateurs. Ces modèles de connaissances

sont utilisés afin de mettre en œuvre la résolution de problèmes, pour répondre à la requête de

l’utilisateur (cf. section 3.3.4 chapitre 3).

L’interpréteur de chorégraphie (Choreography Interpreter). Dans IRS-III, la chorégraphie

décrit les interactions entre la plate-forme et un service Web élémentaire et entre les services

Web élémentaires [Domingue et al., 2006]. La chorégraphie est représentée, d’une part, par un

ensemble de règles de chaînage avant (forward-chaining rule), et, d’autre part, par une

déclaration d’accès au service exprimée en OCML. Une règle exécute des interactions entre la

plate-forme et le service Web si les conditions associées sont satisfaites. Ces interactions sont

basées sur les primitives de communication suivantes : début de chorégraphie (

init-choreography), envoi de message (send-message), réception de message (receive-message),

réception d’erreur (received-error), et fin de chorégraphie (end-choreography).

L’interpréteur d’orchestration (Orchestration Interpreter). Dans IRS-III, l’orchestration est

représentée par un modèle de workflows exprimé en OCML. La particularité d’utiliser OCML

pour représenter un workflow est que l’unité de base d’une composition est un objectif. Le

modèle fournit des constructions de flots de contrôle et de flots de données au-dessus de

l’ensemble des objectifs. Les primitives de flots de contrôle disponibles dans IRS-III sont les

suivantes : la liste des objectifs à invoquer de manière séquentielle (orch-sequence), une

condition (orch-if), la répétition (orch-repeat), le résultat de la dernière invocation de l’objectif

déclaré (orch-get-goal-value) et le résultat de l’exécution de l’objectif courant (orch-return).

Le gestionnaire de médiation (Mediation Handler). Ce composant associe à chaque objectif

(représenté par une ontologie) un service Web. Cette association est permise par des règles de

correspondance (mapping rule). La médiation intervient aussi bien lors de l’exécution de la

chorégraphie que lors de l’exécution de l’orchestration dans le but de sélectionner, d’invoquer et

d’exécuter les services Web adéquats.

Le module d’invocation (Invoker). Ce composant est l’interface de communication entre

l’IRS-III et l’application réalisée à la suite de la requête du client. Il reçoit les entrées envoyées par le

client et retourne les résultats de l’invocation au client.

Composition de services Web

Mediation Handler MyMeteo Mapping rules Orchestration Interpreter MyMeteo-OCML Workflow OCML SWS Library Web services Goals GeoIP-OCML GlobalWeather-OCML MyMeteo-Goal GeoIP-Goal GlobalWeather-Goal Invoker MyMeteo query IRS-III server MyMeteo result GeoIP GlobalWeather

Figure 4.21 Illustration du fonctionnement d’IRS-III à l’aide de l’exemple de la composition

MyMeteo.

Dans l’exemple de fonctionnement d’IRS-III (cf. Figure 4.21), nous faisons l’hypothèse que la

composition MyMeteo est seulement décrite à l’aide de BPEL4WS et est ainsi de type orchestration.

Par conséquent, l’interpréteur de chorégraphie (Choreography Interpreter) n’intervient pas dans notre

exemple. Le module d’invocation (Invoker) reçoit la requête de la composition MyMeteo (MyMeteo

query). La requête est transmise à l’interpréteur d’orchestration (Orchestration Interpreter) via la

bibliothèque de services (SWS Library). La définition des flots de contrôle de MyMeteo est stockée

dans ce module (MyMeteo-OCML Workflow). Via les règles de correspondance spécifiques à

MyMeteo (MyMeteo Mapping Rules) et les bibliothèques de services et d’objectifs, l’interpréteur

d’orchestration appelle les services adéquats. Le résultat de la composition (MyMeteo result) est

transmis au module d’invocation qui l’envoie au client.

La particularité de cette plate-forme de composition de services Web est qu’elle autorise les deux

types de composition (chorégraphie et orchestration). De plus, les auteurs utilisent des méthodes de

résolution de problèmes pour réaliser la composition basée sur un objectif. Cependant, les services

Web intervenant dans les compositions et la définition des workflows doivent être décrits en OCML.

Or, au niveau de ce langage il n’existe pas de moyens qui permettent d’envisager des constructions

évolutives de composition.

4.4 Conclusion

Dans notre travail, nous désignons la composition de services Web (quel que soit son type) comme

un ensemble d’interactions entre services Web répondant à un problème complexe, formalisé par un

client (logiciel ou humain) à l’aide d’une requête. Ces interactions (définies comme des échanges de

données gérés par un flot de contrôle), ont pour but de réaliser un processus préalablement défini par

les concepteurs. Une composition de services peut être de deux types : orchestration ou chorégraphie.

De nombreuses organisations (industrielles, telles qu’IBM et Microsoft, de recherche, telles que le

W3C) travaillent afin de standardiser leur langage de composition de services Web. Dans ce chapitre,

nous avons étudié trois langages de composition : BPEL4WS, WS-CDL et OWL-S.

BPEL4WS permet de définir une composition de services Web de type orchestration à l’aide de

processus métier.

WS-CDL est langage de composition de type chorégraphie. Les interactions entre les services

reposent sur les fondements du π-calcul [Milner, 1999].

OWL-S décrit les interactions entre les services Web sémantiques dans une composition de type

chorégraphie à l’aide d’ontologies et de logiques de description.

Cependant, à ce jour, aucun de ces langages n’est considéré par la communauté des services Web

comme un standard largement accepté pour la description de composition de services Web.

Un langage de composition de services Web permet uniquement aux concepteurs de systèmes à

base de services de définir le processus de composition (l’enchaînement de l’appel de service dans le

cas d’une orchestration et les échanges de messages entre deux services lors d’une chorégraphie). Afin

de permettre la sélection des services, l’invocation des services, le contrôle de l’exécution, la

compensation de services, les concepteurs de systèmes doivent utiliser des plates-formes de

composition de services Web. Dans ce chapitre, quatre ont été étudiées (SELF-SERV, METEOR-S,

SHOP2 et IRS-III).

SELF-SERV est une plate-forme de composition de services Web de type orchestration. La

définition de la composition de services Web est décrite par l’intermédiaire de diagrammes

d’états-transitions où chaque état peut être exécuté par une communauté de services Web. Cette

idée permet de mettre en œuvre la compensation de services Web.

METEOR-S est une plate-forme de composition de type orchestration. La définition de la

composition repose sur le langage BPEL4WS. Sa particularité est que les services Web

invoqués, sont décrits à l’aide de OWL-S et sélectionnés dans un registre UDDI amélioré afin de

gérer des services Web sémantiques.

SHOP2 est une plate-forme de composition de services Web sémantiques de type orchestration.

La description de services Web sémantiques intervenant dans la composition doit être formalisée

en OWL-S afin d’être interprétée par la plate-forme. La particularité de SHOP2 est que la

définition de la composition est décrite en tant que décomposition de tâches à l’aide de l’HTN ce

qui permet une automatisation de l’exécution de la composition.

IRS-III est un cadre de travail pour l’implémentation d’application à base de services Web

sémantiques. Le processus d’implémentation est terminé par une composition de services Web.

IRS-III gère aussi bien la composition de type chorégraphie (définie à l’aide de règles de

chaînage avant et de déclaration d’accès au service) que la composition de type orchestration

(définie à l’aide de workflow). La sélection des services à appeler est réalisée à l’aide de règles

de correspondance entre les ontologies représentant la composition et celles représentant les

services Web.

Lors de l’exécution de la composition, la plate-forme de composition doit, à chaque étape,

sélectionner le service correspondant au mieux à la requête du client. Cependant, la plupart du temps,

la requête seule ne permet pas de sélectionner le service Web qui convient le mieux. La prise en

compte du contexte d’utilisation est nécessaire en vue d’améliorer les résultats de la composition de

services Web.

5 ADAPTATION AU CONTEXTE DE SERVICES

WEB

Ce chapitre est consacré à la mise en œuvre de l’adaptation au contexte dans les applications à base

de services Web. Afin de répondre à cette problématique, il est, à notre avis, important de la prendre

en compte dès le niveau conceptuel.

Dans le chapitre précédent, nous avons étudié des travaux portant sur la composition de services

Web proposant des solutions (langages ou plates-formes) qui permettent de définir la composition afin

de mettre en œuvre une application particulière. À chaque étape de la composition, le processus de

sélection doit choisir le service Web qui convient le mieux à la requête du client. Afin que

l’application soit adaptée au contexte d’utilisation (l’utilisateur, son dispositif d’accès, le lieu et le

moment de l’utilisation de l’application), il est impératif, lors du processus de sélection, de prendre en

compte ce contexte.

D’après [Benslimane et al., 2007], une nouvelle génération de services Web, qui met l’utilisation

du contexte au centre de leurs préoccupations, émerge. Ceci s’inscrit dans la nature dynamique de

l’Internet en général et des services Web en particulier. Tout d’abord, les services Web élémentaires

ont besoin d’une capacité à adapter leurs opérations afin de convenir à la situation dans laquelle ils

sont appelés (i.e. le contexte). Ensuite, les services Web composants doivent pouvoir participer ou non

à une composition de services Web selon le contexte. Or, les spécifications et langages sous-jacents

aux services Web ne prennent pas en compte le contexte. D’après [Zhu et al., 2005] et [Cuddy et al.,

2005], UDDI n’utilise pas les informations contextuelles dans le processus de recherche et ainsi ne

renvoie pas les services les plus appropriés et pertinents pour les clients. De plus, les travaux de [Chen

et al., 2004] et [Wang et al., 2004] montrent que le langage de description OWL-S n’inclut pas, dans

sa forme originelle, de description sémantique du contexte.

De nombreux travaux proposent d’intégrer l’adaptation au domaine des services Web. Ces derniers

présentent de multiples possibilités d’adaptation (telles que la personnalisation ou la recommandation

de services) et interviennent dans différentes étapes du cycle de vie d’une application à base de

services (telles que la sélection ou la planification). [Claro et al., 2005] sélectionnent les services Web

afin de les composer de manière optimale selon leur qualité de service – QoS (coût, temps

d’exécution, disponibilité, et réputation). [Baresi et al., 2003] sélectionnent les services Web (décrits

selon leur qualité de service) répondant au mieux à la requête d’un client (profil de l’utilisateur et

localisation) selon des règles de correspondance. [Sam et al., 2007] utilisent la logique d’attributs afin

de décrire les services Web personnalisés et les requêtes des clients en vue de sélectionner les services

répondant au mieux aux attentes des clients. [Taher et al., 2008] utilisent le traitement d’événements

complexes afin d’adapter les interfaces incompatibles entre les services communicants au sein d’une

composition. [Soukkarieh et al., 2008] proposent d’étendre l’architecture du système hypermédia

adaptatif AHA ! [De Bra et al., 2008] pour la recherche de services Web afin de concevoir des

systèmes d’information basés sur le Web sensibles au contexte. Dans la suite de ce chapitre nous

rapportons plus en détail les travaux qui portent sur l’adaptation au contexte d’utilisation que nous

considérons significatifs dans le cadre de la problématique retenue dans cette thèse.

Dans ce chapitre, nous définissons tout d’abord l’adaptation au contexte d’utilisation. Ensuite, nous

présentons les différents travaux qui mettent en relation l’adaptation au contexte d’utilisation avec,

d’une part, les services Web élémentaires, et, d’autre part, la composition de services Web.

Dans le document Sélection et composition de services Web pour la génération d'applications adaptées au contexte d'utilisation (Page 84-89)