Composition de Services Web Dr. Djamel Benmerzoug Email : djamel.benmerzoug@univ-constantine2.dz Maitre de Conférences A, Département TLSI Faculté des NTIC Université Constantine 2 Abdelhamid Mehri 127
Composition de Services Web Plan: Introduction Approches de composition Orchestration Chorégraphie Orchestration vs Chorégraphie BPEL : Business Process Execution language 128
Introduction SOA : Décomposition d un grand problème en parties plus petites, donc plus gérables Comment assembler ces petits services ensemble pour créer des services à valeur ajoutée? 129
Introduction Exemple de Scénario : Solution 1: L utilisateur se rend sur chaque site Web des administrations Solution 2: L utilisateur utilise un seul site Web Début Réserver Hotel OK? oui Réserver Avion OK? oui non non Echec Réserver Train Louer Voiture oui OK? non Echec OK? non Echec oui Succès 130
Introduction La composition de services est le mécanisme qui permet l intégration des services pour construire un nouveau Web service à valeur ajoutée. 131
Introduction Composition : Implémentation d une application (offerte comme service) dont la logique implique l invocation d opérations offertes par d autres services. Le nouveau service est appelé service composite Les services invoqués sont des composants de service Du point de vue du client, un service composite et un service basique sont in-distinguables. 132
Approches de composition Deux approches principales pour a composition des services web : Orchestration Chorégraphie 133
Approches de composition Orchestration de services Orchestration de services La composition de services par orchestration consiste à faire l assemblage de services selon un ordre et un flux d exécution. L exécution d une composition par orchestration est réalisée par un coordinateur de services. L utilisation d un tel coordinateur implique une composition avec une logique d exécution qui sera interprétée par ce coordinateur. 134
Approches de composition Orchestration de services Web Service 1 Web Service 2 Web Service 3 Web Service 4 135
Approches de composition Orchestration de services Standards d Orchestration BPMN (Business Process Modeling Notation) Succède à BPML (Business Process Modeling Langage) Définit une représentation visuelle de la séquence BPEL (Business Process Execution Language) ou BPEL4WS (BPEL for Web Services) Code qui exécute la séquence Exprimé en XML Définit deux types d activités: Activités de base : interagissant avec les services externes (invoke, receive, reply) Activités structurées : contrôle de flux du processus interne (flux séquentiel, condition, boucle ) 136
Approches de composition Orchestration de services Limites de l Orchestration Approche centralisée autour du moteur de composition En cas de panne, plus de composition Schéma de composition statique En cas de changement dans les besoins, le schéma devient invalide 137
Approches de composition Chorégraphie de services Chorégraphie de Services La Chorégraphie est un effort de collaboration dans lequel chaque participant du processus décrit l itération qui l appartient. Le comportement global du processus est basé sur l interaction des différentes parties, chacune suivant son propre rôle de manière autonome. 138
Approches de composition Chorégraphie de services Chorégraphie de Services 139
Approches de composition Chorégraphie de services Standards de la Chorégraphie WS-CDL (Web Services Choregraphy Description Language) Succède à WSCI (Web Services Choregraphy Interface) Langage de description en XML Décrit les messages qui sont impliqués dans l échange collaboratif entre services Ne définit pas de processus métier exécutable (contrairement à BPEL) Un seul document WS-CDL spécifie la contribution d un partenaire à l échange de messages. Contient un ensemble d interactions, représentant les échanges de messages entre parties 140
Approches de composition Chorégraphie de services Limites de la Chorégraphie Collaborations et partenaires statiques Si les besoins ou partenaires changent, les collaborations deviennent impossibles Pas de langage pour exprimer les besoins Les travaux existant proposent une chorégraphie statique 141
Approches de composition Orchestration vs. Chorégraphie Orchestration Le processus est défini en utilisant un langage comme BPEL puis un engin d orchestration est appelé pour l exécuter. Les services invoqués ne savent pas qu ils font partie d un processus métier. Chorégraphie La logique d exécution, ou d appels des services, est gérée par chaque composant. Chaque service web participant dans la chorégraphie doit savoir exactement quand être actif et avec qui interagir. 142
BPEL : Business Process Execution language BPEL : Business Process Execution language OU BPEL4WS : BPEL for Web Services OU WS-BPEL 143
BPEL : Business Process Execution language Le langage BPEL: proposé par Microsoft, IBM et BEA Systems, en 2002 représente la fusion des deux standards auparavant rivaux : WSFL et XLANG Standardisé par OASIS en 2007 (version 2.0) Principe: Le fichier BPEL définit le processus, ou l'enchaînement et la logique des actions. Ce fichier est véritablement le code source de l'application que constitue le processus, le moteur d'orchestration agissant comme une machine virtuelle capable d'exécuter le code BPEL. 144
BPEL : Business Process Execution language Pour fonctionner, BPEL4WS s'adosse à deux éléments d'infrastructure : WS-Transaction: conçu pour garantir l'intégrité des transactions entre deux services, c est-à-dire gérer le déroulement des tâches et garantir que toutes les transactions aboutissent ou échouent en groupe. WS-Coordination: précise la manière de coordonner un Service Web avec le monde extérieur, assure la communication entre les services Web composant une tâche et décrit leur interaction. Il a pour but d'expliciter l'ensemble des fonctions nécessaires à l'invocation du composant en question. 145
BPEL : Business Process Execution language Exemple de code en BPEL 146
BPEL : Business Process Execution language Structure d un fichier BPEL4WS: activités de base L activité <process> est l'élément racine (au sens XML) du fichier BPEL L activité <partnerlinks> permet de lier des actions définies dans le fichier WSDL (via partnerlinktype) au process BPEL L activité <variables> permet de définir les variables L activité <Receive> : Activité d attente d un message L activité <Invoke> : Invoquer d'autres web services L activité <Reply> : Envoi d un message en réponse à une <Receive> Activity. Les activités <Assign> et<copy> : Utilisées pour mettre à jour les valeurs des variables. 147
BPEL : Business Process Execution language activités structurées L activité <Sequence> : Bloc d activités à exécuter en séquence L activité <Flow> : Bloc d activités à exécuter en parallèle Les activités <if> <else> pour définir les structures conditionnelles L activité <Switch> : Sélection d une activité à exécuter parmi un ensemble L activité <While> : Boucle d exécution d une activité tant qu une condition est vérifiée L activité <Pick> : Attente bloquante d un message, d un partenaire ou de l expiration d un délai 148
BPEL : Business Process Execution language Processus abstrait vs processus exécutable Avec BPEL, on peut décrire les processus métiers de deux manières différentes : Un processus abstrait est un protocole métier, spécifiant le comportement des messages entre les différents intervenants sans révéler leur comportement interne. Un processus exécutable spécifie l ordre d exécution de différentes activités, les partenaires concernés, l échange de messages, ainsi que les problèmes et les erreurs d exécution pouvant être rencontrés. 149
BPEL : Business Process Execution language Quelques moteurs BPEL Biztalk Server de Microsoft Collaxa BPEL Orchestration Server de Oracle Parasoft BPEL Maestro IBM WebSphere Process Choreographer BEA WebLogic 8.1 150
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA Objectifs du TP : Création de d une application SOA Composite en utilisant BPEL et Netbeans Outils utilisés: OpenESB (version 3.05) BPEL JBI (Java Business Integration) Une architecture basée SOA permettant la mise en place de solutions d intégration 151
OpenESB: TP1: DÉVELOPPEMENT D UNE APPLICATION SOA OpenESB est un Enterprise Service Bus (ESB) respectant la norme Java Business Integration (JBI), définie dans la spécification JSR 208. Un openesb permet l'intégration de plusieurs logiques métier hétérogènes. Il dispose de deux types de composants: engins d'exécution (service engine) qui permettent d'exécuter les différentes logiques métier (BPEL, SQL, JEE, etc.) composants de connexion (binding component) implémentant les différents standards de communication 152 (FTP, HTTP, JDBC, etc.).
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA BPEL: Le langage BPEL permet de représenter les processus métiers, et de créer simplement des applications complexes faisant appel à plusieurs services web. Les outils SOA de openesb fournissent un environnement graphique BPEL rendant ainsi la création de ces applications plus intuitive. 153
BPEL: TP1: DÉVELOPPEMENT D UNE APPLICATION SOA 154
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA BPEL: Pour comprendre les processus BPEL, il faut définir un ensemble de concepts: Les services partenaires (Partner Services) : représentent tout service externe ou client qui interagit avec le processus BPEL. Les activités : ce sont les tâches métier individuelles dans le processus, permettant de réaliser l objectif global de processus. Les variables : Il existe plusieurs variables et messages qui circulent entre les activités du processus, et entre les activités et les partenaires. 155
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA BPEL: utilisation des variables (BPEL Mapper) 156
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA JBI: JBI (Java Business Integration) est une norme édictée dans la JSR208, basée sur une approche SOA. Il définit une architecture permettant la mise en place de solutions d intégration, basées sur l utilisation de composants qui communiquent via des messages. 157
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA JBI: JBI définit une partie d un ESB: le conteneur de services, responsable de la vraie intégration. C est l endroit où des composants informatiques (comme des applications, protocoles, bases de données ou même fichiers de données) sont transformés en fournisseurs et/ou consommateurs de services. Il définit les services sous forme de fichiers WSDL. 158
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA Objectifs de TP1 L'API Google Webs vous permet d'incorporer la fonction de recherche Web de Google dans les pages Web et applications que vous voulez développer, de sorte que vos utilisateurs peuvent rechercher tout ou partie du Web directement depuis l'application. L'API Google Webs est un service Web qui utilise les normes SOAP et WSDL. 159
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA Objectifs de TP1 Types d'applications Google Market research Data analysis Trend analysis Search interface Spell checking 160
TP1: DÉVELOPPEMENT D UNE APPLICATION SOA Objectifs de TP1 L objectif principal de ce TP est de développer une application SOA composite en utilisant l environnement openesb et le langage BPEL. L application permet d invoquer une fonctionnalité de Google (par exemple l API Google Custom Search). L application doit comporter au moins un service externe invoqué, puis stocker les informations de la demande ainsi que la réponse dans une base de données. 161