Composition de Services Web - Djamel...

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

130

Composition de Services Web

Plan:

Introduction

Approches de composition

Orchestration

Chorégraphie

Orchestration vs Chorégraphie

BPEL : Business Process Execution language

131

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 ?

132

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

133

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.

134

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.

135

Approches de composition

Deux approches principales pour a composition des services web :

Orchestration

Chorégraphie

136

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.

137

138

Web

Service 1

Web

Service 2

Web

Service 3

Web

Service 4


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…)

139


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

140


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.

141

Approches de composition Chorégraphie de services

Chorégraphie de Services

142


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

143


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

144


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.

145

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.

146


OU

BPEL4WS : BPEL for Web Services

OU

WS-BPEL


147

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.


148

■ Exemple de code en BPEL


149


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

150


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.

151


152

■ Quelques moteurs BPEL

■ Biztalk Server de Microsoft

■ Collaxa BPEL Orchestration Server de Oracle

■ Parasoft BPEL Maestro

IBM WebSphere Process Choreographer

BEA WebLogic 8.1


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

153


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.).

154


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.

155


BPEL:

156


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. 157

TP1: DÉVELOPPEMENT D’UNE APPLICATION SOA BPEL:

utilisation des variables (BPEL Mapper)

158


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.

159


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. 160

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.

161


Objectifs de TP1

Types d'applications Google

Market research

Data analysis

Trend analysis

Search interface

Spell checking

162


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.

163


Composition de Services Web - Djamel...

Documents

Transcript of Composition de Services Web - Djamel...