RUGBY MATCH MANAGEMENT - Encadrants : Chantal Taconet Frédérick Seyler KHAIREDDINE Mohamed Abderrahmene BOUKDHIR Walid
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
KHAIREDDINE Mohamed Abderrahmene
BOUKDHIR Walid
Encadrants :
Chantal Taconet
Frédérick Seyler
RUGBY MATCH MANAGEMENT
Rapport du Projet de Fin d’Etudes 1
ASR 2006/2007
TABLE DE MATIERES
INTRODUCTION 3
I. PRESENTATION 4
1. Les acteurs: 4
2. Scénario principal : 4
3. Modèle UML: 5
a. Formalisme et Définitions: 5
4. Modèle : 7
II. MISE EN ŒUVRE 12
1. Outils de travail 12
a. ORCHESTRA 12
b. AXIS 12
2. Environnement de travail 12
a. Pré-requis pour ORCHESTRA : 12
b. Pré-requis pour Axis : 13
3. Installation 13
a. ORCHESTRA 13
b. AXIS : 15
4. Services Web 16
a. Conception 17
b. Déploiement 23
c. Vérification 24
5. BPEL 25
a. Présentation 25
b. Conception 25
c. Déploiement 31
6. Orchestration 32
CONCLUSION 35
Rapport du Projet de Fin d’Etudes 2
ASR 2006/2007
Introduction :
Actuellement il y a un besoin imminent pour développer un système d'information
pour la gestion des feuilles de math pour les sports collectifs tels que le rugby, football ou
basket-ball au niveau amateurs. Ceci est dû au fait que dans la procédure mise en place
actuellement, la gestion et la diffusion des résultats et des classements des équipes n'est
pas immédiate et nécessite beaucoup d'efforts. Dans notre travail on s'est focalisé sur le
développement du processus de remplissage d'une feuille de match de rugby.
L’objectif de notre projet est donc le développement d’une application Rugby
Match Management. Cette application est composée de plusieurs services web assurant la
gestion et la prise en charge des taches administratives des différents intervenants lors
d’un match de Rugby (Arbitre, représentants des clubs, fédération…), ainsi que d’un
service web général d’orchestration de ces différents services.
Cette application a pour objectif de remplacer le système actuel basé sur le
remplissage manuel de plusieurs copies de la feuille de match et qui s’avère très lent et
assez compliqué. Elle accélère au final la gestion, la mise à jour centralisée des résultats
et des classements, pour que les joueurs, les dirigeants et le public puissent prendre
connaissance rapidement des résultats des autres équipes.
Dans notre rapport, nous allons présenter la modélisation du problème et des acteurs
ainsi que le scénario de remplissage de la feuille de match. Par la suite nous allons
présenter les étapes de développement et de mise en œuvre de notre application : nous
allons donc présenter les outils de développement et de travail ainsi que la manière de
l’exploiter. Nous allons conclure avec une démonstration.
Rapport du Projet de Fin d’Etudes 3
ASR 2006/2007
I. PRESENTATION
1. Les acteurs:
Dans cette section nous allons présenter les différents acteurs qui interviennent dans
le processus de gestion de la feuille de math.
• Arbitre: il vérifie les licences, valide la feuille de match, note les cartons, signe la
feuille et envoie le résultat partiel après la fin du match à la fédération régionale.
• Responsable Club: il remplie la feuille de match par sa liste de joueurs et la valide
après être livrée par le délégué de la fédération.
• Délégué: il est désigné par la fédération, il note les différents évènements à savoir les
remplacements, les points, les fautes...
• Fédération: elle fournie les informations nécessaires à l'arbitre, le délégué, les joueurs
et les clubs et met à jour les résultats et les classements.
2. Scénario principal :
Ce scénario décrit les interactions entre les différents acteurs: la fédération, l'arbitre
du match, le délégué et les responsables clubs.
• L'Arbitre reçois une notice pour assister au match.
• Les Responsables des Clubs local et visiteur reçoivent les licences des joueurs
suspendus.
• Arrivant sur le terrain l'Arbitre rempli sa partie de la feuille de match.
• Ensuite le Délégué rempli sa partie.
• Après c'est au Responsable du Club Local et le Responsable du Club Visiteur de
remplir leur parties.
• L'Arbitre vérifie et valide la feuille du match pour donner ensuite le signal de début
du match.
• Au cours du match le Délégué note les événements qui se sont produits: le
remplacements, les fautes...
• L'Arbitre note aussi toute mal conduite et en fait un rapport.
Rapport du Projet de Fin d’Etudes 4
ASR 2006/2007
• Enfin la feuille de math sera signée par les Responsables des Clubs, ensuite elle sera
validée par l'Arbitre et envoyée à la Fédération.
Vue globale de la gestion d’un match
3. Modèle UML:
Dans cette section nous allons décrire le Méta Modèle du processus de composition
des services web. Le modèle proposé suit la spécification UML 2.0 incluant une section
pour la modélisation des services distribués:définition et déploiement.
a. Formalisme et Définitions:
Un objet interagit pour implémenter un comportement. On peut décrire cette
interaction de deux manières complémentaires: l'une est centrée sur des objets
individuels (diagramme d'états transitions) et l'autre sur une collection d'objets qui
coopèrent (diagramme d'interaction).
La spécification d'un diagramme d'états transitions est précise et conduit
immédiatement au code. Elle ne permet pas pour autant d'expliquer le fonctionnement
global d'un système, car elle se concentre sur un seul objet à la fois. La vue d'ensemble
de l'interaction offre une vue plus générale du comportement d'un jeu d'objets.
Rapport du Projet de Fin d’Etudes 5
ASR 2006/2007
Les diagrammes d'interaction permettent d'établir un lien entre les diagrammes de
cas d'utilisation et les diagrammes de classes: ils montrent comment des objets
communiquent pour réaliser une certaine fonctionnalité. Ils apportent un aspect
dynamique à la modélisation du système. UML permet de décrire un comportement
limité à un contexte précis de deux façons dans le cadre d'un classeur structuré ou dans
celui d'une collaboration.
• Classeur Structuré:
Les classes découvertes au moment de l’analyse (celles qui figurent dans le
diagramme de classes) ne sont pas assez détaillées pour pouvoir être implémentées par
des développeurs. UML propose de partir des classeurs découverts au moment de
l’analyse (tels que les classes, les sous-systèmes, les cas d'utilisations,...) et de les
décomposer en éléments suffisamment fins pour permettre leur implémentation. Les
classeurs ainsi décomposés s'appellent des classeurs structurés.
• Collaboration:
Une collaboration montre des instances qui collaborent dans un contexte donné
pour mettre en oeuvre une fonctionnalité d'un système.
• Composant:
UML 2.0 spécifie un composant comme étant une unité modulaire, réutilisable qui
interagit avec son environnement par l’intermédiaire de points d’interactions appelés
ports.
Structure externe d’un composant
Rapport du Projet de Fin d’Etudes 6
ASR 2006/2007• Port :
Un port permet de spécifier les points d'interactions d'un objet : soit entre l'objet et
son environnement, soit entre l'objet et sa décomposition interne. Les ports sont reliés
au moyen de connecteurs sur lesquels transitent les messages permettant de déclencher
le comportement des objets. Un port indique les interfaces proposées par l'objet
(realized) ainsi que les interfaces requises (required).
• Signal:
Un signal est un type de message pouvant être échangé entre deux objets. Il se
distingue du concept d'opération : en effet, le signal est asynchrone. Un signal peut
transporter des données, ces données sont spécifiées au moyen des paramètres du
signal.
Le signal dispose donc de deux caractéristiques : son nom, ses attributs (ou
paramètres).
4. Modèle :
Dans notre scénario chaque service délivré par les différents acteurs est modélisé
par un composant ayant un comportement : l'Arbitre, Fédération, Club Local, Club
Visiteur et le délégué. Le processus principal de gestion du match est considéré comme
un composant avec des ports (arbitre, fédération, délégué...) qui invoque les services
distants.
La figure suivante illustre la structure externe du composant Match Management
Process. Ce composant possède un port de comportement qui invoque son
comportement intérieur à la réception d'un signal ou d'une invocation.
Rapport du Projet de Fin d’Etudes 7
ASR 2006/2007Modélisation du composant : Processus de gestion du match Cette figue montre la structure externe du Délégué. Ce composant possède un port de comportement et deux interfaces pour la réception des signaux et la notification des mouvements du match. Rapport du Projet de Fin d’Etudes 8 ASR 2006/2007
• Le Délégué
En ce que concerne les joueurs un capteur de mouvement est placé dans leurs
chaussures pour donner l'identifiant du joueur lors d'un remplacement. Aussi l'Arbitre
envoie un signal si le joueur se comporte mal sur le terrain et pour les tirs, penalties,
début et fin du match.
L'arbitre a plusieurs comportements: le premier est la vérification de la feuille du
math pour la validation des licences des joueurs, le deuxième est la gestion du match.
La figure nous montre les interfaces et le port du comportement du processus
Arbitre :
• L’Arbitre
Les interactions entre les composants sont gouvernées par un modèle de
collaboration. Dans ce modèle chaque structure possède un comportement et elles sont
connectées entre elles par des connecteurs
La figue montre une collaboration entre les composant du Match Management
Process. Ce processus est connecté à l'Arbitre, la Fédération, Le Club Local et le Club
Visiteur ainsi que le Délégué.
Rapport du Projet de Fin d’Etudes 9
ASR 2006/2007Diagramme de collaboration
La figue suivante représente le diagramme d'activité du Match Management
Process. Ce diagramme correspond au scénario principal décrit précédemment dans le
paragraphe (ajouter le nom du paragraphe)
Rapport du Projet de Fin d’Etudes 10
ASR 2006/2007Rapport du Projet de Fin d’Etudes 11 ASR 2006/2007
II. MISE EN ŒUVRE
1. Outils de travail
Dans cette partie nous allons présenter les outils de travail que nous
avons utilisés au cours de notre projet.
a. ORCHESTRA
Orchestra est un moteur d'Orchestration de Service Web conçu par Bull
et conforme au standard BPEL pour la définition et l'exécution de processus
métier. Orchestra est une application J2EE et profite donc des
fonctionnalités du serveur d’application JOnAS pour la montée en charge, la
gestion des transactions et la persistance.
Cet outil offre plusieurs fonctionnalités dont un éditeur de BPEL
(Zenflow), une console d’administration et un outil de monitoring en temps
réel.
Cet outil est disponible en version open source et peut être téléchargé sur
l’adresse suivant (http://www.bullopensource.org/)
Nous avons travaillé avec la version 2.4.2.
b. AXIS
Axis est un outil développé par la fondation Apache écrit en java
conforme au protocole SOAP ("Simple Object Access Protocol").
Cet outil permet de créer, de déployer et d’héberger des services web.
Axis peut être utilisé avec tout serveur d’application J2EE.
Cet outil est disponible en version open source et peut être téléchargé sur
l’adresse suivante (http://ws.apache.org/axis/).
2. Environnement de travail
Dans cette partie nous allons présenter l’environnement de
développement requis pour la construction de notre application.
a. Pré-requis pour ORCHESTRA :
• Coté logiciel :
Rapport du Projet de Fin d’Etudes 12
ASR 2006/2007o Java Development Kit (jdk) 1.4 ou ultérieur qu’on peut récupérer
sur l’adresse suivante (http://java.sun.com/j2se/1.4/ ).
Nous avons travaillé avec la version 1.4.2_04.
o Un serveur d’application JOnAS version 4.6.6. ou ultérieur qu’on
peut récupérer sur l’adresse suivante
(http://jonas.objectweb.org/download/index.html).
Nous avons travaillé avec la version 4.7.7.
o Télécharger JOnAS 4.6.6 release build (jonas4.6.6-
tomcat5.5.12.tgz pour la plateforme Linux®). La procédure
d’installation de JOnAS est expliquée sur
http://jonas.objectweb.org/current/doc/howto/install_j2ee.html
• Coté matériel:
o Il est recommandé d’avoir un processeur de 1 GHz avec 512 Mo
de RAM
b. Pré-requis pour Axis :
o J2SE SDK qu’on peut récupérer sur l’adresse suivante
(http://java.sun.com/j2se/1.4/ ).
Nous avons travaillé avec la version 1.4.2_04.
o Un conteneur de Servlet comme celui d'Apache Tomcat ou un
autre serveur d'application J2EE.
Dans notre travail nous avons utilisé la version 4.1.18 de Tomcat,
qu’on peut récupérer sur l’adresse suivante
(http://tomcat.apache.org/ )
3. Installation
Dans cette partie nous allons présenter la démarche d’installation du
moteur d’orchestration Orchestra et d’Axis.
a. ORCHESTRA
Pour installer Orchestra, il faut suivre les étapes suivantes :
• Téléchargez Orchestra sur l’adresse suivante :
http://www.bullopensource.org/.
• Commencez par copier le fichier BSOA_Orchestra_'version'.tgz
sur votre disque.
Rapport du Projet de Fin d’Etudes 13
ASR 2006/2007• Décompressez l’archive avec la commande
tar zxvf BSOA_Orchestra_'version'.tgz
• Cette opération crée un répertoire nommé
BSOA_Orchestra_'version'/ qui représente Bsoa_Repository.
• Assurez vous que vos variables d’environnement JAVA_HOME,
ANT_HOME et JONAS_ROOT sont bien définies.
• Définissez la variable d’environnement JONAS_BASE avec
l’adresse ou vous voulez mettre vos fichiers de configuration.
• Définissez la variable d’environnement BPEL_HOME avec
l’adresse suivante : " Bsoa_Repository /BPEL".
• Assurez vous que votre PATH contient $BPEL_HOME/bin/unix,
$JAVA_HOME/bin, $ANT_HOME/bin et
JONAS_ROOT/bin/unix.
• Mettez vous dans le répertoire ou vous avez extrait BSOA et
tapez la commande :
./install.sh
• Pour démarrer ou arrêter Orchestra, on utilise les commandes
suivantes :
o Pour démarrer BSOA :
bsoap start
o Pour arrêter BSOA :
bsoap stop
• Pour accéder à la console d’administration de l’outil, il faut le
démarrer puis aller sur l’adresse suivante
http://localhost:9000/jiapAdmin
(http://:/jiapAdmin)
(User Name = bsoa et Password = bsoa )
Rapport du Projet de Fin d’Etudes 14
ASR 2006/2007b. AXIS :
Pour installer Axis, il faut suivre les étapes suivantes :
• Télécharger Axis sur l’adresse suivante http://ws.apache.org/axis
.
• Extraire l’archive d’Axis.
• Copier le dossier webapps\axis dans le répertoire webapps de
Tomcat.
• Ajouter a votre classpath
o axisHome/lib/commons-discovery.jar
o axisHome/lib/commons-logging.jar
o axisHome/lib/jaxrpc.jar
o axisHome/lib/log4j-1.2.4.jar
o axisHome/lib/saaj.jar
o axisHome/lib/wsdl4j.jar
o axisHome/lib/axis.jar
Avec axisHome le répertoire d’axis.
• Lancer Tomcat.
• Vérifier votre déploiement en ouvrant l’adresse
suivante (http://localhost:8080/axis) sur votre navigateur.
A l’issu de ces étapes, nous avons mis en place l’environnement de travail avec
tous les outils nécessaires pour le développement.
Rapport du Projet de Fin d’Etudes 15
ASR 2006/20074. Services Web
La gestion du match de rugby nécessite, comme on vient de le voir dans la
présentation du projet, l’intervention de plusieurs acteurs. Ces différents acteurs
interagissent à travers des services web. Pour chaque acteur, nous avons développé
un service web que nous avons déployé sur Axis. Ces services web sont les
suivants:
• RegionalLeague :
Ce service web effectue les opérations réalisées par la fédération.
o getMatchReportForm : Cette opération crée la feuille de match
en y inscrivant la date et le nom de l’arbitre qui va diriger ce
match.
• Clubs :
Ce service web effectue les opérations réalisées par les deux clubs.
o fill : Chaque club doit remplir sa partie dans la feuille de match
avant le début de celui-ci. Cette opération permet d’inscrire lors
de son premier appel le nom de la première équipe et lors du
deuxième appel celui de la deuxième équipe.
• Referee :
Ce service web effectue les opérations de l’arbitre qui sont les suivantes :
o check : Vérification de la feuille de match. Cette opération prend
en entrée la feuille de match fournie par la fédération et remplie
par les deux Clubs. A la fin de cette opération la variable isOk
prend la valeur TRUE.
o refereeMatchResult : Cette opération simule l’enregistrement du
score du match par l’arbitre. Elle renvoi un MatchResult qui
contient le score du match et qui va être intégrée par la suite dans
la feuille de match.
Rapport du Projet de Fin d’Etudes 16
ASR 2006/2007o integrateMatchResult : Cette opération effectue l’intégration du
résultat du match MatchResult dans la feuille de match. Elle
prend en entrée le MatchResult fourni par l’arbitre ainsi que la
feuille de match qu’il possède. Cette opération fourni une feuille
de match qui contient le résultat du match.
o buildFinalMRF : Cette opération effectue la construction de la
feuille de match finale à partir de la feuille de match de l’arbitre
qui contient le résultat et de la feuille de match du délégué qui
contient les événement du match. C’est cette feuille de match
finale qui doit être envoyée à la fédération après la fin du match.
• Delegate :
Ce service effectue les opérations réalisées par le délégué.
o matchEventRegister : Cette opération enregistre les événements
qui ont lieu au cours du match dans la feuille de match.
Ces services utilisent deux structures de données qui sont :
• MatchReportForm : Cette classe contient toutes les informations
relatives au match et à son déroulement. Ainsi on y trouve :
o Referee
o Date
o Team1
o Team2
o MatchEvents
o isOk (validation de la feuille de match)
o MatchResult
• MatchResult : Cette classe contient le résultat du match.
a. Conception
Le développement des services web commence par la création d’un package
qui va contenir toutes les classes. Dans notre cas on utilise le dossier rmrf.
mkdir rmrf
cd rmrf
Rapport du Projet de Fin d’Etudes 17
ASR 2006/2007Dans ce dossier il faut créer les classes java des services web et implémenter
les différentes méthodes.
Les classes crées sont les suivantes :
• Les structures de données : ce sont les structures de données
échangées entre les services web qu’on vient de présenter et qui
contiennent le résultat et les différentes informations relatives au
déroulement du match.
o MatchReportForm.java :
package rmrf;
public class MatchReportForm {
private String Referee, Date, Team1, Team2, MatchEvents;
private MatchResult matchResult= new MatchResult();
private boolean isOk;
.............
//Constructeurs et methodes set et get pour récupérer et modifier les
variables
.........
}
o Match Result :
package rmrf;
public class MatchResult {
public String Result ;
public MatchResult() {
super();
Result="";
// TODO Auto-generated constructor stub
}
public String getResult() {
return Result;
}
Rapport du Projet de Fin d’Etudes 18
ASR 2006/2007public void setResult(String result) {
Result = result;
}
}
• Les services web : ce sont les classes qui implémentent les différents
services web présenté ci- dessus :
o RegionalLeague.java :
package rmrf;
public class RegionalLeague {
// Méthode qui crée la feuille de match en y inscrivant la date
// et le nom de l’arbitre
public MatchReportForm getMatchReportForm(String RefereeName,
String Date){
MatchReportForm mrf = new MatchReportForm();
mrf.setDate(Date);
mrf.setReferee(RefereeName);
return mrf;
}
}
o Clubs.java :
package rmrf;
public class Clubs {
// Méthode qui enregistre le nom de l’équipe dans la partie
// réservée dans la feuille de match.
public MatchReportForm fill(MatchReportForm mrf){
if
z(mrf.getTeam1().equals(null)||mrf.getTeam1().equals(""))
mrf.setTeam1("Team1");
else mrf.setTeam2("Team2");
return mrf;
}
}
Rapport du Projet de Fin d’Etudes 19
ASR 2006/2007o Referee.java :
package rmrf;
public class Referee {
// Méthode check qui affecte la valeur true a la variable isOk
// de la feuille de match , elle représente la validation
// de celle-ci par l’arbitre
public MatchReportForm check(MatchReportForm mrf){
mrf.setOk(true);
return mrf;
}
// Méthode qui enregistre le résultat du match dans la feuille
// du match
public MatchReportForm integrateMatchResult(MatchReportForm
mrf, MatchResult matchResult){
mrf.setMatchResult(matchResult);
return mrf;
}
// Méthode qui retourne le résultat du match
public MatchResult refereeMatchResult(){
MatchResult matchResult = new MatchResult();
matchResult.setResult("24 - 17");
return matchResult;
}
// Methode qui enregistre les événements du match enregistrée
// par le délégué dans la feuille de match finale
public MatchReportForm buildFinalMRF(MatchReportForm mrfReferee,
MatchReportForm mrfDelegate){
mrfReferee.setMatchEvents(mrfDelegate.getMatchEvents());
return mrfReferee;
}
}
Rapport du Projet de Fin d’Etudes 20
ASR 2006/2007o Delegate.java :
package rmrf;
public class Delegate {
// Méthode qui enregistre les événements du match dans la
// feuille de match du délégué
public MatchReportForm matchEventRegister(MatchReportForm mrf){
mrf.setMatchEvents("Match Events");
return mrf;
}
}
Pour chaque service web on écrit un descripteur de déploiement qui va
permettre le déploiement de celui-ci sur le Axis.
Ces fichiers sont de la forme suivante (deploy.wsdd du service Referee) :
Rapport du Projet de Fin d’Etudes 21
ASR 2006/2007Ce fichier contient la description des différentes opérations fournies par
le service ainsi que la description des classes et des structures de données
d’entrées de sortie et l’emplacement des classes utilisées par ce service.
Rapport du Projet de Fin d’Etudes 22
ASR 2006/2007Ces fichiers peuvent être générées automatiquement à partir des classes
java à l’aide de l’éditeur eclipse ou bien à partir d’un wsdl à l’aide de l’outil
WSDL2java fourni avec Axis.
b. Déploiement
Pour déployer ces services web sur le serveur Axis, il faut commencer
par les déclarer dans le fichier de configuration du serveur :
« $axisHome/WEB-INF/server-config.wsdd ».
Pour cela, on se sert de l’outil d’administration d’Axis AdminClient avec
pour paramètre les descripteurs de déploiement de chaque service. La
commande à utiliser est la suivante :
java org.apache.axis.client.AdminClient deploy.wsdd
L’étape suivante consiste à copier le package qui contient les différentes
classes utilisées par les services après leur compilation dans le dossier
$axisHome/WEB-INF/classes/ des classes d’axis. Dans notre cas on copie
les classes Referee.class, Delegate.class, RegionalLeague.class, Clubs.class,
MatchReportForm.class et MatchResult.class dans le dossier
$axisHome/WEB-INF/classes/rmrf/.
Pour que le serveur prenne en compte les modifications qu’on vient de
réaliser, il faut le redémarrer. On peut donc soit redémarrer le serveur
d’application qui héberge Axis (Tomcat dans notre cas), ou bien recharger
Axis à partir de la console de gestion de Tomcat.
Pour avoir une orchestration en distribué, on a déployé ces services sur
quatre machines différentes de la salle B313.
Rapport du Projet de Fin d’Etudes 23
ASR 2006/2007c. Vérification
On peut vérifier le bon déroulement du déploiement en allant sur
l’adresse suivante sur le navigateur web :
http://localhost:8080/axis/servlet/AxisServlet .
Ces services sont accessibles sur des adresses du type :
http://localhost:8080/axis/services/ .
A la fin de cette étape, nous avons les services web nécessaires pour la gestion
du match. Dans la prochaine étape, nous allons développé le processus métier principal
de notre application qui va faire appel à ces différents services web.
Rapport du Projet de Fin d’Etudes 24
ASR 2006/20075. BPEL
a. Présentation
Le BPEL, Business Process Execution Language, est un langage
d'exécution des processus métier qui définit les règles de dialogue entre
services Web.
C’est une représentation XML d’un processus métier (workflow) qui
représente des envois de messages, des appels de fonctions, des
transformations de données et des dialogues entre différents services web.
Le fichier BPEL est lisible par les moteurs de gestion des processus
métiers (dans notre cas on utilise Orchestra) qui se chargeant d'appliquer les
règles du fichier en question. Sans BPEL, les services Web ne pourraient pas
dialoguer entre eux.
Un processus BPEL dispose par ailleurs de sa propre définition WSDL :
tout processus BPEL est un service web à part entière.
b. Conception
Dans cette étape on a utilisé l’outil ZENFLOW fourni par Orchestra en
application indépendante et en plugin pour eclipse.
Cet outil est un éditeur graphique de fichiers BPEL. Il permet de
construire, de modifier et de visualiser des processus BPEL. Zenflow fournit
aussi des interfaces pour créer et définir des variables, des partenaires et
pour lier le fichier BPEL avec des fichiers WSDL, ce qui facilite
énormément la construction du BPEL.
La première étape de la conception du BPEL est la récupération des wsdl
de différents services web. Ceux-ci peuvent être générées automatiquement
en rajoutant a l’adresse de chaque service « ?wsdl ». Pour le service web
Referee on récupère le wsdl sur l’adresse
http://localhost:8080/axis/services/Referee?wsdl . On récupère les autres
wsdl de la même manière et on peut passer à la conception du BPEL
Par la suite il faut passer à la préparation du wsdl et du fichier
partnerlinktype qui est un fichier wsdl comprenant l’ensemble des
références des ports que le BPEL va utiliser pour faire appel aux différents
services utilisés.
Rapport du Projet de Fin d’Etudes 25
ASR 2006/2007Les fichiers qu’on a utilisés dans notre cas sont les suivants :
• Match.wsdl :
Rapport du Projet de Fin d’Etudes 26
ASR 2006/2007• Partnerlinktype.wsdl : Rapport du Projet de Fin d’Etudes 27 ASR 2006/2007
• Importer les fichiers wsdl : cette étape permet au processus BPEL, à
l’aide du « targetNamespace » d’avoir une visibilité sur les types
des messages et opérations définies dans les services web cibles.
• Créer les variables : ce sont des variables globales au processus
PBEL qui vont permettre l’échange de messages entre les différents
services web au cours de son exécution
• Définir les partnerlink : Dans cette étape on définit les associations
entre les services web utilisés et les ports qui vont permettre au
processus BPEL de les invoquer au cours dans son exécution.
• Edition du processus BPEL : dans cette étape on définit les différents
appels de méthodes, échanges de données et séquences
d’événements qui représente la gestion du match de rugby. Ici on a
la représentation graphique finale de l’orchestration.
Rapport du Projet de Fin d’Etudes 28
ASR 2006/2007Rapport du Projet de Fin d’Etudes 29 ASR 2006/2007
Cette Orchestration correspond au diagramme suivant :
RefereeName
Date RegionalLeague
getMatchReportForm
fill Local Club
fill
Visitor Club
Referee
check
Delegate
Referee
refereeMatchResult
matchEventRegister
integrateMatchResult
Referee
buildFinalMRF
Web Service
Rapport du Projet de Fin d’Etudes 30
ASR 2006/2007L’orchestration commence par l’appel du service web de la fédération
(RegionalLeague) qui reçoit la date du match ainsi que le nom de l’arbitre et
qui renvoi la feuille de match, l’opération invoquée est
« getMatchReportForm ». Cette feuille est par la suite transférée au club
local puis au club visiteur (Clubs) qui vont y inscrire les noms des deux
équipes, l’opération invoquée est « fill ». Ensuite on passe à la validation de
cette feuille de match par l’arbitre (Referee) et on fait appel à l’opération
« check » avant le début du match. Quand le match commence, l’arbitre et le
délégué possède chacun une copie de la feuille de match qui vient d’être
validée par l’arbitre. Durant le match, le délégué (Delegate) y inscrit les
événements « matchEventRegister » et l’arbitre y inscrit le résultat
« refereeMatchRestult » et « integrateMatchResult ». A la fin du match,
l’arbitre construit la feuille de match finale en ajoutant les événements du
match enregistrés par le délégué dans sa feuille de match qui contient le
résultat « buildFinalMRF ». Ainsi à la fin du match, qui correspond à la fin
de l’orchestration, on reçoit une feuille de match remplie qu’on peut
envoyer à la fédération.
c. Déploiement
• Pour le déploiement il faut commencer par créer un dossier match dans
le dossier $BPEL_HOME/samples/
• Copier les fichiers match.wsdl, match.bpel, partnerlinktype.wsdl dans le
dossier $BPEL_HOME/samples/match/
• Créer un dossier wsdl dans le dossier $BPEL_HOME/samples/match/
Copier les wsdl des services web dans le dossier
$BPEL_HOME/samples/match/wsdl/
Il faut bien vérifier les chemins des fichiers wsdl des services web dans
la partie import du wsdl du BPEL, il faut bien veiller mettre le chemin
absolu de chaque wsdl.
$BPEL_HOME doit être remplacée par sa vrai valeur dans ce fichier :
Rapport du Projet de Fin d’Etudes 31
ASR 2006/2007• Par la suite il faut lancer bsoa et lancer le déploiement en tapant les
commandes suivantes :
bsoap start
bsoap deploy -p match -samples
$BPEL_HOME/samples/match/wsdl/Referee.wsdl
$BPEL_HOME/samples/match/wsdl/Clubs.wsdl
$BPEL_HOME/samples/ match/wsdl/RegionalLeague.wsdl
$BPEL_HOME/samples/ match/wsdl/Delegate.wsdl
On peut vérifier que le déploiement s’est bien déroulé sur la console d’administration
d’Orchestra.
6. Orchestration
Pour lancer l’orchestration, il faut démarrer les services web sur les différentes
machines où ils sont déployés.
Par la suite il faut lancer Orchestra et s’assurer que bsoa n’est pas démarré sur
aucune des autres machines.
Pour exécuter le fichier BPEL nous allons utiliser la Console d’Administration
d’Orchestra. Pour accéder à cette console, nous nous connectons sur cette adresse
URL http://:/jiapAdmin et nous entrons le login et mot de passe.
Ensuite nous accédons à la liste des processus déjà déployés et en attente
d’exécution. Après la sélection du processus concerné (match) un formulaire
apparaît pour saisir les paramètres d’entrées du processus et on lance l’exécution.
Rapport du Projet de Fin d’Etudes 32
ASR 2006/2007On peut visualiser le déroulement de l’orchestration à l’aide de l’outils Bpem
fourni avec ORCHESTRA. Cet outil nous permet la visualisation dynamique et
temps réel du processus BPEL qui est en cours d’exécution ainsi que l’analyse des
l’état final des informations pour ce processus à l’issu de son exécution.
Pour la lancer il faut utiliser la commande : bsoap bpem .
Rapport du Projet de Fin d’Etudes 33
ASR 2006/2007Le résultat de l’exécution s’affiche sur la console et vérifie bien que la
gestion du match de rugby s’est bien déroulée.
Rapport du Projet de Fin d’Etudes 34
ASR 2006/2007CONCLUSION :
L’utilisation du moteur Orchestra a apporté donc une couche d’abstraction de la
logique d’orchestration pour chaque service Web impliqué. Cette couche
supplémentaire a bien entendu un coût le rendant surtout intéressant pour les
orchestrations complexes.
Cela étant, la version actuelle de BPEL ne peut non plus être utilisée pour les
orchestrations trop complexes, où de nouveaux services ou activités peuvent être rendus
nécessaires en cours de traitement. Un outil du quotidien, donc, mais qui ne peut pas
remplacer l'apport humain.
Ce projet a été une occasion pour approfondir nos acquis sur les services web et
de voir de plus près les problématiques de développement, de déploiement et de
construction d’une architecture orientée service (SOA). Nous avons aussi eu l’occasion
de vivre des situations proches des situations de travail dans le monde professionnel.
Rapport du Projet de Fin d’Etudes 35
ASR 2006/2007Vous pouvez aussi lire
