WIXLIB

Les web services sémantiques : Partie 25Ainsi, l’organisation a réalisé des modules d’intégration distincts avec chaquepartenaire : i) RosettaNet utilisant l’architecture RNIF (RosettaNet ImplementationFramework) sur HTTP avec le partenaire B, ii) EDI4 X12 utilisant un servicesupport d’opérateur de télécommunication (Value-Added Network « VAN ») avecle partenaire C et l’interface SAP IDOC (SAP Intermediate Documents) mettant enoeuvre une solution à base de services web avec le partenaire D.1.1.2 MotivationLe but de la recherche en SWS appliquée à ce scénario est d’introduire del’intégration dynamique en B2B sans coutures entre partenaires commerciaux endéveloppant des interfaces entre la plate-forme d’intergiciel WSMX (cf. § 3) et lesarchitectures e-Business existantes, en mappant les messages e-Business dans unmodèle de représentation commun de manière à surmonter les hétérogénéités desdonnées et des processus et donc in fine de rendre les processus d’intégration eBusiness fiables et plus rapides.En complément des concepts et technologies génériques d’intergiciel sémantiquedéveloppé pour les SWS avec WSMO, WSML et WSMX, il est essentiel de montrerque cette technologie co-existe parfaitement avec les standards et plateformes eBusiness déployés. De par sa nature ouverte, la plateforme SOA WSMX répondprécisément à ce besoin et est en cours de standardisation à l’OASIS5. De plus, leW3C est en cours de rédaction de l’extension sémantique de l’annotation desServices Web (WSDL Working Group) et leur mappage vers la représentation RDF(ontologies).1.1.3 RésultatsLa démonstration et son évaluation sont organisées par le DERI au sein d’unecompétition internationale (Semantic Web Services Challenge)6. Dans cettecompétition, IST NoE Knowledge Web en coopération avec Bell Labs-Lucent aprésenté une première réalisation du scénario d’intégration B2B décrit et a été trèsbien évalué (2005). De plus, Bell Labs Ireland fournit des contraintes de gestion derègles commerciales qui sont intégrées au processus de découverte et de sélectiondes services web.1.2 Scénario 2 : Configuration automatisée de services de TélécommunicationLa technologie SWS de FT R&D Orange Labs est en cours d’intégration au seind’un projet d’infrastructure de services. La motivation est de donner aux clients lapossibilité de créer son bouquet de services personnalisé de télécommunication,sans l’aide d’aucune assistance. Le client doit simplement sélectionner les options4See for example /EDI/edi.pdf oasis-open.org/committees/tc home.php?wg abbrev semantic-ex SemanticExecution Environment TC6http://sws-challenge.org/

6Revue. Volume X – n x/annéede configuration qu'il souhaite souscrire. Par exemple, les offres Orange peuventêtre les suivantes : ADSL eligibility, LiveBox, Voice over IP, FunTone, AddressBook, Visiophone, IPTV (TV over IP), Voice Messaging, HDTV. Comme chaqueoffre élémentaire de services est décrite sous forme de SWS (e.g. FunToneServiceest l’interface de l’offre FunTone), le but est de construire une composition correctedes services sélectionnés. La Figure 2 présente une partie de l’Ontologie décriteavec le langage ALE, qui comprend en réalité 305 concepts définis et 117propriétés décrivant le domaine i.e., les concepts décrivent les entrées et sorties desservices web via des annotations (ex. SA-WSDL). Cette description ontologiqueformelle (ALE) nous permet ensuite d’automatiser le processus de compositionentre services web « compatibles » (Lécué et al., 2006).Figure 2. Exemple d’une partie de l’ontologie du Use Case Orange LabsDans l’exemple qui suit, seuls 4 services web parmi une trentaine sont décrits :- ADSLELIGIBILITY service qui à partir d'un n de téléphone PHONENUM, unZIPCODE et une EMAIL address, retourne la connection réseauNETWORKCONNECTION de la zone désirée;- VOICEOVERIP service qui à partir d'un n de téléphone PHONENUM et d'uneconnexion bas débit SLOWNETWORKCONNECTION, retourne l'identifiant VOIPID dela ligne ADSL que France Telecom doit installer;- TVOVERIP service qui à partir du n de téléphone PHONENUM et d'uneconnexion haut débit FASTNETWORKCONNECTION, retourne le numéro de série duVIDEODECODER que le client utilisera pour accéder à la vidéo sur IP;

Les web services sémantiques : Partie 27- LIVEBOX service qui retourne la facture INVOICE de l’offre commercialepersonalisée que le client a demandé, dépendant du n de téléphone PHONENUM, del'adresse IP IPADDRESS et du numéro de série du DECODER.Un tel scénario est aujourd’hui considéré comme stratégique pour tout opérateurde services qui souhaite des gains importants de productivité mais qui souhaite offrirà ses clients des « bouquets de services sur mesure » pour optimiser leur budget detélécommunication.2. Composition de web servicesAprès avoir décrit dans la partie 1 de cet article, les méthodes de raisonnementnécessaires pour la découverte de services web sémantique ; nous abordonsmaintenant leur composition en rappelant la problématique et les principalesapproches qui sont explorées aujourd’hui7.2.1. Composition de Services Web sémantiqueUne composition de services vise à répondre à un besoin ne pouvant êtresatisfait par aucun des services web élémentaires disponibles à un instant donné,mais seulement par de possibles combinaisons de certains d’entre eux. Lacomposition de services implique donc, préalablement de découvrir des servicespouvant répondre à ce besoin (Partie 1), de sélectionner les plus pertinents, puis deles composer et finalement de les orchestrer pour leur exécution.Demande AccordAcheterBanqueOK1tPaiemaAche1Not2t1eniemParec seur 1Fournisseur 2Figure 3. Une composition de services élémentaires87Etat de l’art recherche et technologique issu des conférences majeures sur le sujet et descontributions personnelles des auteurs. L’état de l’art industriel est encore très embryonnaireen ce début 2008.8Exemple classique extrait de (Hull et al., 2003). L'agence de voyage virtuelle est aussi unautre exemple (ultra) classique qui se traite de la même façon.

8Revue. Volume X – n x/annéeDans ce qui suit, nous exposerons l’état de l’art du domaine de l’automatisationde la composition de services web sémantique. Tout d’abord, nous expliciterons laproblématique de la composition de services Web. Ensuite, nous présenterons lessolutions proposées pour résoudre le problème de composition de services Web.L’objectif de la composition de services est donc de créer – en rapport à unnouveau besoin - une nouvelle offre de services combinant les fonctionnalitésoffertes par des services existants (élémentaires ou déjà composés). La figure 3illustre le besoin classique de composition automatique dans le contexte ducommerce électronique (e-commerce B2C, B2B).Cette composition est un assemblage de quatre services web élémentaires(Boutique, Banque, Fournisseur 1 et Fournisseur 2). La boutique ayant pignon sur leWeb propose à ses clients des produits (services) et interagit avec eux via uneinterface « Acheter / Emporter ». Cette boutique fait appel à des services bancairespour le débit du compte client via l’interface « Demande d’accord / OK ». Enfin,les deux fournisseurs (1 et 2) réapprovisionnent les rayons de la boutique vial’interface « Achat / Note » et débitent le compte boutique via l’interface « Facture /Paiement ». Dans le contexte générique de la Fig. 1, on peut imaginer par exemple,un client souhaitant acheter (boutique) un ensemble réfrigérateur-congélateur(fournisseur 1) et se faire livrer (fournisseur 2) le produit sous trois jours (il existebien entendu, des variations infinies d’usage pratique de cette architecture decomposition très générique).Des résultats mettant en œuvre des services web pour résoudre cetteproblématique commencent seulement à émerger dans la littérature scientifique(actes de conférences) et livrables de projets R&D coopératifs9. Des travaux récentsde la communauté du web sémantique (Rao et al., 2005) (Pistore et al., 2004)(Medjahed et al., 2003) (Wu et al., 2003) (Narayanan et al., 2002) (McIlraith et al.,2001a), se sont intéressés à des approches de planification (IA) qui permettent deconstruire une (des) composition(s) meilleures possibles connaissant le but àatteindre i.e. la satisfaction de requête quelle soit humaine ou issue d'une autremachine. D'autres (Hull et al., 2003) (Berardi et al., 2003) (Bultan et al., 2003),s’intéressent à une modélisation abstraite des services plongés dans un cadre formelde type workflow, Machines à états finis et Mealy machine afin de les composer àpartir du but (idem plus haut) décrit formellement. Cette dernière permet en outre lavérification des modèles générés et donc des propriétés d’un service composite àpartir des propriétés de ses composants. Tous ces travaux tentent de ré-exploiter etd’étendre des techniques existantes en rapport avec l’étude formelle des systèmes9Les technologies agents logiciels ont déjà dans les années 90 tenté d’y répondre sansapporter de réponses industrielles à grande échelle – voir par exemple dans la littérature desarticles sur les systèmes multi-agents (MAS ) (Gleize M.P. et al., 1999). Les technologiesEAI ont, elles, été déployées mais utilisent des méthodes « manuelles » pour la composition,et donc difficile à déployer et à maintenir, et surtout pas exécutables sur le web.

Les web services sémantiques : Partie 29dynamiques, tels que : la logique temporelle et dynamique, l’algèbre des processuset pi-calculus (Milner, 1999), les processus de Markov, la planification en IA(Russel et al., 1995), la planification hiérarchique de tâches (HTN planning), lathéorie des automates et les réseaux de Pétri (Diaz, 2001), la logique des situations(Reiter R., 2001), pour nommer les plus représentatifs.2.2 Etat de l'art sur la composition automatisée de services Web sémantiqueLa composition automatisée de services Web peut être vue à différents niveauxd'abstraction (Pistore et al., 2005a). D'un point de vue de haut niveau, les servicesWeb sont présentés comme de simples entités (une telle description est fournie parexemple par « OWL-S profile », « WSMO service capability model ») fournissantdes sorties et des effets sur le monde réel ( ex. le débit d’un compte bancaire), enfonction d'entrées et de pré-conditions d’activation (ex. accord de la banque pour latransaction) (on utilise l’acronyme « IOPE » pour Input/Output/Précondition/Effects). Ainsi à partir d'un ensemble de services Web, la composition apour but de sélectionner et de combiner les services avec des opérateurs decomposition simple (séquence, choix, boucle etc.) pour satisfaire un but ou unerequête initiale (Figure 1 : besoin d’un client ou besoin d’un fournisseur). Il va desoi que le modèle de composition va s’appuyer sur les outils de découverte deservice Web (Partie 1) pour trouver – à la volée - les services élémentairescompatibles avec la composition recherchée.La composition met en scène clairement deux niveaux (Figure 4) :1- Un niveau fonctionnel10 qui assemble ou regroupe des services élémentairesprésentant des interfaces ou signatures opérationnelles (IOPE) compatibles (ex. lasortie paiement de la banque en Euros est acceptée par les fournisseurs 1 et 2, lesdonnées de facturation sont similaires, etc.) ;Ce premier niveau d'analyse est une étape essentielle pour l'assemblage decomposants de types compatibles. Et de façon assez complémentaire à la découvertede services (partie 1) on va ici rechercher les interfaces de services que l'on pourraitassembler pour obtenir la fonctionnalité de service globale à atteindre exprimé par lebut (Requête). Elle est décrite par OWL-S ("service profile"), WSMO ("servicecapability") et par SA-WSDL.2- Un niveau conversationnel11 (ou protocole) qui assemble des servicesélémentaires dont les protocoles de dialogue sont compatibles et complémentaires(Fig. 1 : l’interaction entre la boutique et la banque se fait selon le protocoledemande d’accord de la boutique, réponse de la banque par OK ou non-OK, si OKalors commande vers les fournisseurs, si non-OK alors refus retourné au client).1011Dans la littérature anglo-saxonne on trouve aussi "data flow driven composition"Dans la littérature anglo-saxonne on trouve aussi "control flow driven composition"

10Revue. Volume X – n x/annéeCe deuxième niveau est crucial, en effet les interactions entre les différentsservices i.e., conversation par échanges de messages (ex. « OWL-S processprocess », « WSMO interface model », SWSL-FLOWS), permet une compositionau niveau des protocoles pour générer un service composé exécutable.La composition automatisée de services Web consiste ainsi à effectuer lacomposition à un niveau fonctionnel des signatures des services et au niveauconversationnel des protocoles des services comme présenté en Figure 2. Dans lasuite de cette section nous décrirons les principaux modèles de compositionnotamment a) la composition au niveau fonctionnel, et b) la composition au niveaudes protocoles de services Web.RequêteFigure 4. Les deux niveaux de composition dans une architecture simple2.2.1 Composition au niveau fonctionnelLa composition au niveau fonctionnel est très liée à la découverte et enparticulier avec les approches qui relient une requête à une réponse composée deplusieurs services web nécessaires à la couverture "au mieux" des besoins de larequête (Partie 1 : approches par abduction et couverture "1-N"). Mais la réponse àune requête de découverte n'est qu'un conglomérat de services web indépendants. Lacomposition de niveau fonctionnel va tenter d'assembler (comme un jeu de Lego )ces services web par rapprochement n à m des interfaces fonctionnelles (types,opérations, Pré-conditions, effets) restreintes à des interactions atomiques. La

Les web services sémantiques : Partie 211composition fonctionnelle réalise donc une (des) sélection(s) et un (des) préassemblage(s) de services web potentiellement capables de répondre"fonctionnellement" à la requête (Figure 5).La composition fonctionnelle fait souvent appel aux outils de la planification enIntelligence Artificielle (ou “AI planning”) assez bien couvert par (Chan et al.,2007) (Peer, 2005a) (Ghallab et al., 2004) (Nilsson et al., 1980) (Russell et al.,1995) (Mc Illraith et al., 2002b). Le problème de la composition de services web estexplicité par une connaissance de l’ensemble des entrées (informations dont nousdisposons), et de l’ensemble des sorties (buts que nous voulons résoudre). Engénéral un problème de planification de tâches se décrit comme le n-uplet {S, S0, G,A, Γ}, où S est l’ensemble des états du monde (du domaine de l’application), S0 Sest l’état initial, G S représente l’état du monde à atteindre (le but), A estl’ensemble des actions disponibles (les web services élémentaires) pour passer d’unétat à un autre et enfin le graphe des transitions Γ S x A x S qui relie les préconditions et effets attachés à l’exécution de chaque action.Intégration fontionnelleEntréesSortiesEntréesAchatAccord banqueBanque okCommandeFactureEmporterBoutiqueSortiesAccord ban.Ok banqueNote four.Paiement urnisseursFigure 5. Composition fonctionnelleLa résolution de ce problème aboutit à une planification de tâches selon uneorientation donnée dépendante des conditions initiales disponibles(chaînage avantou arrière, résolution en profondeur ou en largeur) et du but à atteindre. Ainsi leplanificateur positionne chaque service utile et pertinent dans un diagramme de

12Revue. Volume X – n x/annéeséquences ou diagramme d’états (ou « workflow ») afin de satisfaire le but12. Laposition de chaque service dans le diagramme de séquences est déterminée aumoyen de ses IOPEs.Dans cette classe de solutions au problème de composition, (McIlraith et al.,2001a), (McIlraith et al., 2001b), (McIllraith et al., 2002) étend le langage deprogrammation logique Golog construit à partir des éléments du calcul de situation(Levesque et al., 1998), afin de raisonner à partir des actions (i.e. entrées) et deschangements opérés sur l'état du monde (i.e. effets). Plus précisément (McIllraith etal., 2002) voient le problème de la composition de services comme un problème derecherche de procédures génériques qui seront ensuite exécutées dans le contextespécifique d’un « état du monde » (ex. annulation de vols) et de contraintes del’utilisateur (ex. Primes Air France). Par exemple, la planification d’un voyage oul’achat d’un produit sur Internet, se représentent aisément par des procéduresgénériques standard (ex. de l’achat d’un livre sur Amazon.com), que l’utilisateur vaexécuter pour son contexte particulier. Cette approche propose ainsi une séquencede services génériques, modifiables et réutilisables. Ce modèle a été développé surla base d'un interpréteur du langage “ConGolog” (De Giacomo G. et al., 2000).Une autre illustration de la mise en œuvre de la planification est celle de (Wu D.et al., 2003) utilisant SHOP-2, un formalisme de planification hiérarchique (HTN)13.La planification HTN est une méthodologie de planification qui construit un planpar décomposition hiérarchique de tâches. C'est un processus dans lequel le systèmede planification décompose les tâches globales (i.e. le but initial) en tâches pluspetites jusqu'à obtention de tâches primitives correspondant aux opérationsréellement offertes par les services Web. En suivant cette approche HTN, le systèmedécrit par (Wu et al., 2003) propose une composition de services Web s'appliquantau standard OWL-S. Mais cette fois l’idée est d’associer à l’outil de planificationHTN-SHOP214 un raisonneur logique pour OWL (i.e. Pellet15). En soutien destâches de planification, le raisonneur assume la fonction d’évaluation des préconditions (raisonnement standard de satisfiabilité en Logique de Description) et demise à jour de la base de connaissance de « l’état du monde » suite aux effetsproduits par l’exécution des opérations. Ainsi, l’intégration du raisonneur OWLassume toutes les tâches d’interactions avec la base de connaissance sur « l’état dumonde » (Base de faits décrits en OWL ou assertions de la ABox). Les auteursprésentent aussi quelques pistes très intéressantes d’optimisation pour l’évaluationdes pré-conditions et une évaluation sur un prototype associant OWL-DL Pellet et laversion Java de SHOP (JSHOP). L'inconvénient de cette méthode HTN est qu'elleimpose une structure hiérarchique des tâches en sous-tâches, ce qui s'avèredifficilement applicable aux cas réels et de plus ne passe pas à l'échelle.12On utilisera aussi "Requête" pour exprimer le but ou le besoin attendu global de services(humain-machine ou machine-machine)13Hierarchical Task iption.html15http://pellet.owldl.com/

Les web services sémantiques : Partie 213Une méthode récente se basant sur la composition de services Web au niveaufonctionnel est l'approche suivie par (Lécué et al., 2006). Les correspondancessémantiques entre services Web sont assimilées à des liens causaux entre opérations(I/O) où ces derniers sont pondérés par les degrés de correspondance sémantique("exact", "plug-in", "Subsume", "disjunction") telles celles introduites par (Paolucciet al., 2002). Leur modèle de composition faisant appel à la planification en IA suitune méthode de chaînage arrière des services Web. Ainsi aucune, ou plusieurschaînes des services Web capable de satisfaire une requête utilisateur sont trouvées.Une originalité de la méthode de composition tient dans l’optimisation apportée parun pré-calcul des correspondances sémantiques des entrées et des sorties de tous lesservices web découverts et compatibles avec le but global à atteindre, dans unematrice dite des « liens causaux » qui ne conserve que les liens entrée-sortiesémantiquement compatibles. Partant du but à atteindre et de la matrice de "lienscausaux", l'algorithme de chaînage arrière proposé agit récursivement sur une listede services web liés par les liens découverts i.e., pour chaque service de la liste, unenouvelle liste est découverte de telle sorte que les paramètres de sortiecorrespondent sémantiquement aux paramètres d'entrées. Une fois les différenteschaînes (ou plan) de composition possible trouvées, (Lécué et al., 2006) proposentde calculer la composition optimale en termes de correspondance sémantique entreles services web, que l'on peut étendre aisément à la prise en compte de propriétésnon fonctionnelles (QoS, Coût, ). Cette méthode ne tient pas compte des préconditions et nécessite donc d'être complétée (Lécué et al., 2008).(Cardoso et al., 20

Framework) sur HTTP avec le partenaire B, ii) EDI4 X12 utilisant un service support d'opérateur de télécommunication (Value-Added Network « VAN ») avec le partenaire C et l'interface SAP IDOC (SAP Intermediate Documents) mettant en oeuvre une solution à base de services web avec le partenaire D. 1.1.2 Motivation