Thèse UNLANGAGEETUNENVIRONNEMENT

université paris dauphineLaboratoire LAMSADE

N° attribué par la bibliothèque

ThèsePour l'obtention du titre de

DOCTEUR EN INFORMATIQUE(Arrêté du 7 août 2006)

Spécialité : informatique

UN LANGAGE ET UN ENVIRONNEMENTDE CONCEPTION ET DE DEVELOPPEMENT DE

SERVICES WEB COMPLEXES

Demba COULIBALY

JURYDirecteur de thèse : Serge HADDAD

Professeur, ENS Cachan

Rapporteurs : Fabrice KORDONProfesseur, Université Paris 6Laure PETRUCCIProfesseur, Université Paris Nord

Examinateurs : Jean-François PRADAT-PEYREProfesseur, Université Paris Ouest Nanterre la défense (Paris X)Céline BOUTROUS-SAABMaître de Conférence, Université Paris DauphineLynda MOKDADMaître de Conférence, Université Paris Dauphine

Présentée et soutenue publiquement le 5 juin 2009

L'université n'entend donner aucune approbation ni improbation aux opinions émisesdans les thèses : ces opinions doivent être considérées comme propres à leurs auteurs.

i

À mon épouse et mes enfants.À mon père, à ma mère,À mes s÷urs et frères,À mes grands parents.

ii

Remerciements

Mes meilleurs remerciements vont d'abord à mon directeur de thèse, le Professeur SergeHADDAD, et à ma co-encadrante Madame Céline BOUTROS-SAAB pour leur suivi,soutien et conseils judicieux tout au long de cette thèse. Monsieur Serge HADDAD estProfesseur à l'Ecole Normale Supérieure de Cachan et Madame Céline BOUTROUS-SAAB est Maître de Conférence à l'Université Paris-Dauphine.

Mes remerciements vont aux rapporteurs les Professeurs Fabrice KORDON et LaurePETRUCCI pour avoir accepter de rapporter ce travail de recherche. Leurs conseils, re-marques et critiques m'ont permis d'améliorer considérablement ce document.

Mes remerciements vont également aux membres du jury le Professeur Jean-FrançoisPRADAT-PEYRE de l'université Paris Ouest Nanterre La Défense, Madame LyndaMOKDAD, Maître de Conférence à Paris-Dauphine pour avoir accepté de faire partiede mon jury de thèse.

Mes remerciements vont à Messieurs Tarek MELLITI du laboratoire IBISC et Jean-Baptiste VORON du laboratoire LIP6 qui, par leurs conseils, m'ont appuyé dans le dé-veloppement du langage. Qu'ils trouvent ici ma plus grande gratitude.

Je remercie le Service de la Coopération et de l'Action Culturelle de l'ambassade deFrance au Mali, le Ministère des A�aires Étrangères de la France et à travers lui, lecontribuable français, pour le �nancement de cette thèse.

Je remercie in�niment le Professeur SIBY Ginette BELLEGARDE pour ses encourage-ments et soutien moral durant toute la période de la réalisation de ce travail de recherche.Le Professeur SIBY Ginette BELLEGARDE est le Recteur de l'université de Bamako.Je remercie Monsieur Lansina SIDIBE, professeur d'économie à l'université de Bamako,le Professeur Jean-François CASTA de l'université Paris Dauphine pour m'avoir aidé àtrouver une inscription en thèse. Mes remerciements vont aussi à la Direction de l'Insti-tut Universitaire de Gestion de Bamako et plus précisément à son Directeur le ProfesseurIssiaka Ahmadou SINGARE pour le soutien �nancier à ma famille pendant mes missions.En�n mes remerciements vont à mes collègues Macki SAMAKE, Bakary CISSE pourleurs conseils et encouragements.

Des enseignants qui m'ont marqué par leurs competence, discipline, et gentillesse : Mon-sieur Baba COULIBALY, Monsieur Thiompé COULIBALY enseignants à Bamako, Mon-

iii

sieur Valentin Nikitovitch EFFIMETS de l'Institut d'Aviation Civile de Kiev, qu'ilstrouvent ici ma plus grande gratitude.

Je remercie mes collègues du LAMSADE et plus particulièrement M. Samir YOUCEF etM. Salem CHAKAR pour leurs conseils et soutien.

Je termine mes remerciements par ceux adressés au laboratoire LAMSADE et à l'écoledoctorale EDDIMO de l'université Paris-Dauphine qui m'ont accueilli en leur sein. C'estpour dire merci à tout le personnel de ces deux institutions et particulièrement aux pre-miers responsables les Professeurs Cristina BAZGAN et Vangelis PASCHOS.

Table des matières

1 Introduction Générale 11.1 Position du problème et objectifs . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Position du problème . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Plan du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

I ETAT DE L'ART 7

2 Composition de services web 92.1 Les technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 XML (eXtensible Markup Language) . . . . . . . . . . . . . . . . . 102.1.2 Les services web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

L'architecture orientée service . . . . . . . . . . . . . . . . . . . . . 12Le protocole SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 13Le référentiel UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . 14Le langage de description WSDL . . . . . . . . . . . . . . . . . . . 16Invocation d'un service web . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Les langages de composition des services web . . . . . . . . . . . . . . . . 212.2.1 Composition des services web . . . . . . . . . . . . . . . . . . . . . 212.2.2 Le langage ebXML . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.3 Le langage XLANG . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.4 Le langage WSFL . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.5 Le langage BPEL4WS . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.6 Le langage BPELJ . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.7 Discussion sur les langages de composition . . . . . . . . . . . . . . 32

2.3 Les plates-formes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.1 La plate-forme .NET de Microsoft . . . . . . . . . . . . . . . . . . 36

Dé�nitions et principes . . . . . . . . . . . . . . . . . . . . . . . . . 36

vi TABLE DES MATIÈRES

Architecture générale et concepts . . . . . . . . . . . . . . . . . . . 372.3.2 La plate-forme J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Dé�nitions et principes . . . . . . . . . . . . . . . . . . . . . . . . . 40Architecture générale et concepts . . . . . . . . . . . . . . . . . . . 41

2.3.3 Comparaison de .Net et J2EE . . . . . . . . . . . . . . . . . . . . . 432.3.4 Oracle BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.3.5 ActiveBPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3 Méthodologies UML de conception d'applications coopératives 513.1 Etat de l'art sur les méthodologies de conception d'application . . . . . . 52

3.1.1 Les méthodes cartésiennes . . . . . . . . . . . . . . . . . . . . . . . 523.1.2 Les méthodes systématiques . . . . . . . . . . . . . . . . . . . . . . 543.1.3 Les méthodes assistées par des outils . . . . . . . . . . . . . . . . . 563.1.4 Les méthodes orientées objets . . . . . . . . . . . . . . . . . . . . . 57

3.2 Le langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.2.1 Les diagrammes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.2.2 Avantages et inconvénients . . . . . . . . . . . . . . . . . . . . . . . 723.2.3 Comparaison avec les autres méthodologies . . . . . . . . . . . . . 74

3.3 Applications coopératives . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.3.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 823.3.2 Méthodologies UML de conception d'applications coopératives . . 83

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

II CONTRIBUTIONS 87

4 Le langage JCWSL (Java Complex Web Service Language) 894.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.2 Description du langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.2.1 Notions de BNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.2.2 La BNF de JCWSL . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.3.1 Les importations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.3.2 La dé�nition du service web complexe . . . . . . . . . . . . . . . . 1014.3.3 Les variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1024.3.4 Gestion des erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.4 Génération des analyseurs et d'un service web . . . . . . . . . . . . . . . . 1034.4.1 Génération des analyseurs du langage JCWSL . . . . . . . . . . . . 103

TABLE DES MATIÈRES vii

4.4.2 Génération d'un service web avec JCWSL . . . . . . . . . . . . . . 105Génération du comportement observable . . . . . . . . . . . . . . . 107Présentation de Apache Axis . . . . . . . . . . . . . . . . . . . . . 109Génération du module exécutable . . . . . . . . . . . . . . . . . . . 111

4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

5 Une plate-forme de composition de services web 1195.1 Architecture de la plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.1.1 L'interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.1.2 Le compilateur JCWSL : . . . . . . . . . . . . . . . . . . . . . . . . 122

5.2 Conception de la plate-forme CWSE . . . . . . . . . . . . . . . . . . . . . 1235.2.1 Présentation de l'outil GEF . . . . . . . . . . . . . . . . . . . . . . 1235.2.2 Conception de l'environnement CWSE . . . . . . . . . . . . . . . . 124

5.3 Cycle de développement d'une application dans CWSE . . . . . . . . . . . 1325.3.1 Principe de conception . . . . . . . . . . . . . . . . . . . . . . . . . 1325.3.2 Manuel utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6 Méthodologie de conception de services web - étude de cas 1396.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396.2 Méthodologie UML pour JCWSL . . . . . . . . . . . . . . . . . . . . . . . 139

6.2.1 Quelques rappels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1396.2.2 Processus itératif et incrémental . . . . . . . . . . . . . . . . . . . 1416.2.3 Processus centré sur l'architecture . . . . . . . . . . . . . . . . . . 1426.2.4 Processus piloté par les cas d'utilisation (CU) . . . . . . . . . . . . 1436.2.5 Présentation des diagrammes . . . . . . . . . . . . . . . . . . . . . 146

Les cas d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 146Le diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . 148Le diagramme d'activités . . . . . . . . . . . . . . . . . . . . . . . 152Le diagramme de séquences . . . . . . . . . . . . . . . . . . . . . . 156Le diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . 161

6.3 Etude de cas : reservation de billets auprès d'une agence de voyage . . . . 1616.3.1 Présentation de l'application . . . . . . . . . . . . . . . . . . . . . 1616.3.2 Etude conceptuelle du service . . . . . . . . . . . . . . . . . . . . . 163

Diagramme des cas d'utilisation . . . . . . . . . . . . . . . . . . . . 164Diagrammes des classes . . . . . . . . . . . . . . . . . . . . . . . . 164Diagramme d'activités . . . . . . . . . . . . . . . . . . . . . . . . . 167diagramme de séquences . . . . . . . . . . . . . . . . . . . . . . . . 169

6.3.3 Implémentation de l'étude de cas . . . . . . . . . . . . . . . . . . . 174

viii TABLE DES MATIÈRES

6.3.4 Le diagramme de déploiement . . . . . . . . . . . . . . . . . . . . . 1776.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

7 Conclusion et Perspectives 1797.1 Bilan des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1797.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Bibliographie 183

Annexes 190

Annexe A : Résolution d'une équation du second degré à une inconnue 193

Annexe B : Service web de jeu 199

Annexe C : Service web de reservation de place avec une compagnie aé-rienne 205

Annexe D : Exemple de service web sous CWSE 209

Table des �gures

2.1 Architecture des composants d'un service web . . . . . . . . . . . . . . . . 152.2 Architecture des registres UDDI . . . . . . . . . . . . . . . . . . . . . . . . 162.3 Structure d'un document WSDL . . . . . . . . . . . . . . . . . . . . . . . 202.4 Implémentation et Invocation d'un service web . . . . . . . . . . . . . . . 212.5 Structure d'un document XLANG . . . . . . . . . . . . . . . . . . . . . . 272.6 BPEL4WS et la pile de Protocoles . . . . . . . . . . . . . . . . . . . . . . 292.7 Architecture .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.8 Architecture en couches de J2EE . . . . . . . . . . . . . . . . . . . . . . . 41

3.1 Méthodes cartésiennes : Décomposition "TOP-DOWN" . . . . . . . . . . 533.2 Schéma d'un système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.3 Exemple de schéma conceptuel . . . . . . . . . . . . . . . . . . . . . . . . 563.4 L'architecture à quatre niveaux de l'OMG . . . . . . . . . . . . . . . . . . 593.5 Le diagramme de cas d'utilisation d'une application bancaire . . . . . . . 623.6 Extrait d'un diagramme de classes d'une application bancaire . . . . . . . 623.7 Exemple d'un diagramme de séquence d'UML1.x et ses concepts . . . . . 643.8 Le branchement conditionnel dans les diagrammes de séquence d'UML1.x 643.9 Une partie de méta-modèle des interactions dans UML1.5 . . . . . . . . . 653.10 Une partie du méta-modèle des diagrammes de séquence d'UML2.0 . . . . 673.11 Exemple d'un DS dans UML2.0 et ses concepts . . . . . . . . . . . . . . . 683.12 Exemple d'un diagramme de séquence combiné . . . . . . . . . . . . . . . 693.13 Exemple d'un diagramme de vue d'ensemble d'interaction dans UML2.0 . 703.14 Aspects structurels d'une collaboration . . . . . . . . . . . . . . . . . . . . 713.15 Aspects comportementaux d'une collaboration . . . . . . . . . . . . . . . . 723.16 Diagramme d'activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.17 Branchement conditionnel dans un diagramme d'activités . . . . . . . . . 743.18 Diagramme des �ux (MERISE) . . . . . . . . . . . . . . . . . . . . . . . . 773.19 Exemple de cas d'utilisation (UML) . . . . . . . . . . . . . . . . . . . . . 783.20 Modélisation d'un work�ow . . . . . . . . . . . . . . . . . . . . . . . . . . 85

x TABLE DES FIGURES

4.1 Structure de JCWSL en blocs . . . . . . . . . . . . . . . . . . . . . . . . . 1004.2 Structure du Bloc des importations de JCWSL . . . . . . . . . . . . . . . 1014.3 Structure du Bloc de dé�nition de JCWSL . . . . . . . . . . . . . . . . . . 1024.4 Principe de génération des analyseurs . . . . . . . . . . . . . . . . . . . . . 1054.5 Génération d'un service web complexe . . . . . . . . . . . . . . . . . . . . 1064.6 Diagramme des classes de la description d'un service web complexe . . . . 1084.7 Diagramme des classes du comportement d'un service web complexe . . . 1094.8 Échanges de données entre un client et un service . . . . . . . . . . . . . 116

5.1 La plate forme CWSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1205.2 Editeur Graphique de l'environnement CWSE . . . . . . . . . . . . . . . . 1215.3 La palette de l'environnement CWSE . . . . . . . . . . . . . . . . . . . . . 1225.4 La feuille de propriétés de l'environnement CWSE . . . . . . . . . . . . . 1225.5 L'architecture Model-View-Controller . . . . . . . . . . . . . . . . . . . . . 1255.6 DiagramEditPart principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.7 Schéma du modèle de l'environnement CWSE . . . . . . . . . . . . . . . . 1265.8 Mapping Graphe - Code JCWSL . . . . . . . . . . . . . . . . . . . . . . . 1345.9 Création de nouveau projet - première boîte de dialogue . . . . . . . . . . 1355.10 Création de nouveau projet - deuxième boîte de dialogue . . . . . . . . . . 1355.11 Création d'un graphe JCWSL - première boîte de dialogue . . . . . . . . . 1365.12 Création d'un graphe JCWSL - deuxième boîte de dialogue . . . . . . . . 137

6.1 Processus itératif (source : developpez.net) . . . . . . . . . . . . . . . . . . 1426.2 Processus centré architecture - vues 4+1 . . . . . . . . . . . . . . . . . . . 1426.3 Processus piloté par les cas d'utilisation . . . . . . . . . . . . . . . . . . . 1446.4 Diagramme de déploiement d'un service web complexe . . . . . . . . . . . 1456.5 Cas d'utilisation du service JeuxQuiz . . . . . . . . . . . . . . . . . . . . . 1486.6 Dé�nition des stéréotypes UML d'un service web en JCWSL . . . . . . . . 1496.7 Représentation des constructeurs simples de JCWSL en UML . . . . . . . 1506.8 Classe UML de l'importation du service basique Squiz . . . . . . . . . . . 1516.9 Classe UML de l'importation des API Java . . . . . . . . . . . . . . . . . 1516.10 Classe UML des messages NbQuestions et Response . . . . . . . . . . . . 1516.11 Classe UML de l'opération beginGame . . . . . . . . . . . . . . . . . . . . 1516.12 Classe UML de la dé�nition du service JeuxQuiz . . . . . . . . . . . . . . 1526.13 Dé�nition des classes du service web JeuxQuiz . . . . . . . . . . . . . . . . 1526.14 Illustration du constructeur While pour UML . . . . . . . . . . . . . . . . 1536.15 Illustration du constructeur Pick pour UML . . . . . . . . . . . . . . . . . 1546.16 Illustration du constructeur Flow pour UML . . . . . . . . . . . . . . . . . 154

TABLE DES FIGURES xi

6.17 Illustration du constructeur Switch pour UML . . . . . . . . . . . . . . . . 1546.18 Illustration du constructeur Scope pour UML . . . . . . . . . . . . . . . . 1556.19 Illustration du constructeur JavaCode pour UML . . . . . . . . . . . . . . 1556.20 Classe UML pour le comportement du service web JeuxQuiz . . . . . . . . 1556.21 Diagramme d'activités du service web JeuxQuiz . . . . . . . . . . . . . . . 1566.22 Diagramme d'activités du service web JeuxQuiz (suite) . . . . . . . . . . . 1576.23 diagramme de séquences du service web JeuxQuiz . . . . . . . . . . . . . . 1606.24 Diagramme de déploiement du service web JeuxQuiz . . . . . . . . . . . . 1616.25 Schéma du service web d'une agence de voyage . . . . . . . . . . . . . . . 1636.26 Diagramme de cas d'utilisation du service Travel . . . . . . . . . . . . . . 1646.27 Diagramme des classes du service Travel . . . . . . . . . . . . . . . . . . . 1676.28 Diagramme d'activités de la recherche d'un billet . . . . . . . . . . . . . . 1696.29 Diagramme d'activités de la réservation d'un billet . . . . . . . . . . . . . 1706.30 Diagramme d'activités de la réservation d'un billet et d'une chambre d'hôtel1716.31 Diagramme de séquences de la recherche d'un billet . . . . . . . . . . . . . 1726.32 Diagramme de séquences de la réservation d'un billet et d'une chambre

d'hôtel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1736.33 Diagramme de déploiement du service Travel . . . . . . . . . . . . . . . . 178

7.1 Diagramme du service JeuxQuiz . . . . . . . . . . . . . . . . . . . . . . . 2097.2 Code généré par le diagramme du service JeuxQuiz . . . . . . . . . . . . . 210

xii TABLE DES FIGURES

Chapitre 1

Introduction Générale

1.1 Position du problème et objectifsLes services web ont été introduits pour résoudre les problèmes d'interopérabilité des ap-plications hétérogènes rencontrés par DCOM et CORBA. Ils sont essentiellement baséssur la technologie Internet, car destinés à fonctionner sur Internet. Ces services web quiétaient mis en place par la dé�nition de leurs descriptions en WSDL (Web Service Des-cription Language), ont évolué avec l'évolution des besoins des entreprises. Une évolutionqui a entraîné leur sophistication et les a rendu complexes, car des nouveaux servicespeuvent être bâtis sur des services existants, d'où la notion de services web complexes.A la di�érence des premiers services, dont la mise en place était une description desopérations et messages échangés, les services web complexes demandent la mise en placed'une orchestration ou d'une chorégraphie dé�nissant l'agencement des services qui lescomposent.

1.1.1 Position du problème

Le développement de la technologie des services web complexes connaît aujourd'hui denouvelles formes d'interactions dont la mise en place nécessite des langages de composi-tions adaptés et facile à maîtriser.Bien que les langages existants avec au premier plan le langage BPEL (Business ProcessExecution Language for Web Services) permettent l'accomplissement des tâches de misene place de services web complexes, cette mise en place reste encore très di�cile à réaliser.Une di�culté dûe en grande partie au manque de maîtrise du langage BPEL. Ce manquede maîtrise s'explique par le fait que :

� BPEL est un langage de faible niveau d'expressivité comme langage de program-mation.

� BPEL est un langage di�cile d'apprentissage.� Les conditions d'exploitation de BPEL ne sont pas simples à mettre en ÷uvre.

2 Chapitre 1. Introduction Générale

1.1.2 Objectifs

Le problème ci-dessus annoncé a mis un frein à l'appropriation de BPEL par un grandnombre de développeurs. Les e�orts entrepris par les éditeurs et concepteurs du langageBPEL dans l'objectif de rendre la programmation en BPEL attractive ont permis la miseen place d'outils d'aide à la composition de services web complexes. Ces outils sont soitdes environnements de développement (Oracle BPEL et Active BPEL), soit des outils devalidation de code BPEL avant la mise en place sur un moteur BPEL.Les travaux de cette thèse ont pour objectif la mise en place d'un langage de composi-tion de services web complexes, avec une plate-forme qui permet de passer du modèlegraphique au code, tout en dé�nissant une méthodologie de conception basée sur UML.Nous déclinons nos les objectifs de notre langage en trois points : les qualités du langage,son intégration dans un environnement de développement et la convivialité de l'interfaceutilisateur de son environnement.

Qualités du langage : Sur le plan de la qualité, le langage se donne des objectifs enterme d'expressivité, d'apprentissage, d'extensibilité et de conditions d'exploitation.

� Expressivité : Le langage doit avoir un niveau d'expressivité comparable à celui deslangages de programmation courants, et qui permettra aussi d'exprimer le compor-tement d'un service web complexe. Cette expressivité facilitera son adoption par leplus grand nombre de développeurs.

� Apprentissage : Le langage doit être facile à apprendre et à utiliser. Cet objectifsera source d'appropriation du langage par un grand nombre de développeurs, toutechose qui manque aujourd'hui au langage BPEL.

� Extensibilité : En terme d'expressivité, le langage pourra béné�cier d'une certaineévolution facile, car il a une approche Objet des services web. Il sera un environne-ment extensible a�n de pouvoir intégrer de nouvelles fonctionalités. Incorporer sespropres outils, c' est donner la possibilité à chaque développeur de personnaliserson environnement de développement pour être le plus e�cace possible.

� Exploitation : Le langage ne doit pas requérir des composants matériels ou deslogiciels spéci�ques pour son exploitation. La réalisation d'un tel objectif permettraaux utilisateurs l'exploitation du langage sur des systèmes simples et diminuer ducoup les coûts d'utilisation de l'environnement qui l'accompagne.

Intégration du langage dans un environnement de développement : Le futurlangage, dont la conception fait l'objet du présent mémoire de thèse, sera intégré à unenvironnement de développement. Il intégrera alors des fonctionalités de conception gra-phique et génération automatique de code et vice versa. La conception graphique simpli�e

1.2 Contributions 3

beaucoup l'utilisation des outils de programmation.

Interface : Le langage utilisera une interface graphique et e�cace. L'interface seraconviviale avec une palette d'objets pour représenter les constructeurs du langage. Elleutilisera le système de � drag and drop �.

1.2 ContributionsLa problématique de cette thèse s'articule autour de la résolution des problèmes liés à ladi�culté d'appropriation des langages de composition de services web complexes et plusprécisément à celle de BPEL.Pour contribuer à la résolution du problème d'appropriation par un grand nombre dedéveloppeurs des langages de composition de services web complexes, nous proposonsun langage de composition. Ce langage sera basé sur les standards BPEL et Java. Ilcombinera les constructeurs BPEL à du code Java pur le tout dans le style d'une classeJava standard. Ainsi, le langage proposé sera à cheval sur BPEL et Java et béné�cierade la portabilité de BPEL, de l'expressivité et de la facilité d'apprentissage de Java. Lelangage proposé sera appelé Java Complex Web Service Language avec comme acronymeJCWSL.Le langage JCWSL sera accompagné d'un environnement graphique de développement.Pour rendre notre langage complet, nous proposons aussi une méthodologie UML pour laconception d'un service web complexe en JCWSL. La méthodologie mise en place s'appuiesur le Model Driven Architecture de UML pour choisir les diagrammes UML nécessaires àla conception a�n de proposer des stéréotypes pour chaque constructeur de notre langage.Ces contributions ont été développées dans la deuxième partie du mémoire qui est com-posée des chapitres 4, 5 et 6.Le chapitre 4 présente essentiellement le langage JCWSL en exposant ses concepts, sesprincipes ainsi que sa description formelle. Les di�érents constructeurs du langage JCWSLsont présentés avec des exemples à l'appui. Le chapitre se termine par trois exemples deservices web composés en JCWSL.Le chapitre 5 est consacré à l'étude et la mise en ÷uvre de l'environnement de dévelop-pement. Cet environnement a été conçu à l'aide d'un outil graphique d'Eclipse. Cet outilest appelé GEF (Graphical Editing Framework). L'utilisation de l'environnement pour lacomposition d'un service web consiste à créer un graphe représentant le service web avecla génération automatique de son code JCWSL. En substance, l'environnement créé estcomposé de trois éléments essentiels :

� l'espace de travail qui reçoit le graphe à créer� la palette d'outils de création des objets du graphe,


� la feuille de propriétés pour porter les propriétés de chaque objet créé.

Le chapitre 6 est consacré à la mise en place de notre méthodologie UML. En se basantsur le Model Driven Architecture de UML, nous avons dé�ni les diagrammes nécessaires àla conception d'un service web en JCWSL, nous avons proposé pour chaque constructeurJCWSL, et selon le type de diagramme, un stéréotype. Dans ce chapitre, un plan de miseen ÷uvre de la méthodologie a été établi. Le choix des diagrammes UML a été fait selonleur pertinence dans la mise en ÷uvre d'un service web. Ainsi, les diagrammes suivantsont été retenus : les cas d'utilisation, les diagrammes de classes, les diagrammes d'activitéet les diagrammes de séquences. En�n, un méta-modèle JCWSL en UML a été proposé.

1.3 Plan du mémoire

Nous avons structuré ce mémoire en deux parties.La première partie concerne l'état de l'art et est composée de deux chapitres.Le chapitre 2 présente une étude de synthèse sur les technologies de services web, les lan-gages de compositions des services web et les plates-formes de composition. Une attentionparticulière a été accordée au langage BPEL et sa modi�cation BPELJ car ils constituentpour le premier une des bases de notre langage et pour l'autre un langage qui combineaussi BPEL et Java.Le chapitre 3 est consacré à la présentation des méthodes et langages de conceptiond'applications en général. Dans ce chapitre, la présentation concerne les méthodes car-tésiennes, les méthodes systématiques (MERISE - Méthode d'Etudes et de RéalisationsInformatiques par Sous-Ensembles surtout), les méthodes assistées par des outils, des mé-thodes orientées objet. Pour ce dernier type de méthodes, c'est surtout le langage UMLqui a fait l'objet de notre étude. Cette attention pour UML se justi�e par le fait quede nos jours, UML a une certaine avance sur toutes les autres méthodes, mais aussi etsurtout, seul UML propose des éléments de modélisation des services web. UML est aussiun langage de conception adaptable à la presque totalité des langages de programmationactuels.La deuxième partie concerne nos contributions et est divisée en trois chapitres.Le chapitre 4 présente essentiellement le langage JCWSL en exposant ses concepts, sesprincipes ainsi que sa description formelle.Le chapitre 5 est consacré à l'étude et la mise en ÷uvre de notre environnement dedéveloppement. Cet environnement a été conçu à l'aide d'un outil graphique de Eclipse.Le chapitre 6 est consacré à la mise en place de notre méthodologie UML. En se basantsur le Model Driven Architecture de UML, nous avons dé�ni une méthodologie UML pourle langage JCWSL en dé�nissant les diagrammes nécessaires à la conception d'un service

1.3 Plan du mémoire 5

web dans ce langage.Ce mémoire se termine par un ensemble de conclusions et de perspectives des travaux encours et à venir.


Première partie

ETAT DE L'ART

Chapitre 2

Composition de services web

La composition des services web est une activité permettant la mise en ÷uvre de servicescomplexes sur Internet. Elle est réalisée à l'aide de technologies, langages, et environne-ments. Dans ce chapitre, nous présentons les technologies des services web, les langagesde description et de composition des services web ainsi que les plates-formes de compo-sition de services web. Ce chapitre permet de faire l'état des lieux du domaine a�n ded'identi�er les limites des approches actuelles des langages de composition de servicesweb.

2.1 Les technologies

Internet est devenu le moyen de communication des centaines de millions d'utilisateursqui échangent des informations numériques à travers des serveurs. Ce succès de l'Internets'est construit autour de trois technologies : TCP/IP, HTTP et HTML [30].

� TCP/IP (Transmission Control Protocol / Internet Protocol) a apporté la connec-tivité mondiale.

� La norme réseau dont HTTP (Hyper Text Transfert Protocol), le protocole desserveurs Web a permis à tous les ordinateurs de dialoguer de la même manière quelque soit le système.

� HTML (Hyper Text Markup Language) est devenu le langage universel de présen-tation des informations aux utilisateurs.

Ces technologies qui permettent un accès rapide à l'information ont contribué à la révolu-tion Internet. Cependant, bien qu'un grand nombre d'informations existent sur Internet,il est souvent di�cile de les localiser. De plus, les utilisateurs et les entreprises souhaitentdes sites Web qui fournissent des services tels que des commandes de clients. HTMLn'étant pas conçu pour développer de tels services, un autre langage était nécessaire :XML est né.

10 Chapitre 2. Composition de services web

2.1.1 XML (eXtensible Markup Language)

XML [74] est un langage de balisage extensible qui a été mis au point par le XMLWorkingGroup sous l'égide du World Wide Web Consortium (W3C) en 1996. Les spéci�cationsXML 1.0 sont reconnues comme recommandations par le W3C, ce qui en fait un standard.XML sert de base pour créer des langages balisés spécialisés : c'est un � méta-langage �.Il est su�samment général pour que les langages basés sur XML, appelés aussi dialectesXML, puissent être utilisés pour décrire toutes sortes de données et de textes. Il s'agit doncpartiellement d'un format de données. Son objectif est, dans un échange entre systèmesinformatiques, de transférer, en même temps, des données et leurs structures. Permettantde coder n'importe quel type de données, depuis l'échange EDI (Electronic Data Inter-change ou Echange de Données Informatisées) jusqu'aux documents les plus complexes,son potentiel est de devenir le standard universel et multilingue d'échange d'informations.XML Namespaces est une extension de la recommandation XML qui permet de créerdes espaces de nommage. Les espaces de noms d'XML permettent de quali�er de manièreunique des éléments et des attributs. On sait alors à quel domaine de dé�nition se rapporteun objet et comment il doit être interprété, selon sa spéci�cation.Di�érencier des espaces de noms permet de faire coopérer, dans un même document, desobjets ayant le même nom, mais une signi�cation di�érente, souvent liée à un modèle decontenu di�érent. Cette spéci�cation est une avancée importante car, à partir du momentoù beaucoup de formats s'expriment selon XML, les risques de � collision de noms � de-viennent plus importants et cette spéci�cation prend alors toute son importance.Les buts �xés pour XML étaient [17] :

1. XML sera simplement utilisable au-dessus de l'Internet.

2. XML soutiendra une grande variété d'applications.

3. XML sera compatible avec le SGML 1.

4. Il sera facile d'écrire les programmes qui traitent un document XML.

5. Le nombre d'options dans XML doit être gardé au minimum absolu, zéro idéale-ment.

6. Les documents XML devraient être lisibles et raisonnablement clairs.

7. La conception XML devrait être préparée rapidement.

8. La conception XML sera formelle et concise.

9. Il sera facile de créer des documents XML.

10. Le laconisme dans la marge béné�ciaire de XML est d'importance minimale.

1. SGML : Standard Generalized Markup Language

2.1 Les technologies 11

XML est le langage universel pour représenter des documents structurés ou des donnéessur le Web. Une information structurée rassemble non seulement l'information elle-même(mots, image,etc.) mais aussi des indications sur son contenu et son type. XML permetde représenter des données structurées ou des objets dans un �chier texte plat [30]. Ceciest un exemple de �chier XML valide :<Personne>

<Nom>COULIBALY</Nom><Prenom>Demba</Prenom>

</Personne>

XML permet aux utilisateurs de dé�nir leurs propres structures de données. Ces structuressont appelées méta-données. Cette possibilité va permettre aux entreprises d'accroître lestransactions B2B (Business to Business - transactions entre deux entreprises) et B2C(Business to Customer - transactions entre une entreprise et ses clients) sur Internet, enstructurant mieux les informations qu'elles veulent présenter aux partenaires et clients etde passer ainsi des sites Web HTML aux services web avec XML. XML est un formalismepermettant les échanges d'informations sur Internet indépendamment de la plate-formelogicielle utilisée. Ainsi, en plus des sites Web traditionnels, les entreprises vont développerdes services web.

2.1.2 Les services web

Le terme � web services � regroupe un ensemble de technologies basées sur XML, per-mettant de créer des composants logiciels distribués, de décrire leurs interfaces et de lesutiliser indépendamment du langage d'implementation choisi et de la plate-forme d'hé-bergement.� A Web Service is a software system designed to support interoperable machine to ma-chine interaction over a network. It has an interface described in a machine-processableformat (speci�cally WSDL). Other systems interact with the Web Service in a mannerprescribed by its description using SOAP messages, typically conveyed using HTTP withan XML serialization in conjunction with other Web-related standards. � [15]SOAP 2, WSDL 3, UDDI 4 sont les technologies standard qui rendent possibles la construc-tion et la publication de tels services. Il existe plusieurs dé�nitions des services web. Ci-dessus, nous avons choisi une dé�nition généralement acceptée et fournie par le consortiumW3C.Ainsi, un service web est un système logiciel conçu pour soutenir l'interaction inter-

2. SOAP : Simple Object Access Protocol3. WSDL : Web Service Description Language4. UDDI : Universal Description, Discovery and Integration


opérable de machine-à-machine au-dessus d'un réseau. Il a une interface décrite dans unformat exploitable par machine (spéci�quement WSDL). D'autres systèmes agissent avecles services web prescrits par leurs descriptions en utilisant des messages SOAP sur HTTPen format XML et autres normes du Web.Les services web ont une architecture basée sur trois composants principaux qui répondentchacun à une question :

� Echange : comment échanger les messages entre les services web ?� Découverte : comment identi�er et localiser les services web ?� Description : comment exposer les fonctions des services web ?

Cette architecture est appelée une architecture orientée service (Service Oriented Archi-tecture en Anglais - SOA).

L'architecture orientée service

L'architecture orientée services est le terme utilisé pour désigner un modèle d'architecturepour l'exécution d'applications logicielles réparties. Les deux modèles (CORBA 5 [40] etDCOM 6 [68]) relèvent de l'architecture par composants logiciels répartis plutôt que del'architecture orientée services, et le terme � service � est généralement absent de leur ter-minologie. Ces concepts ont ouvert la voie aux services web. Les systèmes d'informationqui découlent de ces deux technologies sont fortement couplés, c'est-à-dire que les interac-tions entre deux applications doivent être soigneusement décrites et qu'une modi�cationdans un composant conduit généralement à une défaillance du système.COM/DCOM est une technologie de composants introduite par Microsoft, héritée deOLE, DirectX et ActivX et COM [68]. Elle autorise les applications compilées à corres-pondre à l'aide d'interfaces spécialisées et elle est incontournable sous Windows. Elle estsous-jacente dans .Net et compatible avec les autres produits de développement de typeVisual Studio [68].CORBA est une norme de communication utilisée pour l'échange entre objets logicielshétérogènes, instituée par le monde du logiciel libre. Un langage, IDL (Interface De�nitionLanguage) décrit les traitements e�ectués et les formats de données en entrée et en sortie.Il est disponible pour C, C++, Cobol, Java, Smalltalk, entre autres. Un bus applicatif,ORB (Object Request Broker) constitue le c÷ur de CORBA par lequel les requêtes surles objets transitent. Un adaptateur d'objets, tel que BOA (Basic Object Adapter) estchargé de la gestion des références aux objets et de l'activation des implémentations.CORBA, de par sa complexité, est réservé aux grandes entreprises.

5. CORBA : Common Object Request Broker Architecture, de l'Object Management Group(OMG)6. DCOM : Distributed Component Object Model, de Microsoft


`````````````̀CritèresTechnologies DCOM CORBA SOAP

Editeurs Microsoft OMG W3CPlate-formes Win32 Multi MultiLangages de Programmation C++, VB, VJ, OPascal Multi MultiLangage de Description de service ODL IDL XML

Table 2.1 � Comparaison des Technologies DCOM, CORBA et SOAP

Un des avantages des SOA réside dans le fait que les applications réparties n'ont plusbesoin d'un système de middleware réparti commun pour communiquer, mais seulementdes protocoles et des technologies de communication intéropérables sur Internet.Le tableau 2.1 présente une comparaison des trois technologies CORBA, DCOM et SOAPsur quelques paramètres choisis.La notion de service fait remonter d'un cran le niveau d'abstraction auquel les dévelop-peurs d'architectures à composants ont été habitués. Traditionnellement, le composantest représenté par une boîte constituée de plusieurs facettes et/ou réceptacles (des entréeset des sorties). Lorsqu'on parle de service, celui-ci est caractérisé par un point appelé in-terface. Le contrat de service précise les messages d'entrée que peut recevoir ce pointd'entrée pour réaliser la prestation. Une architecture orientée services peut donc êtrereprésentée par une interconnexion de multiples points d'accès.Le contrat de service du modèle des SOA s'inspire directement du modèle des contratsprofessionnels de service. Il s'agit d'un document qui développe l'ensemble des points per-mettant de décrire et donc de dé�nir la relation de service entre les parties contractantes.Dans le cas des services web, ce contrat est un document WSDL.

Le protocole SOAP

L'architecture tripartite des services web accomplit trois tâches (échanger, localiser etdécrire).La question relative à l'échange de données entre services web est gérée par le protocoleSOAP [25] (Simple Object Access Protocol). SOAP est un produit de Microsoft et IBM.Sa première version a été acceptée par le W3C (Word Wide Web Consortium) en 2000.SOAP est un protocole de type requête/réponse fonctionnant sur le protocole de com-munication HTTP. C'est un mécanisme d'échange de messages XML par l'intermédiaired'un protocole de communication.SOAP est un protocole de l'architecture SOA (Service Oriented Architecture) qui assurela messagerie. Du fait qu'il est basé sur XML, il permet l'échange de données structuréesindépendamment des langages de programmation ou des systèmes d'exploitation [93].


C'est une spéci�cation XML qui dé�nit un protocole d'échange de données structuréesentre des applications dans un environnement distribué et hétérogène.Une des mesures les plus importantes prises par les concepteurs du protocole SOAPest que la spéci�cation du protocole ne donne aucune indication sur le mécanisme detransport du message. SOAP fait une séparation entre le message (i.e le document XML)et le moyen de transport utilisé. Actuellement, SOAP utilise les protocoles HTTP, SMTP 7

ou FTP 8 pour assurer le transport.Un message SOAP est composé d'un élément envelope. L'envelope contient à son tourdeux éléments �ls : une entête (facultative) et un corps encore appelé body. L'entêtecontient des informations nécessaires aux applications pour interpréter la charge utile. Lacharge utile se trouve dans l'élément body.Le tableau 2.2 suivant nous donne la structure générale d'un message SOAP. Dans cetableau, nous avons présenté les balises principales d'un document SOAP. L'enveloppeest représentée par env :Envelope, l'en-tête est représentée par env :Header et le corpsest dans la balise env :Body. Le nom de domaine est représenté par :xmlns :env="http ://schemas.xmlsoap.org/soap/envelope/".

< ?xml version="1.0" ?><env :Envelope xmlns :env="http ://schemas.xmlsoap.org/soap/envelope/"><env :Header /><env :Body ... >...</env :Body></env :Envelope>

Table 2.2 � Structure générale d'un message SOAP

Le tableau 2.3 représente un exemple de message SOAP. Dans ce tableau, nous avonsprésenté le corps avec la balise Body et l'espace de nom soapenv.Ce message contient les données transférées par un de nos exemples de services web(Calculator) qui est indiqué ici comme une espace de nom dans la balise ns1 :add quireprésente l'opération transférée par le message. Les données proprement dites sont dansles balises multiRef id="id1" et multiRef id="id0". Tout le message est dans labalise racine du corps d'un message SOAP soapenv :Body.

Le référentiel UDDI

La question relative à l'identi�cation d'un service web est gérée par le référentiel universelUDDI (Universal Description, Discovery and Integration) [25] [23]. La spéci�cation UDDI

7. SMTP : Simple Message Transport Protocol8. FTP : File Transfer Protocol


<soapenv :Body xmlns :soapenv="http ://schemas.xmlsoap.org/soap/envelope/"><ns1 :add soapenv :encodingStyle="http ://schemas.xmlsoap.org/soap/encoding/"xmlns :ns1="Calculator"><ns1 :arg0 href=#"id0"/><ns1 :arg1 href=#"id1"/></ns1 :add><multiRef id="id1" soapenc :root="0"soapenv :encodingStyle="http ://schemas.xmlsoap.org/soap/encoding/"xsi :type="soapenc :double"xmlns :soapenc="http ://schemas.xmlsoap.org/soap/encoding/"xmlns :xsi="http ://www.w3.org/2001/XMLSchema-instance">3.0</multiRef><multiRef id="id0" soapenc :root="0"soapenv :encodingStyle="http ://schemas.xmlsoap.org/soap/encoding/"xsi :type="soapenc :double"xmlns :soapenc="http ://schemas.xmlsoap.org/soap/encoding/"xmlns :xsi="http ://www.w3.org/2001/XMLSchema-instance">1.0</multiRef></soapenv :Body>

Table 2.3 � Exemple de corps d'un message SOAP

Figure 2.1 � Architecture des composants d'un service web

est également un travail collaboratif des sociétés Ariba, IBM et Microsoft. La premièreversion date de septembre 2000. L'objectif principal de UDDI est de fournir un formatd'annuaire pour les services web. Il permet de publier les points d'accès aux services weben les caractérisant par les di�érentes informations sur les services web entre autres :les opérations fournies, l'adresse URI, le nom du fournisseur. Il peut gérer aussi bien desannuaires publics destinés à des opérateurs UDDI que des annuaires privés à usage internede l'entreprise ou à usage commun entre entreprises pour la mise en ÷uvre d'échangesB2B.Les registres UDDI permettent :

� la recherche et la publication des di�érents types d'information sur les services etleurs fournisseurs selon un schéma de description,

� la consultation du contenu des registres.Les registres UDDI sont gérés par les opérateurs UDDI (Microsoft, HP, IBM, etc.). Ces


registres sont en réseau (�gure 2.2), donc ils se partagent les informations publiées. Ainsiune publication dans un registre se propage dans tous les autres. Cette propagation sefait par synchronisation des registres. Les informations présentes dans le registre sontréparties en trois catégories :

1. Les pages blanches : Ces pages comprennent la liste des organisations, leursinformations de contacts et les services qu'elles fournissent.

2. Les pages jaunes : Ces pages classi�ent les compagnies et les services web selondes taxonomies qui peuvent être standardisées ou dé�nies par l'utilisateur.

3. Les pages vertes : Ces pages décrivent comment un service web peut être invoqué.Elles fournissent des références vers le document WSDL du service qui est stockénormalement à l'extérieur du registre.

Figure 2.2 � Architecture des registres UDDI

Sur la �gure 2.2, nous avons deux exemples de registres UDDI. Il s'agit des registres deMicrosoft et de IBM. La synchronisation entre les contenus des deux registres est illustréepar les �èches à double traits et portant la mention canaux de di�usion. Sur le registreIBM, nous avons illustré un échange entre le registre et un client par une �èche (requête)et une feuille de réponse.

Le langage de description WSDL

La question relative à la description d'un service web est gérée par un langage de des-cription des services web WSDL [25] (Web Services Description Language). WSDL estun standard du domaine des services web.


La première proposition de ce langage a été faite par Microsoft, IBM et Ariba auprèsdu W3C dont la première version fut publiée en septembre 2000 [25]. WSDL permet dedécrire les services web accessibles sur Internet à l'aide de leur URI (Uniform RessourceIdenti�er) qui permet de nommer une ressource de façon unique sur le Web. Le langageWSDL propose une syntaxe XML pour la dé�nition de documents qui décrivent des ser-vices web. Chaque document est divisé en sept sections : type, message, opération, typede port, liaison, port et service.

Avant de présenter tour à tour les di�érentes sections d'un document WSDL, il est à noterque tout document WSDL commence par sa balise de dé�nition, nommée wsdl :de�ni-tions. Cette balise dé�nit tous les espaces de nom qui seront utilisés dans le document.<?xml version=1.0" encoding="UTF-8" ?><wsdl:definitions targetNamespace="urn:jeux"xmlns:apachesoap="http://xml.apache.org/xml-soap"xmlns:impl="urn:jeux" xmlns:intf= "urn:jeux"xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:xsd="http://www.w3.org/2001/XMLSchema">

La section type : Cette section sert à dé�nir les structures XML des messages échan-gés avec un service web. Pour dé�nir ces structures, on utilise le modèle XML Schéma.XML Schéma est un document qui utilise un ensemble de balises dé�nies au sein dela recommendation du W3C. L'exemple suivant illustre la mise en place du type com-posé RandomQuestion dé�ni par la balise complexType, constitué de sept éléments.Chaque élément est dé�ni par la balise element.<wsdl:types> - <schema targetNamespace="urn:jeux"xmlns="http://www.w3.org/2001/XMLSchema"><import namespace= "http://schemas.xmlsoap.org/soap/encoding/" /><complexType name="RandomQuestion"><sequence><element name="libQuestion " nillable="true" type="soapenc:string" /><element name="numQuestion" type="xsd:int" /><element name="poidsQuestion" type="xsd:int" /><element name="repA" nillable="true" type="soapenc:string" /><element name="repB" nillable="true" type="soapenc:string" /><element name="repC" nillable="true" type="soapenc:string" /><element name="repD" nillable="true" type="soapenc:string" />


</sequence></complexType></schema></wsdl:types>

La section message : Cette section permet de dé�nir le format des messages échangés.Elle peut faire référence aux types dé�nis dans la section type. L'exemple suivant donne lemessage checkResponseRequest. Ce message a deux parties dé�nies par la balise part.<wsdl:message name="checkResponseRequest"><wsdl:part name="id " type="xsd:int" /><wsdl:part name="marep " type="soapenc:string" /></wsdl:message>

La section type de port : Le type de port (ou portType) regroupe simplement unensemble d'opérations. Elle permet de préciser que l'ensemble de ces opérations est o�ertpar le même service web. On peut comparer la section portType à une interface Java.Nous avons ci-après un exemple de portType.<wsdl:portType name="QuizService">...

</wsdl:portType>

La section opération : Elle permet de dé�nir les opérations invoquées sur le serviceweb. Chaque opération est décrite de façon optionnelle à l'aide d'un, de deux ou troismessages :

� le message reçu par le service web lorsqu'il est sollicité pour une requête (input) ;� le message émis en réponse par le service web (output) ;� l'éventuel message d'erreur retourné par le service web en cas de problème (fault).

L'exemple suivant présente l'opération randomQuestion avec ses messages Input(randomQuestionRequest) et Output (randomQuestionResponse).<wsdl:operation name="randomQuestion"><wsdl:input message= "impl:randomQuestionRequest"

name="randomQuestionRequest" /><wsdl:output message= "impl:randomQuestionResponse"

name="randomQuestionResponse" /></wsdl:operation>


La section liaison : La section liaison (ou binding) e�ectue la liaison précise entreles descriptions e�ectuées dans les sections message et opération et le type de protocoleutilisé pour véhiculer les données. Le langage WSDL est dé�ni pour décrire les servicesweb indépendamment du protocole SOAP de communication. Le code suivant présenteun exemple de section binding.<wsdl:binding name="jeuxSoapBinding" type="impl:QuizService">...

</wsdl:binding>

La section service : Elle caractérise un service web en énumérant ses divers pointsd'accès, c'est-à-dire en utilisant une ou plusieurs sections port. Ainsi, un même serviceweb peut être accessible par l'intermédiaire de plusieurs points d'accès où chaque pointd'accès est caractérisé par un mode de communication di�érent. On peut avoir un mêmeservice web avec deux sections port : une pour un accès SOAP/HTTP et une autre pourun accès SAOP/SMTP. Voici un exemple de section service :<wsdl:service name="Quizserviceservice">...

</wsdl:service>

La section port : L'objectif de cette section est de préciser le point d'accès à un serviceweb. Chaque point d'accès est unique et associe un URI à une liaison, c'est-à-dire un pointd'accès à un mécanisme d'utilisation (par exemple l'utilisation du protocole SOAP). En�nun exemple de section port est présenté dans le code suivant.<wsdl:port binding="impl:jeuxSoapBinding" name="jeux"><wsdlsoap:address location="http://localhost:8080/axis/services/jeux" /></wsdl:port>

Les sept sections sont regroupées en trois parties principales (voir �gure 2.3).

Les di�érentes parties de la �gure 2.3 sont :

� la partie description abstraite du service se compose des sections type, message etportType. Cette partie présente les données décrites du service web,

� la partie liaison des opérations avec les protocoles de transport : section liaison oubinding,

� la partie association d'une adresse e�ective à chaque liaison : sections port et ser-vice.


Figure 2.3 � Structure d'un document WSDL

Avantages et inconvénients du langage WSDL Les avantages de WSDL sont :

� premier langage de description des services web en décrivant les actions o�ertes parles services,

� portable, car il utilise le format XML.

WSDL présente les inconvénients suivants :

� il est di�cile d'apprentissage, car c'est un langage de balises,� il n'est pas extensible,� il est peu expressif,� il ne dé�nit pas la logique des composants du service, donc ne supporte pas la com-

position de services.

Invocation d'un service web

Les trois protocoles (SOAP, UDDI, WSDL) sont écrits en format XML. Ces trois proto-coles composent l'architecture d'un service web, représentée sur la �gure 2.1.La description d'un service web est faite en WSDL puis publiée dans le référentiel UDDI.Lorsqu'un client a besoin d'un service web, il interroge le référentiel UDDI pour localiserle �chier WSDL du service web à l'aide de plusieurs critères. Le référentiel UDDI fournitau client la description WSDL du service web pour permettre son invocation. Cettedescription permet de connaître quel message SOAP doit être envoyé et quel messageSOAP sera reçu en retour du traitement souhaité, ainsi que le message qui sera envoyé en

2.2 Les langages de composition des services web 21

cas d'échec ou d'erreurs de traitements. Après localisation, le client invoque le service web.Cette invocation se fait à l'aide de critères statiques fournis dans les messages indiquésci-dessus. La �gure 2.4 représente les interactions entre un client et un service web.Pour invoquer un service web, nous devons envoyer un message SOAP : la requête. Leservice web délivre en retour un autre message SOAP contenant les résultats attendus : laréponse. SOAP (Simple Object Access Protocole) est un mécanisme conçu pour expédierdes messages standardisés, contenant des données structurées au format XML. Dans lecas d'une invocation de service web, SOAP exécute un appel de procédure à distance, ouRemote Procedure Call (RPC). Cette méthode est la plus largement répandue (sauf dansl'environnement .NET qui exploite principalement des messages de type Document).

Figure 2.4 � Implémentation et Invocation d'un service web

2.2 Les langages de composition des services webComme indiqué ci-dessus, WSDL est destiné à la description d'un service web que nousappellerons service web simple ou service web basique. Alors que l'évolution des échangesde types B2B et B2C a entraîné la nécessité de concevoir des services web plus intelli-gents et plus appropriés qui répondent mieux aux besoins des entreprises, il est nécessairesinon obligatoire de créer des langages plus appropriés, appelés langages métier ou lan-gages de composition. Parmi ceux-ci on peut citer : ebXML [51], XLANG [51], WSFL [51],BPEL4WS [96] ou WS-BPEL. Nous avons choisi ces langages car ils ont marqué l'évolu-tion de la composition des services web.

2.2.1 Composition des services web

L'infrastructure de base des services web présentée précédemment (WSDL, SOAP etUDDI), est su�sante pour implementer des interactions simples entre un client et un ser-


vice web. Mais, si l'implémentation d'une logique métier implique l'invocation d'autresservices web, il est nécessaire de combiner les fonctionnalités de plusieurs services dans unordre bien dé�ni. Dans ce cas, nous parlons d'un service web composé ou de compositionde services web. Les services composés sont dé�nis récursivement comme étant l'agré-gation de services élémentaires et composés. En composant des services web, la logiquemétier du client est implémentée par plusieurs services. Ceci est analogue aux WFMS [97](WorkFlow Managment System) où la logique applicative est réalisée en composant desapplications autonomes. Ceci permet la dé�nition d'applications de plus en plus com-plexes en agrégeant progressivement des composants à des niveaux élevés d'abstraction.Il est largement répandu d'employer des langages de programmation conventionnels pourlier des composants à un service web composé, et par conséquent de faire le pont entredes plate-formes hétérogènes. Il devient donc nécessaire, de développer un middlewarecomposition de services pour supporter la composition en termes d'abstraction et d'in-frastructure. Trois éléments principaux d'un middleware de composition de service webpeuvent être identi�és. Ces éléments sont : un modèle de composition et un langage pourspéci�er les services impliqués dans la composition, un environnement de développementmuni d'une interface graphique et un environnement d'exécution pour exécuter la logiquemétier. De plus, un middleware de composition de services exige que les fonctionnalités s,les interfaces et les protocoles que les services web supportent, soient décrites avec préci-sion. Les middleware de composition conventionnels ne possèdent pas ces propriétés. LesWFMS par exemple, sont fortement �exibles et génériques mais exigent des composantsqui tiennent compte des API (Application for Programming Interface) du WFMS. Parconséquent, les composants sont spéci�ques au système et aux vendeurs et nécessitent une�ort de développement additionnel.

La composition peut être décrite sous deux angles : la chorégraphie, et l'orchestration.

La chorégraphie La chorégraphie décrit la collaboration entre une collection de servicesdont le but est d'atteindre un objectif donné [28]. L'accomplissement de ce but commun sefait alors par des échanges ordonnés de messages. La chorégraphie décrit deux aspects dela composition : d'une part un ensemble d'interactions qui peuvent ou doivent avoir lieuentre un ensemble de services (représentés de façon abstraite par des rôles), et d'autrepart les dépendances entre ces interactions.

Un modèle de chorégraphie n'est pas exécutable. Il constitue en fait un accord entredes parties, où celles-ci spéci�ent comment leur collaboration doit se dérouler. Cetteconvention peut être établie par une consultation commune ou conçue par un comité destandardisation.


L'orchestration L'orchestration décrit, du point de vue d'un service, les interactionsde celui-ci ainsi que les étapes internes [28] (ex. transformations de données, invocations àdes modules internes) entre ses interactions. On dit qu'elle décrit un ensemble d'actionsde communication et d'actions internes dans lesquelles un service donné peut ou doits'engager (a�n de remplir ses fonctions) ainsi que les dépendances entre ces actions. Uneorchestration peut être vue comme un ra�nement d'une interface qui inclut des actionsqui ne sont pas nécessairement pertinentes pour les clients du service mais qui servent àremplir les fonctions que le service fournit et doivent donc être prises en compte dans sonimplémentation.L'orchestration permet ainsi à un service d'être associé à d'autres d'une manière prédé�-nie. Elle est ensuite exécutée par des scripts d'orchestration qui décrivent les interactionsentre les applications en identi�ant les messages, la logique et les séquences d'invoca-tions. Le composant exécutant les scripts d'orchestration est appelé moteur d'orchestra-tion. Celui-ci agit comme une entité centralisée pour coordonner les interactions entre lesservices.L'orchestration et la chorégraphie sont toutes deux des manières de composition de serviceweb agrégé. La di�érence principale entre ces deux manières, est que dans la chorégra-phie, chaque service connaît les autres services qui interagissent, alors que dans le cas del'orchestration, le service qui joue le rôle de chef d'orchestre est le seul qui connaît lesservices en interaction.

2.2.2 Le langage ebXML

Electronic Business using eXtensible Markup Language (ebXML) a été développé parle United Nation Center for Trade Facilitation and Electronic Business (UN/Cefact)et l'organisation OASIS (Organization for the Advancement of Structured InformationStandard). Son objectif était de créer un marché électronique unique et global.ebXML est une norme d'infrastructure qui vise à fournir aux entreprises non seulementun référentiel commun (structure d'annuaires répartis) recouvrant d'ailleurs une partiedes fonctionnalités s de UDDI, mais aussi une méthode de description des processus mé-tiers. Par contre, il ne spéci�e pas le type ou le contenu des transactions des processusmétiers. Le processus métier est dé�ni dans la norme ebPSS (Electronic Business ProcessSpeci�cation Schema) comme une séquence d'opérations représentées par des échangesde messages conventionnels entre parties prenantes au processus. Ces processus sont éga-lement organisés en modèles pouvant être classés par secteur industriel ou par objectif.Le traitement d'une prise de commande, le lancement d'un nouveau produit sont desexemples de processus métier ebXML.L'architecture ebXML fournit une méthode de description des entreprises, une méthode


de description des processus métiers, un référentiel où les entreprises peuvent déposer leursmodèles d'a�aires avec les messages associés, une méthode de dé�nition et de négociationd'accords de collaboration, une architecture de transport de message XML, gérant lesstandards HTTP, SMPT, TCP/IP, MIME, FTP et intégrant SOAP.Les concepts clés de ebXML sont :

� Collaboration d'a�aire : la collaboration d'a�aire est un ensemble de transac-tions d'a�aires entre des partenaires engagés dans une relation d'a�aires. ebXMLautorise les collaborations binaires (par exemple un acheteur - un vendeur) et mul-tiparties (par exemple : un vendeur - plusieurs acheteurs). Une collaboration Mul-tipartite associe plusieurs collaborations Binaires.

� Transaction d'a�aires : elle représente une unité de travail dans un arrangemententre deux partenaires commerciaux qui jouent chacun un rôle (le demandeur etle répondeur). Chaque transaction est spécialisée et a une sémantique spéci�queattendue par les logiciels d'interface. C'est elle qui déclenche les échanges.

� Flux de documents d'a�aires : il est attaché à la transaction d'a�aire. La tran-saction met en jeu des �ux de documents d'a�aires entre les rôles demandeur etrépondeur.

� Chorégraphie : elle décrit l'ordonnancement des transactions et les transitions quipermettent le passage d'un état à un autre.

� Patrons : ebXML fournit un ensemble d'éléments sémantiques non ambigus réuti-lisables et pouvant être intégrés dans la description des transactions et des collabo-rations.

ebXML utilise deux protocoles de collaborations : CPP et CPA qui dé�nissent res-pectivement les services et les accords entre services web. Le CPP (Collaboration ProtocolPro�le) dé�nit les capacités d'échanges de messages et les spéci�cations des collaborationssupportées par l'entreprise. Le CPA (Collaboration Protocol Agreement) dé�nit la manièredont les deux partenaires et leurs interfaces vont interagir et accomplir les collaborationsd'a�aires sélectionnées. Les deux partenaires doivent utiliser des copies identiques duCPA pour con�gurer les codes exécutables de leurs systèmes.

Avantages et inconvénients Le langage ebXML présente des qualités comme : saspéci�cation dans le domaine des a�aires (échanges commerciaux), l'implémentation dela chorégraphie qui permet à tous les partenaires en interaction de savoir avec qui leséchanges sont e�ectués. L'utilisation du standard XML est aussi un avantage, car il nesera pas lié à une plate - forme logicielle pour son exploitation.Malgré, ces avantages, ebXML présente des inconvénients qui sont :


� la non-adaptabilité, car les modèles d'a�aires sont en général conçus pour un pro-cessus donné,

� la non-extensibilité, car ebXML n'est conçu que pour le domaine économique,� le bas niveau d'expressivité, car ebXML ne spéci�e pas les contenus des processus,� ebXML n'a pas pu être un standard, car ses créateurs ne sont pas arrivés à trouver

de modèles de processus d'a�aires qui puissent convenir à toutes les entreprises.Par exemple, une tentative de bon de commande ou facture modèle a été faite maissans succès.

2.2.3 Le langage XLANG

XLANG (XML Business Process Language) est un langage crée par Microsoft. Il four-nit en même temps un modèle pour une orchestration des services et des contrats decollaboration entre services.Pour la représentation du work�ow entre les participants, XLANG utilise des actions.Ces actions sont les constituants de base des dé�nitions de processus de XLANG. Lestypes d'opérations de WSDL (requête/réponse, sollicitation, et la noti�cation) peuventêtre employés comme actions de XLANG. A ceux-ci XLANG ajoute deux autres actions :arrêts (date limite et durée) et exceptions.Il s'agit d'un langage d'orchestration des �ux nécessaires à l'accomplissement d'un proces-sus et il est déjà exploité au sein de BizTalk Server, le gestionnaire de �ux de Microsoft.XLANG couvre les points suivants :

� �ux de contrôle séquentiel et parallèle ;� transactions longues ;� corrélations des messages entre eux ;� gestion des défaillances et des erreurs ;� découverte dynamique des services ;� contrats multipartites.

Il complète les insu�sances de WSDL avec une structure présentée sur la �gure 2.5.Ainsi, les éléments portType, binding, service et port sont conformes à la syntaxe WSDL.L'élément xlang :behavior représente les spéci�cations de l'enchaînement des activitéspar des balises propres à XLANG. Le xlang :context spéci�e les transactions éventuellesdu processus et les références utilisées dans tout le document. Il permet de dé�nir desvariables locales et des transactions liant les actions ou les combinaisons d'actions. Le


xlang :contract spéci�e les relations entre services XLANG. En résumé, XLANG permetde décrire le circuit logique d'un service. Prenons l'exemple d'un détaillant qui demandeauprès d'un grossiste la livraison d'un produit qu'il n'a plus en stock. Le système d'in-formation du détaillant va pouvoir invoquer le service qui, sur la plate-forme du gros-siste, gère les ordres de réapprovisionnement a�n de lui passer les paramètres de l'ordre(référence produit, quantité, lieu de livraison, etc). Mais, il ne connaît pas la logiqueintrinsèque de ce service web (par exemple les véri�cations �nancières qui conditionnentcertaines étapes de ce processus). Ce service d'ordre d'achat peut avoir deux opérations ;l'une lancée par l'acheteur, qui lui-même active une instance du processus, et une autrelancée par le vendeur. XLANG décrit dans cet exemple la logique d'invocation du servicedu grossiste, car cette invocation n'aura lieu que lorsque, le stock du détaillant arrive àun certain niveau. La logique d'invocation dé�nit les étapes, les types de conditions, lesalternatives, etc.

Avantages et inconvénients Les avantages de XLANG sont :

� édité par un concepteur reconnu (Microsoft),� utilisation dans l'environnement BizTalk,� orchestration des �ux nécessaires à l'accomplissement d'un processus de type Work-

�ow (travail collaboratif).

La principale limite de XLANG est qu'il s'agit plus d'un format de dé�nition de processusque d'un format d'interface de processus. Ce manque d'interface rend XLANG di�cileà exploiter. En plus de cette limite, nous notons aussi le fait que XLANG n'est pas unstandard.Son apprentissage dans l'environnement BizTalk a rendu peu attractif, ce langage decomposition.

2.2.4 Le langage WSFL

WSFL (Web Services Flow Language) est une spéci�cation basée sur XML pour la des-cription de compositions de services web en tant qu'élément d'une dé�nition de processusmétier. WSFL a été conçu par IBM pour faire partie du cadre des techniques de servicesweb et complète les outils existants comme SOAP, WSDL, XML et UDDI. Il décrit deuxmanières de composer des services web :

� un processus métier exécutable nommé �ow Model,� une collaboration métier nommée global Model.


Figure 2.5 � Structure d'un document XLANG

Flow Model (modèle de �ux) : Flow Model est la description explicite de la successiondes étapes et de l'enchaînement des appels aux opérations des services web. Ce style despéci�cation s'apparente à la programmation dans un langage de script.Global Model (modèle global) : Global Model est le modèle d'interactions de services webpris deux à deux, le contrat. Il représente une sorte de contrat entre deux services webqui ne sont pas nommés : il s'agit de réaliser une interface publique a�n que des acteurs,non identi�és, puissent adhérer au contrat, dialoguer avec le service web et incorporerles processus métier de l'entreprise. Ces interactions sont réalisées dans des liens entredes services, avec un lien pour chaque opération possible entre deux services dans unecollection. Ces liens peuvent être adaptés soit à des interactions dans des hiérarchies, soità des interactions collaboratrices entre pairs.WSFL permet de créer des modèles récursifs : une composition de services web est elle-même considérée comme un service web, utilisable à son tour dans d'autres compositions.Dans WSFL, les étapes du processus sont appelées activités et sont reliées par des liensde contrôle et des liens d'information. Un lien de contrôle est un passage explicite ducontrôle d'un processus à un autre. Un lien d'information est le passage des données avectransformation éventuelle, d'un processus à un autre.

Avantages et inconvénients Les avantages de WSFL sont :

� édité par un concepteur reconnu (IBM),� utilisation dans les processus de type Work�ow (travail collaboratif).


De même que XLANG, WSFL n'a pas pu être standardisé bien qu'il était portable. Sanon extensibilité a abouti à la création de BPEL4WS.

2.2.5 Le langage BPEL4WS

Les deux derniers langages (XLANG et WSFL) n'ont même pas eu le temps d'être norma-lisés par le W3C (World Wide Web Consortium), que leurs concepteurs se sont associéspour créer le langage BPEL4WS (Business Process Execution Language for Web Services)ou tout simplement BPEL.Le langage BPEL est le dernier né du domaine. Il est un standard du domaine. BPEL re-présente un langage de programmation standard aidant les entreprises à dé�nir la manièrede combiner des services web (services web basiques) en vue de mener à bien certainestâches (services web agrégés ou complexes).Les premiers objectifs de BPEL étaient de :

� supprimer les con�its liés à la composition de services, à l'intégration de servicesdans des processus d'a�aires, aux di�érences des langages,

� dé�nir un langage standard de spéci�cation et de normalisation des processus d'af-faires, notamment pour la composition de services web.

Il comporte en son sein WS-Coordination [32] et WS-Transaction [50]. WS-Coordinationdécrit l'interaction des di�érents services web associés à une tâche. Le standard WS-Transaction garantit que toutes les transactions aboutissent ou échouent en groupe. Ilgère le déroulement des tâches.Dans la pile des protocoles de services web (�gure 2.6), BPEL est placé au dessus dulangage WSDL. Il utilise WSDL pour spéci�er les actions qui doivent s'e�ectuer au seind'un processus opérationnel et pour décrire les services web o�erts par ce processus. Ilordonne la séquence d'exécution de plusieurs opérations exposées sous forme de servicesweb, les données que ces services se partagent, ainsi que les partenaires impliqués. Il estégalement doté d'un mécanisme de gestion des exceptions.BPEL permet la modélisation des processus exécutables (executable business) et des pro-cédés abstraits (business protocols).Executable business : modélisation des comportements des di�érents partenaires in-teragissant ensemble.Business protocols : description du comportement visible des processus pour les autresservices ou pour les clients.Les descriptions de BPEL sont des documents XML qui décrivent les rôles impliqués


dans l'échange de messages, les types et les orchestrations supportées, et les informationsde corrélation comme aspects du processus. Il se compose également d'un modèle decomposant basé sur les activités, d'un modèle d'orchestration qui permet la dé�nition detypes de données structurées d'activités et basés sur des schémas XML, d'un modèle dechoix de service et d'un mécanisme pour la manipulation des exceptions, des événementset de la compensation.

Avantages et inconvénients Les principaux avantages de BPEL sont :

� depuis sa création, BPEL est devenu le standard du domaine,� la portabilité, car il est basé sur le format XML.

Comme inconvénients, nous pouvons souligner :

� la complexité d'apprentissage, actuellement, il n'existe que des exemples très simples,� le bas niveau d'expressivité, car c'est un langage à balises,� la di�culté de mise en ÷uvre d'un services, car BEPL utilise un moteur très lourd

qui demande des environnements spéci�ques.

Figure 2.6 � BPEL4WS et la pile de Protocoles

2.2.6 Le langage BPELJ

BPELJ [13] (Business Process Execution Language for Java Technology) est un langagebasé à la fois sur BPEL et Java. Il est l'÷uvre de Microsoft et IBM.Avec BPELJ, Microsoft et IBM proposent une combinaison de BPEL avec Java. BPELJpermet d'utiliser ces deux langages de programmation pour construire des processus mé-tier. En permettant BPEL et Java à fonctionner ensemble, BPELJ permet à chaquelanguage de donner ce qu'il a de mieux.


Ainsi, il permet d'incorporer des sections de code java dans un service web BPEL. Cescodes sont appelés Java snippets. Les snippets sont des expressions ou des petits blocs decode Java qui peuvent être utilisés pour des choses telles que : les boucles, les conditionsde branchement, l'initialisation de variables, la préparation de messages du service web.Les Snippets sont des expressions Java ou des blocs d'instructions Java dans la dé�nitiond'un process BPEL. Ils sont exécutés dans des containers J2EE. Les snippets peuventêtre utilisés :

� comme un corps d'activités snippets,� pour initialiser des variables,� en substitution de certains constructeurs BPEL :

1. comme expression booléennes en vue de remplacer while, switch case entresautres,

2. comme une expression jusqu'à (l'attribut Until de onAlarm et wait),

3. comme expression for pour remplacer les expressions for de onAlarm et dewait,

4. dans l'a�ectation générale.

BPELJ répartit les tâches entre BPEL et Java. Le langage BPEL assure le contrôle des�ux tandis que Java assure la manipulation des données.

Les tâches dédiées exclusivement à BPEL sont :

� Décrire la logique des services web,� Maintenir les activités de traitements de longue durée,� Compenser de façon selective les cas de défaillances des activités de longue durée,� Assurer la reprise des traitements à la suite d'une défaillance au point indiqué dans

le processus indiqué,� Envoyer les messages vers le bon endroit dans le bon processus,� Accepter un message parmi un ensemble de types de messages attendus,� Dé�nir un ensemble d'activités à accomplir pendant un temps donné et dans un

ordre prédé�ni,� Envoyer des messages aux services.

La tâches dédiées à Java (les Java Snippets) sont :� Calculer les valeurs,


� Construire les messages à échanger à partir d'autres messages reçus et/ou de va-riables,

� Extraire d'un message reçu les valeurs importantes, les convertir si nécessaire etpuis les insérer dans d'autres messages,

� Assurer les boucles, les branchements, les initialisations entre autres.

Nous avons dans l'exemple suivant, du code Java dans service web BPEL.<process name="PriceQuote" ...>..... <bpelj:snippet name="Calculate Total">

<bpelj:code> response.setTaxRate(taxRate);response.setDiscount(discount.getRate());float subtotal = response.getSubtotal();subtotal = subtotal ∗(1− discount.getRate());response.setSubtotal(subtotal);float taxes = subtotal ∗taxRate;float total = subtotal +taxes;response.setTax(taxes);response.setTotal(total);// Prepare the text message to be sent in the next activity.jmsMessage =p_inquiryTopic.getSession().createTextMessage(response);

</bpelj:code> </bpelj:snippet>....

</process>

Avantages et inconvénients Ce langage aurait pu devenir facile à apprendre, s'iln'était pas aussi conçu sur des concepts de balises limitant ainsi sa capacité de dé�nircertaines structures de données complexes à l'aide de BPEL, car déjà son apprentissagen'est pas plus facile que celui de ses prédécesseurs. Comme avantage principal, nous avonsnoté l'inclusion du code Java rendant possible l'utilisation des structures de programma-tion telles que les boucles de type do et for en Java, ainsi que l'utilisation de l'alternativeà branches multiples. BPELJ a rendu facile les tâches d'initialisation des variables et laréalisation de certaines tâches dans le service composite ne nécessitant pas la mise enplace d'un service web basique. BPELJ est portable car basé sur BPEL. Dans les Javasnippets, il reste quand même possible d'introduire de nouvelles fonctionnalités qui serontdécrites comme des objets Java.


2.2.7 Discussion sur les langages de composition

Tous les langages présentés dans cette section, ont en commun les standards XML commeformat des données et SOAP comme moyen de communication. L'utilisation de ces deuxstandards de la technologie des services web est une qualité qui fait d'eux tous portables,donc indépendants des systèmes d'exploitation.Dans la plupart des cas, ils sont tous d'apprentissage di�cile, car bâtis sur des conceptsde balises.Certains comme ebXML n'opèrent que dans le domaine économique, car conçus pourl'uniformisation du commerce international sur Internet ce qui limite leurs domainesd'utilisation. Les autres sont plus généraux, car ils peuvent être utilisés dans tous lesdomaines. Du point de vu expressivité, il est à noter que le niveau varie entre bas niveauet niveau moyen (BPELJ).Seul le langage BPEL a eu une déclinaison nommée BPELJ sinon tous les autres sontrestés dans leurs versions basiques, ce qui justi�e les di�cultés d'évolutions de ces lan-gages.Dans le souci de mise en place de moyens plus simples et ne nécessitant pas d'environ-nement spéci�ques pour leur mise en ÷uvre, nous proposons dans ce travail de rechercheun langage beaucoup plus simple et plus expressif. Il sera basé sur Java et BPEL, mais àla di�érence de BPELJ, il ne sera pas un langage de balises, mais un script Java. Ce lan-gage qui sera exposé dans la deuxième partie au chapitre 4 du présent rapport exploiterala portabilité de Java et le standard de BPEL pour la conception des processus métier(services web complexes).Le tableau 2.4 représente un résumé des propriétés des langages existants par rapport ànos objectifs qui sont en en-tête de colonnes.Ainsi, le langage WSDL est destiné à la description des services web. Ce qui le predestineaux services web simples sans pouvoir dé�nir la logique des composants des services web.Il est basé sur XML ce qui fait de lui un langage verbeux. Même si, WSDL permet dedé�nir ses propres structures de données, il reste peu expressif quant à l'ajout de fonc-tionnalités s propres à l'utilisateur, l'exemple est aujourd'hui l'expression des qualitésdes services web qui ne sont pas encore prévues dans la sémantique de WSDL. L'ex-ploitation des services web WSDL est par contre très aisée, car un serveur web commeTomcat [4] associé à AXIS (Apache eXtensible Interaction System) [4] permet facile-ment leurs exploitation. En terme de développement de client correct, des outils commeorg.apache.axis.WSDL2Java [4] permettent leur génération. Il est aussi possible de dé-velopper un client pour WSDL dans un environnement C++ ou Java. Il n'existe pasd'environnement dédié à la conception de services web WSDL.Le langage ebXML met en contact des partenaires d'a�aires pour échange. Son apprentis-


sage est plutôt facile, car aucun développement propriétaire n'est pré-requis pour partici-per à ebXML. En e�et, des applications et des composants � prêt à l'emploi � [20] conformesaux spéci�cations ebXML sont mises à disposition par les o�res ebXML. L'utilisationdu � prêt à l'emploi � a des inconvénients pour l'expressivité et l'extensibilité, car il nesera pas possible de présenter les données dans une forme propriétaire ni d'ajouter d'autresfonctionnalités. Pour l'exploitation, par contre, il utilise les mêmes ressources que WSDL.Il n'est pas nécessaire de construire un client ebXML, car pour utiliser ebXML, les entre-prises construisent leurs Systèmes ebXML à partir du � prêt à l'emploi � et les publientdans les registres ebXML.

Le langage XLANG réalise de l'orchestration de services web existants. Il est une extensionde WSDL. En terme d'expressivité et d'extensibilité, il a amélioré les limites de WSDLsans atteindre un niveau élevé. Il n'est pas extensible, car ne permet pas d'ajouter d'autresfonctionnalités s en plus de celles qui sont prévues dans sa sémantique. Son exploitationa été réalisée dans le BizTalk Server de Microsoft. Les clients pour XLANG sont d'unecertaine di�culté à programmer, car à la di�érence de WSDL, les client doivent pouvoirsuivre l'orchestration (la logique introduite) dans la service web.

Le langage WSFL réalise la chorégraphie des services. Il est aussi basé sur WSDL pourla description de l'interface des services. Tout comme XLANG, il n'est pas extensible niassez expressif pour permettre la personnalisation de certaines tâches de l'utilisateur. Il estimplémenté dans le IBM WebSphere Server. La mise en ÷uvre d'un client pour WSFL a lemême niveau de di�culté que celle d'un client pour XLANG. En terme d'environnementde développement, il n'existe pas d'environnement dédié à WSFL comme à XLANG.

Le langage BPEL peut réaliser des services web complexes par l'orchestration ou parchorégraphie, car il est basé sur XLANG et WSFL. BPEL est comme ses précédents d'unniveau pas assez expressif comme langage de programmation, car il ne prévoit pas nonplus d'autres possibilités de représentation des données que le format XML. L'utilisateurde BPEL ne peut pas ajouter ses propres besoins en terme de fonctionnalités s, car seulescelles prévues dans sa sémantique sont réalisables. L'apprentissage de BPEL et la concep-tion d'un client correct pour BPEL sont d'une di�culté importante. Si l'apprentissageest comparable à celui de ses précédents, car tous des langages verbeux, la réalisationd'un client est très complexe. Les di�cultés liées à son apprentissage ont abouti à la miseen place d'environnements facilitant la réalisation de services web BPEL. Parmi ces en-vironnement, nous avons cité les plus utilisés et connus (Oracle BPEL et Active BPEL).

Le BPELJ est venu améliorer les insu�sances de BPEL en terme d'expressivité et d'exten-sibilité. Avec l'incorporation de Java dans ce langage, il a obtenu un niveau d'expressivitéet d'extensibilité plus élevé que BPEL, car il devient ainsi possible de dé�nir ses propres


classes Java par exemple pour exprimer certaines formes de données non prévues dansla sémantique de BPEL natif. Comme il est aussi un langage verbeux comme les autres,son apprentissage exige la connaissance de tous les mots clés prévus par sa sémantique.En terme d'environnement, en plus des environnements prévus pour BPEL, BPELJ peututiliser du Java.


XX

XX

XX

XX

XX

XLa

ngag

eCr

itères

Type

sApp

rentiss

age

Expressiv

itéEx

tensibilité

Exploitatio

ndé

velopp

erenvironn

ement

uncli

ent

deconc

eptio

nba

sécréatio

nde

ses

non

Serveu

rfacil

epa

sW

SDL

descrip

tion

sur

prop

restype

sextensible

Web

d'environn

ement

XML

dédié

plutôt

prob

lèmede

non

Serveu

rfacil

epa

seb

XML

chorégraph

iefacil

ereprésentatio

nextensible

Web

d'environn

ement

dedo

nnées

dédié

basé

non

non

Serveu

rdi�cu

ltépa

sXLA

NG

orchestration

sur

expressif

extensible

BizT

alk

moyen

ned'environn

ement

XML

dédié

basé

non

non

Serveu

rdi�cu

ltépa

sW

SFL

chorégraph

iesur

expressif

extensible

IBM

moyen

ned'environn

ement

XML

Web

sphe

redé

dié

chorégraph

iepe

uno

nSe

rveu

rdi�cu

ltéAc

tiveBP

ELBP

ELorchestration

di�cil

eexpressif

extensible

BPEL

moyen

neOracle

BPEL

orchestration

plus

extensible

Serveu

rdi�cu

ltéAc

tiveBP

ELBP

ELJ

orchestration

di�cil

eexpressif

parJ

ava

BPEL

moyen

neOracle

BPEL

queBP

ELSn

ippe

tsutilise

Java

Tabl

e2.4�Ta

bleaucompa

ratif

desl

anga

gese

xistan

tspa

rrap

port

àno

sobjectifs


2.3 Les plates-formesDans cette section, nous présentons les plates-formes .NET, J2EE, ActiveBPEL, et OracleBPEL. Ces plates-formes semblent prendre l'ascendant sur les autres dans le domaine dela composition des services web. Elles sont de nos jours les plus connues mais aussi lesplus utilisées.En e�et, au début de l'année 2002, dans le cycle de développement et de di�usion desservices web, deux technologies de base émergent pour le développement et le déploiementdes services et des applications web dans l'entreprise : l'univers Java avec J2EE et l'universMicrosoft avec .NET..NET et J2EE sont des technologies conçues initialement pour devenir des plates-formesgénérales de développement et de déploiement d'applications d'entreprises, mais que l'onpeut employer pour construire et déployer des services et applications web.ActiveBPEL et Oracle BPEL, quant à elles, sont conçues pour faciliter l'exploitation deBPEL. Ce sont des outils de composition de services web composites avec BPEL.

2.3.1 La plate-forme .NET de Microsoft

.NET [85] est la plate-forme Microsoft pour la nouvelle génération de logiciels distribuéset coopératifs, les services web XML. Elle vise à simpli�er la vie de l'utilisateur en luifournissant des services intégrés, accessibles depuis tous ses périphériques, à tout momentet en tout lieu. S'il ne fallait retenir qu'un seul mot de .NET, c'est donc l'intégration.Fondée sur des standards de l'industrie (HTTP, XML, SOAP, WSDL), la plate-forme.NET est un moyen simple de normaliser la coopération des services logiciels entre eux(services web XML), quelle que soit leur localisation, leur implémentation technique,qu'ils soient internes ou externes, existants ou à créer..NET est une technologie fréquemment utilisée pour la réalisation de projets informa-tiques. Dans ce chapitre nous présentons la complexité et la richesse de l'ensemble desbibliothèques de .NET et �xons le vocabulaire pour di�érencier les éléments normali-sés de la plate-forme par Microsoft de ceux qui sont restés propriétaires a�n de pouvoirtrès rapidement comparer les di�érentes plates-formes de développement. Une section seraconsacrée à l'architecture générale de la plate-forme et sur ses principales caractéristiques.Nous présenterons aussi le modèle de composants et la machine virtuelle permettant leurexécution.

Dé�nitions et principes

Microsoft .NET est une architecture logicielle destinée à faciliter la création, le déploie-ment des applications en général, mais plus spéci�quement des applications Web ou desservices web. Cette architecture logicielle concerne aussi bien les clients que les serveurs

2.3 Les plates-formes 37

qui vont dialoguer entre eux à l'aide d'XML. Elle se compose de quatre principaux élé-ments :

1. un modèle de programmation qui prend en compte les problèmes liés aux déploie-ments des applications (gestion de version, sécurité) ;

2. des outils de développement dont le c÷ur est constitué de Visual Studio .NET ;

3. un ensemble de systèmes serveurs représentés par Windows Server 2003, SQL Serverou Microsoft BizTalk Server qui intègrent, exécutent et gèrent les services web etles applications ;

4. un ensemble de systèmes clients représenté par Windows XP, Windows CE ou Mi-crosoft O�ce 2003.

En fait, Microsoft .NET est essentiellement un environnement de développement et d'exé-cution avec des concepts similaires à ceux de la machine virtuelle de Java, via le CLR [85](Common Language Runtime). Le principe est le suivant : la compilation du code sourcegénère un objet intermédiaire dans le langage MSIL [85] (Microsoft Intermediate Lan-guage) indépendant de toute architecture de processeur et de tout système d'exploitation.Cet objet intermédiaire, est ensuite compilé au sein du CLR, au moyen d'un compilateurJIT [85] (Just In Time) qui le transforme en code machine lié au processeur sur lequelil réside. Il est alors exécuté. L'avantage est que son code intermédiaire est commun àun ensemble de langages (C#, VB.NET 9, C++, etc.) contrairement à Java, pour lequelle code intermédiaire (byte-code) est lié à un seul langage source. Le CLR en charge del'exécution du code intermédiaire contient un ensemble de classes de base liées à la gestionde la sécurité, de la mémoire, des processus et des threads.

Architecture générale et concepts

Le composant central de l'architecture .NET est le CLR qui est un environnement d'exé-cution pour des applications réparties écrites dans des langages di�érents. En e�et, avec.NET on peut véritablement parler d'interopérabilité entre langages. Cette interopéra-bilité s'appuie sur le CLS (Common Language Speci�cation) qui dé�nit un ensemble derègles que tout compilateur de la plate-forme doit respecter. Le CLS utilise entre autresun système de types uni�é permettant d'avoir le même système de types entre les di�é-rents langages et le même système de types entre les types prédé�nis et les types dé�nispar l'utilisateur.

9. VB.NET est la nouvelle version de Visual Basic, il intègre la notion d'objets qui existe dans .NET


Un autre concept majeur, lié au CLR est celui du code géré, c'est à dire le code exécutésous le contrôle de la machine virtuelle. Dans cet environnement, un ensemble de règlesgarantissent que les applications se comporteront d'une manière uniforme, et ce indépen-damment du langage ayant servi à les écrire. Pour répondre à ce souci d'interopérabilitéentre les langages, la plate-forme .NET contient une bibliothèque de classes très complète,utilisable depuis tous les langages et permettant aux développeurs d'utiliser une mêmeinterface de programmation pour toutes les fonctions o�ertes. Dans .NET, le langage lui-même est essentiellement une interface syntaxique de bibliothèques dé�nies dans le CLR.Grâce au jeu commun de ces bibliothèques, tous les langages disposent théoriquement desmêmes capacités car ils doivent, exception faite de la déclaration des variables, passer parces bibliothèques pour créer des threads, les synchroniser, sérialiser des données, accéderà Internet.Pour permettre la compilation de di�érents langages sur la plate-forme .NET, Micro-soft a dé�ni une sorte de langage d'assemblage, indépendant de tout processeur baptiséMSIL [85] (Microsoft Intermediate Language). Pour compiler une application destinée à.NET, le compilateur concerné lit le code source dans un langage respectant les spéci�-cations CLS, puis génère du code MSIL. Ce code est traduit en langage machine lorsquel'application est exécutée pour la première fois. Le code MSIL contient un en-tête austandard PE [85](Win-32 Portable Executable) qui permet de di�érencier les exécutables.NET des autres exécutables de l'OS Windows en chargeant au démarrage de l'applicationun ensemble de DLL spéci�ques précisées dans cet en-tête. Pour compiler à l'exécutionle code MSIL, la plate-forme .NET utilise un compilateur à la volée (JIT Compiler -just-in-time compiler) qui place le code produit dans un cache. Sur la plate-forme .NET,trois JIT sont disponibles :

1. Génération de code à l'installation : le code MSIL est traduit en code machine lorsde la phase de compilation comme le fait tout compilateur.

2. JIT : les méthodes sont compilées une à une à la volée lors de leur première exécu-tion, ou lorsqu'elles ne sont plus en cache.

3. EconoJIT : JIT permettant de minimiser la place mémoire utilisée pour exécuterun programme et qui sera utilisé pour les équipements portables.

Les compilateurs de la plate-forme .NET incorporent dans l'exécutable produit di�érentesméta-données. Ces méta-données décrivent l'exécutable produit et lui sont systématique-ment incorporées pour pouvoir être atteintes lors de l'exécution. Il est ainsi possible dy-namiquement de connaître les di�érents types déclarés par un exécutable, les méthodesqu'il implémente, etc. La lecture des méta-données est appelée ré�exion et la plate-forme


.NET fournit de nombreuses classes permettant de manipuler de manière re�exive lesexécutables.Les services web mis en ÷uvre dans le cadre de la plate-forme .NET sont accomplis àl'aide de ASP.NET (nouvelle version d'ASP - Active Server Pages) [85]. ASP.NET per-met d'intégrer dans une page HTML du code .NET. Ce code est exécuté par le serveurweb lorsque la page est demandée. Ainsi, le serveur web doit être, pour cela, capabled'exécuter du code .NET. Deux su�xes de �chiers sont utilisés :

1. aspx pour les pages HTML qui contiennent du code .NET devant être interprétéespar le serveur Web. Ces pages sont envoyées au client dans le format HTML.

2. asmx pour des pages qui contiennent le code du service web. Ce service est exécutépar le serveur Web. Les pages sont envoyées au client dans le format SOAP.

La �gure 2.7 représente l'architecture générale de la plate-forme .NET.

Figure 2.7 � Architecture .NET

2.3.2 La plate-forme J2EE

Dans cette section, nous donnons un aperçu sur les grands principes qui gouvernent lamise en ÷uvre de l'environnement J2EE (Java 2 Entreprise Edition) [85] [70]. Cetenvironnement, proposé dans le contexte de Java par Sun Microsystems, o�re un supportau développement, au déploiement, ainsi qu'à l'exécution d'applications s'exécutant en


mode serveur, comme par exemple des applications web ou des applications répartieso�rant des prises de service. Cette section comportera, une introduction à l'environnementJ2EE, un bref historique et une présentation des éléments de l'architecture.

Dé�nitions et principes

La synthèse proposée ici étudie les principes structurant qui gouvernent le mise en ÷uvrede J2EE. La vue qui est donnée de l'environnement J2EE dans ce passage n'a pas l'inten-tion d'être exhaustive. Certains aspects couverts par le standard J2EE sont des simplesdéclinaisons Java des autres standards plus généraux. C'est le cas par exemple de la cou-verture des standards de CORBA de l'OMG autour de la gestion d'objets répartis, desstandards du W3C autour de la gestion de documents XML ou encore du support desservices web.L'environnement Java pour l'entreprise a commencé à émerger assez rapidement après lesdébuts de Java au milieu des années 90. A son origine, Java était destiné aux environne-ments contraints (par exemple des petits équipements électroniques comme les téléphonesportables). Il a en fait percé dans l'environnement du web, notamment dans les naviga-teurs pour le support d'interfaces graphiques riches (notion d'applet Java en anglais). Lespremières déclinaisons de Java dans l'environnement des serveurs sont apparues en 1997avec les servlets, dont l'objectif est la construction de pages Web à l'aide de programmes,puis avec les Entreprise Java Beans dont l'objectif est le support de code métier néces-sitant un contexte d'exécution transactionnel [26]. Après quoi, Sun a structuré l'o�retechnique autour des serveurs d'application Java à travers le standard J2EE. L'objectifde ce dernier est de fédérer dans un cadre cohérent toutes les technologies nécessaires àla mise en ÷uvre des applications de l'entreprise (applications orientées � serveur �). Lapremière version des spéci�cations de J2EE est publiée en 1999. Suivront alors la ver-sion 1.3 de J2EE en 2001, puis la version 1.4 en 2003 incluant un support complet desstandards XML et le support des services web. Il devient ainsi le principal concurrent del'environnement .NET de Microsoft.J2EE a été conçu comme un environnement pour développer, déployer et exécuter desapplications réparties pour le monde de l'entreprise. Ce contexte de l'entreprise se carac-térise généralement par la nécessité d'assurer des niveaux de qualité de service tels que lasûreté de fonctionnement, la résistance à des charges d'exécution importantes ou encorela sécurité.Les principales forces de l'environnement J2EE ont été regroupées en deux :

� Le spectre fonctionnel couvert [26]. Le développeur dispose d'une très large palettede fonctions pour construire des applications d'entreprise, l'un des objectifs étant


de garantir un niveau élevé de productivité. C'est notamment le cas de la connec-tivité, pour laquelle J2EE o�re des mécanismes tels que l'appel de procédure à dis-tance (Remote Procedure Call - RPC ), les systèmes de communication asynchrone(Message-Oriented Middleware - MOM ), l'accès aux bases de données, ou encoredes protocoles divers. Cela positionne l'environnement comme une base logiciellepertinente pour l'intégration d'applications (Entreprise Application Integration -EAI ).

� Une o�re importante. De grands éditeurs (BEA, IBM, Oracle, Sun, Macromedia,etc.) ont bâti leur o�re sur ce socle intergiciel. Par ailleurs, le monde de l'OpenSource participe lui aussi à l'abondance de l'o�re à travers des produits commeJBoss [39], JOnAS [24] et Geronimo [7]. C'est d'autant plus rassurant pour les uti-lisateurs qui investissent dans la technologie que la portabilité des applications estréellement avérée, si l'utilisateur reste dans le cadre des fonctions standard évidem-ment. Sun met à disposition pour cela des outils de véri�cation de la conformitéd'applications au standard J2EE [70].

La richesse et la puissance de l'environnement J2EE en font aussi un défaut car la phased'apprentissage reste lourde si l'objectif est la connaissance de l'ensemble. Il est aussinécessaire de bien maîtriser les concepts sous-jacents à J2EE (notamment les principesdes transactions) pour l'utiliser e�cacement.

Architecture générale et concepts

Figure 2.8 � Architecture en couches de J2EE


L'architecture de la plate-forme J2EE est présentée sur la �gure 2.8. On distingue plu-sieurs niveaux qui s'apparentent à ceux disponibles dans l'architecture de l'environnementde la plate-forme .NET.La vue architecturale proposée correspond à une décomposition de la chaîne d'exécutiond'application du terminal jusqu'aux di�érents serveurs intervenant dans l'exécution d'uneapplication. Les éléments proposés par cette décomposition sont décrits ci-après.

La couche Client La couche client est représentée par le terminal et prend en chargel'interaction avec l'utilisateur. Elle peut être client léger ou client lourd.

1. Architecture client léger : dans ce cas, le terminal embarque un mécanisme quipermet d'interpréter les informations de présentation et d'interaction avec l'utilisa-teur produite par le serveur. Cela peut être un navigateur qui interprète des pagesXML (XHTML, WML -Wireless Markup Language, ou VoiceXML suivant la moda-lité utilisée) produite par le serveur J2EE. La communication avec le serveur passegénéralement par le protocole HTTP dans le cas du Web ou des interfaces vocales,sachant que dans ce dernier cas, le navigateur VoiceXML est lui-même exécuté parun serveur vocal connecté au terminal par un canal voix classique (RTC, GSM, etc).Dans le cas du WAP (Wireless Application Protocol) [26] [43] pour les pages WML,le protocole utilisé est WTP [26] qui ne fait pas partie des protocoles supportés enstandard par l'environnement J2EE.

2. Architecture client riche (ou client lourd) : dans ce cas, le terminal exécute uneapplication Java utilisant généralement des couches graphiques évoluées de J2SE oud'autres (AWT, Swing, SWT, etc). La communication avec la partie serveur peutpasser ici par les di�érents moyens disponibles dans le cadre J2EE : RMI, web ser-vices, voire JMS. Une telle application peut d'ailleurs elle-même être exécutée sousla forme d'une applet dans le contexte d'un navigateur supportant une JVM. Celapeut en simpli�er le déploiement même si cela pose des problèmes de compatibilitéde version de JVM ou encore de gestion de politique de sécurité. D'autres approchestechnologiques émergent actuellement comme par exemple AJAX qui s'appuie surla machine Javascript dont le support est généralisé dans les navigateurs web et surdes interactions à base de services web entre le client riche et le code serveur.

La couche Serveur Cette couche exécute le code applicatif J2EE pour le compte deplusieurs utilisateurs simultanément. Ce même code est à son tour décomposé en deuxcouches distinctes :


1. La couche présentation : cette couche exécute le code des interfaces utilisateurde type client léger. Il produit généralement des pages XML qui sont retournéesà un navigateur représentant la couche client qui se charge alors de les interpréterpour construire le rendu attendu.

2. La couche métier : cette couche correspond au code dé�nissant le métier ou lafonction même de l'application. L'environnement J2EE propose plusieurs types decomposants pour mettre en ÷uvre cette couche. Les composants de session gèrentle code métier représentant une session d'interaction entre un utilisateur et l'appli-cation, cette session pouvant ou non contenir des données propres. Les composantsde données encapsulent l'accès aux bases de données relationnelles. En�n les com-posants réactifs permettent au code métier de réagir sur l'arrivée d'événementsprovenant d'applications externes ou d'événements internes à l'application (pro-grammation asynchrone dans le cadre d'une application J2EE).

La couche information La couche information (couche EIS dans la �gure 2.8) secompose des systèmes qui fournissent les informations de l'entreprise nécessaires aux ap-plications. Ces informations peuvent être fournies par d'autres applications patrimoniales,ou directement par des bases de données. Ces principes d'architecture ont un impact surl'organisation des di�érentes phases du cycle de vie d'une application J2EE : sur la phasede développement avec les principes d'organisation du code mais aussi sur les phases dedéploiement et d'exécution.

2.3.3 Comparaison de .Net et J2EE

Après avoir présenté les deux plates-formes, nous allons les comparer. Il est à noter queces plates-formes permettent de concevoir des services web basiques et non composites,même s'ils permettent leur déploiement.Ainsi, .NET et J2EE se ressemblent sur de nombreux aspects mais di�èrent aussi dans leurimplémentation des couches dans leurs architectures respectives (présentation, clients,services, accès aux données).Ainsi, Java se distingue par l'ouverture de ces APIs avec comme maître mot la portabilitédu serveur. Même si .NET possède un module similaire à la JVM (le CLR), il restepropriétaire et plutôt lié au système Microsoft. Quant aux di�érences entre les services,nous noterons que Microsoft propose .NET/COM+ et J2EE les EJB. La distribution estassurée par Remoting pour .NET et RMI sur IIOP pour Java.Nous résumons les avantages et inconvénients suivants :


Avantages pour .NET� Plusieurs de langages,� Réutilisation de l'existant,� Gestion des données,� Gestion des interfaces,� Pas d'implémentations multiples.

Avantages pour J2EE� Un grand nombre d'API,� Variété des plates-formes,� Communauté des développeurs,� Gestion de la persistance EJB,� Pas de contrôle � fort � d'un éditeur

Inconvénients pour .NET� La politique globale de Microsoft (intégration dans les futurs produits),� Une politique de mise en avant de l'IDE Visual Studio.

Inconvénients pour J2EE� Java n'est pas aussi libre qu'on ne le pense.

2.3.4 Oracle BPEL

Oracle BPEL se décline en deux modules complémentaires : Oracle BPEL Process Ma-nager et Oracle Web Services Manager.Oracle BPEL Process Manager [41] fournit une solution complète pour concevoir, déployeret administrer des processus métier exprimés à l'aide du langage normalisé BPEL. Il assureles fonctionnalités suivantes [41] :

� Support natif de BPEL : le langage BPEL est utilisé comme base de description desprocessus.

� Moteur d'orchestration : il interagit avec les services composants le service webBPEL.

� Navigateur UDDI et WSDL : Le navigateur UDDI et WSDL apportent la possibilitéde naviguer dans un référentiel UDDI et de visualiser les interfaces des services Web(au format WSDL). Cette fonctionnalité permet de décrire et de sélectionner leséléments externes avec lesquels interagit le moteur d'orchestration.

� Modeleur graphique de processus : Modeleur de processus en mode �Drag-and-drop�, l'ensemble des verbes du langage BPEL sont accessibles depuis une paletteet peuvent être directement insérés sur un schéma représentant le processus.


� Console graphique de supervision : Elle o�re une interface de type web permettantde gérer, administrer et déboguer les processus déployés sur le BPEL serveur.

� Fonctionnalités de Work�ow humain : BPEL Designer fournit des assistants per-mettant d'intégrer des interactions de contributeurs humains dans la dé�nition desprocessus.

� Adaptateurs d'integration technique et fonctionnelle : BPEL Designer fournit desassistants permettant la con�guration et l'utilisation d'adaptateurs dans la dé�ni-tion des processus.

Oracle BPEL Process Manager est une interface graphique qui permet de spéci�er desprocessus en utilisant le langage BPEL 1.1. BPEL est le format natif du BPEL Designer,ceci garantit la portabilité des dé�nitions des processus métier. De plus les développeurspeuvent voir et modi�er directement le code source BPEL. BPEL Designer est disponiblesous forme de � Plug-in � Eclipse ou de � Plug-in � Jdevelopper. C'est l'outil de référencedes développeurs pour l'implémentation des processus .

Oracle Web Services Manager [41] permet la sécurisation des services et la dé�nition decontrats de services (SLA). Oracle Web Services Manager apporte la centralisation desdé�nitions et de l'exécution des règles qui régissent les opérations relatives aux servicesWeb. Les fonctionnalités de Oracle Web Services Manager sont :

� De�nition, gestion et Monitoring centralise des règles de sécurité des Services Web� Collecte de statistiques� Outil graphique pour la gestion de l'audit et des règles� Suivi du niveau de service (SLA)

Oracle Web Services Manager est une solution complète permettant d'ajouter des règlesd'administration à l'ensemble des Web Services (existants ou nouveaux) de l'architectureSOA mise en place. Oracle Web Services Manager apporte les fonctionnalités de sécuritéet d'administration nécessaire à une architecture de service.

2.3.5 ActiveBPEL

Nous ne nous étendrons pas assez sur cet outil vu ses similarités avec Oracle BPEL. Cartous sont des environnements graphique destinés à faire de la composition de services webbasés sur BPEL. Ils sont plus ici comme des outils que comme des technologies.ActiveBPEL Designer [1] est un environnement de développement intégré qui permet laconception, les tests et le déploiement d'applications basées sur BPEL. Originaire EclipseReady technologie, ActiveBPEL Designer est utilisé par les développeurs de construiredes applications à faible couplage et de systèmes composites.ActiveBPEL Designer réduit considérablement le coût, le temps et la complexité de laconstruction d'applications BPEL. ActiveBPEL Designer prend en charge la modélisa-


tion � top-down � et � bottom-up �, en fournissant une grande �exibilité à toutes lesétapes du processus d'orchestration.

ActiveBPEL Designer permet de :� Découvrir les services Web existants en utilisant leurs descriptions WSDL.� Construire des processus avec BPEL de façon intuitive en faisant du glisser-déposer.� Simuler des exécutions de processus basés sur des scénarios de tests de l'utilisateur.� Créer et déployer des processus standard BPEL.� Dépanner des processus déployés à distance.

Les processus créés avec ActiveBPEL Designer peuvent être déployés sous BPEL4WS 1.1et WS-BPEL 2.0, y compris la suite ActiveBPEL Entreprise server [1].Le tableau 2.5 résume les propriétés des plates-formes utilisées dans le domaine en lesmettant ensemble avec les objectifs de la thèse en terme d'environnement de mise en placede services web complexes.

Le .NET est la propriété de Microsoft. C'est une plate-forme utilisée pour la mise en placede services web simples, car elle permet de dé�nir la description des services web dans laplupart des cas à l'aide du langage C++. .NET est une plate-forme d'apprentissage facileavec une interface conviviale. Elle permet la production de code pour plusieurs langagesde programmation dont (C#, VB.NET, C++) ce qui est un certains avantage dans ledomaine. Le fait d'être une plate-forme propriétaire, fait qu'elle est plus utilisée par lesdéveloppeurs en entreprise, car un de ses objectifs est l'augmentation de la productivité.Cette plate-forme n'a pas d'outils de modélisation de services web.

J2EE est aussi une plate-forme permettant plutôt la description de services web que leurscomposition, donc elle permet la mise en ÷uvre de services web simples. Elle est le plussouvent associée à des éditeurs (EDI - Environnement de Développement Intégré) dotésd'interface conviviale comme Eclipse, NetBeans. J2EE est une plate-forme de Sun micro-systems ce qui explique l'utilisation de Java comme unique langage de développement.L'utilisation de Java par des communautés de développeurs comble le défaut de plusieurslangages comme chez .NET. J2EE n'pas d'outils de modélisation, car il utilise le pussouvent des EDI comme interface. Il est à noter que parmi les EDI utilisés, certains ontdes possibilités de modélisation d'objets, même si ces outils ne sont pas spéci�ques auxservices web. Même étant une propriété de Sun, Java est considéré comme plutôt libre,ce qui explique son statut de logiciel � pas aussi libre �.

Oracle BPEL est une plate-forme destinée à la composition de services web BPEL. Elleest munie d'une interface conviviale et d'outils destinées à la modélisation de services webBPEL avec production de code BPEL. C'est une plate-forme propriétaire de ORACLE.Elle est plutôt utilisée dans les entreprises pour l'augmentation de la productivité et de lavaleur ajoutée. Elle est l'une des solutions utilisées pour la facilitation de l'apprentissage


de BPEL. Le code BPEL exige un moteur BPEL pour fonctionner, ce qui la rend lourde.

ActiveBPEL est une plate-forme destinée à la composition de services web BPEL. Elleest munie d'une interface conviviale et d'outils destinées à la modélisation de services webBPEL avec production de code BPEL. C'est une plate-forme open source en partie. Elleest utilisée par le monde libre. Elle est l'une des solutions utilisées pour la facilitation del'apprentissage de BPEL. Le code BPEL exige un moteur BPEL pour fonctionner, ce quila rend lourde.


XX

XX

XX

XX

XX

XPlate-form

esCr

itères

Type

sde

service

sApp

rentiss

age

Interfa

ceLa

ngag

esutilisés

Dévelo

ppeu

rsMod

élisatio

nCa

tégo

rie

.NET

Simples

Facil

eCo

nviviale

Plusieu

rsEn

trep

rise

non

Prop

riétaire

lang

ages

J2EE

Simples

Facil

eVa

riété

des

Java

Commun

auté

non

Pasau

ssi

plates-fo

rmes

libre

Activ

eBPE

LCo

mplexes

Facil

eCo

nviviale

BPEL

Entrep

rise

oui

libre

Oracle

BPEL

Complexes

Facil

eCo

nviviale

BPEL

Entrep

rise

oui

Prop

riétaire

Tabl

e2.5�Ta

bleaucompa

ratif

desp

lates-f

ormes

exist

antesp

arrapp

ortà

noso

bjectifs

2.4 Conclusion 49

2.4 ConclusionLe présent chapitre qui a traité de l'état de l'art sur les services web et leurs langagesde composition, nous a vu faire le tour des technologies utilisées dans le domaine, deslangages de composition et des plates-formes de développement et de déploiement deservices web.Les technologies de base utilisées comme XML, SOAP et WSDL restent toujours incon-tournables, même lors de la composition des services composites, car la publication dansun UDDI se fait toujours à l'aide d'un �chier WSDL. La communication est assurée àl'aide du protocole SOAP et le format des données reste toujours XML.Comme présentés dans la deuxième section, les langages de composition de services com-plexes, ont évolué avec les besoins de l'entreprise. Ainsi, si les premiers langages étaientl'÷uvre de constructeurs particuliers (XLANG de Microsoft et WSFL de IBM), les exi-gences du marché ont conduit à des associations de constructeurs pour l'obtention delangages standardisés (ebXML de OASIS et BPEL de Microsoft et IBM).Il est à noter que la plupart des langages en place sont des langages de balises (nepermettent pas alors de dé�nir les structures de données complexes). Leur apprentissageest di�cile et cela malgré des tentatives d'amélioration (BPELJ), même s'ils sont tousportables, car basés sur le format XML.Les plates-forme sont de deux groupes, celles qui permettent la description des servicesweb simples et celles basées sur BPEL pour la composition de services web. Ces dernièressont plutôt des EDI (Environnement de Développement Intégré) pour BPEL et non desplates-forme multi-fonctionnelles comme .NET et J2EE. Dans leur majorité, ces plates-forme sont toutes caractérisées par leur lourdeur d'exploitation, car nécessitant souventd'autres composants matériels et/ou logiciels.Il devient alors nécessaire et surtout intéressant de trouver un langage de compositionqui puisse s'adapter aux besoins grandissants de l'entreprise qui sera à la fois de niveaud'expressivité élevée, portable et facile d'apprentissage. C'est là l'objectif principal de cestravaux de recherche.


Chapitre 3

Méthodologies UML de conceptiond'applications coopératives

La méthodologie est littéralement la � science (logos) de la méthode �, le discours (logos)sur la méthode, la cartographie des méthodes ou tout simplement la méta-méthode ouméthode des méthodes [99]. La méthodologie est la systématisation de l'étude. Dans lecadre de la conception des applications coopératives, la méthodologie permet de la miseen place d'un plan de travail et de concepts à utiliser.

Dans ce chapitre, nous allons présenter quatre sections. La première section concerne unétat de l'art sur les méthodologies de conception d'applications, pour faire un tour d'ho-rizon des méthodes, dans la seconde, nous allons présenter le langage UML, il s'agit deprésenter les éléments fondamentaux d'UML tout en s'intéressant plus aux éléments quipeuvent servir dans la composition des services web tels que les diagrammes de classes,d'activités, de séquence, de collaboration, et d'interaction. Dans la troisième partie nousparlerons des applications coopératives et des work�ow comme type d'applications co-opératives. En�n, dans la section � méthodologie UML pour concevoir des applicationscoopératives � nous présenterons certains éléments d'UML dans la conception des appli-cations coopératives avec un exemple de service web.

Uni�ed Modeling Langage a été dé�ni par l'OMG. Dans ses versions 1.X, UML proposaitun ensemble de diagrammes permettant de faire de la modélisation de processus métiersmême si le but premier de ce langage était la conception orientée objet. Actuellement,UML permet de modéliser non seulement la structure d'une application mais égalementson comportement.

52Chapitre 3. Méthodologies UML de conception d'applications coopératives

3.1 Etat de l'art sur les méthodologies de conception d'ap-plication

L'utilisation des systèmes d'information dans l'entreprise est devenue une réalité incon-tournable. Leur conception représente alors un problème de premier plan, car dans lasociété de l'information que nous vivons actuellement, la maîtrise de l'information estun atout majeur pour comprendre le marché. Actuellement, la conception des systèmesd'information est toujours traitée avec précaution a�n d'en tirer le maximum de pro�tpossible.Dans ce chapitre, nous allons présenter les di�érentes méthodologies de conception desystèmes d'information qui ont existé jusqu'aux méthodologies basées sur UML.Les méthodes de conceptions dans leur histoire ont été diverses, parmi lesquelles nouspouvons retenir : les méthodes cartésiennes, les méthodes systématiques, les méthodesassistées par des outils, les approches dynamiques, les méthodes orientées objet et lesoutils intelligents [86].

3.1.1 Les méthodes cartésiennes

Elles constituent la première génération des méthodes. Elles sont basées sur les conceptset techniques de décomposition hiérarchique des processus et de �ux de données. Cesméthodes associent au paradigme cartésien une approche fonctionnelle de conception [86].L'approche fonctionnelle est basée sur le fait que les méthodes cartésiennes préconisentd'analyser et de concevoir le système d'information en se basant sur ses fonctions [86]. Lesystème est ainsi identi�é à une fonction globale de gestion et la conception du systèmerevient à l'analyse de la fonction. Le paradigme cartésien est e�ectué selon une démarchedescendante � top-down � de haut en bas, qui part du général va vers le particulier et meten ÷uvre le principe de Descartes [86]. La démarche conduit à diviser la fonction généraleen autant de sous-fonctions qu'il faut, ainsi l'analyse de chacune des sous fonctions conduità l'analyse de la fonction générale. La fonction générale est ainsi éclatée en un arbre deprocessus comme illustré sur la �gure 3.1.L'exemple que nous donnons ici représente la gestion des inscriptions dans une universitémalienne. Le processus d'inscription se divise en sous processus tels que la préparationdes �ches individuelles pour les étudiants, l'inscription entre autres. L'inscription estdécoupée en remise des �ches, remplissage des �ches, et paiement des frais entre autres.Les méthodes cartésiennes ont été in�uencées d'une part, par la programmation modulaireet les approches de décomposition fonctionnelle de Parnas et Wirth [86] et, d'autre part,par les �ux de données et les méthodes de conception structurées introduites par You [86],puis développées par Meyers [86].Comme exemples de méthodes cartésiennes, nous pouvons citer : la méthode S.A.D.T.

3.1 Etat de l'art sur les méthodologies de conception d'application 53

Figure 3.1 � Méthodes cartésiennes : Décomposition "TOP-DOWN"

(Structured Analysis and Design Technique), les méthodes I.E., SA, ISAC, PSL/PSA [86]parmi d'autres. Pour la plupart, ces méthodes étaient applicables à des systèmes de taillemoyenne avec des fonctionalités relativement claires à priori.Les méthodes fondées sur la décomposition hiérarchique des processus sont utilisées demanière intensive dans le monde entier, même si l'expérience montre que ces approchessont surtout adaptées à la description d'un système existant ou d'un système déjà conçu.Ce sont des instruments d'analyse plus que de conception [86].L'avantage principal des méthodes cartésiennes est le découpage de la fonction géné-rale en sous-fonctions, car cela facilite beaucoup la compréhension et les traitements.Ces méthodes étaient basées sur la méthode universelle de Descartes développée dans lecélèbre � Discours de la méthode �.Dans [86], les insu�sances suivantes ont été relevées :

� L'absence de travaux théoriques susceptibles de fournir des fondements solides auxconcepts et techniques de décomposition descendante.

� L'impression des dé�nitions qui rendent di�cile l'utilisation de concepts tels que�ux de données, archive, action.

� L'impossibilité de prendre en compte le temps, la synchronisation et le parallélismedes processus. Il semble même que la synchronisation de processus soit impossible


à modéliser dans une démarche descendante.� L'incapacité à traiter les cas particuliers et d'exception, toute l'attention étant

focalisée sur l'analyse des �ux et activités typiques.� L'insu�sance de la modélisation des données : en outre, la solution de juxtapo-

sition de techniques de modélisation de données à celles de la décomposition destraitements largement préconisée aujourd'hui, notamment dans les outils CASE(Computer Assisted Software Engineering), est loin d'être fondamentalement satis-faisante.

� L'absence de guide méthodologique précis rend la pratique de la méthode di�cile àmaîtriser. La compétence méthodologique ne peut s'acquérir que par l'expérimen-tation intensive.

� L'évaluation de la cohérence, de la complétude et de la qualité d'une solution estdi�cile.

3.1.2 Les méthodes systématiques

Elles constituent les méthodes de la seconde génération. Les méthodes de conceptionde systèmes d'information (S.I.) de la seconde génération sont entièrement centrées surla modélisation des données. Elles combinent une approche conceptuelle au paradigmesystémique [86], [59].Le paradigme systémique puise ses racines dans la théorie des systèmes. L'organisationest considérée comme composée de trois systèmes principaux : système de pilotage, sys-tème opérationnel et système d'information. Le système est considéré comme un modèleabstrait de la réalité de l'organisation. Il apporte aux décideurs la connaissance nécessairepour agir et prendre des décisions qui s'imposent.Fortement inspirées de la théorie des systèmes, ce paradigme utilise un certain nombrede schémas dont celui de la �gure 3.2 mettant en relation les systèmes opérationnel etdécisionnel de l'organisation.Avec l'approche conceptuelle, le processus de conception du S.I. est devenu un processus demodélisation centré essentiellement sur la modélisation des données. Les modèles dé�nisfacilitent l'interprétation de la sémantique des systèmes et permettent la spéci�cation durésultat de la modélisation à un haut niveau d'abstraction. Le modèle obtenu est appeléschéma conceptuel [86]. Les mots clés utilisés sont : Entité, Association, Cardinalités,Identi�ant.D'après [86], le processus de composition part d'un ensemble d'attributs et de dépen-dances et se propose de regrouper les attributs en relations normalisées en fonction desdépendances qui lient les attributs. Les méthodes systémiques avaient comme objectifprincipal de produire le modèle relationnel proposé par P. Chen [86]. P. Chen suggère de

3.1 Etat de l'art sur les méthodologies de conception d'application 55

Figure 3.2 � Schéma d'un système

voir toute réalité comme composée d'entités ayant entre elles des associations.Une entité est une chose qui peut être distinctement identi�ée : un étudiant, une forma-tion, un cycle d'études.Une association est une relation entre entités dans laquelle chacune d'elles joue un rôlespéci�que. La relation étudiant est inscrit dans une formation à l'université est une asso-ciation entre étudiant et formation qui sont des entités. Les entités et les associations sontcaractérisées par des propriétés. Le nom de l'étudiant, l'adresse de l'étudiant ou encorel'intitulé d'une formation en sont des exemples.Le modèle entité-association fournit des techniques de représentation sous forme de dia-gramme d'un schéma conceptuel qui sont illustrées sur la �gure 3.3.Les méthodes systémiques ont eu l'avantage de faire évoluer l'informatisation des entre-prises avec la mise en place des bases de données informatiques et leurs utilisation presquegénéralisée dans toutes les entreprises. Elles avaient aussi l'avantage de permettre une


Figure 3.3 � Exemple de schéma conceptuel

abstraction des systèmes d'information avec l'élaboration des modèles de toute sorte.D'après [86], le modèle relationnel reste limité dans ses possibilités de représentation desinformations. Il ne permet pas en particulier de visualiser les données et les liens quiexistent entre elles.

3.1.3 Les méthodes assistées par des outils

Les années 80 ont vu apparaître sur le marché des produits d'aide au développementdes systèmes d'information. Cette génération dite troisième génération des méthodes deconception de systèmes d'information est basée sur des outils d'aide au développementencore appelés AGL (Atelier de Génie Logiciel).Ces outils sont fréquemment implantés en monoposte. Ils sont composés :

� de dictionnaires des données,� d'interfaces graphiques,� de modules de documentation,� de moyens de contrôle de la qualité et de la correction des schémas,� de générateurs de code.

Ces produits permettaient d'augmenter la productivité des développeurs et de passerde l'artisanat à la production industrielle des systèmes d'information. Il ont permis unecertaine automatisation du processus de développement des S.I. dont le cadre est dé�nipar les méthodes. Ces méthodes assistées par des outils ont plutôt servi dans la gestionautomatisée des spéci�cations des schémas des di�érents niveaux de conception : concep-tuel, logique, physique et autres. Elles n'ont pas servi à l'automatisation du processusde modélisation pour lequel les spéci�cations sont produites, car pour la plupart d'entreelles, l'accent était mis sur la production du schéma des données qui en général est justedessiné à l'aide de l'outil. Le processus de son obtention en général était manuel. Le pluscélèbre des outils d'aide à la modélisation est le PowerAMC de Sybase.

3.2 Le langage UML 57

3.1.4 Les méthodes orientées objets

Ces méthodes permettent la conception des systèmes en mettant l'accent sur les objets quicomposent les systèmes. L'intérêt croissant de l'approche orientée objet est l'utilisationdes objets du domaine et non les fonctionalités ce qui garantit une meilleure évolution dusystème.La modélisation objet consiste à créer une représentation informatique des éléments dumonde réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui si-gni�e indépendamment d'un langage de programmation. Il s'agit donc de déterminer lesobjets présents et d'isoler leurs données et les fonctions qui les utilisent. Pour cela desméthodes ont été mises au point. Entre 1970 et 1990, de nombreux analystes ont conçudes approches orientées objets, si bien qu'en 1994 il existait plus de 50 méthodes objet.Toutefois seules 3 méthodes ont véritablement émergé :

� La méthode OMT (Object Modeling Technique) de Rumbaugh [78], [75], [77], [94]� La méthode BOOCH'93 [78], [75], [77], [94] de Booch� La méthode OOSE de Jacobson (Object Oriented Software Engineering) [78], [75],

[77],[94].

A partir de 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont uni leurs ef-forts pour mettre au point le langage de description UML (Uni�ed Modeling Language),qui permet de dé�nir un langage standard en incorporant les avantages des di�érentesméthodes précédentes (ainsi que celles d'autres analystes). Il permet notamment de � pro-grammer � entièrement une application avec un langage qui modélise toutes les compo-santes du futur programme. Ce langage est un standard de l'OMG (Object ManagementGroup) un organisme de standardisation dans le domaine des systèmes d'information. Lelangage UML sera développé dans la section suivante, car il englobe presque toutes lesméthodes orientées objets et a pris l'ascendant sur toutes les autres méthodes.

3.2 Le langage UML

Les nouvelles technologies s'appuient sur le modèle objet. En terme d'analyse et de mo-délisation objet, UML (Uni�ed Modeling Language) est aujourd'hui un standard incon-tournable, stabilisé et industriel.UML est un langage standard conçu pour l'écriture de plans d'élaboration de logiciels.Il peut être utilisé pour visualiser, spéci�er, construire et documenter les artefacts d'unsystème à forte composante logicielle.UML est adapté à la modélisation de système, depuis les systèmes informatiques d'en-


treprise jusqu'aux applications distribuées basées sur le web, en passant par les systèmestemps réel embarqués. C'est un langage très expressif qui couvre toutes perspectives né-cessaires au développement puis au déploiement des systèmes.La notation UML [78], [75], [77] constitue une étape importante dans la convergence desnotations utilisées dans le domaine de l'analyse et la conception objet puisqu'elle repré-sente une synthèse des méthodes les plus utilisées : OMT (Object Modeling Technique),Booch et OOSE (Object-Oriented Software Engineering) [94]. Depuis la première versiond'UML, le standard de l'OMG (Object Management Groupe) n'a pas cessé d'évoluer.Cependant la refonte majeure d'UML est le standard UML2.0 [75], [77] adopté en août2003. UML2.0 représente un pas réel pour supporter la croissance des logiciels actuels,d'une part par le support de la nouvelle vision de l'OMG à savoir MDA (Model DrivenArchitecture) [94], et d'autre part par le support des nouvelles technologies en particulierl'approche par composants logiciels.Depuis ses premières versions, le standard UML est caractérisé par sa sémantique dé�niepar une approche de méta-modélisation. Un méta-modèle est la dé�nition des construc-tions et des règles de création des modèles [94]. Le méta-modèle d'UML dé�nit doncla structure que doit respecter tout modèle UML. Le méta-modèle d'UML1.x est dé�nidans un seul document. Le standard UML2.0 est maintenant divisé en deux documents :UML2.0 Infrastructure [78] et UML2.0 Superstructure [77].UML Infrastructure décrit les constructions fondamentales utilisées pour la dé�nitiond'UML2.0 sous forme d'une librairie d'infrastructure (Infrastructure Library).UML Superstructure réutilise et ra�ne la librairie d'infrastructure et dé�nit le méta-modèle proprement dit, vu par les utilisateurs. L'approche de méta-modélisation adoptéepar l'OMG est connue comme une hiérarchie à quatre niveaux [78] (voir la �gure 3.4) :

Niveau méta-méta-modèle (M3) : M3 est le niveau méta-méta-modèle, il dé�nit lelangage de spéci�cation du méta-modèle. Le MOF (Meta Object Facility) est un exempled'un méta-méta-modèle. Le MOF [100] est un ensemble d'interfaces standard permettantde dé�nir et modi�er des méta-modèles et leurs modèles correspondants. C'est un moyende dé�nir la syntaxe et la sémantique d'un langage de modélisation. Il a donc été créépar l'OMG a�n de dé�nir la notation UML, par exemple. C'est un standard de méta-modélisation.

Niveau méta-modèle (M2) : M2 est le niveau méta-modèle. Le méta-modèle d'UMLse situe à ce niveau et il est spéci�é en utilisant le MOF, c'est-à-dire les concepts duméta-modèle d'UML sont des instances des concepts de MOF. La �gure 3.4 montre deuxméta-classes du méta-modèle UML : Class et Association.


Figure 3.4 � L'architecture à quatre niveaux de l'OMG

Niveau modèle (M1) : M1 correspond au niveau des modèles UML des utilisateurs.Les concepts d'un modèle UML sont des instances des concepts du méta-modèle UML.La �gure 3.4 montre un extrait de diagramme de classes pour une application bancairecontenant deux classes Client et Compte liées par une association UML. Les deux classessont des instances de la méta-classe Class et le lien est une instance de la méta-classeAssociation du méta-modèle UML.

Niveau objets (M0) : M0 correspond au niveau des objets à l'exécution. Il s'agit ici dedeux objets must et acc des instances des deux classes Client et Compte respectivement.Le méta-modèle d'UML est décrit en utilisant une partie de la notation d'UML lui-même.


Les concepts suivants sont utilisés :

� les classes d'UML, pour décrire les méta-classes,� les attributs, pour décrire les propriétés attachées à une méta-classe,� les associations, pour décrire des liens entre les méta-classes,� les paquetages (packages), pour regrouper les méta-classses par domaine.

Selon [94], le méta-modèle UML spéci�e la structure que doit respecter tout modèle UML.En d'autres termes, il spéci�e des contraintes structurelles sur ces modèles (les contraintesOCL). UML inclut le langage OCL (Object Constraints Language) comme un moyensupplémentaire pour renforcer les contraintes structurelles des modèles UML en ajoutantdes invariants sur les classes du méta-modèle d'UML. Les contraintes OCL au niveauméta-modèle représentent donc des règles de conformité des modèles UML, elles sontexprimées au niveau méta-modèle et elles sont évaluées sur tous les éléments de modèlesUML, instances des éléments du méta-modèle d'UML. Les contraintes OCL sont étenduespour être utilisées aussi pour exprimer des propriétés sur un modèle UML (niveau M1).Elles sont utilisées pour spéci�er des invariants, des pré et des post conditions sur lesopérations et des gardes sur les transitions dans les machines à états. Les contraintesexprimées au niveau M1 sont évaluées et véri�ées sur les modèles d'objets (niveau M0).En dépit de son expressivité, UML est simple à comprendre et à utiliser. Pour apprendreà s'en servir e�cacement, il faut d'abord s'appuyer sur une représentation conceptuellede ce langage, ce qui nécessite l'assimilation de trois éléments fondamentaux :

� les briques de base d'UML,� les règles qui déterminent la manière de les assembler,� et quelques mécanismes généraux qui s'appliquent à ce langage.

3.2.1 Les diagrammes

La notation UML est décrite sous forme d'un ensemble de diagrammes. La premièregénération d'UML (UML1.x), dé�nit neuf diagrammes pour la documentation et la spé-ci�cation des logiciels. Dans UML2.0 Superstructure [77], quatre nouveaux diagrammesont été ajoutés : il s'agit des diagrammes de structure composite (Composite structurediagrams), les diagrammes de paquetages (Packages diagrams), les diagrammes de vued'ensemble d'interaction (Interaction overview diagrams) et les diagrammes de synchro-nisation (Timing diagrams). Ils sont regroupés dans deux classes principales :


� Diagrammes statiques : ils regroupent les diagrammes de classes, les dia-grammes d'objets, les diagrammes de structure composite, les diagrammes de com-posants, les diagrammes de déploiement, et les diagrammes de paquetages.

� Diagrammes dynamiques : les diagrammes de séquence, les diagrammes decommunication (nouvelle appellation des diagrammes de collaboration d'UML1.x),les diagrammes d'activités, les machines à états, les diagrammes de vue d'ensembled'interaction, et les diagrammes de synchronisation.

Dans ce document, nous nous sommes intéressés à cinq types de diagrammes : les dia-grammes de cas d'utilisation, de classes, de séquence, de communication et d'activité.Nous décrivons brièvement ces diagrammes. Les diagrammes de cas d'utilisation, de sé-quence, de communication et d'activité sont choisis pour leur possible utilisation pourla conception de la chorégraphie et de l'orchestration des services et les diagrammes declasses pour leur possibilité de représenter la structure interne des services web com-plexes lors de leur composition ainsi que la représentation des données manipulées parles services web. Les autres diagrammes sont présentés en détail dans [77].

Les diagrammes de cas d'utilisation Les cas d'utilisation (use cases) représententl'apport principal de Ivar Jaccobson et sa méthode OOSE [94] à UML. L'objectif des casd'utilisation est l'expression des besoins en termes de services que doit assurer le système.Les diagrammes de cas d'utilisation dans UML dé�nissent deux concepts principaux : lesacteurs, et les cas d'utilisation. Un acteur est une entité extérieure au système qui peutinitier l'un de ses cas d'utilisation. Un cas d'utilisation est une fonctionalité o�erte par lesystème.

La �gure 3.5 montre un diagramme de cas d'utilisation pour un exemple d'une appli-cation bancaire. L'acteur principal est le guichetier de la banque qui peut initier troiscas d'utilisation de système : Retrait d'un compte, Dépôt sur un compte, et Création d'uncompte. Les diagrammes de cas d'utilisation permettent de dé�nir deux types de relationsentre les cas d'utilisation : l'inclusion et l'extension.

Un cas d'utilisation peut être compris dans un autre cas d'utilisation ; ceci signi�e quele service spéci�é par le deuxième est compris dans le service du premier. Un cas d'uti-lisation peut étendre un cas d'utilisation père ; ceci signi�e que le service du premier estune spécialisation du service du deuxième. Les relations entre les cas d'utilisation sontnotées comme des �èches de dépendances avec les mots-clés � include � pour l'inclusionet � extend � pour l'extension.


Figure 3.5 � Le diagramme de cas d'utilisation d'une application bancaire

Les diagrammes de classes : Le diagramme de classes permet de dé�nir la structurede toutes les classes qui constituent un système. Une classe nommée est dé�nie par desattributs et des méthodes.Les classes constituent les briques de base les plus importantes d'un système orienté objet.Une classe est la description d'un ensemble d'objets qui partagent les mêmes attributs,les mêmes opérations, les mêmes relations et la même sémantique. Une classe implémenteune ou plusieurs interfaces.Le diagramme de classes dans la �gure 3.6 montre deux classes Compte et Client, laclasse Compte est dé�nie avec un attribut balance et trois méthodes getBalance, depositet withdraw.

Figure 3.6 � Extrait d'un diagramme de classes d'une application bancaire


En plus de la structure des classes, le diagramme de classes dé�nit aussi des relations entreses classes (les associations d'UML). Une association UML peut contenir des informationssupplémentaires : le nom de l'association, le rôle de chaque classe dans l'association et lescardinalités de chaque classe dans l'association. L'association dé�nie dans le diagrammede classes de la �gure 3.6 illustre la relation de possession entre les deux classes Compteet Client. Une instance de la classe Client peut être liée à un ensemble d'instances de laclasse Compte (cardinalité *). Cependant une instance de la classe Compte est liée à uneet une seule instance de la classe Client (cardinalité 1).UML o�re aussi des mécanismes d'abstraction dans les diagrammes de classes à traversles notions de l'héritage, de classes abstraites, et d'interfaces. L'héritage (spécialisation/ généralisation) est un mécanisme permettant à une sous-classe d'hériter des attributset des méthodes d'une autre classe appelée super-classe. Une sous-classe peut redé�nirl'implantation d'une ou de plusieurs méthodes de la super-classe : c'est le mécanisme dela surcharge. Une classe abstraite peut contenir des méthodes dont le corps est dé�ni parses sous-classes. Le nom d'une classe abstraite dans un diagramme de classes est noté enitalique. Une classe d'interface dé�nit seulement les signatures des méthodes sans aucuneimplémentation et ses sous-classes fournissent leur implémentation. Une classe d'interfaceest notée avec le stéréotype � Interface �. Les classes peuvent être regroupées dans despaquetages. Un paquetage UML (Package) est un espace de nommage. La �gure 3.6illustre un paquetage UML appelé Banque qui regroupe les deux classes Compte et Client.

Les diagrammes de séquence : Ici, nous présenterons les trois générations de dia-grammes de séquence qu'UML a connu. Il s'agit des diagrammes avant UML1.5, lesdiagrammes de UML1.5 et les diagrammes de UML2.0 qui sont actuellement les plus uti-lisés. Cet intérêt particulier à ce type de diagrammes est dû au fait qu'il permet au mieuxl'illustration des services web complexes, car il permet la modélisation de l'orchestration.Depuis les premières versions d'UML, les diagrammes de séquence ont été introduitscomme un moyen pour décrire les interactions dans un système. La première générationdes diagrammes de séquence d'UML1.x est inspirée des OMSC (Object Message SequenceChart) qui sont eux même dérivés, avec des modi�cations des MSC (Message SequenceChart). Un diagramme de séquence (DS) d'UML permet de décrire les interactions entreles objets du système selon un point de vue temporel. Il spéci�e l'ordre des envois et desréceptions de messages [75].La �gure 3.7 montre un exemple de diagramme de séquence et ses éléments de base. Lesaxes verticaux représentent les lignes de vie des objets participant dans le DS. Un objetdans un DS est soit une instance d'une classe du système, soit une instance d'un acteur.La notion d'activation permet d'indiquer la durée d'une action et elle décrit le �ot decontrôle sur la ligne de vie d'un objet.


Graphiquement, elle est décrite par un rectangle sur la ligne de vie de l'objet. Les inter-actions entre les objets sont modélisées par des �èches horizontales appelées messages.Un message est dé�ni par un objet émetteur et un objet récepteur. Sur la �gure 3.7,nous avons des messages m1 et m2. La création et la destruction des objets sont des casparticuliers de messages dans un DS (voir la �gure 3.7).

Figure 3.7 � Exemple d'un diagramme de séquence d'UML1.x et ses concepts

Figure 3.8 � Le branchement conditionnel dans les diagrammes de séquence d'UML1.x

La recursion est un message particulier pour lequel l'objet récepteur et l'objet émetteur


sont identiques (voir la �gure 3.7). En plus de ces éléments de base, la spéci�cation desdiagrammes de séquence d'UML1.x [75] fait référence à deux mécanismes décrivant lebranchement et l'itération de messages. La �gure 3.8 montre un exemple de branchementconditionnel dans un diagramme de séquence d'UML1.x [75]. Le branchement est réaliséen associant des gardes (conditions) aux messages. Seul le message dont la garde estvéri�ée est envoyé. Le branchement est en quelque sorte un moyen de décrire l'alternativeentre l'envoi de deux ou plusieurs messages. Le standard UML1.x fait référence à lapossibilité d'ajouter des itérations dans un diagramme de séquence. Cependant il ne ditpas comment cette itération est possible. Les diagrammes de séquence d'UML1.x sontdé�nis dans la partie collaboration du méta-modèle d'UML.La �gure 3.9 montre la partie du méta-modèle d'UML dé�nissant les interactions dansla version UML1.5 [75], [94]. Une interaction, spéci�ée par un diagramme de séquence,regroupe un ensemble de messages échangés entre un ensemble d'instances de Classi-�erRole. La sémantique d'un diagramme de séquence peut être considérée comme unerelation d'ordre partiel entre ses messages [75], [94]. Elle est dé�nie par les deux asso-ciations activator et predecessor (voir la �gure 3.9). L'association activator dé�nit unerelation de causalité entre un message entrant (qui joue le rôle d'activator) et un ensemblede messages sortants sur une ligne de vie. L'association predecessor décrit une relationd'ordre entre les messages sortants sur une instance.

Figure 3.9 � Une partie de méta-modèle des interactions dans UML1.5

Limites des diagrammes de séquence d'UML1.x : Comme nous l'avons vu ci-dessus, la sémantique de la première génération des DS d'UML1.x est dé�nie par les deux


relations predecessor et activator. La spéci�cation UML1.5 dé�nit les prédécesseurs d'unmessage par : � The set of Messages whose completion enables the execution of the currentMessage. All of them must be completed before execution begins �. Dans le cas des mes-sages asynchrones, la question posée est comment un émetteur d'un message asynchronesait-il que ce message est terminé pour passer au message suivant ? Les auteurs de [78]et de [89] présentent une étude critique des diagrammes de séquence d'UML1.x dans unenvironnement asynchrone. De plus, les diagrammes de séquence d'UML1.x sont pauvresen termes de mécanismes pour la description des interactions complexes. La sémantiquedes branchements conditionnels et de l'itération est ambiguë. Les auteurs de [37] et [94]pointent cette ambiguïté et proposent d'associer aux diagrammes de séquence des anno-tations textuelles pour permettre la description explicite des alternatives et des itérations.Les mêmes constats de manque d'expressivité de la première génération des diagrammesde séquence ont été retrouvés dans le Request For Proposal (RFP) pour UML2.0.La nouvelle génération adoptée des diagrammes de séquence dans UML2.0 [77] [94] a prisen compte ces manques et elle améliore fortement ceux proposés dans UML1.x.Le standard UML2.0 a apporté une refonte majeure aux diagrammes de séquence. Il estmaintenant possible de décrire et spéci�er les exigences sous forme d'un ensemble dediagrammes de séquence de base et par la suite de les composer en utilisant des opé-rateurs pour obtenir des scénarios plus complexes. Aussi, les diagrammes de séquencedans UML2.0 sont maintenant considérés comme des collections partiellement ordonnéesd'événements (au lieu des collections ordonnées de messages dans UML1.x), ce qui in-troduit la concurrence et l'asynchronisme et permet la dé�nition de comportements pluscomplexes.Les diagrammes de séquence dans UML2.0 sont dé�nis dans la section Interaction de laréférence UML2.0 Superstructure [77] [94]. La �gure 3.10 résume cette section. La méta-classe Interaction spéci�e une unité de comportement décrivant l'échange d'informationentre un ensemble d'objets dans un diagramme de séquence. La méta-classe Lifeline spé-ci�e un objet dans une interaction. InteractionFragment est une partie d'interaction. Lacomposition entre une interaction et InteractionFragment spéci�e qu'une interaction peutenglober un ensemble de sous-interactions. CombinedFragment dé�nit une compositiond'un ensemble de InteractionOperand en utilisant un opérateur d'interaction. Chaquemessage est dé�ni par deux événements : un événement spéci�ant son émission et unautre spéci�ant sa réception. L'événement d'émission d'un message précède toujours l'évé-nement de sa réception. La méta-classe EventOccurrence dé�nit les événements dans uneinteraction. Un événement se produit sur une ligne de vie particulière, les événements surla même ligne de vie sont totalement ordonnées [77] [94].Les diagrammes de séquences (DS) d'UML 2.0 peuvent être composés en utilisant un en-semble d'opérations appelés Interaction Operator. Les opérateurs de composition possibles


Figure 3.10 � Une partie du méta-modèle des diagrammes de séquence d'UML2.0

dans UML 2.0 sont dé�nis dans le méta-modèle par l'énumération Interaction Operator(voir la �gure 3.10). Un opérateur d'interaction est associé à une interaction combinée(CombinedFragment, voir la �gure 3.10) et il compose un ensemble d'opérandes d'inter-action (InteractionOperand, voir la �gure 3.10). Nous allons décrire dans ce qui suit lesopérateurs fondamentaux.

� La séquence (seq) : L'opérateur de séquence spéci�e une séquence faible entre lescomportements des opérandes [94]. La composition séquentielle faible signi�e queles événements situés dans le premier DS sur une ligne de vie particulière doiventêtre exécutés avant les événements du deuxième DS situés sur la même ligne devie [94]. L'opérateur seq n'impose pas de synchronisation entre des lignes de viedi�érentes.

� L'alternative (alt) : L'opérateur alt dé�nit un choix entre les comportements d'unensemble de DS.

� L'itération (loop) : L'opérateur loop spéci�e l'itération de comportement d'un DS.� La séquence forte (strict) : L'opérateur strict spéci�e une composition séquentielle

forte. Au contraire de l'opérateur seq, où l'ordre est seulement imposé sur les événe-ments sur la même ligne de vie, l'opérateur strict spéci�e que tous les événements(quelle que soit leur localisation) du premier DS doivent être exécutés avant lesévénements du deuxième DS.

� La composition parallèle (par) : L'opérateur par spéci�e que les événements desopérandes peuvent être exécutés en parallèle, c'est-à-dire dans n'importe quel ordreou en concurrence.

� Option (opt). L'opérateur opt spéci�e un choix entre le comportement d'un DS


ou un comportement vide. Cet opérateur est équivalent à une alternative où ledeuxième opérande est une interaction vide (sans événements).

Une nouvelle notation des diagrammes de séquence a été introduite dans UML2.0. Un dia-gramme de séquence d'UML2.0 est maintenant décrit par un cadre rectangulaire étiquetépar le mot-clé sd (pour Sequence Diagram) dans le coin gauche supérieur. La Figure 3.11montre la notation d'un diagramme de séquence simple dans UML2.0.

Figure 3.11 � Exemple d'un DS dans UML2.0 et ses concepts

La composition des diagrammes de séquence d'UML2.0 est décrite dans des diagrammesde séquence combinés. La �gure 3.11 montre un exemple de diagramme de séquence com-biné qui référence et compose trois diagrammes de séquence : SD1, SD2 et SD3. Lesopérateurs de composition dans les diagrammes de séquence combinés sont décrits pardes cadres rectangulaires avec un coin gauche supérieur étiqueté par l'opérateur tel queseq, alt, loop entre autres. Les opérandes pour les opérateurs de séquence, d'alternative,et de parallélisme sont séparés par des lignes horizontales discontinues. La compositionséquentielle peut être aussi implicitement donnée par l'ordre relatif de référence aux dia-grammes de séquence. Par exemple le DS CombinedSD dans la �gure 3.12, est équivalentà l'expression : loop (SD1 seq (SD2 alt SD3)).

UML2.0 propose aussi une autre notation pour la spéci�cation de la composition des


diagrammes de séquence dans ce qui est appelé les diagrammes de vues d'ensemble d'in-teractions (qui sont en quelque sorte des diagrammes d'activités dont les activités sontdes DS). La �gure 3.13 montre un exemple de diagramme de vues d'ensemble d'interac-tions ; il est équivalent à l'expression : SD1 seq (SD2 alt SD3).

Figure 3.12 � Exemple d'un diagramme de séquence combiné

Les diagrammes de collaborations : Comme les diagrammes de séquence, les dia-grammes de collaboration sont également des diagrammes d'interaction. Les diagrammesde collaboration véhiculent les mêmes informations que les diagrammes de séquence, maisils se concentrent sur les rôles des objets plutôt que sur les moments où les messages sontenvoyés.Dans un diagramme de séquence, les rôles d'objets sont les sommets et les messages


Figure 3.13 � Exemple d'un diagramme de vue d'ensemble d'interaction dans UML2.0

sont les liens de connexion. Dans un diagramme de collaboration (voir �gure 3.14), lesrectangles rôle d'objet sont étiquetés avec les noms de classe ou d'objet (ou les deux).Dans le contexte de l'architecture d'un système, une collaboration permet de nommer unepartie conceptuelle qui comprend à la fois des aspects statiques et dynamiques. Une colla-boration désigne un ensemble de classes, d'interfaces et d'autres éléments qui travaillentensemble.Les diagrammes de collaborations comportent deux aspects : une partie structurelle quiprécise les classes, les interfaces et les autres éléments qui travaillent ensemble pour réaliserla collaboration désignée et une partie comportementale qui précise la dynamique del'interaction entre ces éléments.La partie structurelle d'une collaboration peut comporter n'importe quelle combinaisond'éléments, tels que des classes, des interfaces, des composants et des n÷uds. Au sein d'unecollaboration, ces éléments peuvent être organisés à l'aide de l'ensemble des relationshabituelles d'UML, y compris les associations, les généralisations et les dépendances. En


fait, les aspects structurels d'une collaboration peuvent utiliser toutes les possibilités demodélisation structurelle d'UML.La �gure 3.14 est un exemple représentant l'aspect structurel de la collaboration. Sur cette�gure, nous avons trois classes décrivant la collaboration entre l'objet AgentDeTransportet l'objet Message. Les di�érents messages sont ajoutés un à un à une queue dans la classeQueue, ce qui dé�nit une dépendance entre les objets Queue et Message.La �gure 3.15 illustre l'aspect comportemental du même diagramme. Ce diagramme pré-sente les échanges de messages entre les trois objets du système. Les messages échangéssont créer(), ajouterMessage() et supprimerMessage().

Figure 3.14 � Aspects structurels d'une collaboration

Les diagrammes d'activités D'après [14], les diagrammes d'activités font partie descinq diagrammes d'UML utilisés pour la modélisation des aspects dynamiques des sys-tèmes. Un diagramme d'activités est principalement un organigramme qui montre le �otde contrôle d'une activité à l'autre. Ils sont utilisés pour modéliser les aspects dynamiquesd'un système. Il s'agit de la modélisation des étapes séquentielles et/ou concurrentes dans


Figure 3.15 � Aspects comportementaux d'une collaboration

un processus. Un diagramme d'activité permet également de modéliser le �ot d'un objetlorsqu'il passe d'un état à l'autre à di�érents points dans le �ot de contrôle.Une activité est une exécution non atomique en cours à l'intérieur d'un automate à états�nis [14]. Les activités �nissent par produire une action, composée de calculs atomiquesexécutables qui aboutissent à un changement dans l'état du système ou au retour d'unevaleur.Les diagrammes d'activités sont importants non seulement pour modéliser les aspects dy-namiques d'un système, mais également pour construire des systèmes exécutables grâce àl'ingénierie vers l'aval et à la rétro-ingénierie. La �gure 3.16 est un exemple de diagrammed'activités décrivant le work�ow lié à la construction d'une maison.Dans un diagramme d'activité, il est possible d'inclure une branche qui spéci�e les di�é-rents chemins que l'on prend en se basant sur une expression booléenne. La �gure 3.17illustre un branchement conditionnel dans un diagramme d'activités.

3.2.2 Avantages et inconvénients

Au vu de la section précédente, nous pouvons retenir les forces et faiblesses suivantes dulangage UML et des méthodologies basées sur lui.Le langage UML cadre l'analyse objet en o�rant :

� di�érentes vues complémentaires d'un système, qui guident l'utilisation des conceptsobjets,


Figure 3.16 � Diagramme d'activités

� plusieurs niveaux d'abstraction, qui permettent de mieux contrôler la complexitédans l'expression des solutions objets.

Les principaux points forts de UML [12], [82] sont :


Figure 3.17 � Branchement conditionnel dans un diagramme d'activités

� UML est un langage formel et normalisé, il permet un gain de précision et un gagede stabilité. ce qui encourage l'utilisation d'outils.

� UML est un support de communication performant, il cadre l'analyse et il facilitela compréhension de représentations abstraite complexes.

� UML est polyvalent et sa souplesse en font un langage universel.� Sa notation graphique permet d'exprimer visuellement une solution objet.� L'aspect formel de sa notation limite les ambiguïtés et les incompréhensions.� Son aspect visuel facilite la comparaison et l'évaluation de solutions.

En termes de faiblesses, nous pouvons retenir [12], [82] :

� La mise en pratique d'UML demande un apprentissage et passe par une périoded'adaptation.

� UML n'est pas à l'origine des concepts objets, mais en constitue une étape majeure,car il uni�e les di�érentes approches et en donne une dé�nition plus formelle.

� Le processus non couvert par UML est une autre clé de la réussite d'un projet. Or,l'intégration d'UML dans un processus n'est pas triviale et améliorer un processusest une tâche complexe et longue.

3.2.3 Comparaison avec les autres méthodologies

En comparaison aux méthodes qui ont co-existé et comme toute méthodologie objet, lesméthodologies basées sur UML ont un certain avantage dû au méta-modèle d'UML.Aujourd'hui, UML se généralise dans la conception de systèmes d'information et de plusen plus d'utilisateurs cherchent à exploiter la �exibilité et l'expressivité d'UML pourrépondre à des besoins spéci�ques. Ce qui a permis aujourd'hui une grande variété de


domaines utilisant UML, et notamment le développement des applications coopératives.Dans cette partie, nous allons développer la comparaison entre UML et une méthodesystémique : MERISE (Méthode d'Etudes et de Réalisations Informatiques par Sous-Ensemble). Le choix de MERISE est motivé par le fait que cette méthode a été l'une desméthodes les plus utilisées sur le marché. Ses concepts sont compatibles avec la presquetotalité des systèmes de gestion des bases des données relationnelles.Les points de comparaison entre UML et MERISE dans cette section sont : les principesfondamentaux des deux méthodes et la modélisation métier par les deux méthodes.

Les principes Cinq principes fondamentaux ont présidé à l'élaboration de MERISE.Il s'agit de : l'approche systémique, les cycles de construction du système d'information,l'approche fonctionnelle, la vision duale données - traitements et l'approche qui part dugénéral pour atteindre le particulier. Nous présenterons pour chaque principe cité, lessimilitudes ou di�érences au niveau d'UML.D'après [59], pour le principe de l'approche systémique, la méthode MERISE s'intéresseaux systèmes ouverts qui sont en relation permanente avec leur environnement. Ces sys-tèmes sont caractérisés par :

� la globalité : Un système n'est pas la simple agrégation de parties indépendantes.Son comportement dépasse la somme des comportements de ses éléments. Il formeun tout cohérent et indivisible.

� la rétroaction : Le fonctionnement du système est basé sur le principe d'interactionentre les composants du système et entre le système et son environnement.

� la �nalité : Le système réagit à court terme aux sollicitations en cherchant à rame-ner ses variables fondamentales dans des plages de valeurs qui lui assurent sa survie.

Selon [59], l'approche par les cas d'utilisation d'UML constitue de fait une approche detype systémique. En e�et le système étudié est considéré de façon externe comme uneboîte noire qui réagit à des sollicitations extérieures qui sont formalisés par des �èchesdont l'origine est l'acteur. L'ensemble des cas d'utilisation traduit le comportement dusystème à modéliser.En ce qui concerne les cycles du processus de construction d'un système d'information,MERISE préconise 3 cycles : le cycle de vie, le cycle d'abstraction et le cycle de décision.

� le cycle de vie de MERISE comprend la gestion, la naissance, la maturité, l'obso-lescence et la mort du système. Quant à UML, il ne dé�nit pas de cycle de vie. Lecycle de développement sous-jacent à UML est itératif et incremental, guidé par les


cas d'utilisation et centré vers l'architecture [59].� le cycle d'abstraction de MERISE est composé de trois niveaux : conceptuel, or-

ganisationnel et physique. Dans MERISE /2 un quatrième niveau existe commeintermédiaire entre les niveaux organisationnel et physique : c'est le niveau lo-gique. D'après [59], UML permet de modéliser les di�érents niveaux du système(conceptuel, organisationnel, logique et physique). Pour cela il propose des notionscomme : cas d'utilisation, paquetage, classes, composant, n÷ud et di�érents dia-grammes pour modéliser le système aux di�érents niveaux d'abstraction.

� Le cycle de décision permet d'organiser l'intervention des personnes de l'entrepriseen fonction de la hiérarchie des décisions à prendre à propos du contenu du sys-tème et de son mode de développement [59]. MERISE permet à chaque acteur del'entreprise de participer à la conception du système et cela à l'aide des validationsdes di�érents modèles. Comme MERISE, UML se soucie d'associer étroitement lesutilisateurs dans les tâches d'analyse et de conception.

Dans le domaine de l'approche fonctionnelle, nous remarquons que : d'après [59], MERISEpropose une approche descendante où le système réel est décomposé en activités, elles-mêmes déclinées en fonctions, alors qu'UML se démarque de cette approche en remplaçantles fonctions par les cas d'utilisation dans le contexte réel.Pour l'approche données - traitements, MERISE divise le système en deux vues : une vuestatique (données) et une vue dynamique (les traitements). Pour UML avec l'approcheobjet, les informations et les traitements sont associés pour assurer un certain niveau decohérence.Dans le cadre des échanges, MERISE utilise les notions de �ux et d'acteurs pour dé�nirle champ de l'étude. UML décrit l'entreprise sous forme de processus métier et ensuitesous forme de travailleurs (de rôles) qui interagissent dans l'exécution de ces processus.Les activités sont ensuite décrites dans les diagrammes d'activités.

La modélisation du métier D'après [59], la modélisation du métier dans MERISEs'appuie sur les concepts de domaine, d'acteurs, de �ux, de modèles liés aux niveauxconceptuel et organisationnel pour décrire le métier de l'entreprise indépendamment deses structures. Pour présenter les modèles, cette méthode utilise des notions d'entités,d'associations, de cardinalités, d'identi�ants et d'occurrences. Ces notions permettent lareprésentation du système du point de vue statique, alors que les notions d'acteurs, de�ux modélisent les modèles dynamiques du système. Pour UML, la dé�nition du domaineest un préalable. Elle doit être proposée dès l'étude d'opportunité et peut évoluer jusqu'àla �n de la phase d'élaboration du système. Le diagramme de cas d'utilisation est unereprésentation externe qui ne montre que les liens de haut niveau sans expliquer les détails


des échanges, car seule l'existence de la relation est montrée.

Figure 3.18 � Diagramme des �ux (MERISE)

Les �gures 3.18 et 3.19 illustrent deux schémas et deux représentations des échanges entreles acteurs du système à l'aide de MERISE et d'UML.Sur la �gure 3.18, les acteurs sont regroupés en deux acteurs principaux (client et plani�-cateur) qui sont représentés par les rôles d'acheteur et de plani�cateur. Ces deux acteursparticipent chacun de son côté aux échanges dans le système commun (marché). Parexemple le processus est déclenché par l'acheteur qui demande un marché, le plani�ca-teur prend en charge la gestion du marché en faisant une étude, après quoi, la commandeest enregistrée et mise à la disposition de la livraison. Une fois la livraison e�ective, lacomptabilité s'occupe de la suite des tâches 3.18.


Figure 3.19 � Exemple de cas d'utilisation (UML)

Sur le diagramme des cas d'utilisation de UML, on constate presque les mêmes acteurs(client, plani�cateur), mais ici le plani�cateur est moins ambigu, car les acteurs secon-daires sur le diagramme des �ux sont bien visibles sur la �gure 3.18, il s'agit du dépôt,de la comptabilité et du contrôle des marchandises.Dans [59], nous retrouvons des tableaux de comparaison entre MERISE et UML sur lesnotions de type et d'instance comme le tableau 3.1. Dans ce tableau, nous constatons quela notion d'entité en MERISE correspond à la notion de classe, celle d'occurrence d'entitéde MERISE à la notion d'instance d'UML. Les notions d'association et d'occurrencesd'association de MERISE correspondent respectivement aux notions d'association et delien d'UML. En�n à la notion modèle conceptuel des données de MERISE, UML associela notion de diagramme des classes. En plus des classes, UML utilise aussi les notionsd'interface et de package sur son diagramme des classes. UML améliore la représentationdes classes, car en plus des données qui caractérisent les objets, UML ajoute les opérations.Une comparaison exhaustive des modèles de MERISE (MERISE/2) aux diagrammes


Equivalence sur les types Equivalence sur les instancesMERISE UML MERISE UML

Entité (objet) Classe Occurrence d'entité InstanceAssociation Association Occurrence Lien(relation) d'association

Modèle conceptuel Diagramme Schéma d'occurrences Diagramme d'objetsdes données (MCD) des classes d'entités

Table 3.1 � Comparaison entre MERISE et UML sur les notions de type et d'instance

d'UML est présentée dans [59]. De la dite comparaison, il ressort que :

� Le diagramme de classes et le diagramme d'objets sont proches des MCD (Mo-dèle Conceptuel de Données) et MOD (Modèle Organisationnel des Données). Lesdi�érences fondamentales résident dans l'intégration des méthodes dans les classeset les objets. Les diagrammes de classes contiennent aussi des paquetages et desinterfaces.

� Le diagramme de collaboration n'a pas d'équivalence.� Le diagramme de séquence possède des points communs avec le MCC (ModèleConceptuel de Communication) et le MFC (Modèle des Flux Conceptuels) pour cequi concerne les échanges d'information.

� Le diagramme d'états-transitions est quasi identique aux CVO (Cycle de Vie desObjets) et CVOO (Cycle de Vie Organisationnel des Objets).

� Le diagramme d'activités présente des similitudes avec les diagrammes de �ux et serapproche du MCTA (Modèle Conceptuel de Traitement Analytique) et du MOTA(Modèle Organisationnel de Traitement Analytique) pour fournir une vue globalede l'organisation.

� Le diagramme de composants montre la mise en ÷uvre physique des modèles lo-giques avec l'environnement de développement.

� Le diagramme de déploiement présente des similitudes avec le modèle d'architecturede TACT, les n÷uds pouvant être assimilés aux serveurs logiques.

Les avantages d'UML sur MERISE se résument comme suit :� UML est un language de modélisation (et pas une méthode à proprement parler)

se basant sur l'hypothèse que le logiciel développé est orienté objet.� Dans UML, l'architecture logicielle a une place prépondérante et est intégrée très

en amont dans l'élaboration du système d'information.� UML admet des extensions qui sont regroupées en pro�ls UML. Cette notion qui est

apparue depuis la version UML 1.3 est un moyen de structuration des extensions


UML (tagged values, stéréotypes et contraintes). Ce qui rend UML adaptable à lapresque totalité des systèmes existants.

L'un des objectifs de cette thèse est aussi la mise en place d'une méthodologie de concep-tion de services web, le tableau 3.2 nous donne un résumé des caractéristiques des mé-thodologies existantes.Les méthodes cartésiennes sont l'une des premières méthodes de conception de systèmesd'information. La philosophie principale de ces méthodes est le fait qu'elles considèrentle système comme la fonction principale qu'elle réalise. Elles sont fondées sur la méthodecartésienne qui stipule que tout problème complexe doit être découpé en au tant depetits systèmes pour faciliter leurs traitements. Ces méthodes n'utilisaient pas la notionde représentation par modèle. Elles ont atteint leurs limites avec l'évolution des besoinsdes entreprises, car elles n'ont pas pu s'adapter.Les méthodes systémiques qui ont en quelque sorte remplacé les méthodes cartésiennes,étaient fondés sur la notion de système découlant de la théorie des système. Elles considé-raient l'entreprise comme une ensemble de sous-systèmes. Leur philosophie était basée surla notion de modèle. La force de ces méthodes était la modélisation des données. Les mé-thodes systémiques se sont aussi révélées incapables d'exprimer certaines exigeances dessystèmes d'information telles que la spécialisation des objets. Ces problèmes d'adaptationont abouti à l'abandon progressif des méthodes systémiques.Les méthodes orientées objet sont basées sur le langage UML et utilisent la notion d'objetpour représenter les systèmes d'information. Les méthodes orientées objet sont conçuespresque pour tous les systèmes d'information. La notion d'objet a permis à ces méthodesde s'adapter à tous les systèmes dont les services web. Le méthodes orientées objet les pluscourantes sont : la méthode uni�ée (ou Processus uni�é) [56] et [54], la méthode COMETde Gomaa [56] et la méthode ROPES de Douglass [56]. Ces méthodes sont adaptées auxsystèmes temps réel. Ces méthodes seront détaillées dans le chapitre 6.


``

``

``

``

``

``

`̀Métho

dologies

Critè

res

Type

sde

systèm

esmod

élisables

Philo

soph

iePo

ssibilitésd'ad

aptatio

n

Métho

des

Systèm

esd'inform

ationde

gestion

Systèm

e=

safonc

tionprincip

ale,

non

cartésien

nes

detaillemoyen

nedivisio

nde

lafonc

tionprincip

ale

Métho

des

Systèm

esd'inform

ationde

gestion

App

rochesystém

ique

,qu

elque

sad

aptatio

nssystém

ique

sde

gran

detaille

mod

élisatio

nde

sdo

nnées

réalisé

essous

MER

ISE

Métho

des

Presqu

etous

systèm

esBa

séesurl

elang

ageUML,

oui

Orie

ntéesObjet

dont

lesservice

swe

bla

notio

nd'ob

jet

Tabl

e3.2�Ta

bleaucompa

ratif

desm

étho

dologies

exist

antesp

arrapp

ortà

noso

bjectifs


3.3 Applications coopératives

Dans cette section, nous allons présenter les applications coopératives à travers leursdomaines d'utilisation, la problématique de leur conception après avoir donné une pré-sentation de celles-ci. L'étude ce type d'application se justi�e par le fait que les servicesweb complexes sont des applications coopératives (des sortes de work�ow) fonctionnantsur Internet. Cette étude permettra de comprendre comment la modélisation de ce typed'application se réalise à l'aide d'UML, c'est à dire quels sont les diagrammes UML lesplus appropriés pour leur modélisation.

3.3.1 Présentation

Une application coopérative est une application caractérisée par l'a�ectation dynamiquedes tâches, le partage d'informations, l'interaction entre les membres en collaborationdans le système et la prise de décision mutuelle par négociation ou collective.

Selon [9], dans un cadre purement informatique, l'interaction est la composition parallèlede comportements. La notion de plate-forme coopérative caractérise un système d'ex-ploitation réparti o�rant des services tels que : appel d'o�res, placement dynamique,tolérance aux fautes par replicas ou par points de reprise répartis constants. Une applica-tion coopérative comporte plusieurs �ls de contrôle concurrents qu'il faut coordonner etsa conception est donc très di�érente de la rétro-conception distribuée d'une applicationcentralisée. Une telle application doit prendre en compte la concurrence, la répartitionou la mobilité pour les exploiter pleinement.

La conception et la maintenance d'une application coopérative est complexe, car ellesdemandent à faire un choix entre une structure partagée/répliquée, un contrôle statiqueou dynamique et un placement �xe ou mobile. En plus d'un noyau que l'application doitavoir, il faut se préoccuper [9] :

� du contrôle des accès partagés et/ou de la consistance des accès répliqués,� des synchronisations ou des contraintes temps réel,� des communications et de la sécurité des accès,� de la répartition (placement, migration) et de l'allocation de ressources,� de la tolérance aux fautes,� des interfaces utilisateurs,� des interfaces avec des bases de connaissances et des moteurs d'inférences.

3.3 Applications coopératives 83

3.3.2 Méthodologies UML de conception d'applications coopératives

L'objectif de cette section est d'étudier certains diagrammes de UML et de voir commentles utiliser pour la conception d'applications coopératives. Dans cadre nous parlerons demodélisation de work�ow comme type d'application coopérative.Avant de parler de modélisation de work�ow, voyons d'abord ce que c'est un work�owainsi que ses principes fondamentaux.Le work�ow fait partir du domaine du travail coopératif. Les systèmes d'information co-opératifs mettent en ÷uvre des techniques de work�ow et plus généralement de groupware(logiciel de groupe, collecticiel). Il me semble important de donner une dé�nition précisedu terme work�ow (la gestion automatique du �ux de travail) en le situant par rapportaux autres disciplines du travail de groupe que sont le collecticiel et le CSCW (ComputerSupported Cooperative Work).Le work�ow peut être dé�ni comme un travail coopératif impliquant un nombre limitéde personnes devant accomplir, en un temps limité, des tâches articulées autour d'uneprocédure dé�nie et ayant un objectif global.Dans le cas du work�ow, le terme travail coopératif signi�e que plusieurs personnes sontimpliquées pour atteindre l'objectif global, mais à des étapes di�érentes du déroulementdu travail et cela individuellement à partir du moment où la personne � prend � la tâche.Les systèmes d'information coopératifs sont des systèmes d'information orientés vers lamodélisation de l'organisation contrairement aux autres systèmes d'information plutôtorientés vers l'organisation des données et l'automatisation des traitements.De façon pratique, le work�ow décrit le circuit de validation, des tâches à accomplir entreles di�érents acteurs d'un processus, les délais, les modes de validation et fournit à chacundes acteurs les informations nécessaires pour la réalisation de sa tâche.Les work�ow font partie des systèmes à forte composante logicielle, donc ils n'existentjamais indépendamment des autres systèmes. Leur modélisation consiste en la représen-tation des processus métier qui les composent, UML contient des outils permettant cela,tels que les diagrammes de cas d'utilisation, de collaboration et d'activité.Nous utiliserons les diagrammes d'activités pour modéliser ces processus métier a�n dereprésenter la façon dont les di�érents systèmes collaborent. D'après [14], pour modéliserun work�ow, il faut :

� déterminer un point central pour le work�ow. Pour les systèmes importants, il estimpossible de représenter dans un seul diagramme tous les �ots de travail intéres-sants ;

� sélectionner les objets métier qui ont des responsabilités de haut niveau pour cer-taines parties du work�ow global. Il s'agit d'objets réels qui font partie du vocabu-


laire du système ou au contraire d'objets abstraits. Dans chaque cas, il faut créerune travée pour chaque objet métier important ;

� identi�er les préconditions de l'état initial du work�ow et les postconditions de sonétat �nal, cela a�n d'aider à la modélisation de son périmètre ;

� en partant de l'état initial du work�ow, préciser les activités et les actions qui ontlieu dans le temps et les représenter dans le diagramme d'activités soit comme desétats d'activité ; soit comme des états d'action ;

� réduire les actions compliquées ou les groupes d'actions qui apparaissent de façonrépétée en les transformant en états d'activité et proposer un diagramme d'activitésà part qui développe chacun d'eux ;

� représenter les transitions qui connectent ces états d'activité et d'action en com-mençant d'abord par les �ots séquentiels du work�ow, puis en continuant avec lesbranchements conditionnels et en�n avec la synchronisation des �ots concurrents ;

� dans le diagramme d'activités, faire �gurer également les objets importants impli-qués dans le work�ow. Représenter leurs changements de valeurs et d'état de façonà communiquer le but du �ot d'objet.

La �gure 3.20 décrit un diagramme d'activités pour un work�ow simple qui se produitlorsqu'un client renvoie une marchandise suite à une commande par correspondance. Letravail commence avec Demander retour du Client, puis il se poursuit avec Televentes(Obtenir num retour). Il revient ensuite au Client (Expédier article) et à Entrepot (Re-cevoir article) puis à Entrepot (Restocker article) et prend �n au service Comptabilité(Créditer compte). Comme le montre le diagramme, un objet important (a, une instancede Article) fait aussi partie du processus et passe de l'état retourne à l'état disponible.

3.4 Conclusion

Ce chapitre a été consacré au panorama des méthodes de conception des systèmes d'in-formation. Ainsi un tour d'horizon a été fait des méthodes dites cartésiennes jusqu'auxméthodes orientées objet dont celles basées sur le langage UML, car ce langage à la di�é-rence des méthodes permet, grace à son méta-modèle de faire des notations particulièreslors de la conception de certains passages d'un système d'information. Une attentionparticulière a été donc portée au langage UML, car les méthodologies basées sur UMLont actuellement pris un ascendant sur toutes les autres qui ont tendance à disparaîtreau pro�t d'UML. D'ailleurs depuis son apparition, seule la méthodologie MERISE avecsa version MERISE/2 a opposé une timide résistance. Dans la présentation de chaquegénération de méthodes, nous avons fait ressortir les avantages et inconvénients (plusprécisément les insu�sances) qui ont amené à chaque fois à la création d'une méthode

3.4 Conclusion 85

Figure 3.20 � Modélisation d'un work�ow

améliorée.Lors de la présentation de UML, nous avons privilégié certains diagrammes comme lesdiagrammes de classes, de séquence, d'activités et de collaboration. Ces diagrammes sonten fait les mieux adaptés à l'étude des services web complexes, car les services web sont desapplications comme des work�ow qui nécessitent une interaction avec d'autres servicesweb. Leur conception demande des outils qui modélisent l'aspect statique, mais aussidynamique des systèmes d'information.Nous avons également fait une étude comparative des méthodes MERISE et UML enétudiant leur attitude vis-à-vis des principes généraux, de la modélisation métier et dupoint de vue notation et concepts.Un tableau (le tableau 3.2) a été conçu pour résumer les fonctionalités et caractéristiquesdes méthodologies existantes. Au vu de ce tableau, il apparaît que nos objectifs quiconsistent à l'élaboration d'une méthodologie pour JCWSL est fondée, car aucune desméthodologies ne prévoit la modélisation des services web complexes. Une adaptation dulangage UML pourra être envisagée.


Le présent chapitre a aussi présenté les applications coopératives a�n comprendre leurconception.

Deuxième partie

CONTRIBUTIONS

Chapitre 4

Le langage JCWSL (Java ComplexWeb Service Language)

Ce chapitre concerne la présentation exclusive du langage que nous avons mis en ÷uvrepour la composition des services web. Dans ce chapitre, nous présentons tour à tour : lesconcepts du langage, les instructions du langage en les décrivant une à une, les processusde génération des analyseurs du langage et celui de génération d'un service web avec lelangage.

4.1 Introduction

Nous avons constaté dans le chapitre 2, qu'il existe beaucoup de langages dans le domainede la composition des services web. Il est à remarquer que la presque totalité de ceslangages ont en commun la portabilité due chez certains à l'utilisation de XML et chezd'autres à l'utilisation des JVM (Java Virtual Machine) ou correspondants. Quand à lasimplicité, elle varie selon le langage choisi, car certains sont simples par l'utilisation desenvironnements graphiques et d'autres tutoriels graphiques.Notre travail concerne le développement d'un langage de programmation permettantd'obtenir l'abstraction du comportement observable d'un service web complexe et degénérer un code exécutable en Java. Ce langage permet le développement dynamique d'unservice web complexe et la génération de son comportement observable en BPEL. C'estainsi que nous allons proposer un langage capable de décrire un service web complexe enutilisant la richesse du langage Java. Ce qui permettra d'obtenir un langage aussi simple,expressif et communicatif comme Java.Ce travail est fait en utilisant les outils WSDL4J [6] et BPWS4J [47], etAntlr. Ce langageest nommé Java Complex Web Service Language (JCWSL).Le langage à mettre en place combinera BPEL (pas assez expressif ) et Java (pas assezfonctionnellement structurant). Il est à noter que ces deux langages sont basés sur des

90 Chapitre 4. Le langage JCWSL (Java Complex Web Service Language)

paradigmes di�érents. BPEL a une approche Work�ow, tandis que Java a une approcheObjet. Comme le langage sera plus proche de Java que BPEL en terme de paradigmes.JCWSL est un langage de script de Java enrichi des constructeurs de BPEL. L'objectifprincipal est de concevoir les services web complexes en utilisant le langage Java et dé�niren même temps le comportement du service web avec les constructeurs de BPEL. Le choixde Java est essentiellement dû à sa popularité dans la communauté des services web. Lesconstructeurs de BPEL sont dé�nis et implémentés en respectant la sémantique dé�niepar la description du langage.JCWSL présente les avantages suivants :

� niveau élevé d'expressivité : Il supporte le langage Java, et donc o�re un niveauélevé d'expressivité pour dé�nir et concevoir un service web complexe,

� transparence : L'orchestration des services web locaux ou distants est intégré dansla langage de façon transparente,

� �exibilité : Il o�re deux types d'invocation de l'opération : invocation visible ouinvisible. Une invocation visible apparaît dans le comportement de service, alors quel'invisible exécute l'invocation sans apparaître dans le comportement de service,

� fortement couplé : JCWSL prolonge d'une manière élégante et normale le lan-gage Java. Ainsi, la manipulation des opérations et des messages sont très facileset sont visibles et accessibles dans les parties implementation et comportement.

4.2 Description du langageDans cette section, nous allons présenter JCWSL de façon rigoureuse en utilisant lanotion de BNF (Backus-Naur Form). Cette représentation permet de dé�nir les règlessyntaxiques de notre langage.

4.2.1 Notions de BNF

La forme de Backus-Naur (souvent abrégée en BNF, de l'anglais Backus-Naur Form) estune notation permettant de décrire les règles syntaxiques des langages de programmation.C'est donc un méta-langage. Elle est utilisée dans certains livres pour décrire le langageétudié, mais également par de nombreux logiciels d'analyse syntaxique comme les parserspour travailler sur des �chiers sources de plusieurs langages di�érents. C'est une notationpour des grammaires formelles de type hors-contexte (car on dé�nit les termes hors deleur contexte, pour replacer ensuite la dé�nition de ces termes dans ce contexte).En BNF, on distingue les méta-symboles, les terminaux et les non terminaux. Les méta-symboles sont tout simplement les symboles de BNF. Les symboles non terminaux sontles noms des catégories que l'on dé�nit, tandis que les terminaux sont des symboles du

4.2 Description du langage 91

langage décrit.Exemple de conception des méta-symboles.

<structure_if> ::≡ "if" ( <condition>) "{" <code> "}"

<structure_if>, <condition> et <code> sont des non-terminaux.::≡ est un méta-symbole signi�ant est dé�ni par."if", "(", ")", "{" et "}" sont des terminaux.

Les méta-symboles utilisés dans notre document sont :

� " " les symboles terminaux sont placés entre guillemets,� ::≡ signi�e � est dé�ni par �,� | dé�nit les alternatives,� <> les chevrons encadrent les non-terminaux,� [] les parties encadrées par des crochets sont optionnelles,� () les parenthèses éliminent les ambiguïtés d'analyse,� ∗ signi�e � peuvent être répétées zéro ou plusieurs fois �,� + signi�e � peuvent être répétées une ou plusieurs fois �.

4.2.2 La BNF de JCWSL

Ainsi, en se basant sur les concepts de la section précédente, la BNF principale représen-tant le langage est la suivante :CWSLanguage ::≡ <ImportBloc><DefBloc>

ImportBloc est composé à son tour de deux blocs :Un bloc d'importation de services web basiques qui permet d'inclure dans un service webcomplexe des services nécessaires existants.ImportBloc ::≡ ("importBWS" <ID>=<STRING> ";" | "import" <ID>(.<ID>)* ";")+Il est à noter que ce bloc est composé d'au moins une instruction importBWS car il faut aumoins un service web à invoquer pour composer un service complexe. Un bloc ImportBlocpeut ne pas contenir d'instruction import s'il n'est pas nécessaire d'utiliser d'API Java.

Comme exemple d'illustration d'importations, nous donnons ici un exemple de l'exempledu service web JeuxQuiz (voir Annexe B).import Java.io.*;importBWS Squiz= "http://localhost:8080/axis/services/jeux?wsdl";


DefBloc représente la dé�nition d'un service web complexe. Il est composé d'un bloc dedéclaration (declaration) et d'un bloc de comportement (main).DefBloc ::≡ "public CWSDefinition" <ID> {[<declaration>]<main>}

Nous allons illustrer une dé�nition de service, par celle du service JeuxQuiz (voir AnnexeB).public CWSDefinition JeuxQuiz{

// declarations// main

}

Le bloc declaration représente la déclaration des opérations locales et/ou des messageslocaux. Cette partie est facultative, car on peut ne pas avoir besoin de dé�nir de messageslocaux et/ou d'opérations locales.declaration ::≡ (<MessDeclaration>|<OpDeclaration>)*

MessDeclaration assure la dé�nition d'un message. Un message est identi�é par son nomet comprend les variables qui le composent et leurs types. Chaque message comporte aumoins une variable, car les messages dé�nis dans un service web complexe JCWSL, sontdes messages complexes décrivant les données à échanger.MessDeclaration ::≡ "public DefMessage" <MessageName>

"{"(<Variabletype> <VariableName>;)+"}"

Dans le service jeuxQuiz (voir Annexe B), nous avons les messages suivants à déclarer :public DefMessage Question{squiz.RandomQuestion question;}public DefMessage Answer{String choice;}public DefMessage Level{int value;}public DefMessage Score{int value;}public DefMessage NbQuestions {int value;}public DefMessage ChoiceMode{String message;}public DefMessage Response{int id; String choice;}public DefMessage CheckedResponse{boolean result;}

OpDeclaration permet de dé�nir une opération. Une opération est identi�ée par un nomet est composée de un ou deux messages selon son type. Il existe trois types :

� opération d'entrée : Input,� opération de sortie : Output,� opération d'entrée/sortie : Intput/Output.


Une opération peut aussi contenir un corps qui est représenté par un code Java. La BNFdécrivant OpDeclaration est la suivante :OpDeclaration ::≡ "public DefOperation" <OperationName>

"(" <Input>":"<messagetype><ID> ")"| "("<Output>":"<messagetype><ID> ")"| "("<Input/Output>":"<messagetype><ID>,<messagetype><ID> ")""{" <OperationBody> "}"

OperationBody ::≡ (<java>|<execute>)*java ::≡ "JavaCode" "{" (instructionJava)+"}"

Dans le service JeuxQuiz (voir Annexe B), nous avons six opérations dont voici les dé-clarations.public DefOperation beginGame(Input/Output: NbQuestions nbquestion, ChoiceMode mychoice){}public DefOperation randomLevel(Input: Level random) {}public DefOperation clientLevel(Input: Level specified) {}public DefOperation displayQuestion(Output: Question myquestion){}public DefOperation checkAnswer(Input: Answer answer) {}public DefOperation finalScore(Output: Score score) {}

Pour JavaCode, nous donnons ici, un code permettant des initialisations dans le serviceweb JeuxQuiz (voir Annexe B). Le bloc JavaCode permet d'ajouter du code en ligne dansun service web complexe JCWSL. Il peut être utilisé pour l'appel d'une méthode externe.Dans ce cas, il sera nécessaire de développer d'abord une classe indépendante en Java,l'archiver et l'importer avec le constructeur import.JavaCode{

int nbQuestion=0;vScore.setValue(0);boolean resulttat=false;

}

Exemple d'utilisation de méthode externe dans un code Java : on suppose que nous avonsbesoin de représenter une date dans le format "jj/mm/yyyy" (c'est-à-dire deux chi�respour le jour, deux chi�res pour le mois et quatre chi�res pour l'année). Pour cela, nousavons besoin d'importer une classe Java puis appliquer le format de date indiqué ci-dessus.Dans le code ci-dessous, la méthode format() est appelée. Elle appartient à la variableVarDeFormatage qui est du type SimpleDateFormat du package java.text.*.import java.text.*;


import java.util.*;.....JavaCode{

SimpleDateFormat VarDeFormatage=new SimpleDateFormat("dd/MM/yyyy");Date uneDate=null;String stDate="";stDate=VarDeFormatage.format(uneDate);

}

Les commentaires en JCWSL sont représentés par :

� // pour une ligne� /* */ pour plusieurs lignes.

Exemples : // ce ci est un commentaire sur une ligne/* ce ci est un

commentaire surplusieurs lignes

*/

Le deuxième élément de DefBloc est main. Cet élément représente le comportement pro-prement dit du service web complexe. Il est constitué par les activités du service webet/ou des blocs Java. Le bloc main est dé�ni par la BNF suivante :main ::≡ "void main" "{"(<variables>|<process>|<Java>)*"}"

Nous donnerons ici, le comportement de notre service JeuxQuiz (voir Annexe B) commeexemple de dé�nition de comportement.void main {

// variables// process

}

variables représente la section dans la quelle nous devons mettre les variables qui serontutilisées dans le service pour les échanges entre le service web complexe et les servicesbasiques invoqués. La BNF de <variables> est :variable ::≡"Variables""{"(<varelement>)+ "}"

varelement ::≡"Variable""("<varName>","<varMessageType> ")"";"


Pour exemples, voici les variables du service web JeuxQuiz (voir Annexe B). Ici, lesvariables vLevel, clientAnswer, currentQuestion, currentAnswer, questionAnswer,vMode, vNbQuestions et vScore sont déclarées respectivement pour les types de messagesLevel, Question, Answer, Response, CheckedResponse, ChoiceMode, NbQuestions etScore.Le constructeur Variables est dé�ni à l'image de la section variables de BPEL. Auconstructeur Variables, on associe uniquement les variables aux types de messages, caril ne permet ne pas de contrôler les types primitifs de Java et les types dé�nis dans despackages importés. Pour dé�nir des variables de types primitifs de Java ou venant depackages importés, on utilise la déclaration dans JavaCode.Variables{

Variable(currentQuestion, Question);Variable(vLevel, Level);Variable(clientAnswer, Answer);Variable(currentAnswer, Response);Variable(questionAnswer, CheckedResponse);Variable(vMode, ChoiceMode);Variable(vNbQuestions, NbQuestions);Variable(vScore,Score);

}

process représente le comportement du service complexe et est composé des construc-teurs suivants :process ::≡ sequence|receive|reply|invoke|throw|wait|pick|switch|while|

flow|scope|compensate|<java>

Nous présentons dans un premier temps les constructeurs simples sequence, receive,reply, invoke, throw et wait pour terminer par la présentation des constructeurs com-plexes pick, switch, while, flow, scope et compensate.

sequence : Il permet de dé�nir une séquence d'instructions à exécuter séquentiellementdans l'ordre fourni. Il permet de dé�nir les blocs d'instructions dans un programme.sequence ::≡ "Sequence" "{" (<process>)+ "}"

Sequence { .... }

receive : le constructeur receive permet au processus de faire une attente bloquantejusqu'à l'arrivée d'un message.


receive ::≡ "Receive" "([ "createInstance"=""Yes" | "No]"<OperationName>","<InputVariable>")"";"

L'exemple d'illustration est l'attente du nombre de questions d'un joueur du service webJeuxQuiz (voir Annexe B) qui utilise l'opération beginGame pour entrer le nombre dequestions avec la variable vNbQuestions.Receive(beginGame,vNbQuestions);

reply : le constructeur reply permet au processus d'envoyer un message en réponse àun message qui a été reçu. La combinaison des deux messages forme une opération dequestion-réponse sur le portType WSDL du service complexe.reply ::≡ "Reply" "("<OperationName>","<OutputVariable>")"";"

Comme exemple, nous donnons le renvoi de la question obtenue par le service web com-plexe JeuxQuiz à la suite de l'invocation de l'opération randomQuestion() ou de l'opéra-tion randomQuestionByDifficultyLevel(Level) du service basique Squiz. Cet exempleutilise l'opération displayQuestion() de notre service.Reply(displayQuestion,currentQuestion);

invoke : Il permet d'invoquer une opération de type � one-way � (opération à sensunique) ou � request-response � (question/réponse) à travers un port type donné. IciInputVariable et OutputVariable sont des messages. InputVariable représente le pa-ramètre de l'opération invoquée et OutputVariable représente le résultat retourné parl'opération invoquée.invoke ::≡ "Invoke"(<OperationName>,

[<InputVariable>]"[,"<OutputVariable>])";"

Nous avons des exemples d'invocations d'opérations du service basique Squiz comme :// invocation d'une opération sans paramètreInvoke(squiz.randomQuestion, ,currentQuestion);// invocation d'une opération avec paramètreInvoke(squiz.randomQuestionByDifficultyLevel,vLevel,currentQuestion);

throw : le constructeur throw traite les exceptions survenues lors de l'exécution du pro-cessus.


throw ::≡ "Throw" "{" <ThrowName>","<ThrowVariable> "}"

wait : Ce constructeur provoque un temps d'arrêt (une pause) lors de l'exécution d'unprocessus.wait ::≡ "Wait" "(" "For""="<duration-expr> | "Until""="<deadline-expr>");"

Une illustration d'exemple de Wait qui provoque une attente de 5 minutes dans un serviceest le suivant :Wait(For=5);

pick : Il est constitué de branches exclusives. Ces branches sont de deux types :

� l'attente bloquante représentée par OnMessage. Un constructeur Pick, contient unensemble d'attentes bloquantes (au moins une attente),

� l'alarme représentée par OnAlarm. Un constructeur Pick contient au plus une alarme.

Le constructeur pick contient aussi un paramètre de type booléen permettant la créationd'instance du processus. Ce paramètre createInstance, peut prendre la valeur Yes (sipick doit créer une instance du processus) ou No dans le cas contraire.OnMessage permet de créer une attente bloquante jusqu'à l'arrivée d'un message. A l'exé-cution d'un événement (arrivée d'un message), le traitement correspondant est réalisé.La branche OnAlarm s'exécute lorsqu'aucune des branches OnMessage n'est satisfaite.pick ::≡ "Pick" "{"[ "createInstance"=""Yes" | "No"]

("OnMessage" "(" <OperationName>")" ("{"<process>"}")*)+("OnAlarm" "(" "For""="<conditionExpr> |"Until""="<conditionExpr> ")" ("{"<process> "}")* )*}"

Dans le service JeuxQuiz, nous avons illustré, ce constructeur pour pouvoir gérer le choixdu mode de choix des questions.Pick{

OnMessage(randomLevel, vLevel) {Invoke(squiz.randomQuestion, ,currentQuestion);

}OnMessage(clientLevel, vLevel) {

Invoke(squiz.randomQuestionByDifficultyLevel,vLevel,currentQuestion);}

}


Un deuxième exemple illustre l'élément OnAlarm mettre au service de passer à la ques-tion suivante si le joueur n'a pas pu répondre à une question dans le temps imparti de 5minutes.Pick{

OnMessage(checkAnswer,clientAnswer){JavaCode{currentAnswer.setId(currentQuestion.getQuestion().getNumQuestion());currentAnswer.setChoice(clientAnswer.getChoice());}Invoke(squiz.checkResponse,currentAnswer,questionAnswer);JavaCode{if((questionAnswer!=null) &&

(questionAnswer.getResult()==true)) {vScore.setValue(vScore.getValue()+currentQuestion.getQuestion().getPoidsQuestion());

}}

}OnAlarm(For=5){JavaCode{}}

}

switch : Ce constructeur permet de faire un branchement conditionnel. Il permet d'exé-cuter une instruction ou un bloc d'instructions suivant la valeur de la condition associée.switch ::≡ "Switch" "{"(Case:"{""JavaCode" "{"<conditionalExpr>"}""}" "{"(<process>)*"}")+

["Otherwise""{" (<process>)* }"] "}"

Nous illustrons le choix du mode de choix des questions dans le service JeuxQuiz avecswitch. Pour cela, nous allons considérer que si la valeur de vMode.getMessage() estégale à 1, c'est l'opération randomQuestion() qui sera exécutée et si elle est égale à 2l'opération randomQuestionBydifficultyLevel(Level) sera exécutée.Switch {

Case:{JavaCode{vMode.getMessage()=1}}{Invoke(squiz.randomQuestion, ,currentQuestion);}

Case:{JavaCode{vMode.getMessage()=2}}


{Invoke(squiz.randomQuestionByDifficultyLevel,vLevel,currentQuestion);}}

while : Ce constructeur permet la répétition d'une instruction ou d'un groupe d'instruc-tions jusqu'à ce qu'une certaine condition soit satisfaite. Le groupe d'instructions doitêtre mis dans Sequence.while ::≡ "While" "{" "JavaCode" "{" <conditionalExpr> "}" , <process> "}"

Dans notre exemple JeuxQuiz, nous avons illustré la répétition dans le jeu, par une bouclewhile.While{JavaCode{nbQuestion<vNbQuestions.getValue()},

Sequence{....... .......}}

flow : le constructeur flow permet d'indiquer une ou plusieurs activités à exécuter concur-remment.flow ::≡ "Flow" "{"(<process>)+"}"

Nous donnons comme exemple, l'invocation concurrente des opérations carre() et mult()du service basique Calculator par le service web complexe Equation (voir Annexe A).Flow {

Invoke(cal.carre,coefB,bCarre);Invoke(cal.mult,donnees,afoisc);

}

� cal représente le service basique Calculator� carre représente une opération du service Calculator� mult représente aussi une opération du service Calculator� coefB, bCarre, donnees et afoisc représentent des variables.

scope : le constructeur scope permet de dé�nir une activité nécessaire avec ses propresvariables.scope ::≡ "Scope"(<Java>|corSets|faultHands|compHandler|eventHands

|<process>)

corSets ::≡ "CorrelationSets" "{"<CorSet>+ "}"corSet ::≡ "CorrelationSet "{" <CorSetName>,(<CorSetMessage>) "}"


faultHands ::≡ "FaultHandlers" "{"(<vCatch>)* [, <vCatchall>] "}"vCatch ::≡ "CatchFault" (<FaultName>) "{" <process> "}"vCatchall ::≡ "CatchAll" "{"<process> "}"compHandler ::≡ "CompensationHandler" "{" <process> "}"eventHands ::≡ "EventHandler" "{"

"("OnMessage" "(" <OperationName> ")" ( "{" <process> "}")*)+"("OnAlarm" "(" "For" "="<conditionExpr> | "Until""=" <conditionExpr>") ("{" <process> "}" )* )* "}"

compensate : le constructeur est employé pour appeler la compensation à la suite d'unincident. Ce constructeur est appelé seulement avec un constructeur scope.compensate ::≡ "Compensate"("<CompensateName>,<ScopeName>")"

4.3 Concepts

Un service web complexe décrit dans le langage JCWSL est composé de deux blocs prin-cipaux qui sont le bloc des importations (ImportBloc) et le bloc de dé�nition (DefBloc),comme sur la �gure 4.1.

Figure 4.1 � Structure de JCWSL en blocs

4.3.1 Les importations

La �gure 4.2 illustre en détail ce bloc. C'est une sorte de préprocesseur permettant d'in-clure dans le service web complexe JCWSL, l'ensemble des API Java et des services webbasiques nécessaires. Nous prévoyons deux types d'importation qui sont les importationsd'API Java (import) et les importations des services web à agréger dans notre service

4.3 Concepts 101

web complexe, représenté par importBWS (import Basic Web Services).

Figure 4.2 � Structure du Bloc des importations de JCWSL

Les importBWS dé�nissent dans JCWSL les liens avec les services basiques qui inter-agissent avec le service web complexe. Les commandes importBWS jouent en quelquesorte le rôle des PartnerLinks dans BPEL. Chaque service JCWSL doit avoir au moinsune commande importBWS parce qu'un service complexe utilise au moins un service ba-sique dans sa composition. Les importBWS permettent au service web complexe d'être lecoordonnateur des interactions avec d'autres services, en faisant de l'orchestration.Pour importer un service web existant, son adresse doit être connue au préalable.Les importations de services web existants se traduisent en substance par la créationd'un package Java pour chaque service importé. Il est crée pour chaque service importéun ensemble de classes Java constituant son Stub. Ainsi à l'aide de ce Stub, il devientfacile d'invoquer le service par appel simple de ses méthodes comme celles d'une classeordinaire Java.Lors du déploiement du service web complexe, les packages des services importés doiventêtre archivés, car ces packages seront importés dans le code Java obtenu après la compi-lation du service complexe par le langage JCWSL.Les import permettent l'importation des API Java nécessaires au service complexe. Cesont des imports ordinaires de Java.

4.3.2 La dé�nition du service web complexe

La �gure 4.3 illustre le bloc de dé�nition. Ce concept représente le corps du service,une sorte de classe JCWSL faite à l'image d'une classe Java. Tout comme le bloc desimportations, ce bloc est aussi composé de deux parties : le bloc des déclarations desmessages locaux et des opérations locales et le bloc du comportement du service webcomplexe.Le bloc des déclarations : Ce bloc permet de déclarer les messages et opérations duservice web complexe. Les messages sont dits messages locaux et les opérations opérationslocales.Les messages représentent les données échangées entre le service complexe et les servicesbasiques importés.


Figure 4.3 � Structure du Bloc de dé�nition de JCWSL

Les opérations quant à elles, sont dé�nies pour les fonctionalités du service. Elles sontpour la plupart destinées à être utilisées dans les constructeurs du bloc comportementpour les interactions. Elles dé�nissent l'interface du service web complexe ainsi que ladescription WSDL du service web complexe.Le bloc comportement : Le comportement contient les interactions entre d'une part leservice web complexe et d'autre part les services basiques importés. Ces interactions sontorganisées en orchestration, car seul le service complexe connaît les services qui entrentdans le système. Le comportement contient des constructeurs WS-BPEL et du code Java.L'ajout du code Java permet l'utilisation des instructions d'a�ectation, de boucles foret do, de l'instruction alternative if then else.

4.3.3 Les variables

L'utilisation de variables est une obligation dans tout langage de programmation. DansJCWSL, nous utiliserons un seul formalisme pour les variables. Les variables seront dansle formalisme de Java, car tous les constructeurs de BPEL seront aussi transcrits en Java.En plus, Java est plus riche que BPEL en terme de représentation des données et est plusconnu que BPEL dans la communauté des développeurs. Le formalisme des variables deBPEL est peu adapté aux langages qui n'utilisent pas les balises.

4.3.4 Gestion des erreurs

L'interprétateur JCWSL gère certaines erreurs telles que :� Impossibilité de trouver une URL lors de l'importation d'un service existant. Une

telle erreur provoque l'arrêt de la compilation et a�che le message suivant :java.io.IOException : Server returned HTTP response code 400 for URL :adresse URL du service invoqué.

� Erreur de Syntaxe : Les erreurs de syntaxes sont générées en cas de non respect duformalisme du langage. Elles provoquent aussi l'arrêt de la compilation et a�chent

4.4 Génération des analyseurs et d'un service web 103

les messages du type :Encountered "...." at line XX, column XX.Was expected : << liste des caractères attendus >>.

� Une variable non déclarée : Comme JCWSL prévoit une zone pour la déclarationdes variables dans le comportement, donc toutes les variables sont contrôlées dansle programme. La rencontre d'une variable non déclarée provoque aussi une erreur.

4.4 Génération des analyseurs et d'un service webDans cette section, nous allons présenter le langage JCWSL dans sa structure interne.Elle comprend deux parties : la conception des analyseurs et la composition d'un serviceweb.

4.4.1 Génération des analyseurs du langage JCWSL

La production du langage consiste à créer deux analyseurs.

1. l'analyseur pour le comportement observable, représenté ici par le �chier CWS-LanguageC. Cet analyseur permet la génération des �chiers XML du service webcomplexe,

2. l'analyseur pour le module exécutable, représenté ici par le �chier SWCLangua-geC. Cet analyseur permet la génération des classes Java constituants une sorte demoteur du langage.

Nous avons choisi le principe des analyseurs, car il permet de faire évoluer le langage avecbeaucoup plus de facilité, en ajoutant les nouvelles fonctionalités éventuelles dans le codesource JavaCC et puis de le compiler.Dans chacun des cas, la génération comprend trois étapes.La première étape consiste à transformer la BNF du langage dans la grammaire dulangage JavaCC (Java Compiler Compiler). Le choix de JavaCC est dû à sa simplicité età ses possibilités d'utiliser les API (Application for Programming Interface) de Java. End'autres termes, à cette étape, nous devons produire un �chier de type JavaCC (.jj). Pourcela, nous avons utilisé les API bpws4j - business process in web services for Java [47] etwsdl4j - web services description language for Java [6]. Ces API o�rent des commandes quidonnent une représentation interne (in-memory model) du comportement du service webcomplexe (analyseur CWSLanguageC ). Nous utilisons aussi des API pour la générationde l'analyseur du module exécutable (analyseur SWCLanguageC ). Ces API viennent dupackage antlr (ANother Tool for Language Recognition) [80].


La deuxième étape représente la compilation de notre �chier (.jj) par JavaCC. JavaCCfait une analyse syntaxique de la grammaire de notre �chier. Il produit un ensemble de�chiers de type Java (.java) qui sont représentés dans le troisième bloc de la �gure 4.4.Ces �chiers sont :

� ParseException.java� SimpleCharStream.java� Token.java� TokenMgrError.java� <NomParser>.java� <NomParser>Constants.java� <NomParser>TokenManager.java

La troisième étape représente la compilation par Javac des �chiers .java pour lestraduire en �chiers de type .class, parmi lesquels notre analyseur (dernier bloc de la�gure 4.4). A partir de là, l'analyseur du langage est prêt. La �gure 4.4 représente lachaîne de production.

L'analyseur CWSLanguageC (Complex Web Service Language Compiler) est un en-semble de classes Java permettant de contrôler la syntaxe et la sémantique d'un serviceweb en JCWSL en vu de produire un �chier WSDL pour l'interface de publication duservice et un �chier BPEL permettant d'avoir le comportement (l'orchestration) du ser-vice web complexe. Ces deux codes ne sont pas exécutables, mais donnent à l'utilisateurune idée sur les fonctionnalités du service et l'orchestration de son comportement. Cetanalyseur ne compile pas les sections JavaCode. Dans le �chier XML, ces sections sontignorées, car JavaCode n'a pas de représentation standard en XML. Les importations deservices basiques (services existants) sont réalisées et placées dans le �chier WSDL.

L'analyseur SWCLanguageC est à son tour un ensemble de classes Java. A la di�érencedu premier analyseur, il traduit le code JCWSL en code Java. Ainsi, chaque constructeurest traduit en code correspondant en Java.

� import : ce constructeur n'est pas traduit, mais juste reporté dans le code Java,car chaque import est une instruction Java standard, même si elle n'est pas dansun JavaCode.

� ImportBWS : ce constructeur est traduit en créant des packages Java pour les servicesbasiques importés. Chaque service importé devient un package à part.

� CWSDefinition : est transformé en une classe Java permettant ainsi d'obtenir unWSDL normalisé du service complexe pour sa publication. C'est ce constructeur


qui produit les classes du Stub du service web (voir section � Génération du moduleexécutable � dans ce chapitre).

� DefMessage : l'analyseur traduit chaque constructeur DefMessage comme une classeJava permettant de décrire un type de message du service web complexe.

� DefOperation : la traduction de cet opérateur donne pour chaque DefMessage lasignature d'une méthode dans la classe dé�nit par CWSDefinition.

� void main : cet opérateur donne un thread qui représente l'exécutable du compor-tement.

� While et Switch sont traduits en blocs Java while et switch.� Pick : Chaque constructeur Pick est traduit comme un groupe de thread selon les

opérateurs OnMessage et OnAlarm. En e�et, chaque OnMessage et chaque OnAlarmdevient un thread.

� Flow : l'analyseur SWCLanguageC traduit un Flow comme un groupe de threadconcurrents.

� Receive et Reply sont traduits sous forme de méthodes du thread créé par void main.� Invoke : ce constructeur est traduit comme un appel simple d'une méthode du

service web invoqué par le service complexe.� Wait : le constructeur Wait devient un thread provoquant une attente comme son

nom l'indique.� JavaCode : le contenu de ce constructeur est directement transféré dans le thread duvoid main comme une séquence d'instructions Java sans aucune transformation.

� Scope est aussi traduit en Java comme un thread.

Figure 4.4 � Principe de génération des analyseurs

4.4.2 Génération d'un service web avec JCWSL

Le langage JCWSL génère deux groupes de �chiers selon que nous générons le com-portement observable ou le module exécutable. Le service ainsi généré, doit fonctionneravec l'outil Apache Axis que nous présentons aussi dans cette partie. En e�et, un serviceweb JCWSL a besoin d'un serveur web pour son déploiement et notre choix s'est portésur l'environnement Tomcat/Axis qui est l'un des serveurs web le plus utilisé pour ledéploiement des services web et Axis est un moteur SOAP.


La �gure 4.5 représente le schéma de compilation d'un service web complexe (CWS) écritdans le langage Java Complex web Service Language (JCWSL).La compilation d'un service web JCWSL pour l'obtention du comportement observableet du module exécutable se fait à l'aide de deux analyseurs di�érents.La commande de compilation pour l'obtention des �chiers XML (comportement obser-vable), est la suivante :

Java CWSLanguageC file.jcwsl

où CWSLanguageC est le nom du analyseur de génération des �chiers XML et�le.jcwsl est un service web écrit en JCWSL.

La commande ci-dessus permet d'obtenir deux �chiers :� la dé�nition du service web complexe en WSDL (.wsdl),� le comportement observable du service web complexe en BPEL4WS (.bpel).

La commande de compilation pour l'obtention des classes Java exécutables (module exé-cutable) est la suivante :

Java SWCLanguageC file.jcwsl

où SWCLanguageC est le nom du analyseur de génération des �chiers exécutableset �le.jcwsl est un service web écrit en JCWSL.

Figure 4.5 � Génération d'un service web complexe


Génération du comportement observable

Le génération du comportement observable est réalisée à l'aide de l'analyseur CWSLan-gageC. Cette génération produit des �chiers XML (.wsdl et .bpel). Lors de la générationde ces �chiers, le service web se présente dans la mémoire sous forme d'un ensemble declasses. Ces classes représentent les éléments du document XML qui sera produit aprèsla génération du comportement observable du service web complexe. Les �chiers XMLobtenus sont en WSDL et en Abstract BPEL (ABPEL).La �gure 4.6 donne le diagramme des classes générées dans la mémoire pour représenterle document .wsdl du service web complexe.En e�et, pour créer un service web complexe, nous créons dans la mémoire un objet(plutôt une instance de cet objet) Definition. Cet objet représente la structure duservice web complexe. A cet objet, nous attachons les autres éléments du service webcomplexe, c'est-à-dire les messages locaux, les opérations locales, les importations desservices web basiques nécessaires à la conception de notre service web complexe et lecomportement du service web complexe.Pour attacher les éléments constitutifs de notre service web complexe, nous procédonstour à tour à la création d'objets représentant ces éléments.Selon la structure retenue, nous construisons un objet Import qui contient l'ensemble desservices web basiques importés pour la conception d'un service complexe. Il est à noterque dans un service complexe, nous avons besoin d'au moins un service web basique. Unservice web complexe peut avoir besoin de messages locaux et/ou d'opérations locales,ainsi une classe Message est créée pour l'ensemble des messages locaux et une classeOperation est créée pour les opérations locales. Le nombre de messages locaux dans unservice web complexe dépend des besoins du concepteur. Pour les opérations il est toujourscréée une classe PortType, a�n de pouvoir utiliser les opérations. Dans un PortType, ilest possible de regrouper plusieurs opérations (au moins une). La classe Operation esttoujours en relation avec la classe Message car les opérations manipulent les messages(un ou deux). Ces di�érentes classes sont ajoutées au fur et à mesure que notre serviceweb complexe est construit. Quant à la partie comportement, elle est représentée parun ensemble d'activités qui dé�nissent l'orchestration du comportement du service webcomplexe. Ces activités sont dé�nies dans la classe Process.Toutes les classes ci-dessus citées sont conçues à l'aide des API Java. Java, associé àXML permettent le développement facile et rapide de services web complexes. Les classesconstituées sont représentées en format XML validé grâce à W3C XML Schema Languagequi dé�nit le schéma de représentation et de validation des documents XML développés àl'aide d'outils Java sans avoir besoin d'un document DTD (Document-Type De�nitions)ou d'un document XML Schema de validation. La �gure 4.6 représente le diagramme des


classes constituées.

Figure 4.6 � Diagramme des classes de la description d'un service web complexe

Pour la génération du �chier .bpel, nous utilisons les constructeurs BPEL. Chaque construc-teur JCWSL créera un objet de son type à chaque fois qu'il est utilisé dans le �chier.jcwsl. La �gure 4.7, conçue à l'image de BPEL en diagramme de classes Java représentele schéma descriptif de la représentation interne du �chier .bpel. Ce schéma contientla classe principale void main (Process sur le diagramme) qui représente une instanced'un processus BPEL dans la mémoire. Ce processus est composé d'autres classes commeSequence, JavaCode, While, Pick, Flow, Receive, Reply entre autres. La �gure 4.7 nousdonne le schéma principal avec les multiplicités correspondantes.

Le �chier WSDL : Il représente la description du service web complexe généré. Ilcontient les messages locaux et les opérations locales. Ces opérations seront regroupéesdans un seul portType qui servira d'interface d'invocation. Le �chier contient tous leséléments ordinaires d'un �chier WSDL dont l'adresse du service. Cette adresse est engénéral du type :http ://localhost :8080/axis/Services/nomduService.

Le �chier BPEL : Il a pour rôle principal, de représenter le comportement observabledu service. Il permet de connaître l'orchestration des opérations du service web complexe.Il n'est pas exécutable sur un moteur BPEL, car ce rôle est assuré par le code exécutablegénéré par JCWSL. C'est une sorte d'Abstract BPEL.


Figure 4.7 � Diagramme des classes du comportement d'un service web complexe

Présentation de Apache Axis

Axis [8] [99] (Apache eXtensible Interaction System) est un projet de Apache SoftwareFoundation. Axis est un moteur SOAP qui dé�nit un environnement de construction deprocesseurs SOAP tels que clients, serveurs, passerelles. C'est un package Java libre quifournit :

1. un environnement pouvant soit fonctionner comme un serveur SOAP indépendantsoit comme un plug-in de moteurs de servlet (en particulier Tomcat),

2. une API pour développer des services web SOAP RPC ou à base de messages SOAP,

3. le support de di�érentes couches de transport : HTTP, FTP, SMTP, POP et IMAP,

4. la sérialisation/désérialisation automatique d'objets Java dans des messages SOAP,

5. des outils pour créer automatiquement les WSDL correspondant à des classes Javaou inversement pour créer les classes Java sur la base d'un WSDL (classe proxy enquelque sorte, qui fait le lien entre l'application Java cliente et le service distant),

6. des outils pour déployer, tester et monitorer des services web.

Axis est constitué de plusieurs sous-systèmes qui interagissent. Lors du fonctionnementd'Axis, plusieurs gestionnaires � handlers � sont invoqués. L'ordre est déterminé par deux


facteurs :

� la con�guration du déploiement,� le fait de savoir si le moteur est un client ou un serveur.

L'objet qui passe à travers les gestionnaires est un MessageContext. Un MessageContexta une structure qui contient plusieurs parties :

� un "RequestMessage" qui représente le message entrant,� un "ResponseMessage" qui représente le message sortant,� une boîte de propriétés du message.

Il y a deux manières d'invoquer Axis :

1. comme un serveur, le Transport Listener créera un MessageContext et invoqueral'environnement de traitement d'Axis,

2. comme un client, le code de l'application produira un MessageContext et invoqueral'environnement de traitement d'Axis.

Dans tous les cas, l'environnement Axis, permet de faire passer le MessageContext àtravers les di�érents handlers et chacun fait ses traitements nécessaires sur le Message-Context.Pour assurer ses principales fonctions, Axis est composé de sous-systèmes. Les di�érentssous-systèmes d'Axis sont :

1. Message Flow Subsystem : il concerne la gestion des handlers. Les handlers sontinvoqués dans l'ordre pour le traitement des messages. À un certain point de laséquence un Handler peut envoyer une requête et recevoir une réponse, ou bientraiter requête et produire une réponse.

2. Administration Subsystem : permet la con�guration de l'environnement Axis. L'ad-ministration de l'environnement Axis est basée sur WSDD (Web Service DeploymentDescriptor). WSDD est une grammaire XML pour les descripteurs de déploiementqui sont utilisés pour con�gurer statiquement les moteurs d'Axis. Chaque gestion-naire de con�guration obtient des paramètres en termes de classe concrète (nom dela classe), une série d'options pour le handler, et un cycle de vie.

3. Message Model Subsystem : il gère les messages SOAP et les éléments constituantsdes messages. La syntaxe XML d'un message SOAP est assez simple. Un message


SOAP est constitué d'une enveloppe contenant : un header (un entête), un body(un corps).

4. Encoding Subsystem : il s'agit de la gestion du passage de valeurs entre les lan-gages de programmation et XML. Dans Axis, cela signi�e l'encodage (ou � séria-lisation �) et décodage (ou � désérialisation �). La sérialisation est le passage deJava en XML des objets et des primitives. La désérialisation est le passage de XMLen Java des objets et des primitives. Les classes de base qui mettent en ÷uvre cesmesures sont serializers et deserializers.

5. WSDL Tools Subsystem : le sous-système Outils WSDL contient les APIWSDL2Javaet Java2WSDL. Axis ne dépend pas de ces outils. Ils facilitent le travail du déve-loppeur

Pour utiliser un service web dans l'environnement Axis, il doit être publié ou déployé. Ily a deux types de déploiement : le déploiement instantané et le déploiement personnalisé.Le déploiement instantané consiste à transformer une classe Java en JWS (Java WebService). Il s'agit de changer l'extension .java d'une classe en .jws et de copier la classedans l'arborescence <webapp-root>/axis. Les services web JWS sont dits services simples,car il n'est pas possible d'utiliser par exemple les packages.Le déploiement personnalisé consiste à dé�nir des paramètres de déploiement tels que lespackages, les logins. Ce type de déploiement nécessite l'utilisation des notions de �chierde déploiement (�chier .wsdd). Cette personnalisation peut aller jusqu'à la dé�nition dehandlers pour notre service. Dans notre cas, nous utilisons ce type de déploiement, carnos services utilisent des packages, et demandent une personnalisation des handlers pourles échanges de données entre le client et le service web.

Génération du module exécutable

Les �chiers exécutables sont des classes Java générées par l'analyseur SWCLanguageC.Les classes générées représentent le côté serveur du service (le moteur du Service webComplexe généré). Elles sont dans le package générique nomservice. Ces classes sont lessuivantes :

� NomService 1.java� NomServiceSoapBindingStub.java� NomServiceSoapBindingImpl.java� NomServiceService.java� NomServiceServiceLocator.java1. NomService représente le nom du service web complexe.


� NomServiceHandler.java� NomServiceComplex.java� Bu�.java� SynchroneWaitResp.java� deploy.wsdd� undeploy.wsdd� les classes de sérialisation/désérialisation dont le nombre dépend du nombre de mes-sages locaux utilisés dans le service complexe.

L'interface NomService.java : Cette interface Java représente l'interface d'accèsau service et dérive de Java.rmi.Remote. Elle dé�nit l'interface de déploiement du ser-vice. Elle contient la signature de chacune des méthodes du service. Pour un client, ellereprésente le portType du service web. A cette �n, elle permet de dé�nir une variableportType.

NomService portType=null;portType=varService.getNomService();

La classe NomServiceSoapBindingStub.java : Cette classe implémente l'interfaceNomService.java . Elle dé�nit les fonctions assurant l'invocation des opérations o�ertespar le service web complexe. Elle contient les méthodes _initOperationDescXX() 2 quimettent en place les paramètres et les types des données utilisées dans le service. Chaqueméthode _initOperationDesc() contient au maximum dix opérations numérotées de zéroà neuf, du service web. Ce nombre limité de dix opérations est établi par les capacités dumoteur Axis.

L'interface NomServiceService.java : Cette interface dé�nit les signatures desfonctions d'accès au service. Elle contient les méthodes d'accès à l'adresse et au nomdu service. Elle sera utilisée par les clients pour dé�nir une variable de type service. Lavariable ainsi dé�nie sera utilisée pour invoquer le service.

La classeNomServiceServiceLocator.java : La classeNomServiceServiceLocator.javaimplémente l'interface NomServiceService.java. Elle permet de dé�nir une instance d'unservice web. En association avec l'interface NomServiceService.java, elles permettent unedéclaration complète d'une variable pour le service web complexe à invoquer.

NomServiceService varService=new NomServiceServiceLocator();

2. XX représente le numéro d'un groupe de 10 opérations


La classe NomServiceSoapBindingImpl.java : Elle implémente les méthodes duservice. La classe NomServiceSoapBindingImpl.java implémente l'interface NomService.Cette classe est utilisée pour assurer le lien entre le handler et le processus associé aucomportement du service web.

Les classes de sérialisation/désérialisation des messages locaux : Chaque mes-sage local est représenté par une classe Java du même nom qui permet son utilisation lorsdes invocations. Chaque classe implémente l'API Java.io.Serialisable.

Le handler : Comme dé�ni dans la sous-section concernant Axis, un handler est unobjet qui prend des messages et les exporte. Il pourrait par exemple, les écrire sur uneconsole ou les écrire dans un �chier, ou les envoyer à un service à travers un réseau. Notrehandler est utilisé pour canaliser les messages des clients vers le module (processus)représentant le comportement du service web. Il permet de dé�nir des �ux en entrée(RequestMessage) et des �ux en sortie (ResponseMessage).Il crée une instance du comportement du service. A cet e�et, il est utilisé dans les des-cripteurs de nos services web. Le handler récupère le message envoyé par le client (re-questMessage()) et le � route � vers le thread représentant le service web complexe.Ce routage se fera par appel simple du processus dans le handler. L'appel du processusassocié au comportement qui correspond à la création d'une instance du processus n'estréalisé que si l'opération contenue dans le message reçu par le handler a le droit d'ins-tantier le processus sinon, le handler renvoie un message au client lui informant que cetteinvocation est impossible.La classe Java qui représente le handler est une classe dans laquelle, est dé�nie l'orches-tration du service. Le handler et le processus associé au comportement échangent lesinformations à l'aide de variables que nous appelons bu�ers, dont le type est représentépar la classe Bu�.java.Le squelette du handler est présenté sur le listing suivant :1 package nomservice ;2 import org.apache.axis.AxisFault;3 import org.apache.axis.MessageContext;4 import org.apache.axis.handlers.BasicHandler;5 import Javax.xml.soap.SOAPMessage;67 public class <NomService >Handler extends BasicHandler {8 static final long serialVersionUID =0; ;9 public Map <String , Buff > mapBuffIn=new HashMap <String ,Buff >();10 public Map <String , Buff > mapBuffOut=new HashMap <String ,Buff >();11 public void invoke (MessageContext msgContext) throws AxisFault {12 try {13 if (msgContext.getRequestMessage () !=null) {14 // remplissage des tampons (mapBuffIn et mapBuffOut)


15 SOAPMessage mess=msgContext.getRequestMessage ();16 String myOP =null;17 myOP=mess.getSOAPBody (). getFirstChild ()18 .getLocalName (). toString ();19 if(myOP.equalsIgnoreCase("uneoperation")){20 // création d'une instance du thread du comportement21 // démarrage du thread22 }23 }24 } catch (Exception e) {throw AxisFault.makeFault(e);}25 try{26 if (msgContext.getResponseMessage () !=null) {27 System.out.println("fin de l'invoque28 le message est route pour le client");29 }30 } catch(Exception e){e.printStackTrace ();}31 }32 }

Le descripteur de déploiement : Pour le déploiement du service, il est nécessairede créer un descripteur de déploiement. Un descripteur de déploiement est un �chier.wsdd (Web Service Descriptor for Deployment) en format XML. Dans le descripteur dedéploiement, nous dé�nissons les paramètres du service tels que : le nom du handler dedéploiement, l'espace de nom du service, le nom du service, le portType du service, lesopérations du service, et les types de mappage entre les données de type Java et XML.Ce �chier est appelé deploy.wsdd. Il est accompagné d'un �chier undeploy.wsdd poursupprimer le déploiement du service. Ces deux �chiers sont générés en utilisant l'APIJava JDOM.

Le processus associé au comportement : Le comportement du service web com-plexe est représenté par un thread. La méthode run() du thread contient la transcriptionJava des constructeurs JCWSL. La classe représentant le comportement du service webcomplexe est dérivée de l'objet java.lang.Thread. Elle contient des données membres,qui représentent les bu�ers d'échange avec le handler et le nom de l'opération invoquéepar le client. Un constructeur est créé pour permettre l'instantiation du processus lorsdes invocations qui exigent cela. Fondamentalement, ces constructeurs sont représentéscomme suit :

� les constructeurs Receive et Pick sont des sortes d'écouteurs, car ils écoutent l'ar-rivée d'un message pour exécuter les opérations prévues dans le comportement,

� les constructeurs Reply et Invoke sont des appels simples de fonction,� le constructeur Flow crée des threads qui s'exécuteront de façon concurrentielle,


� les constructeurs JavaCode et Sequence sont représentés par des séquences d'ins-tructions Java,

� le constructeur While créera des instructions itératives avec des JavaCode pour dé-�nir les conditions de répétitions des séquences d'instructions.

Ainsi, chaque constructeur JCWSL aura une représentation en code Java dans le threaddu comportement.A chaque appel du service, ce thread crée une nouvelle instance. Le constructeur d'ins-tance a toujours trois attributs (un bu�er (tampon) d'entrée, un bu�er de sortie et unnom d'opération).

La classe NomServiceComplex.java représente le comportement. Le squelette de laclasse représentant le comportement du service web complexe est présenté sur le listingsuivant :1 package nomservice ;2 // import des API nécessaires3 import javax.xml.rpc.Service;4 public class <NomService >Complex extends Thread {5 public String op;6 public Map <String , Buff > pbuffersIn=new HashMap <String , Buff >();7 public Map <String , Buff > pbuffersOut=new HashMap <String , Buff >();8 public ArrayList <Thread > mesOnMess=new ArrayList <Thread >();910 public MyProcess(Map <String , Buff > mapb ,Map <String , Buff > out ,11 String o){12 this.pbuffersIn=mapb;13 pbuffersOut=out;14 op=o;15 }16 public void run () {17 // les instructions18 }

Sur la �gure 4.8, nous présentons les échanges de données entre un client et un servicecréé dans notre langage. La �gure présente les éléments suivants : le client, le handler(NomserviceHandler) dans l'environnement Axis, la classe d'implementation du service(NomserviceSoapBindingImpl) et la classe représentant le processus associé au comporte-ment (NomserviceComplex ). Les échanges sont représentées par des �èches numérotées.Ainsi :

� 1. Invocation d'une opération d'un service,� 2a. Transfert des données au module implementation et simultanément, les tam-

pons d'échanges sont transmis au processus associé au comportement car c'est ceprocessus qui e�ectue les traitements proprement dits du service web,


� 2b. Transfert des tampons d'échanges et si nécessaire création d'une instance duprocessus de traitement,

� 3. Transfert des données dans les tampons,� 4. Transfert des résultats des traitements,� 5. Transfert des résultats à Axis (précisément au handler)� 6. Restitution des résultats au client.

Figure 4.8 � Échanges de données entre un client et un service

4.5 Conclusion

Types Apprentissage Expressivité Extensibilité Exploitation environnementde conception

proche permet utilise Serveur unComplexe de Java de créer des objets Web environnement

ses propres types comme Java Tomcat/Axis dédié (CWSE)

Table 4.1 � Récapitulatif du langage JCWSL

Le tableau 4.1 donne un résumé du langage par rapport à nos objectifs. Ainsi, le chapitreprésenté a permis tour à tour de présenter formellement le langage JCWSL à travers uneBNF. Les di�érents concepts ont été ainsi étudiés et présentés. Nous avons aussi présentéles procédures de génération des di�érents analyseurs ainsi que celle d'un service webcomposé en JCWSL.Le langage JCWSL ainsi proposé, de part sa structure rappelle une classe Java ordi-naire, ce qui n'est pas nouveau pour les communautés de développeurs Java, C/C++et assimilés. En faisant une transcription des constructeurs BPEL existants, ce langagebéné�ciera de standard. L'utilisation des paradigmes Java lors de la programmation faitque ce langage béné�ciera de la facilité de programmation, l'e�cacité du code, la facilitéd'apprentissage dont béné�cie Java.

4.5 Conclusion 117

Le langage JCWSL avec ses blocs d'importation de services existants et de comportementpour l'orchestration, permet alors la mise en place des services web complexes. En �nl'utilisation de l'environnement Tomcat/Axis, comme les services web simples, fait deJCWSL un langage simple à exploiter, car ne demandant pas de composants matérielset/ou logiciels spéci�ques pour son exploitation.


Chapitre 5

Une plate-forme de composition deservices web

La présentation des plate-formes de conception de services web DotNet et J2EE e�ectuéeau chapitre 2, a mis en évidence que ces deux plate-formes permettent de concevoir desservices web simples. Ils sont caractérisés par une certaine lourdeur, et ils exigent desmoyens spéci�ques pour une exploitation rationnelle.Dans ce chapitre, nous présentons notre environnement (plate-forme) de développementde services web avec JCWSL. Cette plate-forme est nommée CWSE (Complex Web ServiceEnvironnement). C'est une plate-forme de type client riche Java développée à l'aide del'environnement de développement intégré Eclipse. Le chapitre s'articule comme suit. Lasection 1 présente l'architecture de la plate-forme. La section 2 présente la conception dela plate-forme. La section 3 décrit le mode de fonctionnement de la plate-forme. et en�n,la section 4 conclut le chapitre.

5.1 Architecture de la plate-forme

La plate-forme CWSE permet de concevoir un service web complexe JCWSL. Elle o�replusieurs modules permettant de dé�nir, compiler et déployer un service complexe. Elleest composée de deux parties principales : une interface graphique de composition et uncompilateur. Elle permet la composition statique des services web complexes. La plate-forme CWSE est un plug-in d'Eclipse.

Un schéma de la plate-forme CWSE est présenté sur la �gure 5.1. Cette plate-formeest composée de quatre modules : le module client, le module UDDI, le module serviceweb complexe et le module services existants (qui peut être composé de services websimples et complexes).

� Le module UDDI (Registre UDDI) : Il sert à la publication du service web

120 Chapitre 5. Une plate-forme de composition de services web

complexe créé à l'aide de JCWSL. Pour la publication, nous plaçons dans le registreUDDI la description WSDL du service complexe a�n de mettre à la disposition duclient les informations nécessaires à l'invocation du service web complexe.

� Le module service web complexe : Ce module représente le service générépar notre langage JCWSL. C'est un ensemble de classes Java et de �chiers dedéploiement WSDD. Cet ensemble de classes a été étudié dans le chapitre � Lelangage JCWSL � dans la section � Génération des analyseurs et d'un service web �.

� Le module services existants : Ce module représente l'ensemble des services exis-tants qui peuvent être invoqués par un service web complexe JCWSL. Ils peuventêtre des services WSDL (simples) ou des services web composites (BPEL).

� Le module Client : Il n'est pas généré par le langage JCWSL. Il représente unclient correct qui peut invoquer un service web complexe. Ce client a fait l'objetd'une thèse soutenue par Sylvain Rampacek [92]. Dans ce travail, il a été traité leproblème lié à l'ambiguïté et autres aspects pour permettre une bonne interactionentre le client et le service web complexe.

Figure 5.1 � La plate forme CWSE

5.1.1 L'interface graphique

C'est un environnement de développement de services web complexes. L'environnementest composé d'un éditeur graphique, d'une feuille de propriétés et d'une palette présentantles di�érents constructeurs du langage de composition. Le langage de composition de laplate-forme CWSE et le langage JCWSL, une extension du langage Java. Dans l'éditeur

5.1 Architecture de la plate-forme 121

graphique l'utilisateur compose le service web en faisant un glisser-déposer à partir de lapalette.

L'éditeur graphique : il est représenté par une fenêtre graphique et servant d'empla-cement de réception du graphe du service web JCWSL. Il porte un nom qui est en généralcelui du service web. L'interface graphique est sur la �gure 5.2.

Figure 5.2 � Editeur Graphique de l'environnement CWSE

La palette : c'est une sorte de barre d'outils pour créer les di�érents éléments du graphedu service web complexe. Elle contient en plus des boutons représentant les constructeurs,des boutons permettant de créer les liens entre les éléments du graphe et de les sélection-ner. La �gure 5.3 illustre la palette de JCWSL. La conception du graphe est présentéedans la section 5.2.2.

La feuille de propriétés : la feuille de propriétés permet au concepteur du graphede renseigner les propriétés des objets choisis. Par exemple, pour un objet de typeCWSDefinition qui représente la dé�nition du service, le conception doit renseigner l'in-formation Nom Service. La �gure 5.4 illustre un exemple de feuille de propriétés avec desinformations de l'objet DefOperation qui représente une opération.


Figure 5.3 � La palette de l'environnement CWSE

Figure 5.4 � La feuille de propriétés de l'environnement CWSE

5.1.2 Le compilateur JCWSL :

Le compilateur prend en entrée la description du service complexe écrit en JCWSLet génère le code exécutable correspondant en Java ainsi que le comportement en BPEL.

5.2 Conception de la plate-forme CWSE 123

Le compilateur est composé d'un analyseur et d'un générateur.� L'analyseur assure deux sortes d'analyse, syntaxique et sémantique. Pendant l'ana-

lyse syntaxique, l'analyseur véri�e que le �chier est conforme à la grammaire dulangage, véri�e la validité de chaque service importé, construit pour chaque serviceimporté une librairie et génère l'arbre syntaxique du service web complexe. L'ana-lyseur sémantique doit s'assurer que le service complexe véri�e certaines propriétés.

� Le générateur, une fois les véri�cations syntaxiques et sémantiques e�ectuées, pro-duit automatiquement le code Java du service et son comportement observableabstrait. Lors de la génération du code Java du service web complexe, le �chierde déploiement est aussi généré. Ce dernier est un �chier WSDD, il est toujoursaccompagné du �chier qui supprime le déploiement.

Une étude plus détaillée du compilateur a été faite dans le chapitre précédent.

5.2 Conception de la plate-forme CWSELa conception de notre plate-forme a été faite à l'aide d'un outil d'Eclipse appelé GEF(Graphical Editing Framework). Le développement de l'outil a été réalisé en utilisant dumatériel de [46].

5.2.1 Présentation de l'outil GEF

Eclipse est un environnement de développement intégré, compatible avec la presquetotalité des langages de programmation actuels. Il o�re aux développeurs de Java unespace graphique et convivial de travail. Eclipse est basé sur la philosophie des plug-ins.Nous utilisons la plate-forme Eclipse [48] comme environnement de développement inté-gré (Integrated Development Environment). Le but de cette plate-forme est de fournirun environnement modulaire permettant de réaliser aisément le développement de dif-férents types d'applications (applications bases de données, Web, J2EE, etc.). IBM està l'origine de cet environnement qui fait partie du noyau de son outil Websphere Stu-dio Workbench [49] (WSW). La spéci�cité d'Eclipse vient du fait que son architectureest totalement développée autour de la notion de modules (en anglais plug-in). Eclipsepeut être étendue avec d'autres modules qui traitent plusieurs aspects du développementcomme la conception UML ou les tests unitaires et d'intégration.GEF est l'un de ses plug-ins pour la conception d'interface graphique. Il est composé dedeux plug-ins.

� org.eclipse.draw2d : ce plug-in o�re des outils de présentation pour a�cher des gra-phiques. Il o�re entre autres : un support e�cace de mise en page et de présentation,diverses �gures et mise en ÷uvre de présentation, des bordures.


� org.eclipse.gef : ce plug-in est le noyau de GEF. Il o�re entre autres les outils sui-vants : des outils comme la sélection, de création, de connexion et des outils � Mar-quee 1 �, deux types de viewers GEF (graphique et arbre), un contrôleur de mappagedu modèle à la vue.

L'utilisation de GEF suppose qu'on dispose un modèle que l'on souhaite a�cher et édi-ter graphiquement. Pour ce faire, GEF fournit des viewers (du type EditPartViewer)qui peuvent être utilisés n'importe où dans le workbench Eclipse. Les viewers de GEFsont adaptés sur des SWT 2 (The Standard Widget Toolkit) Control. Ils sont basés surl'architecture model-Vue-Contrôleur (MVC, voir �gure 5.5).Chaque contrôleur ou EditPart comme ils sont appellés ici, est responsable à la fois dumapping du modèle à sa vue, et d'apporter des modi�cations au modèle. Le EditPartobserve également le modèle, et les mises à jour a�n de re�éter les changements dans lemodèle. Les EditParts sont des objets avec lesquels l'utilisateur interagit. La �gure 5.5illustre l'architecture MVC de GEF. Cette �gure comprend trois éléments essentiels,le modèle qui représente l'objet à a�cher ou éditer graphiquement, la vue (view) quireprésente la vue du modèle généré par le contrôleur ainsi que le Contrôleur lui même.GEF prévoit deux types de visualisation : le type graphique et le type basé sur les arbres.Chaque type a di�érents types de vues.

� La visualisation graphique utilise des �gures qui sont peintes sur un canevas SWT.Les �gures sont dé�nies dans le Draw2D plug-in.

� La visualisation sous forme d'arbres utilise SWT Tree et TreeItems pour ses vues.

5.2.2 Conception de l'environnement CWSE

Comme indiqué ci-dessus, CWSE est conçu à partir de GEF, il est basé sur un modèle àdeux éléments : le diagramme et les �gures (les éléments enfants).Le diagramme représente le graphe du modèle. C'est un élément composé de plusieursautres éléments dits éléments �ls. Les éléments �ls représentent les constructeurs dulangage JCWSL. Dans notre logique et en se basant sur le modèle ShapesDiagram 3 deIBM, chaque constructeur JCWSL est une classe Java. Chaque classe est caractériséepar une �gure qui le représente sur la palette, par ses propriétés. Les propriétés retenuesdans le modèle sont celles qui seront utilisées lors de la traduction du graphe en codeJCWSL. Les éléments �ls sont reliés par des �èches appelés connecteurs. Un connecteura toujours une source et un but. Chaque élément est dé�ni par un EditPart (une classe

1. Marquee : une palette pour l'a�chage des outils de sélection des objets et des connexions.2. SWT : SWT est une boîte à outils open source pour Java Widget conçue pour assurer de manière

e�cace et portable l'accès de l'utilisateur à l'interface des installations des systèmes d'exploitation surlesquels il est mis en ÷uvre.

3. ShapesDiagram : ShapesDiagram est un exemple de diagramme conçu par les développeurs de GEFet qui sert de base pour les modèles personnalisés.


Figure 5.5 � L'architecture Model-View-Controller

Java) qui �xe ses conditions d'implementation en lui faisant correspondre avec sa �gure etses propriétés. La �gure 5.6, nous donne une illustration du EditPart de l'éditeur. Cette�gure présente la fenêtre principale de l'éditeur (Graphical viewer) qui est constitué parl'EditPart racine (DiagramEditPart). Ce dernier est composé de contenu (Contents) quiest constitué de �ls (ShapeEditPart).

Figure 5.6 � DiagramEditPart principal

La �gure 5.7 décrit le modèle qui a servi pour la création de notre environnement. Cemodèle est constitué d'une classe ModelElement de la quelle dérivent les deux classes quireprésentent les éléments de base de CWSE. La classe ShapeDiagram représente le graphedu service web complexe lui même tandis que la classe Shape représente l'ensemble desconstructeurs JCWSL. Pour un souci de simplicité, nous avons regroupé dans la mêmeclasse tous les constructeurs de JCWSL. Cette dernière classe peut se décliner en diverses


classes telles que CWSDefinition pour la dé�nition du service web complexe en JCWSL,ImportJava qui représente une importation d'API Java, DefMessage qui représente la dé-claration d'un message local ou encore Sequence qui représente un constructeur Sequencede JCWSL, ImpBWS qui représente l'importation d'un service web simple ou OnMessagepour le constructeur JCWSL correspondant.

Figure 5.7 � Schéma du modèle de l'environnement CWSE

La classe ModelElement est une classe abstraite qui implémente java.io.Serializable.Elle porte plusieurs méthodes dontvoid addPropertyChangeListener(PropertyChangeListener l) et


void firePropertyChange(String property, Object oldValue, Object newValue)qui gèrent les propriétés globales (par exemple l'ajout ou la suppression d'un objet dudiagramme) des objets principaux du modèle (Shape.java et ShapesDiagram.java).La classe ShapesDiagram représente le diagramme d'un service web JCWSL. Elle a commepropriété la liste des objets qui la compose, dé�nie par List shapes, elle aussi a desméthodes dont quelles que unes sont présentées sur la �gure 5.7.

� boolean addChild(Shape s) : Cette méthode permet d'ajouter un nouvel objetau diagramme. Elle prend en paramètre un objet de type Shape et retourne truesi l'ajout est e�ectif.

� List getChildren() : Elle permet d'obtenir la liste des objets du diagramme.� Shape getLast() : La méthode getLast() renvoie le dernier objet d'un diagramme.� Shape getShape(int index) : Cette méthode renvoie l'élément à la position index

du diagramme.� int taille() : Elle renvoie la taille du diagramme.

La classe Shape 4 est une classe qui implémente l'APIorg.eclipse.core.runtime.IAdaptable pour pouvoir assurer la gestion des propriétésdes di�érents constructeurs JCWSL. Cette classe a comme attributs :

� location : de type org.eclipse.draw2d.geometry.Point qui �xe les coordonnéesd'un objet du diagramme.

� "sourceConnections" : de type java.util.List qui contient la liste des objetsqui sont sources de connexions vers un objet donné du diagramme.

� targetConnections : de type java.util.List qui contient la liste des objets quisont buts de connexions allant d'un objet donné du diagramme.

La classe Shape comporte aussi plusieurs méthodes dont voici deux :� addConnection(Connection conn) de type void, qui permet d'ajouter une connexion

à un élément du diagramme. Il est à noter qu'un même élément peut avoir plusieursconnexions.

� getAdapter(Class adapter) de type Object, qui permet la gestion des propriétésde ses classes �lles, c'est à dire par exemple à près la saisie ou modi�cation de lavaleur d'une propriété quelconque, cette méthode assure le rafraîchissement de savaleur. Pour cela, elle fait appel à la classe ShapePropertySource.java créée à ces�ns.

La spécialisation de la classe Shape a permis la création des classes spéci�ques pourchaque constructeur JCWSL. Ainsi, nous avons :

� Le constructeur import, qui permet l'importation des API Java, a été représentépar la classe ImpJava.java. Cette classe porte une propriété (ApiJava) membre

4. Shape : à ne pas confondre avec l'API GEF org.eclipse.draw2d.Shape qui est une API d'Eclipse


permettant la saisie des API java. Chaque constructeur import doit avoir son objetreprésentatif sur la graphe.

� Le constructeur importBWS est lui représenté par la classe ImpBWS.java. Cette classea deux propriétés : le nom et l'URL du service à importer.

� Le modèle du constructeur CWSDefinition est la classe du même nom. Ce modèleporte le nom comme propriété qui permet l'a�ectation d'un nom à un service.

� Le modèle du constructeur DefMessage est la classe du même nom. Le modèle portedeux propriétés : messname - pour attribuer un nom au message et attributs - pourdé�nir les attributs du message. Chaque attribut sera dé�ni par son type et sonnom. Les attributs seront séparés par point-virgule ( ;).

� Le modèle du constructeur DefOperation est la classe DefOperation.java. Cemodèle a six propriétés :

1. la propriété opName qui permet d'attribuer un nom à une opération,

2. la propriété opType pour dé�nir le type de l'opération, c'est-à-dire si elle estInput, ou Output ou encore Input/Output.

3. la propriété inputType pour dé�nir le type du paramètre en Input.

4. la propriété inputName pour dé�nir le nom du paramètre en Input.

5. la propriété outputType pour dé�nir le type du paramètre en Output.

6. la propriété outputName pour dé�nir le nom du paramètre en Output.

� Le modèle du constructeur void main est représenté par la classe VoidMain.� Le modèle du constructeur Variables est la classe du même nom. C'est un construc-

teur composé d'autres objets et n'a pas de propriétés tout comme le modèle void main.� Le constructeur Variable qui est un sous-élément du constructeur Variables est

quand à lui représenté par la classe VarElement.java qui est caractérisée par deuxpropriétés : varName - pour le nom de la variable et varType - pour le type de lavariable.

� Le constructeur JavaCode est représenté par le modèle Javacode qui a une pro-priété javaString permettant de saisir le code Java nécessaire. Tout le code est saisisur une même ligne.

� Le modèle du constructeur Receive est représenté par la classe Java du même nom.Ce modèle est caractérisé par les propriétés suivantes : oPName - pour le nomde l'opération attendue par Receive, varName - qui permet la saisie du messageattendu et rcvInstance - pour indiquer qu'un constructeur Receive doit ou noncréer une instance du processus.

� Le modèle du constructeur Reply est représenté par la classe Java du même nom.Ce modèle est caractérisé par les propriétés suivantes : RploPName - pour le nom


de l'opération utilisée par Reply et varName - qui permet la saisie du message àrenvoyer.

� Le modèle du constructeur Invoke est représenté par la classe Java du même nom.Ce modèle est caractérisé par les propriétés suivantes : InvoPName - pour représen-ter le nom de l'opération à invoquer, varInput - pour les paramètres de l'opérationinvoquée (variable en entrée du constructeur Invoke) et la propriété varOutput- quireprésente la variable retournée par le constructeur Invoke.

� Le constructeur Wait est représenté par le modèle WaitElement.java. Ce modèleporte une propriété (condition) permettant la saisie de la condition provoquantl'attente.

� Le constructeur Sequence est modélisé par la classe SeqElement.java. Comme leconstructeur est composé, il n'admet pas de propriétés propres en lui.

� Le constructeur Pick est modélisé par la classe PickElement.java. Tout commeSequence, il a comme propriété pickInstance - pour indiquer qu'un constructeurPick doit ou non créer une instance du processus.

� Le constructeur OnMessage est semblable au constructeur Receive. C'est pour celaque son modèle OnMessage.java porte les même propriétés que Receive, c'est-à-dire l'opération attendue et le message attendu.

� Le constructeur OnAlarm, semblable au constructeur Wait, il est représenté par lemodèle OnAlarm.java. Cet élément porte aussi la propriété condition pour la saisiede la condition ou délai d'attente.

� Le constructeur While est représenté par le modèle WhileElement.java. Cetteclasse, bien que représentant un constructeur composé, porte la propriété javaCondpermettant la saisie de la condition d'itération.

� Le constructeur Switch est, comme les constructeurs Pick et Sequence composé etson modèle SwitchElement n'a pas de propriétés.

� Le modèle Case représente les éléments du constructeur Switch et est représenté parle modèle CaseElement.java avec la propriété pour la condition du choix multipleexclusif : javaCond.

� Le constructeur Flow est représenté par la classe FlowElement.java. Ce modèlen'a pas de propriétés en plus.

� Le constructeur Scope est représenté par le modèle de classe ScopeElement.java.Il n'a pas de propriétés propres.

� Le constructeur Compensate est représenté par le modèle CompElement.java.� Chaque modèle d'un constructeur composé est accompagné d'un modèle de classe

Java représentant sa �n.

A chaque classe de notre modèle, correspond une �gure de personnalisation. Les classes


représentant les �gures associées ont les mêmes nom génériques que les classes ci-dessus ci-tées (exemple : CWSDefFigure.java pour le constructeur CWSDefinition). A�n d'associerune image, chaque classe de �gure étend l'API org.eclipse.draw2d.Shape. Chacune desclasses de �gure hérite la méthode void outlineShape(Graphics graphics) de l'API.Cette méthode permet d'associer une image à un objet JCWSL. Pour exemple, les deuxlistings qui représentent respectivement la classe du constructeur CWSDefinition et saclasse de �gure associée.1 // Classe CWSDefinition.java2 package org.eclipse.gef.jcwsl.model;34 import org.eclipse.swt.graphics.Image;56 public class CWSDefinition extends Shape{78 public static final String NAME_PROP = "CWSDefinitionName";9 private static final Image CWSDEF_ICON =10 createImage("icons/cwsDef.png");11 private static final long serialVersionUID = 1L;1213 private String name=" "; // Nom du service web JCWSL1415 @Override16 public Image getIcon () {17 return CWSDEF_ICON;18 }1920 public String toString () {21 return "CwsDef ";22 }2324 public String getName (){25 return this.name;26 }2728 public void setName(String nm){29 String oldName = this.name;30 this.name=nm;31 firePropertyChange(NAME_PROP , oldName , this.name);32 }3334 public void setErreur(String err) {35 String oldErreur=this.erreur;36 this.erreur = err;37 firePropertyChange(ERREUR_PROP , oldErreur , this.erreur );38 }3940 public String getErreur () {41 return this.erreur;42 }4344 }


1 // Classe CWSDefFigure.java2 package org.eclipse.gef.jcwsl.figure;34 import org.eclipse.draw2d.Graphics;5 import org.eclipse.draw2d.Shape;6 import org.eclipse.draw2d.geometry.Point;7 import org.eclipse.draw2d.geometry.Rectangle;8 import org.eclipse.gef.jcwsl.model.CWSDefinition;9 import org.eclipse.swt.graphics.Image;10 import org.eclipse.swt.widgets.Shell;11 import org.eclipse.ui.PlatformUI;1213 public class CWSDefFigure extends Shape {1415 @Override16 protected void fillShape(Graphics graphics) {17 }1819 @Override20 protected void outlineShape(Graphics graphics) {21 Rectangle r = Rectangle.SINGLETON;22 r.setBounds(getBounds ());23 r.width --;24 r.height --;25 r.shrink (( lineWidth - 1) / 2, (lineWidth - 1) / 2);26 Shell shell= PlatformUI.getWorkbench ()27 .getActiveWorkbenchWindow (). getShell ();28 Image palm = new Image(shell.getDisplay (),29 CWSDefinition.class.getResourceAsStream(30 "/ressources/icons/cwsDef.png"));31 graphics.drawImage(palm , new Point(r.getLocation ()));32 }3334 }

La classe ShapePropertySource.java est une classe outil permettant la gestion des pro-priétés des objets du diagramme. Elle ne représente pas un constructeur quelconque. Pourassurer son rôle, cette classe implémente les interfacesorg.eclipse.ui.views.properties.IPropertySource et java.io.Serializable. Ellea plusieurs méthodes dont :

� IPropertyDescriptor[] getPropertyDescriptors() : permet la mise à jour despropriétés des constructeurs.

� Object getPropertyValue(Object id) : permet d'obtenir la valeur d'une pro-priété, par exemple pour pouvoir la modi�er.

� "void setPropertyValue(Object id, Object value)" : permet d'attribuer la valeursaisie à une propriété donnée.


5.3 Cycle de développement d'une application dans CWSE

Cette section décrit, en détail, les di�érentes étapes de mise en place d'un service webcomplexe en utilisant la plate-forme CWSE. Cette procédure que nous appelons cycle dedéveloppement, comprend quatre étapes principales, énumérées dans l'ordre de réalisa-tion :

1. L'étude conceptuelle du service web complexe,

2. La mise en place du graphe représentant le service web accompagnée du codeJCWSL généré,

3. La compilation du code JCWSL avec l'analyseur,

4. Le déploiement du service web complexe.

5.3.1 Principe de conception

L'étude conceptuelle à l'aide de la méthodologie UML pour JCWSL est la première à réa-liser. Lors de cette étude conceptuelle, des diagrammes sont réalisés dont les diagrammesd'activités et de séquences (voir chapitre 6). Les diagrammes d'activités et de sequencesconstituent les éléments de base pour la mise en place du graphe du service. Le graphe estconstruit à l'image des diagrammes d'activités et de séquences seulement, ici les acteursne sont pas illustrés. C'est une reproduction plutôt du diagramme d'activités enrichi desobjets représentant les importations, la classe principale CWSDefinition, les messageslocaux et les opérations locales.

L'étape de la mise en place du graphe comprend la phase de conception graphique duservice dans l'environnement, la génération automatique du code JCWSL du service. Lagénération du code JCWSL est réalisée à l'aide d'une classe qui contient les mots cléset les éléments du modèle du graphe (présentés dans la section précédente). A chaqueélément du modèle correspond un code JCWSL approprié.Ainsi, lors de la conception d'un graphe, ce dernier est lu dans une variable de typeShapesDiagram qui est représentée sur la �gure 5.7 par la classe ShapesDiagram. Leséléments du diagramme (illustrés sur la �gure 5.7 par la classe Shape) sont lus un à unet codi�és à l'aide des mots clés prévus à cet e�et.Pour assurer la traduction du graphe en code JCWSL, nous avons créer la classe de typeString :la classe ModelWriter.java. Cette classe comporte une seule méthode de typeString et nommée translateToJcwsl(ShapesDiagram diagram). Cette méthode lit legraphe et le transforme en StringBuilder.La méthode translateToJcwsl(ShapesDiagram diagram) renvoie un String obtenu dela transformation du StringBuilder.

5.3 Cycle de développement d'une application dans CWSE 133

Il est aussi prévu la traduction d'un code JCWSL en graphe. Pour cette traduction, uneclasse Java de mapping entre code JCWSL et �gure d'image est créée. Ce procédé estaussi réalisé à l'aide du modèle qui lit chaque ligne de code, trouve et convertit en classeJava les instructions. Cette traduction est réalisée à l'aide de la classe ModelLoader.java.La classe ModelLoader.java comporte une seule méthode de type ShapesDiagram et ap-pelée loadFromJcwsl(IFile jcwslFile). Cette méthode prend en entrée un objet IFilereprésentant le �chier ouvert. Le contenu du �chier est lu dans une variable de typejava.io.InputStream, qui à son tour est placée dans une variablede type java.io.InputStreamReader. Cette dernière est placée �nalement dans une va-riable de type java.io.BufferedReader.Les lignes de code suivantes nous donnent une illustration.public static ShapesDiagram loadFromJcwsl(IFile jcwslFile){

ShapesDiagram mydiagram=new ShapesDiagram();...try {

// recupération du contenu du fichierInputStream stream=jcwslFile.getContents();/* creation d'une variable streamReader pour

* la transformation du contenu en String* creation du StringWriter pour écrire une

* ligne dans une variable String* le buffer permet le readline*/InputStreamReader streamReader=new InputStreamReader(stream);BufferedReader buffer=new BufferedReader(streamReader);

.....

Le BufferedReader est lu ligne par ligne jusqu'à la �n et chaque ligne est codi�ée à l'aidedu mapping JCWSL objet graphique. En e�et, il est véri�é dans chaque ligne lue la pré-sence d'un mot-clé du langage. Lorsqu'un mot-clé est trouvé, alors l'objet correspondantest construit et ajouté au graphe du modèle. Pour assurer correctement la création desliens entre objets, nous utilisons les méthodes getLast(), getShape(int index).Les deux classes de traduction graphe <===> code et vice-versa font parti des mo-dules de personnalisation du modèle GEF existant. La �gure 5.8 illustre un mapping entreun fragment de graphe et son code JCWSL correspondant. Sur la �gure 5.8, sont illustrésdes exemples de traductions de certains constructeurs comme Sequence, JavaCode, Pickentre autres. Les instructions du constructeur JavaCode, par exemple sont issues de la


propriété javaString de l'objet correspondant.

Figure 5.8 � Mapping Graphe - Code JCWSL

5.3.2 Manuel utilisateur

La création d'un nouveau service (graphe de service) se fait comme la création d'unenouvelle classe Java sous Eclipse. Il s'agit de suivre la procédure suivante :

� Créer un projet sous Eclipse.� Créer un nouveau graphe JCWSL dans le projet.� Enregistrer le graphe, a�n d'obtenir son code JCWSL.� Compiler le service à l'aide de l'analyseur JCWSL, a�n d'obtenir les classes Java

représentants le service web complexe.� Déployer le service web complexe.

Créer un nouveau Projet Eclipse :

1. Clic sur le menu File,

2. Clic sur New

3. Clic sur Project, la boîte de dialogue de la �gure 5.9 apparaît,

4. Clic sur General/Project, et puis Next>, la boîte de dialogue de la �gure 5.10 ap-paraît,

5. Saisir le nom du projet, et puis faire Finish.


Dans le projet, ainsi créé, nous plaçons les classes des graphes.

Figure 5.9 � Création de nouveau projet - première boîte de dialogue

Figure 5.10 � Création de nouveau projet - deuxième boîte de dialogue

Créer un nouveau graphe de service web complexe Il s'agit ici de créer l'ob-jet (fenêtre) qui doit recevoir le graphe et de dessiner le graphe. Un graphe de serviceweb JCWSL est par défaut enregistré dans un �chier de type .jwsl. La procédure est lasuivante :


1. Clic droit sur le nom du projet qui doit recevoir le service web JCWSL et puis surNew,

2. Clic sur Examples, la boîte de dialogue 5.11 apparaît,

3. Clic sur JCWSL Diagram, et puis sur Next>, la boîte de dialogue 5.12 apparaît,

4. Saisir le nom du service web, et puis faire Finish.

5. Dessiner le graphe à l'aide de la palette sur la �gure 5.3.

6. Enregistrer le graphe.

Figure 5.11 � Création d'un graphe JCWSL - première boîte de dialogue

Visualiser le code JCWSL généré : La procédure est la suivante :

1. Clic droit sur le nom de la classe représentant le service web,

2. Clic sur Open With,

3. Clic sur Text Editor, le code JCWSL du graphe apparaît.


Figure 5.12 � Création d'un graphe JCWSL - deuxième boîte de dialogue

Compilation du service JCWSL et obtention de classes Java :Pour la compilation, ici, le traitement du service, à l'aide de l'analyseur JCWSL, laprocédure est la suivante :

1. Clic sur le menu Jcwsl,2. Clic sur le commande (Generate Java Files), le service est généré (voir chapitre 4,

Génération du module exécutable).

Compilation du service JCWSL et obtention des �chiers XML :Pour la compilation, ici, le traitement du service, à l'aide de l'analyseur JCWSL, laprocédure est la suivante :

1. Clic sur le menu Jcwsl,2. Clic sur le commande (Generate XML Files), le service est généré (voir chapitre 4,

Génération du comportement).


Déploiement du service complexe :Pour le déploiement, la procédure est la suivante :

1. Clic sur le menu Jcwsl,2. Clic sur le commande (Deploy Web Service),

L'environnement prend en charge les tâches de conception graphique, de génération decode JCWSL, de compilation pour obtenir le code Java du service web complexe. Quantau client, il n'est pas généré par le compilateur du langage, mais la génération du clientest faite à partir de la description du service a�n de permettre une interaction correcteavec le service.

Gestion des erreurs :Lors de création d'un objet, une propriété spéci�que est a�chée en cas d'erreur sur l'objet.Par exemple une variable non déclarée ou un bloc sans �n.

5.4 ConclusionDans ce chapitre, nous avons présenté l'environnement de développement CWSE. Lechapitre présente dans un premier temps l'architecture de l'environnement suivi de laconception proprement dite de la plate-forme et puis du cycle de développement d'unservice web dans CWSE. Nous avons présenté les procédures d'exploitation de l'environ-nement, allant de l'étude conceptuelle à au déploiement en passant par la conception dudiagramme (graphe) du service web complexe et la génération de son code en JCWSL.

Chapitre 6

Méthodologie de conception deservices web - étude de cas

6.1 Introduction

Dans le présent chapitre, nous présentons la méthodologie à suivre pour concevoir unservice web complexe dans JCWSL en utilisant le langage UML. D'après [67], UML peutêtre personnalisé à l'appui de la modélisation des systèmes qui sont entièrement ou par-tiellement a�ectés à une infrastructure de services web, car chaque domaine d'activitésa ses notions et ses besoins spéci�ques pris en compte dans UML à travers des exten-sions qui sont regroupées en pro�ls UML. Cette notion qui est apparue depuis la versionUML 1.3 est un moyen de structuration des extensions UML (tagged values, stéréotypeset contraintes). Nous utiliserons cette notion de pro�ls UML pour proposer une méthodo-logie de réalisation des diagrammes UML pour JCWSL. Les pro�ls UML seront utiliséspour exprimer les règles de transformation de modèles. Le chapitre se termine par laprésentation d'une étude de cas en appliquant UML et JCWSL.

6.2 Méthodologie UML pour JCWSL6.2.1 Quelques rappels

En plus des arguments du chapitre 3, le choix d'UML pour la méthodologie est dû aufait que UML est un standard de l'OMG qui o�re une modélisation visuelle des notationsde la conception et la compréhension des systèmes complexes. Les services web étant dessystèmes complexes, leur modélisation avec UML se justi�e dans ce cadre.Avant de choisir un processus de développement UML pour JCWSL, nous allons faireune présentation des méthodes existantes. Il n'existe pas aujourd'hui de méthode dedéveloppement standard propre à UML, et l'on peut trouver suivant les domaines d'ap-plications des méthodes di�érentes. Ainsi, d'après [56] et [54] malgré un e�ort de stan-

140 Chapitre 6. Méthodologie de conception de services web - étude de cas

dardisation autour du Processus Uni�é, commercialisé par la société Rational 1 sous lenom de RUP (Rational Uni�ed Process), on peut trouver des méthodes comme COMETde Gomaa [56] ou ROPES de Douglass [56], adaptées aux systèmes temps réel.

Le Processus Uni�é rassemble en une description cohérente et bien documentée les meilleurespratiques communément acceptées, telles que le cycle de vie itératif et le développementpiloté par les risques [61]. Cette méthode est caractérisée par :

� La gestion du cycle de vie du développement.� La gestion des risques.� La prise en compte des changements.� L'obtention de manière répétitive des produits de qualité constante.� L'organisation du travail.

Le Processus Uni�é organise les tâches et les itérations d'un projet en quatres phases [61], [72] :� Initialisation : C'est une sorte d'étude de faisabilité, où l'on e�ectue uniquement

les investigations nécessaires pour décider si l'on poursuit ou non le projet.� Elaboration : C'est la phase où l'architecture noyau est développée de façon incré-

mentale et où les problèmes à haut niveau de risque sont traités.� Construction : La construction est la phase de l'implémentation itérative des élé-

ments qui présentent des risques et une complexité moindres et la phase de lapréparation du déploiement.

� Transition : C'est la phase des tests, du déploiement.En�n, il ne s'agit pas d'une méthode � en cascade � ni du cycle de vie séquentiel quiconsiste à dé�nir d'abord tous les besoins puis à e�ectuer la conception en totalité oupresque [61].

COMET est une méthode UML basée sur la modélisation concurrente des Objets et laconception architecturale pour le développement d'applications concurrentes, en particu-lier distribuées et des applications en temps réel [38]. Le cycle de vie du COMET Object- Oriented Software est itératif. La méthode COMET est composée de trois phases : lamodélisation des exigences, l'analyse et la conception architecturale.La modélisation des exigences, consiste en la mise en place d'un modèle de cas d'utilisationdans lequel les exigences fonctionnelles du système sont dé�nis en termes d'acteurs et descas d'utilisation.La phase de l'analyse concerne le développement d'un modèle statique et d'un modèledynamique. Le modèle statique dé�nit les relations structurelles entre les classes d'objetsdu domaine. Les Objets de structuration sont les critères utilisés pour déterminer les

1. Rational : http ://www.rational.com

6.2 Méthodologie UML pour JCWSL 141

objets à prendre en considération lors de l'analyse. Le modèle dynamique développé estun modèle dans lequel les cas d'utilisation du modèle d'exigences sont ra�nés.

Le processus de développement ROPES (Rapid Object-Oriented Process for EmbeddedSystems) est divisé en quatre phases qui sont : l'analyse, la conception, la traduction etles tests [27].L'analyse consiste en l'identi�cation des caractéristiques essentielles de toutes les solutionscorrectes possibles.La phase de conception ajoute des éléments à l'analyse qui dé�nissent une solution surla base de l'optimisation de quelques critères dé�nis.La traduction crée un exécutable, une réalisation de la conception qui peut être déployée.Les tests d'essai permettent de véri�er que la traduction est l'équivalent de la conceptionet valide le fait que la mise en ÷uvre répond à tous les critères d'exactitude identi�ésdans l'analyse.

Bien que ces méthodes aient une approche di�érente de l'enchaînement des activités duprocessus de développement, et utilisent de manière di�érente les diagrammes UML, ilexiste néanmoins des règles communes que l'on retrouve dans ces méthodes. Selon lesauteurs d'UML, le processus utilisant cette notation doit être :

� itératif et incrémental,� centré sur l'architecture,� piloté par les cas d'utilisation.

6.2.2 Processus itératif et incrémental

Un processus itératif consiste à intégrer le fait que les exigences évoluent au cours d'unprojet, en développant des prototypes. La plupart des méthodes s'appuient sur le mo-dèle en spirale de Boehm [56] et [61] qui consiste à réaliser des prototypes en enrichis-sant chaque version de nouvelles exigences. La représentation de ce modèle de processussous � forme de spirale �, (voir �gure 6.1) permet de dé�nir des cadres d'activités com-muns à chaque itération. Par exemple, pour chaque prototype, il est possible de dé�nirdes étapes d'analyse, conception, implémentation et de test [56] et [61]. Les premièresitérations permettent d'expérimenter et de valider des technologies, de plani�er la suitedu développement, et surtout de dé�nir le noyau d'architecture du système. Chaque ité-ration permet de réaliser une partie des fonctionnalités du système. On parle alors deprocessus incrémental.Le point important concerne alors le choix des exigences que l'on souhaite développer, etpar extension à UML, le choix des cas d'utilisation à réaliser. Il convient donc d'établirdes priorités entre cas d'utilisation.


Figure 6.1 � Processus itératif (source : developpez.net)

6.2.3 Processus centré sur l'architecture

Cet type de processus est basé sur la recherche de la forme générale du système doitêtre faite dès le début du développement et va ensuite être complétée tout au long desdi�érentes étapes [56] et [61]. Une approche systématique consiste à rechercher une ar-chitecture :

� adaptée aux changements,� pour et avec la réutilisation,� compréhensible intuitivement,� satisfaisant les cas d'utilisation.

La notion d'architecture consiste néanmoins, pour un système logiciel, à dé�nir la façondont le système est construit. Ainsi, elle est souvent représentée par des packages et dessous-systèmes interagissant pour fournir le service demandé. Un système logiciel peut êtrereprésenté suivant cinq vues représentées sur la �gure 6.2.

Figure 6.2 � Processus centré architecture - vues 4+1

� La vue logique décrit les aspects statiques et dynamiques du système en termes


de classes et d'objets. Elle se concentre sur l'abstraction et l'encapsulation et meten jeu des objets et des classes, ainsi que des collaborations et des interactionsautour de ces objets. Cette vue est composée de diagrammes de classes, d'objets,de séquences, de collaboration et d'états.

� La vue de réalisation se préoccupe de l'organisation des modules dans l'environne-ment de développement. Elle montre l'allocation des classes dans les modules, etl'allocation des modules dans les sous-systèmes. Les sous-systèmes sont eux-mêmesorganisés en niveaux hiérarchiques comportant des interfaces bien dé�nies. Cettevue traite les modules, les sous-programmes, les sous-systèmes et les tâches, dansdes diagrammes de composants.

� La vue des processus représente la décomposition en �ots d'exécution (processus,�ls d'exécution et tâches), la synchronisation entre �ots et l'allocation des objetset des classes au sein des di�érents �ots. Elle prend toute son importance dans desenvironnements multitâches. Elle fait apparaître les tâches, les �ls d'exécution, lesprocessus et les interactions, dans des diagrammes de séquence, de collaboration etd'états.

� La vue de déploiement décrit les ressources matérielles et l'implantation du logicieldans ces ressources. Elle prend toute son importance lorsque le système est distribué.Cette vue se concentre sur les n÷uds, les modules et les programmes principaux,dans des diagrammes de déploiement.

� La vue des cas d'utilisation uni�e les quatre vues précédentes. Les cas d'utilisa-tion permettent d'identi�er les interfaces critiques, et forcent les concepteurs à seconcentrer sur les exigences fonctionnelles. Elle rend compte des acteurs, des casd'utilisation, des classes et des collaborations à l'aide de diagrammes des cas d'uti-lisation et de diagrammes de séquence ou de collaboration.

6.2.4 Processus piloté par les cas d'utilisation (CU)

Les cas d'utilisation, développés par Jacobson dans [55], permettent d'identi�er et demodéliser les besoins fonctionnels lors de l'analyse. Dans un développement utilisantUML, ils permettent de relier les di�érentes activités comme le montre la �gure 6.3. Lefait de s'appuyer sur ces cas d'utilisation, impose aux concepteurs pour chaque étape dudéveloppement de faire le lien avec les exigences. Et en e�et, depuis l'analyse jusqu'auxtests, chaque équipe de développement, ou chaque concepteur, peut réaliser ou tester unou plusieurs cas d'utilisation.Pour l'étude des services web en JCWSL, la méthodologie UML à suivre utilisera leprocessus uni�é. Pour représenter les itérations, nous découpons la procédure en quatreitérations : l'expression des besoins, l'analyse conceptuelle, l'implémentation et le dé-


Figure 6.3 � Processus piloté par les cas d'utilisation

ploiement. A chaque itération, il est fortement conseillé de préciser davantage les besoins(objectifs) du service web à mettre en place.La première itération consiste à prendre contact avec le sujet, cerner les besoins a�n dedé�nir les fonctionnalités premières du service web.Pour la réalisation de l'analyse conceptuelle (réaliser la deuxième itération), nous avonschoisi quatre diagrammes UML : les cas d'utilisation, les diagrammes des classes, lediagramme d'activités et le diagramme de séquences.La mise en ÷uvre et la hiérarchisation des cas d'utilisation permet de dé�nir l'ensembledes acteurs mais surtout les fonctionalités du futur système en dé�nissant les opérationsà mettre à place pour l'utilisation du service web. Chaque cas d'utilisation doit avoir uncommentaire sommaire dans un tableau qui l'accompagne.Le diagramme des classes permet la réalisation de la vue logique du service web. Il s'agitpour chaque message et chaque opération de concevoir une classe UML portant les pro-priétés retenues dans notre formalisme. Cette étape permettra d'avoir une vue d'ensemblesur les données et types de données à manipuler dans le service web. Ce diagramme peutêtre directement traduit en code JCWSL pour dé�nir les messages locaux et opérationslocales.Le diagrammes d'activités, nous présente les données et les acteurs qui les manipulent. Ildonne les interactions des acteurs autour des objets.Le diagramme de séquences est le concept qui fait ressortir la séquence des activités, doncl'orchestration des activités. Il précise le temps de vie de chaque acteur du système endé�nissant les tâches qu'il réalise.L'implémentation du système consiste en la traduction en code JCWSL des diagrammesconçus lors de l'itération � analyse conceptuelle �.Après la conception des diagrammes, le concepteur aura une idée globale sur les donnéesdu services, mais aussi sur l'orchestration du comportement. Le diagramme des classessera traduit en JCWSL pour représenter le bloc de dé�nition (importation d'API Java,importation de services web basiques, dé�nition de la classe principale du service, dé�-nition des messages locaux et des opérations locales. Le diagramme d'activités est alorstraduit en code JCWSL pour représenter le comportement du service, car il est plus proche


des spéci�cations JCWSL que le diagramme de séquences qui présente les échanges sansdévelopper leur organisation.Le déploiement d'un service est réalisé selon la �gure 6.4. Cette �gure dé�nit les élémentsconstitutifs du système informatique nécessaire à la mise en ÷uvre d'un service web. Lesystème est composé de trois composants principaux et leurs liens de communications :

1. Le composant Client : ce composant est une classe Java représentant un clientcorrect pour un service web complexe conçu à l'aide de JCWSL. C'est pour celaque ce bloc contient un élément Java, car l'environnement Java est nécessaire à lacréation d'un client pour le service web complexe.

2. Le composant Serveur : il contient deux modules, le serveur web Tomcat/axis quipermet le déploiement du service web complexe ainsi que un module représentantle service web complexe lui-même. Ce module est un package Java qui contienttoutes les classes générées par le langage (voir � Génération du module exécutableau chapitre 4 �).

3. Le composant Services web basiques : Il s'agit de représenter les services web ba-siques qui entrent dans la composition du service complexe. Chaque service basiquesera représenté par un module.

4. Les communications sont assurées à l'aide du protocole de communication SOAP/HTTP,ce qui est représenté par le stéréotype <<soap/http>>. Il est possible que les servicesweb basiques (comme cela est souvent le cas) soient sur Internet.

Figure 6.4 � Diagramme de déploiement d'un service web complexe


6.2.5 Présentation des diagrammes

Le choix des diagrammes a été fait en nous basant sur les travaux de [67], [83], [12],[56] et [5]. Ces travaux développent et critiquent les méthodologies UML pour les servicesweb complexes écrits en BPEL. Ils utilisent les possibilités de personnalisation d'UMLpour créer des stéréotypes a�n de représenter les concepts de BPEL. Ces travaux serontcomplétés par ceux de [18] beaucoup plus récents dont les stéréotypes complètent les troispremiers.Comme notre travail concerne la composition de services web, il devient nécessaire detrouver une modélisation visuelle avant de concevoir des codes dans le langage JCWSL.Les diagrammes dynamiques (diagrammes de séquence et d'activités) sont utilisés pour lavisualisation du comportement du service web complexe, car les services web sont commedes diagrammes de work�ow établissant des liens d'interaction entre plusieurs acteurs.Le diagramme des classes sera utilisé pour représenter la dé�nition du service.

Les cas d'utilisation

La première étape de la modélisation est la dé�nition du système et de ses relations avecl'environnement extérieur (les acteurs). Cette description est purement fonctionnelle.Pour le développement de services web, les cas d'utilisation permettent de connaître lesacteurs qui échangent les données lors de l'orchestration, les fonctions à mettre en placepour l'utilisation du service lui-même, donc la dé�nition des opérations locales du serviceweb JCWSL. Nous utiliserons les notions natives d'UML pour la représentation des casd'utilisation.

Pour l'exemple du service web JeuxQuiz, nous avons les cas d'utilisation suivants : � Com-mencer le jeu � , � Jouer avec un niveau de di�culté aléatoire � , � Jouer avec un niveaude di�culté dé�ni par le joueur � , � Véri�cation de la réponse du joueur � , � Renvoidu score �nal du joueur �. Lors de chaque mode de jeu, il y a renvoi au joueur de laquestion choisie aléatoirement par le service web JeuxQuiz, nous pouvons alors dire queles cas d'utilisation � Jouer avec un niveau de di�culté aléatoire � , � Jouer avec unniveau de di�culté dé�ni par le joueur � s'étendent à un cas intermédiaire � Renvoi dela question au joueur � , d'où la mention � extends � sur les liens correspondants.Les acteurs principaux sont : le joueur et le service basique Service quiz (voir exemple2 dans le chapitre 4 ). L'illustration de ce cas est présentée sur la �gure 6.5. La �gure 6.5présente le client (joueur) et le service basique (Service quiz) qui interagissent avec lesystème (service JeuxQuiz). Ces interactions sont :

� 1. Le joueur initie le jeu en envoyant le nombre de questions à jouer.� 2. Le service JeuxQuiz l'informe des modes de jeux existants (jeu avec niveau de

di�culté aléatoire et jeu avec niveau de di�culté dé�ni par le joueur).


� 3a. Le joueur choisit le mode de di�culté aléatoire.� 3b. Le joueur choisit le mode de di�culté dé�ni par le joueur.� 4a. Le service JeuxQuiz invoque l'opération correspondante au niveau aléatoire du

service web Service quiz.� 4b. Le service JeuxQuiz invoque l'opération correspondante au niveau dé�ni du

service web Service quiz.� 5a. ou 5b. Le service quiz envoie au service JeuxQuiz une question.� 6. Le service JeuxQuiz envoie la question au joueur.� 7. Le joueur invoque le service JeuxQuiz en envoyant sa réponse à la question reçue.� 8. Le service JeuxQuiz envoie la réponse du joueur au service quiz pour véri�cation.� 9. Le service quiz retourne au service JeuxQuiz la réponse de la véri�cation.� 10. Le service JeuxQuiz envoie au joueur son score �nal à l'issue du jeu.

Nous présentons ici, deux exemples de tableau de résumé de cas d'utilisation.Le tableau 6.1 nous donne un résumé du fonctionnement du scénario � Commencer lejeu �.

Nom du scénario Commencer le jeuRésumé Ouvrir le jeuActeur JoueurPréconditions //Description saisie du nombre de questions par le

joueur, à la reception de cette informationle service informe le joueur des modes de jeu disponibles

cas d'erreurs //Postconditions //

Table 6.1 � Cas d'utilisation � Commencer le jeu �

Le tableau 6.2 nous donne un résumé du fonctionnement du scénario � Jouer avec unniveau de di�culté aléatoire �.

Nom du scénario Jouer avec un niveau de di�culté aléatoireRésumé Jouer avec un niveau dé�ni par le service lui-mêmeActeurs Joueur et Service QuizPréconditions //Description Choisir un mode niveau de di�culté aléatoire

invoquer le service quiz pour obtenir une questionrenvoi de la question au joueur


Table 6.2 � Cas d'utilisation � Jouer avec un niveau de di�culté aléatoire �


Figure 6.5 � Cas d'utilisation du service JeuxQuiz

Le diagramme de classes

Nous présenterons l'ensemble des stéréotypes que nous proposons pour les di�érents élé-ments d'un service web en JCWSL. Pour la composition d'un service web en JCWSL,nous avons souvent besoin d'importer des services basiques qui serviront dans la compo-sition. Chaque service web importé est représenté par un nom (qui servira de package lorsde la génération de ses classes) et une URL permettant ainsi son accès. Cela peut alorsse traduire par une classe avec deux données membres (nom et URL) et une méthode(génération de codes Java ou la création du package). Ainsi, nous créerons le stéréotype<<ImportBWS>> pour la représentation de ce concept et le stéréotype <<Import>> pourreprésenter l'importation de packages Java. Ce dernier aura comme données membres lespackages Java à importer.


Un service web composé avec JCWSL est représenté comme une classe Java à l'aide dumot clé CWSDefinition. Cette classe a trois éléments essentiels qui sont :

� les données (messages) à échanger,� l'interface de publication (l'ensemble de ses opérations locales),� l'orchestration du service (la partie comportementale).

Pour la � classe principale � d'un service web complexe JCWSL, nous proposons lestéréotype <<CWSDefinition>>. Elle a une donnée membre qui est son nom. De la mêmefaçon, des stéréotypes seront créés pour les messages <<DefMessage>>, pour les opérations<<DefOperation>> et pour le comportement <<Main>>. Le comportement, à l'image deBPEL est composé de deux parties principales (les variables et la représentation de laséquence des interactions).Pour une vue d'ensemble, nous proposons un � méta-modèle � UML pour JCWSL. Ilspéci�e la structure que doit respecter tout service web qui sera composé en JCWSL etmodélisé en UML. Le méta-modèle est illustré sur la �gure 6.6.

Figure 6.6 � Dé�nition des stéréotypes UML d'un service web en JCWSL

Lors d'une modélisation, chaque message sera représenté avec ses propres informationsde même que pour chaque opération. Pour documenter le diagramme, nous introduisonsle stéréotype <<Comment>> pour les commentaires.Les données (variables) de la classe <<Main>> représente l'ensemble des variables qui


seront utilisées dans le comportement et le stéréotype <<sequence>> représente tout leprocessus de l'orchestration du service web. Nous proposons aussi une représentationgraphique pour chaque constructeur simple (Receive, Reply, Invoke, Wait, OnMessageet OnAlarm) du comportement <<Main>>. Les stéréotypes ainsi créés porteront des libel-lés textuels comme les cas des messages et opérations en plus des propriétés de chaqueconstructeur. Cela facilitera la transformation d'un diagramme de classes en code JCWSLen sur les travaux du [58]. Dans [58], une méthodologie de représentation des messagespar des classes a permis de tracer un parallèle entre les diagrammes de classes et les codesWSDL des services étudiés. La �gure 6.7 illustre les modèles prévus pour les construc-teurs simples de JCWSL. Sur les stéréotypes <<Receive>>, <<Reply>>, <<Invoke>> et<<OnMessage>>, nous avons choisi de représenter les types des variables dans le souci dedonner une signature complète des opérations qui sont manipulées dans ces constructeurs.Pour les stéréotypes <<OnAlarm>> et <<Wait>>, la donnée à indiquer est la condition dedéclenchement de l'alarme ou de l'attente.

Figure 6.7 � Représentation des constructeurs simples de JCWSL en UML

Les constructeurs composés comme While, Pick, Flow, Switch ainsi que le constructeurJavaCode et Sequence ne pourront pas être représentés sous forme de classe, car ils sontplutôt de type dynamique que statique et ne présentent pas en général les données maisles manipulations de celles-ci.Les diagrammes des classes dans notre méthodologie, permettront de connaître les don-nées échangées dans le service web et leurs types. En guise d'exemple, nous donnons icile cas du service web JeuxQuiz. La �gure 6.8 représente l'importation du service webService Quiz en lui attribuant le nom Squiz. Dans cet exemple, il n'y a pas une impor-


tation d'API Java, la �gure 6.9 montre l'importation de l'API java.lang.Math.

Figure 6.8 � Classe UML de l'importation du service basique Squiz

Figure 6.9 � Classe UML de l'importation des API Java

La �gure 6.10 quant à elle illustre les messages NbQuestions et Response du serviceJeuxQuiz. Le message NbQuestions est représenté par une classe ayant son nom propreet son attribut (value) qui est du type int et de visibilité (private) et le messageResponse avec son nom et ses attributs (id et choice) qui sont respectivement detype int et String. La �gure 6.11 illustre l'opération beginGame en présentant sontype (Input/Output), ses paramètres nbq et mych et leurs types respectifs NbQuestionset ChoiceMode. La �gure 6.12 illustre la dé�nition de la classe principale du serviceJeuxQuiz.

Figure 6.10 � Classe UML desmessages NbQuestions et Response

Figure 6.11 � Classe UML del'opération beginGame

Sur la �gure 6.13, nous présentons une vue d'ensemble des données qui seront manipuléesdans le service web complexe JeuxQuiz. Les �èches signi�ent � entre dans la compositiondu �.


Figure 6.12 � Classe UML de la dé�nition du service JeuxQuiz

Figure 6.13 � Dé�nition des classes du service web JeuxQuiz

Le diagramme d'activités

Le diagramme d'activités sera l'un des moyens de modélisation du comportement. Cetype de diagramme sera utilisé pour modéliser l'orchestration des services en UML. Al'aide du diagramme d'activités, nous mettrons en évidence l'orchestration des servicesen présentant les constructeurs comme des objets avec leurs propriétés. C'est ici que les


stéréotypes créés pour les constructeurs seront utilisés. En se référant aux travaux de [67],nous représenterons également, les constructeurs composés comme While (�gure 6.14),Pick (�gure 6.15), Flow (�gure 6.16) et Switch (�gure 6.17).Le stéréotype de While est représenté par la structure traditionnelle de boucle marquée dustéréotype <<While>> placé dans le losange avec la condition de sortie de la boucle. Lesinstructions exécutées dans la boucle sont représentées par le stéréotype <<Sequence>>.Le stéréotype de Pick est représenté par un losange marqué d'une enveloppe illustrantle message. Ce losange a une seule sortie qui permet de choisir l'une des branches pos-sibles illustrées par les stéréotypes <<OnMessage>> et <<OnAlarm>>. Toutes les branchesse rejoignent sur la sortie unique du Pick.Le stéréotype de Flow est illustré par un paquet de documents marqué par le stéréotype<<Flow>> suivi des branches représentant les activités concurrentes à réaliser.Le stéréotype de Switch est aussi un losange comme pour Pick, à la di�érence que celuidu Switch est accompagné d'un point d'interrogation ( ?). Fait à l'image du constructeurswitch de BPEL, le Switch de JCWSL, porte une branche ou un cas (case en anglais).Ce cas est une condition logique permettant la réalisation de certaines activités si lacondition logique correspondante est réalisée.Le stéréotype du constructeur Scope est illustré par un losange marqué du mot clé<<Scope-Comp>>. Il comporte une entrée et deux sorties. Une sortie marquée par lestéréotype <<Scope>> pour les instructions du contexte Scope et une sortie pour lesinstructions de compensations compensate, cette dernière sera marquée du stéréotype<<compensate>>. La �gure 6.18 représente ce constructeur en UML.Le stéréotype <<JavaCode>> est utilisé lorsqu'il y a un traitement intermédiaire à accom-plir au niveau du service complexe. Ce constructeur permet de faire des déclarations devariables, des a�ectations. La �gure 6.19 illustre la représentation UML de ce construc-teur.

Figure 6.14 � Illustration du constructeur While pour UML

Nous présentons ici un exemple de diagramme d'activités pour le service JeuxQuiz. Leservice web JeuxQuiz est représenté par la classe <<Main>> de la �gure 6.20. La classe


Figure 6.15 � Illustration du constructeur Pick pour UML

Figure 6.16 � Illustration du constructeur Flow pour UML

Figure 6.17 � Illustration du constructeur Switch pour UML

porte les variables qui seront utilisées lors des échanges dans le service web. Chaquevariable a son type correspondant, par exemple vLevel a comme type Level.

Le comportement de la classe <<Main>> est décrit en utilisant le diagramme d'activités.Le diagramme d'activité du service JeuxQuiz est illustré sur la �gure 6.21 et la �gure 6.22(suite de la �gure 6.21). Sur la �gure nous avons présenté la partie comportement du ser-


Figure 6.18 � Illustration du constructeur Scope pour UML

Figure 6.19 � Illustration du constructeur JavaCode pour UML

Figure 6.20 � Classe UML pour le comportement du service web JeuxQuiz

vice web, car c'est à ce niveau que le diagramme d'activités a un intérêt. Les activitéscomme Invoke, Receive, Reply sont représentées par leurs stéréotypes. Chaque partici-pant aux interactions est dans un rectangle portant son nom. Les acteurs sont : le client,le service complexe JeuxQuiz et le service basique SQuiz. Sur le diagramme, les activitéssont de deux types : celles qui sont réalisées seulement au niveau du service complexe, iciles codes Java (JavaCode) et celles qui sont réalisées avec la participation des partenaires.Par souci d'illustrer la participation des partenaires, ces activités ont été placées sous lespartenaires correspondants.Ainsi, le service initialise certaines variables dans un JavaCode et reçoit du client lenombre de questions à jouer (activité <<Receive>>) et lui transmet une information surles modes de jeu existants (activité <<Reply>>). Après cette première conversation, leservice ouvre une itération et attend du joueur une question aléatoire avec ou sans niveaude di�culté dé�ni. A la reception de l'opération dé�nissant le mode de jeu, le serviceinvoque une opération chez le service basique pour obtenir pour le client une questionqu'il lui transmet. Ce passage est illustré par le premier constructeur Pick du diagrammed'activités. Lorsque le service web complexe reçoit une question, il le renvoie au joueur(c'est le deuxième Reply du diagramme). Le joueur doit répondre dans cinq minutes sinonune alarme sera actionnée. Le deuxième Pick illustre l'attente par le service complexe de


la réponse du client. Quand le client envoie sa réponse au service complexe (OnMessagedu deuxième Pick), ce dernier invoke la méthode chekcResponse du service basique a�nde véri�er si la réponse du client est vraie ou fausse. A la réception de la réponse duservice basique, le service JeuxQuiz met à jour le score du joueur. La boucle ainsi ouverteprendra �n après que le joueur ait joué le nombre de questions demandées. A la �n de laboucle, le service complexe renvoie le score �nal au joueur.

Figure 6.21 � Diagramme d'activités du service web JeuxQuiz

Le diagramme de séquences

Cette section est basée sur les travaux de [18]. Même si JCWSL est un langage de com-position de services web n'utilisant pas des balises, une représentation graphique de cesconcepts est un avantage certain. La représentation UML d'un service JCWSL permet-tra une observation graphique du service et facilitera la compréhension de celui-ci. Ici,à la di�érence du diagramme d'activités, la représentation graphique ne portera pas sur


Figure 6.22 � Diagramme d'activités du service web JeuxQuiz (suite)

les objets, mais les échanges entre acteurs du service web. Les diagrammes de séquenceseront faits selon la norme de UML 2.0.Nous utiliserons les stéréotypes de [18] pour illustrer les diagrammes de séquence. Cesstéréotypes ont été mis en ÷uvre pour faciliter la représentation UML du temps, desactions d'exécution comme JavaCode sur le diagramme de séquences.En plus des diagrammes d'activités, nous avons choisi le diagramme de séquences pourreprésenter les services web en JCWSL, car ce type de diagramme permet de représenterau mieux l'orchestration du service. Nos diagrammes utiliseront en général comme ac-teurs le client, le service web en JCWSL et le (les) service(s) basique(s) entrant dans lacomposition du service web complexe en JCWSL.

Le tableau 6.3 nous donne les représentations retenues pour les concepts JCWSL.Les concepts de RT-UML de [18] que nous allons utiliser dans le présent mémoire de thèsese divisent en deux groupes : les concepts représentant les constructeurs principaux et les


Constructeurs JCWSL Représentation UMLReceive, Reply, Invoke SingleMessageVariables VariablesPick , Switch Frame avec opt ou altFlow Frame avec parWhile Frame avec loopOnAlarm, Wait RTaction ou RTdelayJavaCode TRreset ou Expressions

Table 6.3 � Représentation des Constructeurs JCWSL en UML pour le diagramme deséquences

concepts liés aux contraintes de temps des services Web. Les concepts utilisés sont desconcepts d'UML 2.0 enrichis des concepts de représentation du temps et des exécutionslocales. Ainsi :

SingleMessage : il représente un échange de message entre les acteurs du système.Dans le cas de JCWSL, il s'agit en général d'un constructeur Receive, Reply, Invoke.

Variables : la section variables d'un service JCWSL est représentée par les variablesqui seront sur le diagramme RT-UML.

Frame "opt" ou "alt" : selon les cas, ces deux frames vont représenter un Pick ouun Switch en JCWSL, car ils permettent de faire des alternatives sur un diagramme deséquences.

Frame "par" : le Frame 'par' représente l'exécution en parallèle de plusieurs activités,il correspond alors au constructeur Flow en JCWSL.

Frame "loop" : ce frame impose la répétition, pour cette raison, il sera utilisé pourreprésenter le constructeur While.Les frames "opt", "alt", "par" et "loop" sont des fenêtres englobant les activités à réaliserdans le cadre d'un Pick, Switch, While ou Flow.

RTAction : ce concept représente une action chronométrée, car il a une durée, où nouspouvons dé�nir un temps de départ ou un temps d'arrivée. Dans notre langage, ce typed'action correspond au constructeur OnAlarm dans un Pick ou Wait.


RTDelay : ce concept représente un délai d'attente. Dans JCWSL, nous pouvonsutiliser ce concept pour représenter Wait et OnAlarm. De même, Wait et OnAlarm peuventêtre représentés par le concept RTEvent.

RTreset : ce concept représente le changement de valeur de l'horloge. Il est alors utilisépour représenter le constructeur JavaCode de JCWSL.Le passage d'un diagramme de séquences à un code JCWSL se fait en traduisant le dia-gramme selon les stéréotypes du tableau 6.3. Ce tableau permet d'établir une correspon-dance entre les constructeurs de JCWSL et les patterns UML utilisés sur les diagrammesde séquence.

Pour une bonne compréhension, nous donnons un exemple d'illustration du diagrammede séquences du service web JeuxQuiz sur la �gure 6.23. Avant de commencer un com-mentaire de la �gure, il est à noter que nous avons préféré utiliser les types des donnéeséchangées aux noms des variables utilisées pour les échanges, car les types sont beaucoupplus informatifs et dans le domaine des services web, le type des données échangées etplus pertinent que le nom de la variable qui transporte l'information.Sur la �gure 6.23, nous avons trois acteurs comme sur le diagramme d'activités : Joueur,JeuxQuiz et SQuiz où chacun est sur sa ligne de vie. Le Joueur représente une classe Javaconçue pour interagir avec un service web complexe. Le fonctionnement du diagrammecommence par l'envoi du nombre de questions par le client (donc une réception par leservice web complexe JeuxQuiz du nombre des questions). Cet envoi est représenté parla �èche portant la mention beginGame(NbQuestions). A la reception de ce message,le service JeuxQuiz informe le joueur des modes de jeu disponibles en lui envoyant lemessage ChoiceMode, d'où la �èche beginGame(ChoiceMode). Puisque le joueur doit ré-pondre à un certain nombre de questions, une itération est nécessaire. Cette itération estreprésentée par la boucle loop. Le joueur ayant la possibilité de jouer avec des questions àniveau de di�culté aléatoire ou dé�ni par lui-même, il doit faire un choix du mode de jeu.Cette alternative est représentée par un constructeur Pick, d'où le premier frame alt.Dans ce cache, nous avons représenté les échanges entre le service web complexe JeuxQuizet le service basique SQuiz par les �èches portant les opérations randomQuestion() etrandomQuestionByDifficultyLevel(Level). Chacune de ces invocations renvoie au ser-vice complexe un message de type RandomQuestion. Le message reçu est placé dans lavariable currentQuestion pour être envoyé au joueur. Cette action est représentée parle � patron � RTreset qui représente un JavaCode. Après avoir placé le message reçudans la variable currentQuestion, le service complexe le renvoie au joueur, d'où la �èchedisplayQuestion(currentQuestion).A la reception de la question, le joueur répond en envoyant sa réponse checkAnswer(Answer),


mais puisque sa réponse doit venir avant cinq minutes, nous avons placé un Pick pourdéclencher une alarme en cas de dépassement de ce temps, ce qui justi�e le RTAction.A la réception du message contenant la réponse du joueur, une a�ectation du numéro dela question et de la réponse du joueur est e�ectuée d'où RTreset et le service JeuxQuizinvoque la méthode checkResponse(Answer) du service basique SQuiz.La réception de message de véri�cation de la réponse du joueur, un traitement est e�ectuépour savoir si la réponse du joueur était bonne ou mauvaise et son score est mis à jour,d'où le dernier RTreset.En�n, le service complexe renvoie au client son score �nal, ce qui est représenté par la�èche finalScore(Score).

Figure 6.23 � diagramme de séquences du service web JeuxQuiz

6.3 Etude de cas : reservation de billets auprès d'une agence de voyage 161

Le diagramme de déploiement

Les diagrammes de déploiement suivent tous presque le même schéma (voir �gure 6.4).Dans le cas de notre exemple, ce diagramme sera personnalisé selon la �gure 6.24. Cediagramme se compose de trois parties qui sont :

� Le composant Serveur contenant l'environnement Axis/Tomcat et le service webcomplexe JeuxQuiz.

� Le composant Services web basiques qui contient le service web Jeux. Ce servicen'étant pas ici sur Internet, nous avons enlevé le stéréotype correspondant.

� Le bloc Client pour invoquer le service web complexe. Ce composant est développésous Java, d'où la mention Java.

Figure 6.24 � Diagramme de déploiement du service web JeuxQuiz

6.3 Etude de cas : reservation de billets auprès d'une agencede voyage

6.3.1 Présentation de l'application

L'étude de cas consiste en la mise en place d'un service web, qui agrège trois services weben l'occurrence, le service web d'une entreprise et les services web de deux agences devoyage qui sont : Mande voyage et Dogon voyage, pour réserver des billets d'avion auprèsde ces agences de voyage lors de missions et de vacances �nancées par l'entreprise.Les deux agences o�rent des services de vente de billets d'avion avec la possibilité dereserver une chambre d'hôtel. Le service web de l'entreprise permet la gestion des voyagesde mission de ses employés.Les services web des agences de voyage o�rent les fonctionalités suivantes :

1. Recherche de billets (places libres) par date : cette fonctionalité permet l'intro-duction d'une date pour obtenir l'ensemble des places libres de l'agence à la date


concernée.

2. Recherche de billets par date et par destination : comme la précédente, cette fonctionconsiste à introduire une date, une destination ainsi que le type de billet (premièreclasse ou économique) pour obtenir des informations comme un numéro de vol, leprix du billet de la classe de voyage concernée.

3. Réservation d'un billet : elle permet la réservation d'une place, donc d'un billet,après avoir consulté la base des données. Avec cette fonctionalité, il sera nécessaired'introduire le numéro du vol, une place, la classe de voyage, le nom et prénom del'employé. Cette fonction réserve la place dans le vol en enregistrant les informationsde l'employé et retourne des informations comme le numéro du vol, la date et l'heuredu vol, le numéro de la place ainsi que le prix du billet : bref un reçu du billet.

4. Réservation d'une chambre d'hôtel : cette fonctionalité permet à l'agence de voyagede proposer des chambres d'hotels libres à ses clients. Elle permet l'introductiond'une destination de voyage, la date de location de la chambre, le numéro de volde l'employé, sa place dans le vol, et le nombre de jours de location. Les chambressont mises à disposition par des hôtels partenaires.

5. Reservation d'un billet et d'une chambre d'hôtel : Cette fonctionalité permet à lafois de reserver un billet et une chambre d'hôtel.

Toutes ces fonctionalités sont utilisables séparément. La �gure 6.25 représente l'interfaced'invocation des services web des agences de voyage, c'est une illustration symbolique duservice qui est utilisée pour présenter les messages et opérations de ces services web. Surla �gure nous avons représenté les di�érentes opérations des �chiers WSDL des agencesde voyages en schématisant les � portTypes � des services.Le service web de l'entreprise présente cinq fonctionnalités qui sont :

� employeeInfos : permet d'obtenir des informations sur un employé.� allEmployeesInfos : permet d'obtenir des informations sur tous les employés.� employeeTravelStatus : permet d'obtenir le statut de voyage d'un employé, c'est-à-

dire le type de billet d'avion auquel il a droit pour ses déplacements.� employeeHollydayInfo : permet d'obtenir des informations sur les congés d'un em-

ployé.� hollydaiesPlanning : permet d'obtenir le planning global des congés de l'entreprise.

Considérons que les services existants se trouvent aux adresses suivantes :� web service Employe :http://localhost:8080/axis/services/employe?wsdl


Figure 6.25 � Schéma du service web d'une agence de voyage

� web service Mande voyage :http://localhost:8080/axis/services/mande?wsdl

� web service Dogon voyage :http://localhost:8080/axis/services/dogon?wsdl

Dans la présente étude de cas, nous proposons un service web qui utilisera les trois servicespour o�rir de nouvelles fonctionalités telles que la recherche simultanée de billets auprèsdes deux agences, la comparaison des prix, a�n de choisir le moins cher pour l'entreprise.Ce nouveau service va invoquer le service de l'entreprise pour obtenir le statut de voyaged'un employé et les services d'agences, pour reserver un billet ou un billet et une chambred'hôtel. Le service qui sera mis en place sera nommé Travel.

6.3.2 Etude conceptuelle du service

Nous commençons l'étude conceptuelle par la mise ne place du diagramme des cas d'uti-lisation du service Travel. Après le diagramme des cas d'utilisation, nous présenteronsles classes des messages locaux et opérations locales, la classe principale et la classe re-présentant le comportement du service Travel. L'étude conceptuelle se termine par laconception des diagrammes d'activités des scénarios d'invocation du service et leurs dia-grammes de séquences correspondants.


Diagramme des cas d'utilisation

Selon l'objectif de l'application, nous aurons les fonctionalités suivantes :

1. Recherche d'un billet.2. Réservation d'un billet.3. Réservation d'un billet et d'une chambre d'hôtel.

Chaque fonctionalité est un scénario UML. Ce qui nous donne trois scénarios recherchebillet, réservation simple de billet et réservation de billet et d'une chambre d'hôtel. La�gure 6.26 présente les trois scénarios qui mettent le service web JCWSL en interactionavec le client.Le tableau 6.4, 6.5, 6.6 nous donne les résumés des fonctionnements des scénarios.

Figure 6.26 � Diagramme de cas d'utilisation du service Travel

Diagrammes des classes

Notre diagramme permettra de dé�nir nos messages locaux et opérations locales ainsi queles importations diverses. Pour la réalisation du présent service web, nous aurons besoindes messages suivants :

� EmployeeRequest : ce message permet la saisie de l'identi�ant de l'employé, sadestination et de l'année de voyage. Ce message est composé de trois parties id(ID de l'employé), dest (destination de l'employé) et année (année budgétaire duvoyage).


Nom du scénario Recherche d'un billet d'avionRésumé Rechercher un billet d'avion en utilisant une agence de voyageActeur ClientPréconditions //Description Saisie du numéro matricule de l'employé et

de l'année par le client,à la réception des valeurs de ces informations,le service invoque le service Employepour obtenir les informations de voyage de l'employé


Table 6.4 � Cas d'utilisation - Recherche d'un billet d'avion

Nom du scénario Réservation d'un billet d'avionRésumé Rechercher un billet d'avion et puis le réserverActeurs Client, service TravelPréconditions //Description Après avoir obtenu des informations sur les places disponibles

le client fait une réservation d'un billetcas d'erreurs //Postconditions //

Table 6.5 � Scénario : Réservation de billet

Nom du scénario Réservation d'un billetd'avion et d'une chambre d'hôtel

Résumé Rechercher un billet d'avion et puis le réserveravec une chambre d'hôtel

Acteurs Client, service TravelPréconditions //Description Après avoir obtenu des informations sur les places disponibles

le client fait une réservation d'un billet et de sa chambre d'hôtelcas d'erreurs //Postconditions //

Table 6.6 � Scénario : réservation d'un billet et d'une chambre d'hôtel

� GetTravelInfo : ce message représente l'ensemble des informations permettant l'in-vocation des services des agences a�n d'obtenir le plan de vol. ChoosenInfo : repré-sente le résultat de la recherche du plan de vol. Ce message contient entre autresles renseignements de l'agence retenue.

� TicketRequest : représente le message permettant l'invocation des services Mande etDogon a�n de réserver un billet d'avion après comparaison les o�res de Mande voyageet Dogon voyage.


� TicktsInfo : représente le message retourné par le service Travel à la suite desinvocations des services Mande et Dogon pour la réservation d'un billet.

� HotelRequest : représente le message permettant l'invocation des services Mande etDogon a�n de reserver un billet et une chambre d'hôtel.

� HotelInfo : représente le message retourné par le service Travel à la suite des invo-cations des services Mande et Dogon pour la réservation d'un billet et d'une chambred'hôtel.

Les opérations sont au nombre de trois :

1. checkTravelStatus : une opération de type Input/Output permettant la recherchedu statut de voyage d'un employé en invoquant emp.employeeTravelStatus. Elleprend comme paramètre un message de type EmployeeRequest et retourne un mes-sage de type ChosenInfo. Pour cela, l'invocation de emp.employeeTravelStatusretourne une information de type emp.TravelStatus. Cette information est ensuiteutilisée pour invoquer les services Mande et Dogon pour obtenir respectivement lesinformations : mande.TravelInfo ou dogon.TravelInfo. L'agence choisie selon sonprix, verra ses informations placées dans une variable de type ChosenInfo qui estretournée par l'opération checkTravelStatus.

2. ticketWithoutHostel : permet la réservation d'un billet sans chambre d'hôtel. Elleest aussi Input/Output. Elle prend comme paramètre en entrée un message detype TicketRequest et retourne un message de type TicketsInfo. Ce type d'infor-mation est basé sur les types mande.TicketInfo ou dogon.TicketInfo renvoyéesrespectivement après les invocations des services Mande et Dogon.

3. ticketWithHostel : permet la réservation d'un billet avec une chambre d'hôtel.Elle est aussi Input/Output. Elle prend comme paramètre un message de typeHotelRequest et retourne un message de type HotelInfo. Ce type d'informationest basé sur les types mande.BilletHotel ou dogon.BilletHotel retournées res-pectivement après les invocations des services Mande et Dogon..

Dans le diagramme des classes, nous avons aussi les services importés comme Employe,Mande et Dogon. Chaque commande d'importation sera une classe à part. Pour la repré-sentation, nous aurons alors trois classes <<ImportBWS>>. Dans ce service, nous avonsaussi besoin de deux API de Java pour bien représenter les dates et heures. Ces API Javasont java.util.* et java.text.*. Nous n'avons pas représenté sur la �gure les classespour ces deux importations.Le comportement sera représenté par la classe <<Main>> qui comprend les variables quiseront utilisées lors des échanges de messages entre les services qui entrent dans l'orches-


tration du service web complexe Travel.La conception des diagrammes de classe se terminera par celle de la classe principale duservice <<CWSDefinition>>.La �gure 6.27 représente les classes du service web Travel. Nous avons représenté lesclasses représentant les messages, les opérations, les importations de services existantsainsi que la classe du comportement.

Figure 6.27 � Diagramme des classes du service Travel

Diagramme d'activités

Le diagramme d'activités du service Travel a été découpé en trois pour une meilleurecompréhension du système. Nous avons cinq acteurs qui participent à l'ensemble desactivités du service. Ces acteurs sont : le client, le service web complexe Travel, le serviceweb Employe, le service web Mande et le service web Dogon. Comme retenu lors de l'étude


des diagrammes d'activités pour le langage JCWSL, nous avons placé sous chaque acteurles objets qu'il échange avec le service web complexe et seuls les traitements locaux sontplacés sous le service web complexe Travel. Sur chaque diagramme, nous avons présentéles types des messages échangés.

La �gure 6.28 représente le diagramme d'activités du scénario � recherche d'un billet �.Les activités commencent par un objet Receive du service Travel qui représente l'en-voi du message EmployeeRequest (information pour invoquer le service web Employe) àl'aide de l'opération checkTravelStatus(). A la reception du message EmployeeRequest,le service Travel invoque l'opération employeeTravelStatus() du service web Employe.Le service web Employe retourne le statut de l'employé. Avec ces informations et aprèsavoir e�ectué des traitements principalement d'assignation, le service Travel invoque si-multanément les services web Mande et Dogon. Ces deux services retournent chacun desinformations concernant le billet dont le prix. Le service web Travel e�ectue une compa-raison des deux prix et renvoie au client les informations du plus petit prix (ChosenInfo)à l'aide de l'opération checkTravelStatus().

La �gure 6.29 représente le diagramme d'activités du scénario � réservation d'un billet �.Après l'obtention des informations à la suite de la recherche du billet, le client a deuxpossibilités d'action, il peut réserver uniquement un billet, ou un billet avec une chambred'hôtel. Ce choix est représenté par le stéréotype Pick. Sur la �gure 6.29, nous avonsreprésenté le volet réservation de billet uniquement, qui est déclenchée par le stéréotype<<OnMessage>> de l'opération ticketWithoutHotel(). Celui-ci enverra au service le mes-sage TicketRequest. Ensuite selon le choix de service web e�ectué (service dont le prixest le plus petit), le service Travel peut invoquer le service Mande ou Dogon. Chacunde ces services renvoie un message de type TicketsInfo que le service Travel renvoieau client à l'aide de l'opération ticketWithoutHotel(). Les acteurs client, service webTravel, le service web Mande et le service web Dogon participent à ces activités.

La �gure 6.30 représente le scénario � réservation d'un billet avec une chambre d'hôtel �.C'est la deuxième branche du choix du client. Cette branche est déclenchée à la suitede l'opération ticketWithHotel() du client. Cette opération envoie au service Travelle message HotelRequest. A la reception de ce dernier, le service web Travel, selon leservice choisi entre Mande et Dogon invoque l'opération reserverBilletChambre() quirenvoie un message de type HotelInfo. Le service Travel à la reception de ce message, leretourne au client à l'aide de l'opération ticketWithHotel(). Les acteurs client, serviceweb Travel, le service web Mande et le service web Dogon participent à ces activités.


Figure 6.28 � Diagramme d'activités de la recherche d'un billet

diagramme de séquences

Le diagramme de séquences de notre étude est composé de cinq acteurs, donc cinq lignesde vie qui sont le client, le service web complexe Travel, le service web Employe, le service


Figure 6.29 � Diagramme d'activités de la réservation d'un billet

web Mande et le service web Dogon. Sur les diagrammes de séquences, nous avons utilisé lesopérations avec les données échangées sur les �èches. Sur les diagrammes, chaque donnéeéchangée est représentée par son type.


Figure 6.30 � Diagramme d'activités de la réservation d'un billet et d'une chambred'hôtel

Pour une meilleure compréhension, nous utilisons deux diagrammes de séquences pournotre système : un diagramme pour la recherche et un diagramme pour les réservations.Le diagramme de séquences du scénario � recherche de billet � est présenté sur la �-


gure 6.31. La séquence commence par l'envoi d'un message de type EmployeeRequest. Ala réception, le service web Travel invoque l'opération employeTravelStatus(). Cetteinvocation renvoie au service web Travel les informations permettant ensuite d'invoquerles services web des agences de voyage. Ce diagramme comporte le bloc de traitementsparallèles marqué par le mot-clé par qui englobe les invocations simultanées des deuxservices d'agences de voyage.

Figure 6.31 � Diagramme de séquences de la recherche d'un billet

Le deuxième diagramme de séquences concerne les scénarios � réservation d'un billetsimple et réservation d'un billet et d'une chambre d'hôtel �. Les acteurs client, serviceweb Travel, service web Mande et service web Dogon participent à ce diagramme. La�gure représentant le diagramme est la �gure 6.32. La �gure comporte deux blocs alt.Le premier bloc alt représente le constructeur Pick du diagramme d'activités, dont la


deuxième branche est représentée par le bloc else. Le deuxième bloc alt représente leconstructeur Switch permettant de dé�nir le service web d'agence de voyage à invoquerpour la suite des opérations du système.

Figure 6.32 � Diagramme de séquences de la réservation d'un billet et d'une chambred'hôtel


6.3.3 Implémentation de l'étude de cas

L'implémentation consiste à traduire les diagrammes de séquence en code du langageJCWSL. Cette traduction des diagrammes de séquence se fait toujours en considérant lesdonnées sur le diagramme de classes pour traduire les importations, les dé�nitions desmessages et opérations et le tableau 6.3 de mapping entre UML et JCWSL pour traduireles constructeurs du comportement. Le code est illustré sur le listing suivant :

1 import java.text .*;2 import java.util .*;3 importBWS emp="http :// localhost :8080/ axis/services/employews?wsdl";4 importBWS mande="http :// localhost :8080/ axis/services/mande?wsdl";5 importBWS dogon="http :// localhost :8080/ axis/services/dogon?wsdl";67 public CWSDefinition Travel{8 public DefMessage EmployeeRequest{String id; int annee; String dest;}9 public DefMessage GetTravelInfo{String date; String dest;10 String classe ;}11 public DefMessage ChosenInfo{String agence; String NumVol;12 Date dateVol; Object HeureVol; String NumPlace;13 String Depart; String Arrivee; double Prix;}14 public DefMessage TicketRequest{String NumVol; String NumPlace;15 String Classe; String NomPass; String PrenPass ;}16 public DefMessage TicketsInfo{String Nom; String Prenom; String NumVol;17 String DateVol; Object HeureVol; String Depart;18 String Arrivee; String NumPlace; double Prix;}19 public DefMessage HotelRequest{String Dest; String Stdate;20 String NumVol; String NumPlace; String Classe;21 String NomPass; String PrenPass; int nbJour ;}22 public DefMessage HotelInfo{String Nom; String Prenom; String NumVol;23 String DateVol; Object HeureVol; String Depart;24 String Arrivee; String NumPlace; double Prix;25 String NomHotel; String AdrHotel; String NumChbr;26 String debutLoc; int nbJour ;}27 // =========================================================================28 public DefOperation checkTravelStatus(Input/Output:29 EmployeeRequest Etr , ChosenInfo ci){}30 public DefOperation tickWithoutHotel(Input/Output:31 TicketRequest br, TicketsInfo bi){}32 public DefOperation tickWithHotel(Input/Output:33 HotelRequest hr, HotelInfo hi){}34 // ==========================================================================35 void main{36 Variables{37 Variable(vEmpRequest , EmployeeRequest );38 Variable(vTravelInfo , GetTravelInfo );39 Variable(vChosInfo , ChosenInfo );40 Variable(vTktRq , TicketRequest );41 Variable(vTktInfo , TicketsInfo );42 Variable(vHtlReq , HotelRequest );43 Variable(vHtlInfo , HotelInfo );44 }45 Sequence{46 JavaCode{


47 emp.TravelStatus vEmpInfo=new emp.TravelStatus ();48 mande.TravelInfo vMandeRq=new mande.TravelInfo ();49 dogon.TravelInfo vDogonRq=new dogon.TravelInfo ();50 mande.TicketInfo vTktMande=new mande.TicketInfo ();51 dogon.TicketInfo vTktDogon=new dogon.TicketInfo ();52 mande.BilletHotel vHtlMande=new mande.BilletHotel ();53 dogon.BilletHotel vHtlDogon=new dogon.BilletHotel ();54 String nomS="";55 SimpleDateFormat formater=new SimpleDateFormat("dd/MM/yyyy");56 Date uneDate=null;57 String stDate="";58 }59 Receive(checkTravelStatus , vEmpRequest );60 Invoke(emp.employeeTravelStatus , vEmpRequest , vEmpInfo );61 JavaCode{62 uneDate=vEmpInfo.getDateDebut ();63 stDate=formater.format(uneDate );64 vTravelInfo.setDate(stDate );65 vTravelInfo.setDest(vEmpInfo.getDest ());66 vTravelInfo.setClasse(vEmpInfo.getClasseVoyEmp ());67 }68 Flow{69 Invoke(mande.rechercheParDateDest , vTravelInfo ,70 vMandeRq );71 Invoke(dogon.rechercheParDateDest , vTravelInfo ,72 vDogonRq );73 } // end of Flow74 JavaCode{75 if(vMandeRq.getPrix () <= vDogonRq.getPrix ()){76 vChosInfo.setAgence("mande");77 vChosInfo.setNumVol(vMandeRq.getNumVol ());78 vChosInfo.setDateVol(vMandeRq.getDateVol ());79 vChosInfo.setHeureVol(vMandeRq.getHeureVol ());80 vChosInfo.setNumPlace(vMandeRq.getNumPl ());81 vChosInfo.setDepart(vMandeRq.getVilleDepart ());82 vChosInfo.setArrivee(vMandeRq.getVilleArrivee ());83 vChosInfo.setPrix(vMandeRq.getPrix ());84 nomS="mande";85 }86 else {87 vChosInfo.setAgence("dogon");88 vChosInfo.setNumVol(vDogonRq.getNumVol ());89 vChosInfo.setDateVol(vDogonRq.getDateVol ());90 vChosInfo.setHeureVol(vDogonRq.getHeureVol ());91 vChosInfo.setNumPlace(vDogonRq.getNumPl ());92 vChosInfo.setDepart(vDogonRq.getVilleDepart ());93 vChosInfo.setArrivee(vDogonRq.getVilleArrivee ());94 vChosInfo.setPrix(vDogonRq.getPrix ());95 nomS="dogon";96 }97 }98 Reply(checkTravelStatus ,vChosInfo );99 Pick{

100 OnMessage(ticketWithOutHostel , vTktRq ){101 Switch {102 Case:{ JavaCode{nomS.equalsIgnoreCase("mande")}} {


103 Invoke(mande.reserverBillet , vTktRq , vTktMande );104 JavaCode{105 vTktInfo.setNom(vTktMande.getNom ());106 vTktInfo.setPrenom(vTktMande.getPrenom ());107 vTktInfo.setNumVol(vTktMande.getVol ());108 uneDate=vTktMande.getDate ();109 stDate=formater.format(uneDate );110 vTktInfo.setDateVol(stDate );111 vTktInfo.setHeureVol(vTktMande.getHeure ());112 vTktInfo.setDepart(vTktMande.getAllantde ());113 vTktInfo.setArrivee(vTktMande.getSerendanta ());114 vTktInfo.setNumPlace(vTktMande.getPlace ());115 vTktInfo.setPrix(vTktMande.getPrix ());116 }117 }//end case118 Case:{ JavaCode{nomS.equalsIgnoreCase("dogon")}} {119 Invoke(dogon.reserverBillet , vTktRq , vTktDogon );120 JavaCode{121 vTktInfo.setNom(vTktDogon.getNom ());122 vTktInfo.setPrenom(vTktDogon.getPrenom ());123 vTktInfo.setNumVol(vTktDogon.getVol ());124 uneDate=vTktDogon.getDate ();125 stDate=formater.format(uneDate );126 vTktInfo.setDateVol(stDate );127 vTktInfo.setHeureVol(vTktDogon.getHeure ());128 vTktInfo.setDepart(vTktDogon.getAllantde ());129 vTktInfo.setArrivee(vTktDogon.getSerendanta ());130 vTktInfo.setNumPlace(vTktDogon.getPlace ());131 vTktInfo.setPrix(vTktDogon.getPrix ());132 }133 }//end case134 } // end switch135 Reply(ticketWithOutHostel , vTktInfo );136 } // end of OnMessage137 OnMessage(ticketWithHostel , vHtlReq ){138 Switch {139 Case:{ JavaCode{nomS.equalsIgnoreCase("mande")}} {140 Invoke(mande.reserverBillet , vHtlReq , vHtlMande );141 JavaCode{142 vHtlInfo.setNom(vHtlMande.getNom ());143 vHtlInfo.setPrenom(vHtlMande.getPrenom ());144 vHtlInfo.setNumVol(vHtlMande.getVol ());145 uneDate=vHtlMande.getDate ();146 stDate=formater.format(uneDate );147 vHtlInfo.setDateVol(stDate );148 vHtlInfo.setHeureVol(vHtlMande.getHeure ());149 vHtlInfo.setDepart(vHtlMande.getAllantde ());150 vHtlInfo.setArrivee(vHtlMande.getSerendanta ());151 vHtlInfo.setNumPlace(vHtlMande.getPlace ());152 vHtlInfo.setPrix(vHtlMande.getPrix ());153 vHtlInfo.setNomHotel(vHtlMande.getNomHotel ());154 vHtlInfo.setAdrHotel(vHtlMande.getAdrHotel ());155 vHtlInfo.setNumChbr(vHtlMande.getNumChambre ());156 vHtlInfo.setDebutLoc(vHtlMande.getDebut ());157 vHtlInfo.setNbJour(vHtlMande.getNbJour ());158 }

6.4 Conclusion 177

159 }//end case160 Case:{ JavaCode{nomS.equalsIgnoreCase("dogon")}} {161 Invoke(dogon.reserverBilletChambre ,vHtlReq ,vHtlDogon );162 JavaCode{163 vHtlInfo.setNom(vHtlDogon.getNom ());164 vHtlInfo.setPrenom(vHtlDogon.getPrenom ());165 vHtlInfo.setNumVol(vHtlDogon.getVol ());166 uneDate=vHtlDogon.getDate ();167 stDate=formater.format(uneDate );168 vHtlInfo.setDateVol(stDate );169 vHtlInfo.setHeureVol(vHtlDogon.getHeure ());170 vHtlInfo.setDepart(vHtlDogon.getAllantde ());171 vHtlInfo.setArrivee(vHtlDogon.getSerendanta ());172 vHtlInfo.setNumPlace(vHtlDogon.getPlace ());173 vHtlInfo.setPrix(vHtlDogon.getPrix ());174 vHtlInfo.setNomHotel(vHtlDogon.getNomHotel ());175 vHtlInfo.setAdrHotel(vHtlDogon.getAdrHotel ());176 vHtlInfo.setNumChbr(vHtlDogon.getNumChambre ());177 vHtlInfo.setDebutLoc(vHtlDogon.getDebut ());178 vHtlInfo.setNbJour(vHtlDogon.getNbJour ());179 }180 }//end case181 } // end switch182 Reply(ticketWithHostel , vHtlInfo );183 } // end of OnMessage184 } // end of Pick185 } // end of Sequence186 } // end of main187 } // end of CWSDefinition

6.3.4 Le diagramme de déploiement

Le diagramme de la �gure 6.33 représente le schéma physique du système avec trois blocs :� Le composant Serveur contient le serveur web Tomcat avec l'environnement Axis

pour le déploiement et l'invocation du service web complexe. Le service est icireprésenté par le bloc Travel qui contient le package du service web proprementdit.

� Le composant Client qui schématise un client correct pour le service web. Ce clientest en général développé avec Java.

� Le composant des services basiques. Ils sont ici au nombre de trois (Employee,mande et dogon). Ce bloc est composé des services web et des bases des donnéesqu'ils utilisent pour leurs fonctionnements.

6.4 Conclusion

Dans ce chapitre, nous avons mis en place une méthodologie UML pour le langageJCWSL. Cette méthodologie utilise le Processus Uni�é pour dé�nir une démarche. Notre


Figure 6.33 � Diagramme de déploiement du service Travel

démarche prévoit quatre itérations : l'expression des besoins, l'analyse conceptuelle, l'im-plémentation et le déploiement.Grâce aux notions de MDA (Model Driven Architecture) et de UML Pro�ls, nous avonsproposé des stéréotypes pour les objets du langage. Ces stéréotypes permettent la repré-sentation visuelle des � patrons � de JCWSL.Le choix de la démarche du Processus Uni�é a été fait, car des trois méthodologies lesplus connues d'UML (Processus Uni�é, COMET et ROPES), le Processus Uni�é sembleavoir un ascendant sur les autres.Une méthodologie UML pour le langage JCWSL renforce les possibilités de ce dernier, card'une manière générale, il n'existe pas de méthodologie pour la conception des servicesweb complexes.

Chapitre 7

Conclusion et Perspectives

Le présent mémoire de thèse est le fruit de plusieurs années de recherche sur les servicesweb et plus précisément sur la problématique des langages de composition de servicesweb complexes. Ce chapitre sera présenté dans deux temps. Dans un premier temps, nousprésenterons le bilan de nos contributions et dans un deuxième temps nous parlerons desperspectives ouvertes par ces travaux.Le rapport est composé de deux parties principales :

� L'état de l'art : dans cette partie composée de deux chapitres, nous avons faitune présentation de ce qui existe dans le domaine. Ainsi, nous avons présenté lestechnologies des services web, les langages de composition et certaines plate-formede conception et de composition de services web. Comme l'un de nos objectifs étaitde proposer une méthodologie UML pour le langage JCWSL, nous avons fait dansle chapitre 3, un tour d'horizon des méthodologies de conception et des langagesde conception des systèmes d'information, où un accent particulier a été mis sur lelangage UML.

� Nos contributions : cette partie composée de trois chapitres a fait l'objet tourà tour de la présentation du langage Java Complex Web Service Language, deson environnement graphique de composition et de sa méthodologie de conceptionUML. Dans nos conclusions, nous faisons ici un état de ces contributions et lesperspectives possibles du langage et de ses outils.

7.1 Bilan des contributions

Nos contributions qui ont consisté à la proposition d'un langage de composition accom-pagné d'un environnement graphique de composition et d'une méthodologie UML deconception ont été présentées dans trois chapitres.Le chapitre 4 est celui qui a été consacré à l'étude du langage JCWSL. Il a constitué àla présentation des concepts, des mots-clés du langage, mais aussi à la présentation de

180 Chapitre 7. Conclusion et Perspectives

l'exploitation du langage. Le langage JCWSL est représenté sous forme de deux analy-seurs (parsers en anglais) séparés. Chaque analyseur procède à l'analyse syntaxique et àl'analyse sémantique du code JCWSL avant de produire les résultats prévus.

Le premier analyseur appelé CWSLanguageC, permet la production du comportement ob-servable du service web par la réalisation de deux �chiers :

� Un �chier WSDL qui représente l'interface de publication du service web.� Un �chier BPEL qui représente le comportement observable du service web.

Le second analyseur appelé SWCLanguageC, permet la production du module exécutable(en quelque sorte le moteur) du service web. Ce moteur est constitué d'un ensemble declasses Java et des �chiers de déploiement du service web.

En qui concerne l'exploitation du langage, nous avons surtout présenté la génération desanalyseurs du langage. Après quoi, nous avons dé�ni les conditions techniques d'utilisationdu service. Ainsi, un service web généré par JCWSL est utilisable dans l'environnementTomcat/Axis. Ce chapitre se termine par la présentation de trois exemples.

Il est à noter que le langage JCWSL hérite des propriétés de Java telles que la portabi-lité vis-à-vis du système d'exploitation, la facilité d'apprentissage, l'expressivité. Ce quirépond à la question posée dans la problématique de cette thèse, à savoir la contributionà la facilitation de la mise en place des services web complexes.

Le chapitre 5 a été consacré à la présentation de l'environnement JCWSDE. Il a étédéveloppé dans ce chapitre l'architecture de l'environnement ainsi que sa procédure deconception. Dans cette partie, nous avons aussi présenté l'outil GEF (Graphical EditingFramework) qui a été utilisé pour la mise en place de notre environnement. Il est à noterque l'environnement JCWSDE a été conçu comme un plug-in d'Eclipse et en ce sens, ilhérite de la presque totalité des avantages des plug-ins d'Eclipse par exemple en ce quiest de leur indépendance du système d'exploitation.

Le chapitre 6 a fait l'objet de la mise en place d'une méthodologie UML pour notrelangage. Après la présentation du langage UML dans le chapitre 3, et l'étude de certainsde ses multiples diagrammes, dans le chapitre 6, nous avons mis en place une méthodologieUML pour le langage JCWSL, en choisissant les diagrammes nécessaires à notre langage.Parmi les diagrammes UML, nous avons choisi les cas d'utilisation, les diagrammes declasses, les diagrammes d'activités et les diagrammes de séquences. Ces diagrammes ontété choisis en tenant compte de la possibilité de représenter les concepts de JCWSL. Lechapitre s'est terminé par la présentation d'une étude de cas dans le domaine des agencesde voyage et de tourisme.

7.2 Perspectives 181

7.2 PerspectivesComme perspectives nous avons dégagé trois axes : l'exploitation du langage, les pers-pectives d'extension et de prise en charge de la qualité de service (QoS).

Exploitation du langage :Le langage JCWSL étant à ce niveau encore à l'état de prototype, nous espérons une vali-dation expérimentale pouvant tester toutes les possibilités du langage. Ces tests pourrontpermettre une validation du langage comme langage pouvant servir pour la composi-tion des services web complexes. Les conditions d'exploitation du langage n'étant pascomplexes, ces tests de validation doivent être faciles à mettre en ÷uvre en prenant desexemples qui tournent déjà sous d'autres systèmes similaires.

Extension du langage :Ce langage permet l'utilisation des services basiques pour la composition du service com-plexe par invocation statique. Il sera pertinent de faire évoluer le langage vers la dé-couverte dynamique des services basiques, surtout si ces derniers ont des propriétés decatégorisation pouvant permettre de rechercher de façon dynamique un service web ap-partenant à telle ou telle catégorie. Cette évolution (ou extension) doit se traduire parla modi�cation des règles du constructeur importBWS ou la mise en place d'un nouveauconstructeur chargé uniquement de la recherche dynamique des services basiques lors dela composition d'un service web complexe. Pour rendre cette perspective réalisable, lesservices web doivent avoir une propriété permettant cette recherche, telle qu'une propriétédé�nissant par exemple le domaine du service.Une extension du langage consistera à mieux structurer la gestion des erreurs surtoutsur le graphe dans l'environnement CWSE de sorte à mettre des couleurs visibles sur lespoints d'erreurs.

Environnement intelligent :Un des domaines vers lequel ce langage peut évoluer est aussi la possibilité de contrôler laqualité de service (QoS) lors des découvertes statiques ou dynamiques. Cette fonctionalitérendra le langage beaucoup plus intelligent. Une telle extension pour le contrôle du QoSdes services invoqués nécessite des modi�cations au niveau du constructeur importBWS.Comme la perspective de recherche dynamique, l'introduction de la QoS dans JCWSLsuppose que les services existants ont des caractéristiques pouvant exprimer un certainnombre de qualités telles que le temps de réponse, la qualité du réseau.

182 Chapitre 7. Conclusion et Perspectives

Bibliographie

[1] Inc. Active Endpoints. Activevos fundamentals. (http : //www.active −endpoints.com/community − educationcenter.php), 2008.

[2] D. H. Akehurst. Experiment in model driven validation of bpel speci�actions.University of Kent at Canterbury, technical support 265-276, 2006.

[3] B. Alistair, D. Marion, and O. Phillipa. A critical overview of the web serviceschoreography description language ws-cdl. BPTrends, 2005.

[4] D. Almaer. Creating web services with apache axis. ONJava.com (http ://www.onjava.com/lpt/a/1578), 2002.

[5] L. Antoine. Modélisation des processus métiers et standardisation. Journal du Net,17/09/2004.

[6] Apache. Apache mirrors. (http : //apache.mirrors.pair.com/java −repository/wsdl4j/jars/), 2002.

[7] Apache. Apache geronimo. The Apache Software Foundation (http ://geronimo.apache.org/), 2006.

[8] F. Apache. The apache software foundation. WebServices : Axis (http ://ws.apache.org/axis/java/architecture− guide.html/ArchitecturalOverview),25/12/2008.

[9] P. Barril, D. Prun, M.P. Gervais, Ph. Darche, E. Commelin, and P. Estraillier. Ap-plications coopératives, dernière modi�cations : 1er octobre 1997. http : //www −src.lip6.fr/projets/racine/cooperatif.html, 15/07/2008.

[10] D. K. Barry. Service oriented architecture. http ://www.service − architecture.com/web − services/articles/service −orientedarchitecturesoadefinition.html.

184 BIBLIOGRAPHIE

[11] B. Benatallah, M. Dumas, Q.Z. Sheng, and A. Ngu. Declarative composition andpeer-to-peer provisioning of dynamic Web services. In Proc. of ICDE'02, IEEEComputer Society, pages 297�308, San Jose, 2002.

[12] A. Biba, F. Grabherr, E. Larronde-Larretche, and Y. Richard. Mo-délisation avec uml. ISTA DESS QUASSI http : //www.univ −angers.fr/docs/etudquassi/Uml.pdf , 2000.

[13] M. Blow, Y. Goland, M. Kloppmann, F. Leymann, G. Pfau, D. Roller, and M. Row-ley. Bpel for java. A Joint White Paper by BEA and IBM, 2004.

[14] G. Booch, J. Rumbaugh, and I. Jacobson, editors. Le guide de l'utilisateur UML.Eyrolles, 2003.

[15] D. Booth, H. Haas, F. McCabe, Eric Newcomer, Michael Champion, Chris Ferris,and David Orchard. Web services architecture w3c working group note 11. 2004.

[16] S. Brache and K. Østerbye. Business process modeling : De�ning domain speci�cmodeling languages by use of uml pro�les. A. Rensink and J. Warner (Eds.) :ECMDA-FA 2006, LNCS 4066, pp. 241-255, 2006, Springer-Verlag Berlin Heidel-berg 2006.

[17] T. Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau.Extensible markup language (xml) 1.0 (fourth edition). W3C Recommendation 16August 2006, edited in place 29 September 2006, 24(6) :429�456, 2006.

[18] M. Emilia Cambronero, J. José Pardo, Gregorio Díaz, and Valentín Valero. Usingrt-uml for modelling web services, sac '07 : Proceedings of the 2007 acm symposiumon applied computing. http : //doi.acm.org/10.1145/1244002.1244150, pages 643�648, 2007.

[19] J. Cao, M. Li, S.S. Zhang, and Q. Deng. Composing web services based on agentand work�ow. In Proc. of the 2nd International Workshop on Grid and CooperativeComputing (GCC), 3032 :948�955, 2004.

[20] CEN/ISSS and W/S eBES. Technologie ebxml. (http ://www.ebxml.eu.org/French/TechnologieebXML.htm), 1999-2009.

[21] M. Champion, E. Newcomer, and D. Orchard. Web service architecture. W3c draft,W3C Working Group, 2000.

[22] E. Clayberg and D. Rubel, editors. Eclipse Plug-ins, third Edition. SERIES EDI-TORS, 2009.

BIBLIOGRAPHIE 185

[23] UDDISpec TechnicalCommittee. Universal description, discovery and integration(uddi). www.uddi.org/, Draft version 3.0.2, 2004.

[24] OW2 Consortium. Jonas : Java (tm) open application server. http ://jonas.objectweb.org/, 2000.

[25] J. Daniel, editor. Services Web : Concepts,techniques et outils. Vuibert, 2003.

[26] P. Déchamboux. Intergiciel et construction d'applications réparties. Li-cence Creative Commons (http : //creativecommons.org/licenses/by − nc −nd/2.0/fr/deed.fr), 2006.

[27] B. P. Douglass. Ropes : Rapid object-oriented process for embedded systems. DoingHard Time : Developing Real-Time Systems using UML, Objects, Frameworks, andPatterns Reading, MA : Addison-Wesley, 1999.

[28] M. Dumas and M.-C. Fauvet. Intergiciel et construction d'applications réparties.Licence Creative Commons (http : //creativecommons.org/licenses/by − nc −nd/2.0/fr/deed.fr), 2006.

[29] S. Dustdar and W. Schreiner. A survey on web services composite. InternationalJournal of Web and Grid Services, page 1, 2005.

[30] Ernst and Young. Rapport annuel 2000 de cap gemini : Consul-ting, technology, outsourcing. http : //www.capgemini.com/annual −report/2000/fr/LettrePresident.shtml, 2000.

[31] C. Jaelson F.B. et al. Modeling organizational architectural styles in uml. J. Ederand M. Missiko� (Eds.) CAiSE, pages 111�126, 2003.

[32] C. LuisFelipeandal.. Web services coordination (ws-coordination).http : //download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws −tx/WS − Coordination.pdf , Version 1.0, August 2005.

[33] A. Ferrara. Web services : a process algebra approach. in m. aiello, m. aoyama,f. curbera, and m.p. papazoglou, editors. Proceedings of 2nd ACMInternationalConference on Service Oriented Computing, pages 242�251, November 2004.

[34] Y. Fu, Zh. Dong, and Xu. He. Formalizing and validating uml architecture descrip-tion of web systems. ICWE'06 Workshops, July 10-14, 2006, Palo Alto, California,USA, 2006.

[35] F. Casati G. Alonso, H. Kuno, and V. Machiraju. Web services. concepts, archi-tectures and applications. Springer Verlag, 2003.

186 BIBLIOGRAPHIE

[36] H. Garavel. Introduction au langage lotos. Revue de l'Association des AnciensElèves de l'ENSIMAG, 1990.

[37] T. Gehrke and T. Firley, editors. Generative sequence diagrams with textual annota-tions. In Proceedings of the 9th GI/ITG-Workshop Formale Beschreibungstechnikenfuverteilte Systeme (FBT'99), pages 65-72. Herbert Utz Verlag, jun 1999.

[38] H. Gomaa. Designing real-time applications with the comet/uml method. Depart-ment of Information and Software Engineering, 2002.

[39] JBoss Group. Jboss application server. http : //www.jboss.com/products/jbossas,2003.

[40] OMG. Group. Object management group : Common object request broker archi-tecture (corba) speci�cation, version 3.1. OMG Document Number : formal/2008-01-04, January 2008.

[41] ORACLE GROUP. Oracle bpel process manager. http : //www.espace −pme.fr/lang/fr/IMG/pdf/OracleBPELP rocessManager.pdf .

[42] W3C WorkingGroup. Web services architecture. http : //www.w3.org/TR/ws−arch/, Note 11, 2004.

[43] WAP. Group. Wap wae speci�cation. Wireless Application Protocol, Wireless Appli-cation Environment Speci�cation, version 1.1, 24/May/1999, Wireless ApplicationForum Ltd.

[44] M. Ben Hmida and S. Haddad. Vers l'adaptabilité dynamique des architecturesorientés services. Proceedings 3ème Journée Francophone sur le Développement deLogiciels Par Aspects (JFDLPA) 2007, pages 73�88, 2007.

[45] Mohamed Mehdi Ben Hmida. Vers l'adaptabilité dynamique des architectures orien-tées services. PhD thesis, Université Paris-Dauphine, 2007.

[46] R. Hudson. Create an eclipse-based application using the graphical editingframework. http : //www.ibm.com/developerworks/opensource/library/os −gef/#author, IBM 29 Jul 2003, Updated 27 Jun 2006.

[47] IBM. Bpws4j a platform for creating and executing bpel4ws processes. Alphaworks(http : //www.alphaworks.ibm.com/tech/bpws4j/download), 2002.

[48] IBM. Eclipse platform. web site available at. http : //www.eclipse.org/, 2009.

BIBLIOGRAPHIE 187

[49] IBM. Ibm websphere workbench. web site available at. http : //www −306.ibm.com/software/websphere, 2009.

[50] IBM, BEA Systems, Microsoft, Arjuna, Hitachi, andIONA. Web services transactions speci�cations. http ://www.ibm.com/developerworks/library/specification/ws − tx/, August2005.

[51] J-M.Chauvet, editor. Services Web avec SOAP, WSDL, UDDI, ebXML... Eyrolles,Paris, 2002.

[52] C. Park J. Moon, D. Lee and H. Cho. ebxml, bp modeling toolkit. in proc. ofthe 7th international conference on entreprise distributed ogject computing (edoc).IEEE Computer Society, page 296., 2003.

[53] S. Jaber. L'architecture .net comparée à j2ee. http ://www.dotnetguru.org/articles/architecturedotnet.htm, 11/09/2009.

[54] I. Jacobson, G. Booch, and J. Rumbaugh, editors. The Uni�ed Software Develop-ment Process. Addison Wesley Longman, 1999.

[55] I. Jacobson and M. Christensen, editors. Object-Oriented Software Engineering : AUse Case Driven Approach. Addison-Wesley Educational Publishers Inc, 1992.

[56] J.Guiochet. Maîtrise de la sécurité des systèmes de la robotique de service - approcheUML basée sur une analyse du risque système. PhD thesis, Institut National desSciences Appliquées de Toulouse, 2003.

[57] M. B. Juric, B. Mathew, and P. Sarang, editors. Business Process Execution Lan-guage for Web Services. Packt Publishing, October 31, 2004.

[58] H. Kadima and V. Monfort, editors. Les web services - Techniques, démarches etoutils XML, WSDL, SOAP, UDDI, Rosetta, UML. 01 Informatique Dunod, Paris2003.

[59] N. Kettani, D. Mignet, P. Pare, and C. Rosenthal-Sabroux, editors. De MERISE àUML. Eyrolles, 2001.

[60] K. Lano and J. L. Fiadeiro. Extending uml with coordination contracts. Softwareand Systems Modeling, pages : 110�120, (2006)5 (2).

[61] C. Larman, editor. UML et les Design Patterns. CampusPress, 2002.

188 BIBLIOGRAPHIE

[62] L. Laurent. Conception et mise en ÷uvre d'un environnement de programmationparallèle fondé sur un système de mémoire distribuée virtuellement partagée. Tech-nical report, Ecole Normale Supérieure de Lyon, 1997.

[63] F. Leymann. Web services �ow language (ws� 1.0). http ://xml.coverpages.org/WSFL−Guide− 200110.pdf , May 2001.

[64] C. Ferreira M. Butler and M.Y. Ng. Precise modeling of compensating businesstransactions and its application to bpel. Journal of Universal Computer Science11(5), pages 712�743, May 2005.

[65] G. Claude M. Rouaced. A run-time discovery process for web services compositions.ICEC, 2008.

[66] W. Fdhila M. Rouaced, G. Claude. Communications semantics for wsbpel process.ICWS, 2008.

[67] K. Mantell. From uml to bpel. Model Driven Architecture in a web services world,Sep 2005.

[68] Microsoft. Component development. http : //msdn.microsoft.com/en −us/library/bb892725.aspx, January 2009.

[69] Sun MicroSystems. J2ee application validation kit. http ://java.sun.com/j2ee/avk/, 2005.

[70] Sun MicroSystems. Java 2 enterprise edition - j2ee. http ://java.sun.com/products/j2ee, 2005.

[71] C. Morley, J. Hugues, and B. Leblanc, editors. UML pour l'analyse d'un systèmed'information, le cahier des charges du maître d'ouvrage. Dunod, 2002.

[72] P-A Muller and N. Gaertner, editors. Modélisation objet avec UML. Eyrolles, 2000.

[73] M. Nicolas. Méta-modélisation uml pour les evironnements virtuels procéduraux etcollaboratifs. Juin 2006.

[74] S. Nicolas. Conception et mise en oeuvre d'une plate-forme pour la sûreté de fonc-tionnement des Services Web. PhD thesis, Institut National Polytechnique de Tou-louse, 2006.

[75] OMG. Omg uni�ed modeling language speci�cation version 1.5. Object ManagementGroup : Technical Report formal/03-03-01, March 2003.

BIBLIOGRAPHIE 189

[76] OMG. Uni�ed modeling language speci�cation version 2.0 : Superstructure. ObjectManagement Group : Technical Report ptc/04-10-02, October 8, 2004.

[77] OMG. Omg uni�ed modeling language speci�cation version 2.0 : Superstructure.Object Management Group : Technical Report, OMG 2003.

[78] OMG. Uni�ed modeling language speci�cation version 2.0 : Infrastructure. ObjectManagement Group : Technical Report, OMG 2003.

[79] J. L. Ortega and I. F. Aguillo. Mapping world-class universities on the web. Infor-mation Processing and Management, nov. 2008.

[80] T. Parr et al. Antlrworks. http : //www.antlr.org/, 2006.

[81] L. Denivaldo Cicero Pavado. Étude et applications de l'approche mda pour desplates-formes de services web. Technical report, Université de Nantes, Juillet 2005.

[82] L. Piechocki. Uml en français. http : //laurent −piechocki.developpez.com/uml/tutoriel/lp/, 22/10/2007.

[83] W. Provost. Uml for web servives. http ://www.xml.com/pub/a/ws/2003/08/05/uml.html, Aug 2003.

[84] T. Qiang and M.W. Gogfrey. Representing build-time software architecture viewswith uml. Software Architecture Group SWAG, 2001.

[85] M. Riveill, A. Beugnard, and D. Emsellem. Intergiciel et construc-tion d'applications réparties. Licence Creative Commons (http ://creativecommons.org/licenses/by − nc− nd/2.0/fr/deed.fr), 2006.

[86] C. Rolland and A. Flory, editors. La Conception des Systèmes d'Information :Etat de l'Art et Nouvelles Perspectives. Congrès 90 de l'association informatiquedes organisations et systèmes d'information et de décision, Editions Eyrolles, Paris,1990, p. 3-40.

[87] P. Moreaux S. Haddad and S. Rampacek. Client synthesis for web services by wayof a timed semantics. In Proceedings of the 8th Int. Conf. on Enterprise InformationSystems (ICEIS06), pages 19�26, 2006.

[88] P. Moreaux S. Haddad, T. Melliti and S. Rampacek. Modelling web services inter-operability. Proceedings of the 6th International Conference on Enterprise Infor-mation Systems, 4 :287�295, April 2004.

[89] P. Simon. Test des composants logiciels pour les télécommunications. PhD thesis,Université de Rennes 1, 2003.

[90] A. Staikopoulos and B. Bordbar. A. hartman and d. kreische (eds.) : Ecmda-fa2005, lncs 3748, pp. 145-159, 2005. Springer-Verlag Berlin Heidelberg 2006.

[91] C. Stefano, F. Piero, and B. Aldo. Web modeling language (webml) : a modelinglanguage for designing web sites. Comput. Netw., 33(1-6) :137�157, 2000.

[92] R. Sylvain. Sémantique, interactions et langages de description des services webcomplexes. Technical report, Université de Reims Champagne-Ardenne, 2006.

[93] M. Tarak. Interopérabilité des services Web complexes. Application aux systèmesmulti-agents. PhD thesis, Université PARIS IX Dauphine, 2004.

[94] Z. Tew�k. Manipulation des Lignes de Produits en UML. PhD thesis, IFSIC,Université de Rennes 1, 2004.

[95] S. Thatte. Xlang -web services for business process design. http ://www.gotdotnet.com/team/xmlwsspecs/xlang − c/default.htm, 2001.

[96] A. Tony et al. Business process execution language for web services, Version 1.1,bea systems, international business machines corporation, microsoft corporation,sap ag, siebel systems. all rights reserved. BPEL4WS Speci�cation, 2002 and 2003.

[97] W. van der Aalst and K. van Hee, editors. Work�ow Management, Models, Methods,and Systems. The MIT Press, London, 2002.

[98] W3C. Coordination group xmlschema, http : //www.w3c.org/xml/schema. W3CSpeci�cations, 2000.

[99] Wikipédia. Apache axis. L'Encyclopédie Libre (http ://fr.wikipedia.org/wiki/ApacheAxis), 25/12/2008.

[100] B. Xavier. Introduction au processus mda. (http ://www.journaldunet.com/developpeur/tutoriel/cpt/040706 − intro −conception−mda.shtml), JDN Développeurs, 2004.

ANNEXES

Annexe A : Résolution d'uneéquation du second degré à uneinconnue

Le service à mettre en place, permettra de résoudre une équation du second degré à uneinconnue de type :

ax2 + bx + c = 0

Pour assurer les calculs de delta (4 = b2−4ac), nous utiliserons le service web Calculatorà l'adresse http://localhost:8080/axis/services/Calculator?wsdl

Le service Calculator assure les opérations comme :� carre : pour calculer le carré d'un nombre décimal,� add : pour faire la somme de deux nombres décimaux,� mult : pour faire le produit de deux nombres,� sub : pour faire la di�érence de deux nombres.

Pour notre service, nous allons créer l'opération input/output saisirEquation, poursaisir les coe�cients de l'équation et obtenir les résultats. Les messages utilisés sont :

1. Coefficient : représente les coe�cients (a, b, c) de l'équation,

2. Couple : représente un couple de nombres pour le calcul du produit a fois c,

3. Delta : représente le discriminant de l'équation,

4. Resultat : représente le résultat des calculs. Cette, donnée représente un message,et les valeurs des solutions.

Pour réaliser le service nous devons importer certaines API Java telles que Java.lang.Math.L'instruction en JCWSL est :import java.lang.Math;

L'importation du service basique Calculator est :importBWS cal= "http://localhost:8080/axis/services/Calculator?wsdl";

194 Annexe A : Résolution d'une équation du second degré à une inconnue

La dé�nition du service Equation est réalisée par l'instruction :public CWSDefinition Equation{//les instructions}La déclaration des messages locaux ci-dessus énumérés :public DefMessage Coefficient{double a; double b; double c;}public DefMessage Couple{double x1; double x2;}public DefMessage Delta{double x;}public DefMessage Solution{double x1; double x2;String mess;}

L'opération saisirEquation(), est dé�nie par :public DefOperation saisirEquation(Input/Output: Coefficient

mesCoefs, Solution laSolution){JavaCode{ }}

Cette opération prend en entrée une donnée de type Coefficient (mesCoefs) et retourneune donnée de type Solution (laSolution).Le comportement du service est dé�ni par void main.void main {

//les instructions du comportement}

Pour la manipulation des données, nous avons dé�ni des variables permettant les échangesde messages entre le service web complexe et le service Calculator :Variables{

Variable(nosCoefs,Coefficient);Variable(coefB,Delta);Variable(afoisc,Delta);Variable(bCarre,Delta);Variable(resultat,Solution);Variable(delta,Delta);Variable(ac,Couple);

}

Le comportement proprement dit commence par un constructeur Sequence. Dans le pré-sent exemple nous avons :Sequence {......

195

}

La première instruction d'orchestration est la réception d'un message par le service, icice message est nosCoefs de type Coefficient permettant la saisie des coe�cients del'équation.Receive(saisirEquation, nosCoefs);

Nous avons ensuite un bloc d'a�ectation des valeurs reçues dans un bloc JavaCode.JavaCode{

coefB.setX(nosCoefs.getB());ac.setX1(nosCoefs.getA());ac.setX2(nosCoefs.getC());

}

Nous invoquons par la suite les opérations carre et mult du service Calculator qui estreprésenté ici par la variable cal. Puisque ces deux opérations peuvent être invoquées defaçon simultanée, nous les regroupons dans un constructeur Flow.Flow{

Invoke(cal.carre,coefB,bCarre);Invoke(cal.mult,ac,afoisc);

}

Après les calculs e�ectués à la suite des invocations, nous calculons la valeur de la variabledelta et celle de la variable resultat dans un bloc JavaCode.JavaCode{

if (ac.getX1()==0) {resultat.setMess("cette équation est du premier degré");resultat.setX1(-ac.getX2()/coefB.getX());resultat.setX2(0.0);}

else {delta.setX(bCarre.getX()-4*afoisc.getX());if (delta.getX()<0.0) {

resultat.setX1(0.0);resultat.setX2(0.0);resultat.setMess("Pas de solutions !");

}if (delta.getX()==0.0) {

resultat.setX1(-coefB.getX()/(2*nosCoefs.getA()));resultat.setX2(0.0);


resultat.setMess("Solution double !");}if (delta.getX()>0.0){

resultat.setX1(-(coefB.getX()+ Math.sqrt(delta.getX()))/(2*nosCoefs.getA()));

resultat.setX2(-(coefB.getX()- Math.sqrt(delta.getX()))/(2*nosCoefs.getA()));

resultat.setMess("Solutions distinctes !" );}

}}

Le service renvoie du résultat �nal de la résolution de l'équation ax2 + bx + c = 0. Ceciest représenté par le constructeur Reply.Reply(saisirEquation,resultat);

Le code JCWSL du service Equation est illustré sur le listing suivant :1 import java.lang.Math;2 importBWS cal="http :// localhost :8080/ axis/services/Calculator?wsdl";34 public CWSDefinition Equation{5 public DefMessage Coefficient{double a; double b; double c;}6 public DefMessage Couple{double x1; double x2;}7 public DefMessage Delta{double x;}8 public DefMessage Solution{double x1; double x2;String mess;}910 public DefOperation saisirEquation(Input/Output: Coefficient11 mesCoefs , Solution laSolution ){ JavaCode{ }12 }13 void main {14 Variables{15 Variable(nosCoefs ,Coefficient );16 Variable(coefB ,Delta );17 Variable(afoisc ,Delta );18 Variable(bCarre ,Delta );19 Variable(resultat ,Solution );20 Variable(delta ,Delta );21 Variable(ac ,Couple );22 }23 Sequence {24 Receive(saisirEquation , nosCoefs );25 JavaCode{26 coefB.setX(nosCoefs.getB ());27 ac.setX1(nosCoefs.getA ());28 ac.setX2(nosCoefs.getC ());29 }30 Flow{31 Invoke(cal.carre ,coefB ,bCarre );

197

32 Invoke(cal.mult ,ac ,afoisc );33 }34 JMethod void exemple(double xxx1 , duble xxx2) {35 JavaCode{36 if (ac.getX1 ()==0) {37 resultat.setMess("cette équation est du permier degré");38 resultat.setX1(-ac.getX2 ()/ coefB.getX ());39 resultat.setX2 (0.0);}40 else {41 delta.setX(bCarre.getX ()-4* afoisc.getX ());42 if (delta.getX () <0.0) {43 resultat.setX1 (0.0); resultat.setX2 (0.0);44 resultat.setMess("Pas de solutions !");45 }46 if (delta.getX ()==0.0) {47 resultat.setX1(-coefB.getX ()/(2* nosCoefs.getA ()));48 resultat.setX2 (0.0);49 resultat.setMess("Solution double !");50 }51 if (delta.getX () >0.0){52 resultat.setX1(-(coefB.getX ()+ Math.sqrt(deltat.getX ()))53 /(2* nosCoefs.getA ()));54 resultat.setX2(-(coefB.getX()-Math.sqrt(deltat.getX ()))55 /(2* nosCoefs.getA ()));56 resultat.setMess("Solutions distinctes !");57 }}58 }}59 Reply(saisirEquation , resultat );60 }61 }62 }


Annexe B : Service web de jeu

Nous présentons, dans cette section, le développement dans JCWSL d'un CWS (Complexweb Service) mettant en application un jeu avancé d'un jeu basé sur un BWS (Basic WebService) existant. Le BWS, situé à http://localhost:8080/axis/services/jeux?wsdl ,met en application un jeu simple comprenant l'invocation d'un ensemble de questionsde di�érents niveaux de di�culté, et la véri�cation d'exactitude de réponse. Cet exempleprésente un nouveau jeu où le but est de répondre sur un nombre �xe de questions dans untemps �xe. Le niveau de di�culté de chaque question peut être choisi de façon aléatoireou indiqué par le joueur. Notre service complexe sera appelé JeuxQuiz.Le service basique o�re trois possibilités à l'aide de trois opérations qui sont :

1. randomQuestion : cette opération permet au service basique de fournir une questionavec un niveau de di�culté aléatoire,

2. randomQuestionByDifficultyLevel : cette opération permet au service basique defournir une question avec un niveau de di�culté dé�ni par le joueur,

3. checkResponse : cette opération permet au service basique de véri�er la réponse àune question.

Ce service basique permet uniquement de jouer avec une seule question à la fois et laréponse n'est pas automatiquement liée à l'a�chage de la question.Le nouveau service que nous allons mettre en place, permettra de jouer avec plusieursquestions dont le nombre sera dé�ni par le joueur lui même, de choisir le niveau dedi�culté ou de laisser le service prendre de manière aléatoire les questions, de faire lasomme des points obtenus par le joueur qui est la somme des di�cultés des questionschoisies.Pour réaliser cet objectif, nous importerons le service existant de base en utilisant l'ins-truction :importBWS Squiz= "http://localhost:8080/axis/services/jeux?wsdl"Notre nouveau service a besoin de huit messages qui sont :

200 Annexe B : Service web de jeu

� Question : pour représenter une question à choix multiple choisie,� Answer : pour représenter la réponse à une question (réponse choisie dans les ré-

ponses proposées),� Level : pour représenter un niveau de di�culté,� Score : pour représenter le score �nal du joueur,� NbQuestions : pour représenter le nombre de questions à passer,� ChoiceMode : pour représenter le mode de jeu, question à niveau aléatoire ou à

niveau dé�ni,� Response : pour permettre la véri�cation des réponses choisies par le joueur,� CheckedResponse : pour savoir si la réponse choisie par le joueur est vrai (ou faux).

Nous utiliserons aussi des opérations pour notre service complexe au nombre de sept :

� beginGame(Input/Output: NbQuestions nbquestion) : une opération de type In-put/Output, permettant la saisie du nombre de questions à jouer, et d'informer lejoueur qu'il a la possibilité de choisir entre deux modes en a�chant le messagesuivant : Choose a Mode (random mode - level=0 or speci�ed mode - level>0) :.

� randomLevel(Input: Level random) : cette opération de type Input permet d'in-diquer au service qu'on a choisi le mode aléatoire,

� clientLevel(Input: Level specified) : cette opération de type Input permetd'indiquer au service qu'on a choisi le mode dé�ni par le joueur,

� displayQuestion(Output: Question myquestion) : cette opération de type Out-put permet le renvoi de la question invoquée au joueur,

� checkAnswer(Input: Answer answer) : cette opération permet au joueur d'en-voyer sa réponse au service,

� finalScore(Output: Score score) : cette opération permet au service de retour-ner le score �nal du joueur.

La ligne 1 correspond à l'importation du service basique. La ligne 3 correspond à la dé�-nition du service web complexe nommé JeuxQuiz. De la ligne 4 à la ligne 11, nous avonsles messages locaux nécessaires à notre service complexe. Les lignes 13 à 19 représententles opérations du service.De la ligne 21 à la �n du code, nous avons le comportement du service. Le présentservice contient des variables déclarées de la ligne 22 à la ligne 30. Sur la ligne 32, nousavons l'instruction Sequence principale qui dé�nit le corps du comportement. Les lignes33-38 illustrent un code Java initialisant certaines variables à zéro. Les lignes 39 et 40permettent au service de recevoir le nombre de questions du joueur et de lui retourner unmessage sur les modes de jeu.

201

De la ligne 41 à la ligne 79, nous avons une boucle While permettant au service derenvoyer des questions au joueur, tant que le nombre de questions traitées est inférieurau nombre dé�ni par le joueur.Dans la boucle While, nous avons les instructions JCWSL du comportement du servicecomplexe. Ainsi, de la ligne 43 à la ligne 49, nous avons une instruction Pick permettantd'exécuter l'invocation de l'une des deux opérations du service basique pour obtenir unequestion. Sur la ligne 50, l'instruction Reply, renvoie au joueur, la question que le servicea invoqué.Les lignes 51-70, contiennent les instructions d'un deuxième Pick permettant au joueurd'envoyer sa réponse au service, une instruction JavaCode d'a�ectation de valeurs, uneinstruction Invoke, pour véri�er si la réponse choix par le joueur est la bonne ou pas.Entre les lignes 61 et 66, une instruction JavaCode permet de mettre à jour la valeur duscore du joueur si sa réponse est correcte. Le deuxième Pick comporte un volet OnAlarmqui permet au service d'accorder cinq minutes au joueur pour répondre à la questionobtenue.La boucle While se termine par un bloc Java qui incrémente la variable d'itération de laboucle et la réinitialisation des autres variables.Le service se termine par une instruction Reply qui renvoie au joueur son score �nal (ligne80).

Le code JCWSL complet du service JeuxQuiz est illustré sur le listing suivant :1 importBWS squiz="http :// localhost :8080/ axis/services/jeux?wsdl";2 // ------------------------------------------------------------------------3 public CWSDefinition jeuxQuiz{4 public DefMessage Answer{String choice ;}5 public DefMessage Level{int value;}6 public DefMessage Score{int value;}7 public DefMessage NbQuestions {int value ;}8 public DefMessage ChoiceMode{String message ;}9 public DefMessage Response{int id; String choice ;}10 // ------------------------------------------------------------------------11 public DefOperation beginGame(Input/Output: NbQuestions nbq ,12 ChoiceMode mych ){}13 public DefOperation randomLevel(Input: Level randLevel ){}14 public DefOperation clientLevel(Input: Level clLevel ){}15 public DefOperation displayQuestion(Output: squiz.RandomQuestion myq){}16 public DefOperation checkAnswer(Input: Answer clAnswer ){}17 public DefOperation finalScore(Output: Score clScore) {}18 // ------------------------------------------------------------------------19 void main {20 Variables{21 Variable(vLevel , Level );22 Variable(clientAnswer , Answer );23 Variable(currentAnswer , Response );24 Variable(vMode , ChoiceMode );25 Variable(vNbQuestions , NbQuestions );


26 Variable(vScore ,Score );27 }28 Sequence{29 JavaCode{30 squiz.RandomQuestion currentQuestion=new squiz.RandomQuestion ();31 boolean result=false;32 int nbQuestion =0;33 vScore.setValue (0);34 vMode.setMessage("Choose a Mode (random mode -35 level=0 or specified mode - level >0): ");36 }37 Receive(beginGame ,vNbQuestions );38 Reply(beginGame , vMode);39 While{JavaCode{nbQuestion <vNbQuestions.getValue ()},40 Sequence{41 Pick{42 OnMessage(randomLevel , vLevel) {43 Invoke(squiz.randomQuestion , ,currentQuestion );}44 OnMessage(clientLevel , vLevel) {45 Invoke(squiz.randomQuestionByDifficultyLevel ,46 vLevel ,currentQuestion );}47 } // pick48 Reply(displayQuestion ,currentQuestion );49 Pick{50 OnMessage(checkAnswer ,clientAnswer ){51 JavaCode{52 currentAnswer.setId(53 currentQuestion.getNumQuestion ());54 currentAnswer.setChoice(55 clientAnswer.getChoice ());56 }57 Invoke(squiz.checkResponse ,58 currentAnswer ,result );59 JavaCode{60 if(result ==true) {61 vScore.setValue(vScore.getValue ()+62 currentQuestion.getPoidsQuestion ());63 }64 }65 }66 OnAlarm(For =5){67 JavaCode{68 vMode.setsetMessage("Délai d'attente dépassé !69 Passez à la question suivante !");70 }71 Reply(beginGame , vMode );72 }73 }74 JavaCode{75 nbQuestion ++;76 currentQuestion=null;77 currentAnswer=null;78 result=false;79 clientAnswer=null;80 }81 } // end of sequence for while

203

82 } // end of while83 Reply(finalScore , vScore );84 } // end sequence for main85 } // end of main }// end of CWSDefinition86 // ------------------------------------------------------------------------


Annexe C : Service web dereservation de place avec unecompagnie aérienne

Le présent exemple, sert à choisir un vol dans une compagnie aérienne parmi plusieurspossibilités. Le service JCWSL que nous allons concevoir ici est basé sur trois servicesbasiques. Il est conçu à partir d'un exemple dans [57] légèrement modi�é. Cet exemplepréconise l'utilisation par une entreprise de son propre service web qui gère ses employéset de deux services de compagnies aériennes. Il consiste à sélectionner les informations devoyage d'un employé et de choisir une compagnie pour acquérir un billet d'avion. Commedéjà indiqué, nous utiliserons trois services basiques :

� le service EmployeeWS : Il gère les voyages des employés d'une société. Il se trouveà l'adresse : http://localhost:8080/axis/services/employews?wsdl

� le service afWS : Il gère la compagnie d'aviation AF. Il se trouve à l'adresse :http://localhost:8080/axis/services/afws?wsdl

� le service ramWS : Il gère la compagnie d'aviation RAM. Il se trouve à l'adresse :http://localhost:8080/axis/services/ramws?wsdl

Notre service sera nommé TravelWS. Il invoquera les opérations :

� employeeTravelStatus : une opération permettant de connaître la classe (a�aire,économique ou première) de voyage ainsi que les dates de départ et de retour d'unemployé.

� rechercheParDateDest : une opération des services de compagnies d'avion, per-mettant de choisir un vol sur une compagnie.

Dans notre service, nous avons créé des messages locaux (lignes 9-14), des opérationslocales (lignes 16-19). Le comportement de notre service (ligne 21 à la �n) contient desinstructions de déclaration de variables (lignes 22-29), l'instruction d'envoi des coordon-nées de voyage d'un employé (ligne 31). Les invocations des services basiques se font lors

206Annexe C : Service web de reservation de place avec une compagnie

aérienne

des lignes 32,45 et 46. Observez que les invocations des lignes 45 et 46 sont e�ectuées demanière concurrente à l'aide l'instruction Flow. Dans le code nous avons aussi deux blocsJavaCode permettant respectivement, l'a�ection des valeurs des renseignements obtenusaprès l'invocation du service EmployeeWS tels que : date de départ, destination et classede voyage d'un employé choisi précédemment (lignes 33-43) et le choix de la compagnieaprès avoir comparé les prix du billet sur les deux services (lignes 48-56). Le code setermine par le renvoi des informations retenues à l'issue de la comparaison (Reply sur laligne 58). Nous avons aussi importé des API Java pour le bon fonctionnement du code(lignes 1-2) ainsi que les services basiques nécessaires (lignes 4-6).Le code JCWSL du présent service est illustré sur le listing suivant :1 import Java.text .*;2 import Java.util .*;3 importBWS emp="http :// localhost :8080/ axis/services/employews?wsdl";4 importBWS af="http :// localhost :8080/ axis/services/afws?wsdl";5 importBWS ram="http :// localhost :8080/ axis/services/ramws?wsdl";67 public CWSDefinition TravelWS {8 public DefMessage EmployeeTravelRequest{String id; int annee;}9 public DefMessage EmployeeInfo{emp.TravelStatus tstatus ;}10 public DefMessage TravelInvokeInfo{String date; String dest;11 String classe ;}12 public DefMessage AfTravelInfoRequest{af.TravelInfo trInfo ;}13 public DefMessage RamTravelInfoRequest{ram.TravelInfo trInfo ;}1415 public DefOperation checkEmployeeTravelStatus(Input:16 EmployeeTravelRequest Etr ){}17 public DefOperation returnEmployeeTravelStatus(Output:18 AfTravelInfoRequest result ){}1920 void main{21 Variables{22 Variable(vTravel , EmployeeTravelRequest );23 Variable(vEmployeeStatus , EmployeeInfo );24 Variable(vTravelInvoke , TravelInvokeInfo );25 Variable(vTInfoAf , AfTravelInfoRequest );26 Variable(vTInfoRam , RamTravelInfoRequest );27 Variable(choosenInfo , AfTravelInfoRequest );28 }29 Sequence{30 Receive(checkEmployeeTravelStatus , vTravel );31 Invoke(emp.employeeTravelStatus , vTravel , vEmployeeStatus );32 JAVACODE{33 vTravelInvoke.setClasse(34 vEmployeeStatus.getTstatus (). getClasseVoyEmp ());35 Date uneDate=vEmployeeStatus.getTstatus (). getDateDebut ();36 SimpleDateFormat formater=37 new SimpleDateFormat("dd/MM/yyyy");38 String stDate=formater.format(uneDate );39 vTravelInvoke.setDate(stDate );40 vTravelInvoke.setDest(41 vEmployeeStatus.getTstatus (). getDest ());

207

42 }43 Flow{44 Invoke(af.rechercheParDateDest , vTravelInvoke , vTInfoAf );45 Invoke(ram.rechercheParDateDest , vTravelInvoke , vTInfoRam );46 }47 JAVACODE{48 if(vTInfoAf.getTrInfo (). getPrix ()<=49 vTInfoRam.getTrInfo (). getPrix ()){50 choosenInfo.setTrInfo(vTInfoAf.getTrInfo ());51 }52 else {53 choosenInfo.setTrInfo(vTInfoRam.getTrInfo ());54 }55 }56 Reply(returnEmployeeTravelStatus ,choosenInfo );57 } // end of Sequence58 } // end of main59 } // end of CWSDefinition

208Annexe C : Service web de reservation de place avec une compagnie

aérienne

Annexe D : Exemple de service websous CWSE

Le présent exemple permet l'illustration graphique du service web complexe du JeuxQuizdont l'énoncé est à l'annexe C, Exemple n°2 : service web de jeu. Nous utilisons ici, l'en-vironnement CWSE dans la mise en place du dit service. L'utilisation de l'environnementnous fournit deux �chiers : le graphe et le code source généré.

Figure 7.1 � Diagramme du service JeuxQuiz

Figure 7.2 � Code généré par le diagramme du service JeuxQuiz

Vu : Vu :Le Président Les Su�rageantsM. M.

Vu et permis d'imprimer :Le Vice-Président du Conseil Scienti�que Chargé de la Recherche de l'Université Paris-Dauphine

RésuméLes propriétés d'interopérabilité et de faible couplage des services web lors de la

mise en place des systèmes d'information hétérogènes, font d'eux actuellement l'une desmeilleures solutions techniques d'implémentation des systèmes d'information. La mise enplace facile des services web devient alors une nécessité. Vu les moyens actuels de cettemise en place et les di�cultés liées, nous avons proposé une contribution avec un langagebasé sur les langages BPEL (Business Process Execution Language for Web Services) etJava.Notre langage vient en complément au langage BPEL en proposant une méthode decomposition qui présente un service web complexe comme une classe Java. Ce langageutilisera la �exibilité, l'expressivité et la facilité d'apprentissage de Java. Il s'appuie sur laréécriture des constructeurs de BPEL pour l'orchestration des services web. Notre langageutilise son propre environnement graphique pour la composition et propose une métho-dologie UML (Uni�ed Modeling Language) de conception des services web complexes.Cette méthodologie UML a été mise en place en utilisant la notion de Model DrivenArchitecture. Quant à l'environnement graphique, il a été conçu à l'aide de l'outil GEF(Graphical Editing Framework) d'Eclipse.Dans ce mémoire de thèse, notre langage appelé JCWSL (Java Complex Web Service Lan-guage) a été présenté avec des exemples d'application à l'appui. De même, nous avonsprésenté l'environnement graphique de composition de notre langage et ainsi que sa mé-thodologie UML de conception conceptuelle des services web complexes.

Mots-clés : services web, Langage des services web, BPEL, Java, JCWSL, GEF, UML

AbstractThe web services properties of interoperability and loose coupling during the implemen-tation of heterogeneous information systems, now make them one of the best technicalsolutions for information systems implementation. The easy implementation of web ser-vices becomes a necessity. Given the current capacity of this development and the asso-ciated di�culties, we proposed a contribution with a language based on BPEL (BusinessProcess Execution Language for Web Services) and Java.Our language is a complement to BPEL by proposing a method of composition that hasa complex web service as a Java class. This language uses the �exibility, expressivenessand ease of learning of Java. It is based on rewriting BPEL constructors for web servicesorchestration. Our language uses its own graphical environment for composition andproposes its own UML (Uni�ed Modeling Language) methodology to design complex webservices. Our UML methodology was implemented using the concept of Model DrivenArchitecture. As for the graphical environment, it has been designed using the Eclipsetool GEF (Graphical Editing Framework).In this dissertation, our language called JCWSL was presented with examples of applica-tion. Similarly, we presented a graphical environment for the composition of our languageand its UML methodology for complex web services conceptual design.

Keywords : web services, web services Language, BPEL, Java, JCWSL, GEF, UML

Documents

Thèse UNLANGAGEETUNENVIRONNEMENT