eServices-Chp3: Composition de Services

Composition de Services
Chapitre 3 - eServices
GL5
2015/2016
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1

Composition de services
Orchestration de services
Chorégraphie de services
Orchestration vs Chorégraphie : Synthèse
2
PLAN

3
PLAN

Problématique
SOA :
Division d’un grand problème en parties plus petites, donc plus gérables
Comment assembler ces petits services ensemble pour créer des services plus
grands?
Exemple de Scénario :
1.  Inscription d’un étudiant à une école
Inscription : nom, adresse…
Paiement des frais d’inscription (services d’une banque)
Attribution d’un numéro d’étudiant
2.  Chercher un logement dans un foyer d’étudiants (CROUS)
Inscription à partir du numéro d’étudiant
Choisir le type de logement
Paiement des frais d’hébergement
Attribution d’un numéro au foyer
3.  S’abonner au transport
Sélectionner la ligne entre l’école et le logement
Choix de la réduction proposée (num d’étudiant)
Inscription et Paiement
4
Composition de Services Web

Problématique
Solution 1 : L’utilisateur se rend sur chaque site web des administrations
5

Problématique
Solution 2 : L’utilisateur n’utilise que le site web de l’école
6

Définition
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
(implémenté par un langage de programmation traditionnel) sont in-
distinguables.
Notion de Service Mashup :
Forme plus légère de composition
Pour les applications web
Implique l'intégration dans un site web de contenus provenant d'autres sites
7

Besoins de la Composition
Capacité d’invoquer les services d’une manière asynchrone
Gestion des exceptions et de l’intégrité transactionnelle
Les études montrent que presque 80% du temps de construction
des processus métier est passé dans la gestion des exceptions
Fourniture d’un framework dynamique, flexible et adaptable
pour une séparation claire entre la logique métier et les services
utilisés
Deux approches principales
Orchestration
Chorégraphie
8

9
PLAN

Définition
L’approche la plus commune
La séquence d’étape est définie dans un processus, avec conditions et
exceptions
Un contrôleur central est ensuite créé pour implémenter la séquence
Les étapes individuelles d’une séquence sont implémentés par des
opérations sur des services
Pour des compositions de services simples, l’orchestration est faite dans
le code (Java, C#...) résidant dans le composite
Pour des orchestrations complexes, un outil est utilisé pour :
Créer un modèle visuel d’une séquence
Générer le code qui exécute cette séquence dans un environnement d’exécution
dédié
➪ Approche BPM (Business Process Model)
10
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
Utilise WSDL à deux niveaux :
Interagir avec les ressources requises par le
processus
Décrire le processus BPEL lui-même
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…)
11

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
12

L’Orchestration en Résumé
Définit un seul maître contrôlant tous les aspects du processus
Supporte une vue graphique de la séquence d’exécution
Se couple facilement avec SOA
Présente un bon point de départ, mais un passage à l’échelle
difficile pour les processus complexes
Supporté par la plupart des outils
13

14
PLAN

Définition et Objectif
Dédiée
Aux processus complexes ayant plusieurs parties qui interagissent
Aux systèmes basés sur les évènements et sur les agents
Des règles déterminent le comportement de chaque participant individuel
d’un processus
Le comportement global du processus est basé sur l’interaction des
différentes parties, chacune suivant son propre rôle de manière
autonome.
Deux approches:
Basée sur les messages
Basée sur les composants fonctionnels
15
Chorégraphie de Services

Approche Basée sur les Messages
Basée sur l’examen des messages entre les participants dans un
processus
Le comportement est défini par la capture des contrats de messages
entre les parties en collaboration.
Supporté par le standard WS-CDL (Web Service Choregraphy Definition
Language)
Souvent utilisé pour les applications B2B (entre entreprises)
Difficile de spécifier l’implémentation des participants
Pas d’autorité centrale pour le flux global
Besoin de spécifier uniquement l’échange des messages (syntaxe,
sémantique, comportement)
16

Approche Basée sur les Composants Fonctionnels
Basée sur la configuration des composants du processus
On définit le comportement des composants individuels et on laisse le
comportement du processus émerger quand chaque instance de
processus évolue.
Exemple : Implémentation du routage dans les différents composants
avec de simples règles :
Quelles fonctionnalités ce composant a besoin de faire?
Quels rôles peuvent réaliser quels besoins?
Qu’est ce qui peut activer un besoin?
Comment un besoin peut-il être considéré comme réalisé?
Ressemblance avec les systèmes à base d’agents
Exemple d’implémentation: BPEL4Chor
17

Standards de la Chorégraphie
WS-CDL (Web Services Choreography Description Language)
Succède à WSCI (Web Services Choreography 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
Décrit l’ordre des messages dans lequel ils doivent être observés
Si cet ordre n’est pas respecté, WS-CDL considère les messages comme hors de la
séquence, donc erronés
18

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 existants proposent une chorégraphie statique
19

La Chorégraphie en Résumé
Le comportement global du processus émerge du travail des différentes
parties. Aucune perspective globale n’est nécessaire
Les processus complexes sont décomposés en agendas de travail où
chaque élément autonome contrôle son propre agenda.
Se couple facilement avec les systèmes basés sur les évènements et
sur les agents
Est généralement plus difficile à démarrer, mais la mise à l’échelle à des
processus complexe est plus facile
Les représentations graphiques peuvent être dérivées des processus
è la forme succède à la fonction
20

21
PLAN

Orchestration vs. Chorégraphie (1/3)
Orchestration Chorégraphie
Exécution automatique d’un processus: le
processus est défini en utilisant un
langage comme BPEL puis un engin
d’orchestration est appelé pour l’exécuter.
Un processus orchestré est exposé
comme service.
Description d’interactions coordonnées
entre deux ou plusieurs parties.
Les services invoqués ne savent pas qu’ils
font partie d’un processus métier. Seul le
processus central est conscient de
l’objectif général à atteindre.
Chaque service web participant dans la
chorégraphie doit savoir exactement
quand être actif et avec qui interagir.
22
Synthèse

Décrit ce qu’un processus fait sans
spécifier comment cela est
implémenté.
Interaction peer-to-peer, car il n’y a pas de
conducteur. C’est un modèle consensuel pour
les interactions, qui peut consister en un
ensemble d’orchestrations.
Fixe, car elle définit un ensemble
d’étapes et décisions bien définies.
Orientée objectif: les ressources sont
coordonnées pour réaliser cet objectif
Intra-organisationnel (une
organisation ne peut pas en
orchestrer une autre)
Inter-organisationnel
Autocratique (dirigée par un
dictateur)
Autonome (les services s’administrent eux-
mêmes)
23
Synthèse

24
Synthèse

Scénarios d’Utilisation
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 25
Synthèse
•  Quand on a besoin de produits à la
demande, car c’est l’approche
implémentée par la plupart des
produits
•  Quand les processus peuvent s’étendre à
un grand nombre d’étapes
•  Pour les services composés •  Où le détail d’un processus doit rester
secret pour les autres partenaires du
processus (B2B par exemple)
•  Pour les processus relativement
statiques
•  Où les différents partenaires d’un
processus ont besoin de leurs propres
personnalisation du processus
•  Où une définition graphique des
processus est nécessaire
•  Où les processus sont hautement
dynamiques ou basés sur un objectif

Cours
Robert Ma, Web Service Composition, 2007
Articles de Recherche
A. ALBRESHNE, P. FUHRER, J. PASQUIER, Web Services
Orchestration and Composition, Case Study of Web services
Composition, September 2009
Mike Rosen, BPM and SOA : Orchestration or Choreography,
Avril 2008
26
Sources

eServices-Chp3: Composition de Services

Contenu connexe

Tendances

En vedette

Similaire à eServices-Chp3: Composition de Services

Plus de Lilia Sfaxi

eServices-Chp3: Composition de Services