Services WEB - Djamel Benmerzoug

Transcription

Composition de Services Web
Dr. Djamel Benmerzoug
Email : [email protected]
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
Début

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
Réserver
Hotel
non
OK ?
oui
Echec
Réserver
Avion
OK ?
non
Réserver
Train
oui
Louer
Voiture
OK ?
oui
non
OK ?
non
Echec
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

Deux approches principales pour a
composition des services web :


Orchestration
Chorégraphie
133
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
Web
Service 1
Web
Service 3
Web
Service 2
Web
Service 4
135

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
136
séquentiel, condition, boucle…)

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
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

Chorégraphie de Services
139

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

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
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
OU
BPEL4WS : BPEL for Web Services
OU
WS-BPEL
143

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
144
capable d'exécuter le code BPEL.
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
■ Exemple de code en BPEL
146

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

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
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
■
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
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
152
(FTP, HTTP, JDBC, etc.).
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
APPLICATION SOA

BPEL:
154
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
APPLICATION SOA

BPEL:

utilisation des variables (BPEL Mapper)
156
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
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
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
APPLICATION SOA

Objectifs de TP1

Types d'applications Google





Market research
Data analysis
Trend analysis
Search interface
Spell checking
160
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

Services WEB - Djamel Benmerzoug

Transcription

Documents pareils

Formation SOA - Service Oriented Architecture

Orchestrer et composer ses services avec BPEL Détails

Services WEB - Djamel Benmerzoug

SOA, mise en œuvre en Open Source/Java

Slicing du BPEL

Ingénierie logicielle à base de composants - membres

Programme détaillé formation `Architecture SOA`- 5j

Service Oriented Architecture