RUGBY MATCH MANAGEMENT - Encadrants : Chantal Taconet Frédérick Seyler KHAIREDDINE Mohamed Abderrahmene BOUKDHIR Walid

 
RUGBY MATCH MANAGEMENT - Encadrants : Chantal Taconet Frédérick Seyler KHAIREDDINE Mohamed Abderrahmene BOUKDHIR Walid
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
RUGBY MATCH MANAGEMENT - Encadrants : Chantal Taconet Frédérick Seyler KHAIREDDINE Mohamed Abderrahmene BOUKDHIR Walid
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
RUGBY MATCH MANAGEMENT - Encadrants : Chantal Taconet Frédérick Seyler KHAIREDDINE Mohamed Abderrahmene BOUKDHIR Walid
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
RUGBY MATCH MANAGEMENT - Encadrants : Chantal Taconet Frédérick Seyler KHAIREDDINE Mohamed Abderrahmene BOUKDHIR Walid
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
RUGBY MATCH MANAGEMENT - Encadrants : Chantal Taconet Frédérick Seyler KHAIREDDINE Mohamed Abderrahmene BOUKDHIR Walid
• 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
RUGBY MATCH MANAGEMENT - Encadrants : Chantal Taconet Frédérick Seyler KHAIREDDINE Mohamed Abderrahmene BOUKDHIR Walid
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/2007
Modé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/2007
Diagramme 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/2007
Rapport 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/2007
o 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/2007
b. 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/2007
4. 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/2007
o 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/2007
Dans 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/2007
public 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/2007
o 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/2007
o 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/2007
Ce 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/2007
Ces 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/2007
c. 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/2007
5. 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/2007
Les 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/2007
Rapport 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/2007
L’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/2007
On 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/2007
Le 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/2007
CONCLUSION :

           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/2007
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler