composition de services web -...
TRANSCRIPT
Composition de Services Web
Dr. Djamel Benmerzoug
Email : [email protected]
Maitre de Conférences A, Département TLSIFaculté 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
130
Début
Réserver
Avion
Louer
Voiture
Réserver
Train
Réserver
Hotel
OK ?
OK ?
OK ?
OK ?
Echec
Echec
Echec
Succès
oui
oui
oui
oui
non
non
non
non
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 compositionOrchestration de services
Orchestration de services
La composition de services par orchestrationconsiste à faire l’assemblage de services selonun ordre et un flux d’exécution.
L’exécution d’une composition par orchestrationest réalisée par un coordinateur de services.
L’utilisation d’un tel coordinateur implique unecomposition avec une logique d’exécution quisera interprétée par ce coordinateur.
134
135
Web
Service 1
Web
Service 2
Web
Service 3
Web
Service 4
Approches de compositionOrchestration 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 compositionOrchestration 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 compositionOrchestration de services
Chorégraphie de Services La Chorégraphie est un effort de collaboration dans
lequel chaque participant du processus décrit l’itérationqui l’appartient.
Le comportement global du processus est basé surl’interaction des différentes parties, chacune suivant sonpropre rôle de manière autonome.
138
Approches de compositionChorégraphie de services
Chorégraphie de Services
139
Approches de compositionChoré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 compositionChoré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 compositionChorégraphie de services
Approches de compositionOrchestration 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.
142
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.
143
BPEL : Business Process Execution language
OU
BPEL4WS : BPEL for Web Services
OU
WS-BPEL
BPEL : Business Process Execution language
144
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.
BPEL : Business Process Execution language
145
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.
BPEL : Business Process Execution language
146
■ Exemple de code en BPEL
BPEL : Business Process Execution language
147
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.
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
150
■ Quelques moteurs BPEL
■ Biztalk Server de Microsoft
■ Collaxa BPEL Orchestration Server de Oracle
■ Parasoft BPEL Maestro
IBM WebSphere Process Choreographer
BEA WebLogic 8.1
BPEL : Business Process Execution language
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
TP1: DÉVELOPPEMENT D’UNE APPLICATION SOA
OpenESB:
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 (FTP, HTTP, JDBC, etc.).
152
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
TP1: DÉVELOPPEMENT D’UNE APPLICATION SOA
BPEL:
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
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
TP1: DÉVELOPPEMENT D’UNE APPLICATION SOA