mi
THESE
pour l‟obtention du Diplôme de
DOCTORAT EN SCIENCES APPLIQUEES
Spécialité : Informatique
Présentée par
Adil KENZI
Sujet de thèse :
Ingénierie des Systèmes Orientés Services
Adaptables : Une Approche Dirigée par les Modèles
Soutenue le 16/10/2010 à 10H00 devant le jury composé de :
Président :
M. Abdelhak MOURADI Professeur à l‟ENSIAS de Rabat, Maroc
Rapporteurs :
M. Djamal BENSLIMANE Professeur à l‟Université Claude Bernard Lyon 1, France M. Bouchaib BOUNABAT Professeur à l‟ENSIAS de Rabat, Maroc
M. Bernard COULETTE Professeur à l‟Université de Toulouse II-Le Mirail, France
Examinateur :
M.Mahmoud NASSAR Professeur Habilité à l‟ENSIAS de Rabat, Maroc Directeur de thèse :
M.Abdelaziz KRIOUILE Professeur à l‟ENSIAS de Rabat, Maroc Université Mohamed V- Souissi Rabat
Ecole Nationale Supérieure d’Informatique et d’Analyse des Systèmes
-ENSIAS-
UFR : Systèmes d’Information Métiers, Multimédia et Mobiles (SI3M)
-ENSIAS-
Numéro d’ordre : ----
Remerciements
Les travaux présentés dans le cadre de ce mémoire de thèse ont été réalisés au laboratoire Systèmes d‟Information multimédia et mobile (SI2M) à l‟Ecole Nationale Supérieure d‟Informatique et d‟Analyse des Systèmes (ENSIAS) de Rabat.
Tout d‟abord, je tiens à remercier vivement mon directeur de thèse Monsieur Abdelaziz KRIOUILE, Professeur à l‟ENSIAS, pour sa sympathie, son écoute, son soutien, sa disponibilité et sa patience. Je le remercie également pour ses relectures minutieuses de ce mémoire.
Je remercie également Madame Bouchra El Asri, Professeur Assistant à l‟ENSIAS pour m‟avoir co-encadré durant cette thése. Je la remercie aussi pour ses conseils précieux, sa disponibilité, son soutien ainsi que pour les nombreuses discussions que nous avons eues sur le thème de cette thèse.
Je tiens aussi à remercier Monsieur Abdelhak MOURADI de m‟avoir fait l‟honneur de présider le jury de ma thèse.
J‟adresse également mes vifs remerciements à Monsieur Djamal BENSLIMANE, Professeur à l‟université Claude Bernard Lyon1, Monsieur Bernard COULETTE, Professeur à l‟université de Toulouse II et Monsieur Bouchaib BOUNABAT, Professeur à l‟ENSIAS, d‟avoir accepté de rapporter ma thèse. Je les remercie également pour les remarques et conseils prodigués.
J‟exprime ma profonde gratitude à Monsieur Mahmoud NASSAR, Professeur Habilité à l‟ENSIAS pour les nombreuses discussions techniques que nous avons eues. Je le remercie également pour ses conseils et ses remarques tout au long de ces années. Je le remercie aussi pour avoir accepté d‟être examinateur de cette thèse.
J‟adresse également mes remerciements à Monsieur Rdouan FAIZI, Professeur à l‟ENSIAS pour ses nombreuses relectures et ses corrections des différentes publications rédigées en Anglais.
Je tiens à remercier tous ceux qui m‟ont aidé et soutenu durant cette thèse, et plus particulièrement ma famille. J‟adresse mes vifs remerciements à mes frères Jilali et Najib de m‟avoir tant soutenu aussi bien matériellement que moralement. Je tiens aussi à remercier mon frère Abdelkarim de m‟avoir soutenu et encouragé et surtout de m‟avoir orienté vers des études en informatiques. Je remercie également mon frère Hatim qui est loin de la Faculté d‟Informatique de l‟Université Technique de Dortmund, de m‟avoir encouragé et soutenu et surtout de n‟avoir ménagé aucun effort pour me fournir la meilleure documentation dans le domaine.
J‟adresse également mes chaleureux remerciements à tous les amis et collègues que j‟ai côtoyés durant les années de cette thèse. Leurs conseils, leur amitié et leur bonne humeur m‟ont beaucoup encouragé durant mes travaux.
Résumé
De nos jours, les Systèmes d‟information occupent une position centrale dans la stratégie de l‟entreprise. Leur capacité de communication et d‟intégration, leur agilité ainsi que leur adaptation aux utilisateurs constituent des défis majeurs pour la compétitivité des entreprises. Pour relever ces défis, l‟ingénierie logicielle est marquée particulièrement par l‟émergence de deux nouveaux paradigmes : SOC (Service Oriented Computing) et CAC (Context-aware Computing). Le paradigme SOC a pour objectif de faire face aux problèmes de l‟interopérabilité et de l‟intégration des SI ainsi que de leur agilité. Le paradigme CAC vise à relever le défi de l‟adaptabilité des SI. L‟adoption rapide et massive de ces deux paradigmes, a fait naitre de nouveaux challenges, plus particulièrement le challenge de l‟ingénierie des systèmes orientés services adaptables.
L‟objectif de cette thèse est de proposer une approche d‟ingénierie dirigée par les modèles pour le développement des systèmes orientés services adaptables. Une telle approche définit principalement : (i) un profil UML 2.0 appelé VSoaML (View based Service Oriented Architecture Modeling Language) (ii) un processus de développement et (iii) un outil logiciel associé à VSoaML pour la génération automatique de code appelé VSoaMLTool.
Le profil VSoaML a pour objectif la modélisation et la spécification des systèmes orientés services adaptables indépendamment des standards (WSDL, BPEL4WS, etc.) et des plateformes d‟implémentation (J2EE, dotNet, etc.). Ce profil se base essentiellement sur le concept de service multivue comme une entité de modélisation fondamentale pour le développement des systèmes orientés services adaptables et sur un ensemble de stéréotypes permettant la modélisation des systèmes orientés services adaptables. La particularité du service multivues réside dans la représentation des besoins et des spécificités des utilisateurs finals tout au début du cycle de développement des systèmes orientés services.
Le processus de développement associé au profil VSoaML définit les phases, les activités et les artefacts nécessaires pour la transformation des exigences métiers en des services flexibles et adaptables. Il permet l‟identification, la spécification et l‟implémentation des services multivues à partir des besoins métier spécifiés via les diagrammes des cas d‟utilisation. L‟objectif principal d‟un tel processus est l‟élaboration des modèles à différents niveaux d‟abstraction ainsi que leur transformation pour cibler différentes plateformes d‟implémentation. Après l‟élaboration des modèles métiers en se basant sur le profil VSoaML
et sur le processus de développement y associé, l‟outil VSoaMLTool permet la génération automatique de code en se basant principalement sur deux transformations définies dans le cadre MDA ciblant différentes plateformes technologiques. Chaque transformation a été définie en deux étapes. La première étape consiste en la spécification des correspondances entre les métamodèles source et cible. La deuxième étape consiste en la définition des transformations en se basant sur le langage ATL comme langage de transformation de modèles. Les transformations définies visent essentiellement la génération de l‟implémentation et de la description de chaque service.
Mots clés : UML, VSoaML, Service multivues, Adaptabilité, MDD/MDA, SOA/Services
Introduction générale ... 1
I.
Etat de l’art ... 7
I.1. Introduction ... 7
I.2. Systèmes Orientés Services (SOS) : concepts et définitions ... 8
I.3. SOS : Approches de modélisation ... 9
I.3.1. Approches à base de « Service Component » ... 10
I.3.2. Approches à base de « Service Component Architecture » (SCA) ... 12
I.3.3. Approches à base de profils UML ... 14
I.3.4. Discussion ... 20
I.4. SOS : Concepts d‟adaptation ... 20
I.4.1. Concept d‟adaptation : les Vues ... 21
I.4.1.1 Vues à base de l‟adaptation par rôles ... 21
I.4.1.2 Vues à base de l‟adaptation contextuelle ... 23
I.4.1.3 Discussion ... 26
I.4.2. Concept d‟adaptation : la variabilité de service ... 27
I.4.2.1 Description de l‟approche ... 27
I.4.2.2 Discussion ... 30
I.4.3. Concept d‟adaptation : la différenciation de service ... 30
I.4.3.1 Description de l‟approche ... 30
I.4.3.2 Discussion ... 33
I.5. SOS : technologies d‟adaptation ... 34
I.5.1. AWSDL et CWSDL ... 34
I.5.2. CBPEL et VXBPEL ... 35
I.5.3. Discussion ... 35
I.6. SOS : Approches d‟adaptation dirigées par les modèles ... 36
I.6.1. Concepts et définitions ... 37
I.6.2. Approches MDA de développement des SOS ... 39
I.6.2.1 PIM (UML) vers services Web ... 39
I.6.2.2 PIM(EDOC) vers services web ... 45
I.6.3. Approches MDA d‟adaptation des SOS ... 53
I.6.3.1 Approches de gestion des propriétés non-fonctionnelles ... 53
I.6.3.2 Approches de gestion des droits d‟accès... 56
I.6.3.3 Approches de gestion de la qualité de services ... 59
I.6.3.4 Approches d‟adaptation au contexte ... 61
I.6.3.5 Discussion ... 62
I.7. Synthèse générale ... 63
II.
VSoaML : Un profil UML de modélisation des systèmes orientés
services adaptables ... 69
II.1. Introduction ... 69
II.2. Exemple illustratif : Le système d‟enseignement à distance ... 71
II.3. Le concept de service multivues ... 72
II.3.1. Le concept de vue ... 73
II.3.2. Le service multivues... 74
II.4. Les couches d‟abstraction d‟un SOS Adaptable ... 78
II.5. Le profil VSoaML ... 82
II.5.1. Le profil VSoaML : Vue d‟ensemble ... 82
II.5.2. VSoaML : les stéréotypes ... 88
II.5.2.1 Le stéréotype Service ... 88
II.5.2.2 Le stéréotype Message ... 90
II.5.2.3 Le stereotype MessageAttachment ... 91
II.5.2.4 Le stéréotype Specification ... 92
II.5.2.5 Le stéréotype MVService ... 94
II.5.2.6 Le stéréotype MVServiceSpecification ... 96
II.5.2.7 Le stéréotype Collaboration ... 98
II.5.2.8 Le stéréotype ServiceChannel ... 100
II.5.2.9 Le stéréotype Requester ... 101
II.5.2.10 Le stéréotype MVServiceInterface ... 102
II.5.2.11 Le stéréotype BaseServiceInterface ... 103
II.5.2.12 Le stéréotype ViewServiceInterface ... 105
II.5.2.13 Le stéréotype Provider ... 106
II.5.2.14 Le stéréotype ServiceOperation ... 107
II.5.2.15 Le stéréotype ServiceDomain ... 108
II.5.3. Exemple illustratif DLS : Couches d‟abstraction ... 109
II.6. Conclusion ... 116
III.
Processus de Développement Dirigé par les Modèles des Systèmes
Orientés Services Adaptables ... 117
III.1. Introduction ... 117
III.2. Processus de développement des systèmes orientés services : phases, activités et artefacts ... 118
III.3. Processus de développement MDA : phases, activités et artefacts ... 121
III.3.1. Les types de modèles et de transformation de MDA ... 121
III.3.1.1 Computation Independent Model (CIM) ... 121
III.3.1.2 Platform Independent Model (PIM) ... 121
III.3.1.3 Platform Specific Model (PSM) ... 122
III.3.2. Le processus de développement dans le contexte de MDA : ... 124
III.4. Processus MDA de développement des SOS adaptables ... 126
III.4.1. Phase 1: Elaboration des modèles des cas d‟utilisation... 128
III.4.2. Phase 2: Identification des services par acteur ... 129
III.4.3. Phase 3 : Spécification des interfaces de services ... 133
III.4.4. Phase 4 : Fusion des modèles visuels ... 135
III.4.5. Phase 5: Transformation des modèles et génération de code ... 137
IV.
VSoaMLTool : Outil de génération de code automatique ... 140
IV.1. Introduction ... 140
IV.2. VSoaMLTool : modules et fonctionnalités ... 141
IV.3. VSoaMLTooL : Transformation de modèle et génération de code... 143
IV.4. Le PIM (VSoaML) de l‟étude de cas DLS ... 144
IV.5. Le métamodèle du profil VSoaML ... 147
IV.6. Du PIM (VSoaML) vers des descriptions (MVWSDL) ... 148
IV.6.1.1 Le Multiview WSDL pour la description des services multivues... 148
IV.6.1.2 Du PIM(VSoaML) vers PSM(MVWSDL) ... 151
IV.6.1.3 Du PSM (MVWSDL) vers le code (MVWSDL) ... 154
IV.7. Du PIM (VSoaML) vers PSM (JaxRPC) ... 157
IV.7.1. Le métamodèle JAX-RPC ... 158
IV.7.2. Spécification des correspondances entre le métamodèle de VSoaML et le métamodèle JAX-RPC ... 159
IV.7.3. Les règles de transformation ... 160
IV.7.4. Le code java généré à partir des PIM(VSoaML)... 162
IV.8. VSoaMLTool : déploiement selon l‟architecture SOA ... 166
IV.9. Conclusion ... 168
Conclusion générale et perspectives ... 169
Liste des publications ... 172
Table des figures
Figure 1–Métamodèle du “service component” (Zhang et al., 2006) ... 11
Figure 2–Composant SCA ... 13
Figure 3–Modélisation à base de SCA du système de l‟agence de voyage ... 13
Figure 4–Métamodèle du profil UML (Johsnston et al., 2006). ... 15
Figure 5–Métamodèle du profil PIM4SOA (López-Sanz et al., 2007) ... 17
Figure 6 –Diagramme de classe et les rôles de l‟application «video central » (Fink et al, 2003) . 22 Figure 7–Déclaration des vues en VPL (Fink et al., 2003). ... 23
Figure 8–Métamodéle de vue (Maamar et al., 2005) ... 24
Figure 9–Script de transformation des documents WSDL ... 26
Figure 10–Types de variabilité de services (Chang et al., 2007b) ... 28
Figure 11–Concept de service différencié (Tao et al. , 2008) ... 32
Figure 12–Conception à base des services différenciés de l‟application OPS) (Tao et al., 2007b) . ... 33
Figure 13–Types de transformations : modèle vers modèle et modèle vers code (Bezevin et al., 2004). ... 40
Figure 14–Modèle PIM de l‟étude de cas « agence de voyage » (Bezevin et al., 2004). ... 41
Figure 15–Correspondances UML/WSDL (Bezevin et al., 2004) ... 42
Figure 16–Correspondances UML/Java (Bezevin et al., 2004) ... 43
Figure 17–Méthodologie de développement des SOS (Gronmo et al., 2004a). ... 44
Figure 18–Correspondance UML/WSDL ... 45
Figure 19–Processus de transformation du framework défini (Yu et al , 2007) ... 46
Figure 20–Métamodèle « Document Model » (Yu etal ., 2007) ... 47
Figure 21–Métamodèle WSDL (Yu et al., 2007) ... 48
Figure 22–Métamodèle Choreography (YU et al., 2007) ... 49
Figure 23–Métamodèle BPEL (Yu et al., 2007) ... 50
Figure 24–Profil “Document Model” (Patrasciuo, 2004) ... 51
Figure 25–Métamodèle du XML schéma ... 52
Figure 26–Métamodèle WSDL (Patrsciou et al., 2004) ... 52
Figure 27–Profil «Extra- functional Property » (Ortiz et al., 2006b) ... 54
Figure 28–Stéréotype « Extra-functional property » (Ortiz et al., 2006b) ... 54
Figure 29–Service TouristService (Ortiz et al., 2006a) ... 55
Figure 30–Processus de transformation ATL (Ortiz et al., 2006a) ... 55
Figure 31–Métamodèle cible SOAP (Ortiz et al., 2006a) ... 56
Figure 32–Métamodèle Policy (Ortiz et al, 2006a) ... 56
Figure 33–Métamodèle de SECTET-UML(Hafner et al.,2009) ... 58
Figure 34–Métamodèle XACML ... 59
Figure 35–Processus de développement dirigé par les modèles (D‟ambrogio, 2007) ... 60
Figure 36–Métamodèle ContextUML (Maamar et al., 2006) ... 61
Figure 37–Diagramme des cas d‟utilisation du DLS ... 72
Figure 38–Modèle d‟interaction des services avec leurs clients ... 75
Figure 39–Métamodèle de l‟interface MVServiceInterface ... 76
Figure 41–Couches fonctionnelles d‟un SOS (Papazoglou, 2007) ... 79
Figure 42–SOS adaptable : Couches d‟abstraction ... 81
Figure 43–Stéréotypes de VSoaML et leurs métaclasses de base UML2.0 ... 83
Figure 44–Métamodèle de VSoaML ... 84
Figure 45–Stéréotype Service ... 89
Figure 46–Service Agenda ... 89
Figure 47–Stéréotype message ... 91
Figure 48–Exemple d‟un message ... 91
Figure 49–Stéréotype MessageAttachment ... 92
Figure 50–Stéréotype specification... 93
Figure 51–Exemple de stéréotype Specification... 94
Figure 52–Stéréotype MVService... 95
Figure 53–Exemple de service multivues ... 95
Figure 54–Stéréotype MVServiceSpecification ... 97
Figure 55–Exemple de MVServiceSpecification... 97
Figure 56–Stéréotype Collaboration ... 98
Figure 57–Exemple de collaboration de services ... 99
Figure 58–Stéréotype Channel ... 101
Figure 59–Stéréotype Requester ... 102
Figure 60–Exemple de Requester ... 102
Figure 61–Stéréotype MVServiceInterface ... 103
Figure 62–Exemple de MVServiceInterface ... 103
Figure 63–Stéréotype baseServiceInterface ... 104
Figure 64–Exemple de BaseServiceInterface ... 104
Figure 65–Stéréotype ViewServiceInterface ... 105
Figure 66–Exemple de ViewServiceInterface ... 106
Figure 67–Stéréotype Provider ... 107
Figure 68–Stéréotype ServiceOperation ... 108
Figure 69–Exemple de serviceOperation ... 108
Figure 70–Stéréotype ServiceDomain ... 109
Figure 71–Modèle BPMN du cas d‟utilisation « Assurer Formation ». ... 110
Figure 72–Modèle BPMN du cas d‟utilisation « Suivre formation» ... 111
Figure 73–Modèle des services multivues du DLS ... 114
Figure 74–Extrait du modèle d‟information du système d‟Enseignement à Distance... 115
Figure 75–Phases du cycle de vie méthodologique (Papazoglou et al., 2006) ... 119
Figure 76–Types de transformations MDA (Blanc, 2005) ... 123
Figure 77–Processus de développement MDA des systèmes logiciels ... 125
Figure 78–Processus de développement des systèmes orientés services multivues dans le cadre de l‟approche MDA ... 127
Figure 79–Cas d‟utilisation du DLS ... 129
Figure 80–Scénario associé au cas d‟utilisation «assurer Formation» associé à l‟acteur ... 131
Figure 81–Identification des services associés à l‟acteur « Enseignant » ... 132
Figure 82–Identification des services associés à l‟acteur «Administrateur» ... 133
Figure 83–Identification des services associés à l‟acteur «Etudiant » ... 133
Figure 85– PIM raffiné associé à l‟acteur Administrateur... 135
Figure 86–Extrait du résultat de l‟étape de fusion du service Formation ... 136
Figure 87-Phase de transformation de modèle et génération du code ... 138
Figure 88–Modules de VSoaMLTool ... 142
Figure 89–Processus de génération de code à partir des PIMs (VSoaML) ... 143
Figure 90–Extrait des interfaces de service multivues des services multivues du DLS ... 146
Figure 91–Métamodèle VSoaML ... 147
Figure 92–Structure d'un document WSDL ... 149
Figure 93–Métamodèle MVWSDL ... 151
Figure 94–Code ATL de la règle de transformation viewinterface2WSDL ... 153
Figure 95–Code ATL de la règle de transformation BaseInterface2WSDL ... 154
Figure 96–Requête de génération de code MVWSDL ... 155
Figure 97–Code ATL pour la génération de code MVWSDL ... 155
Figure 98–Code MVWSDL généré ... 156
Figure 99–Processus de génération des implémentations des services à partir des PIMs (VSoaML) ... 157
Figure 100–Métamodèle JAX-RPC ... 158
Figure 101- Règle de transformation Domain2Package ... 161
Figure 102–Règle de transformation MVService2jaxrpcClass ... 161
Figure 103–Règle de transformation Operation2Method ... 162
Figure 104–Règle de transformation viewinterface2interface ... 162
Figure 105–Requête de génération de code Java ... 163
Figure 106–Code ATL pour la génération de code java ... 164
Figure 107–Code java généré à partir du PIM(VSoaML) ... 165
Figure 108–Architecture de déploiement des services multivues ... 167
Liste des tableaux
Tableau 1–Stéréotypes et métaclasse de base ... 16Tableau 2–Profil PIM4SOA ... 17
Tableau 3–Stéréotypes du profi l SoaML ... 19
Tableau 4–Correspondances Model Document/Web service (YUet al., 2007) ... 47
Tableau 5–Correspondances CCA/WSDL (Yu et al., 2007) ... 48
Tableau 6–Stéréotypes du profil SECTET-UML (Alam et al., 2008) ... 57
Tableau 7–Synthèse des différentes approches étudiées ... 65
Tableau 8–Stéréotypes du profil VSoaML ... 88
Tableau 9–Services multivues du Systéme d‟Enseignement à distance ... 145
Tableau 10–Correspondances VSoaML/MVWSDL ... 152
Tableau 11–Spécification des correspondances VSoaML/JAX-RPC ... 160
Liste des abréviations
Abréviation Signification
API Application Programming Interface
ATL Atlas Transformation Language
BPEL Business Process Execution Language
CAC Context aware Computing
DTD Data Type Definition
EMF Eclipse Modelling Framework
GMF Graphical Modelling Framework
GUI Graphical User Interfaces
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IDE Integrated Development Environment
J2EE Java 2 Platform Enterprise Edition
MDA Model Driven Architecture
MDD Model Driven Development
MOF Meta-Object Facility
OCL Object Constraint Language
OMG Object Management Group
PIM Platform Independent Model
PSM Platform Specific Model
QVT Query/View/Transform
SOC Service Oriented Computing
SOS Service Oriented Systems
SoaML Service Oriented Architecture Modeling Language
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
UDDI Universal Description, Discovery and Integration
UML Unified Modeling Language
WSDL Web Service Description Language
XMI XML Metadata Interchange
Introduction générale
Les systèmes d‟information occupent aujourd‟hui une position centrale dans la stratégie de l‟entreprise. La capacité de communication et d‟intégration de ces systèmes, leur réactivité aux changements métiers et technologiques ainsi que leur facilité d‟utilisation et d‟adaptation constituent des défis majeurs pour la compétitivité des entreprises. Pour relever ces défis, l‟ingénierie logicielle n‟a cessé de fournir de nouveaux paradigmes et de nouvelles technologies. Actuellement, l‟ingénierie logicielle est marquée particulièrement par l‟émergence de deux nouveaux paradigmes : SOC (Service Oriented Computing) et l‟Informatique Sensible au Contexte (Context-aware Computing). Les travaux menés au sein de cette thèse s‟inscrivent dans l‟étude et l‟exploitation de ces paradigmes selon une approche dirigée par les modèles (MDA-Model Architecture) pour répondre à certaines attentes des systèmes d‟information en pleine évolution.En effet, SOC (Papazoglou et al., 2003) (Huhns et al., 2005) permet le développement des systèmes d‟information distribués, flexibles, agiles et interopérables. SOC s‟appuie principalement sur le concept de service qui se définit comme une entité informatique indépendante des plateformes, auto-contenue et autonome permettant le support de la composition des applications distribuées en couplage faible tout en optimisant les coûts et les délais (Papazoglou, 2007). SOC se base sur l‟architecture orientée service (SOA-Service Oriented Architecture) dont l‟objectif est d‟organiser un ensemble d‟applications isolées, en un ensemble de services interconnectés, chacun étant accessible à travers des interfaces et des protocoles de communication standards. SOA définit une approche permettant de répondre aux besoins de développement des applications en couplage faible en se basant sur les standards tout en restant indépendant de tout protocole et de toute plateforme. La technologie des services web (Gustavo et al., 2003) constitue une implémentation de l‟architecture SOA. Elle définit un ensemble de standards et de protocoles fournissant ainsi une infrastructure assurant des fonctionnalités de transport, de messagerie (SOAP), de description (WSDL) (Chinnici et al ., 2001) de découverte et de publication (UDDI) (Clement et al., 2004) et de composition de
services (BPEL4WS)(Andrews et al., 2003).
En parallèle avec l‟émergence du SOC, l‟informatique Sensible au Contexte (Dey, 2000) a été proposée dans l‟objectif d‟adapter des applications et des systèmes logiciels aux différents contextes d‟utilisation. Ces derniers couvrent toutes les informations pouvant être utilisées pour caractériser la situation d‟une entité. Une entité peut être une personne, un lieu, ou un objet qui peut être pertinent pour l‟interaction entre l‟utilisateur et l‟application, y compris l‟utilisateur et l‟application (Dey, 2000). Bien qu‟il n‟existe pas une définition unique de ce qui est un contexte d‟utilisation, les caractéristiques des terminaux utilisés pour accéder aux systèmes et celles du réseau et surtout le profil de l‟utilisateur constituent les éléments clés du contexte d‟utilisation. Par ailleurs, l‟OMG a proposé l‟architecture dirigée par les modèles MDA (MDA-Model Driven Architecture) (OMG, 2003) pour le développement et la maintenance des systèmes d‟informations distribués et complexes. MDA propose une nouvelle manière de spécification des systèmes informatiques basée sur différents perspectives du même système. En premier lieu, les fonctionnalités et le comportement d‟un système sont décrits sans tenir compte des caractéristiques technologiques. Ensuite, la spécification des fonctionnalités et du comportement est utilisée pour créer les systèmes informatiques conformément à une technologie spécifique.
La première phase dans une approche MDA, est effectuée par un modèle indépendant d‟une plate-forme technologique (PIM - Platform Independent Model) alors que la deuxième phase est effectuée par un modèle spécifique à une plate-forme technologique (PSM - Platform Specific Model). Le passage du PIM vers le PSM constitue un aspect important de cette approche et se fait en se basant sur la spécification et la définition d‟un ensemble de règles de transformation.
La séparation claire et explicite entre les modèles indépendants et dépendants d‟une plate-forme permet d‟apporter plusieurs avantages au développement des systèmes logiciels. En effet, la logique métier est protégée contre les incessantes évolutions et l‟apparition des nouvelles technologies. De plus, elle apporte une plus grande réactivité quand les systèmes informatiques doivent évoluer pour utiliser une autre technologie ou atteindre d‟autres exigences. L‟approche MDA vise comme objectif de rendre les systèmes informatiques plus indépendants d‟une technologie spécifique en fournissant la portabilité et l‟interopérabilité au niveau des modèles.
Cette approche permet également la maîtrise de la complexité du développement de logiciels grâce à l‟utilisation des modèles comme éléments centraux pour le développement des systèmes logiciels.
Dans le but de gérer la complexité du développement des systèmes orientés services, d‟une part, et la prise en compte de l‟utilisateur, d‟autre part, il est nécessaire de fournir une méthodologie définissant concepts, Formalisme/Notation, Processus et outils. En effet, le développement des systèmes à base de service est généralement basé sur la technologie des services web qui fournit une infrastructure à base de standards incluant les standards WSDL, SOAP, UDDI et BPEL4WS permettant la description, l‟invocation, la découverte/publication et la composition de services. Certes, les technologies et les standards sont très importants pour le développement de tels systèmes, mais ils sont insuffisants pour le développement des systèmes d‟entreprise complexes et distribués vu que les différents stakeholders (e.g., les analystes métiers, les architectes, les utilisateurs finals, les développeurs, etc.) n‟ont pas forcément des connaissances techniques. Le challenge principal qui se pose aujourd‟hui est la spécification des systèmes orientés services indépendamment des technologies caractérisées par leur bas niveau d‟abstraction. Dans cette optique, plusieurs travaux de recherche ont été proposés. Pour sa part, L‟OMG est aujourd‟hui dans la phase de standardisation d‟un profil UML appelé SoaML(OMG, 2009) pour la modélisation des systèmes orientés services.
L‟objectif principal de cette thèse est de définir une approche d‟ingénierie pour le développement des systèmes orientés services adaptables aux différents types d‟utilisateur, dans le cadre de l‟approche MDA. Une telle approche définit (i) un profil UML appelé VSoaML (View based Service oriented architecture Modeling Language) pour la modélisation et la spécification des systèmes orientés services adaptables (ii) un processus de développement des systèmes orientés services adaptables dans le cadre de l‟approche MDA (iii) un outil logiciel dirigé par les modèles, appelé VSoaMLTool, permettant la génération de code à partir des modèles métiers de haut niveau via un ensemble de règles de transformations.
VSoaML (Kenzi et al., 2009) permet de modéliser un système orienté service adaptable à un haut niveau d‟abstraction indépendamment des plates-formes d‟implémentation (J2EE, dotNet, etc) et des standards de la technologie des services web (SOAP, WSDL, UDDI, BPEL4WS, etc.).
VSoaML est centré utilisateur et il se base fondamentalement sur le concept de service multivues (Kenzi et al., 2008) comme une entité de modélisation de première classe capable de représenter les besoins et les spécificités des utilisateurs suivant leurs profils. Le service multivues est une nouvelle entité de modélisation qui fournit, en plus des interfaces de services, des interfaces multivues qui se caractérisent par leur flexibilité et leur adaptabilité aux différents acteurs interagissant avec le service. Le service multivues permet la capture des exigences des utilisateurs et de leurs spécificités tout en séparant leurs préoccupations fonctionnelles. Pour ce faire, le service multivues fournit/requiert des interfaces capables de décrire les capacités du service suivant le profil de l‟utilisateur interagissant avec le service. Une telle interface permet la représentation des fonctionnalités de service accessible seulement à un type particulier d‟utilisateur.
Pour identifier les services multivues, les spécifier et les développer, nous avons défini un processus de développement dans le cadre de l‟approche MDA (Kenzi et al., 2008) (Kenzi et al., 2009). Ce processus définit les phases, les activités et les artéfacts pour transformer les exigences métier en termes d‟un ensemble de services flexibles et adaptables. La spécificité d‟un tel processus consiste en l‟identification des services en partant des modèles des cas d‟utilisation et en se basant sur un ensemble de règles de refactoring capables de faire les correspondances entre les cas d‟utilisations et les services (correspondance binaire, fusion/décomposition, etc). Ce processus de développement qui s‟inscrit dans le cadre de l‟approche MDA permet l‟élaboration des modèles et de gérer la transition d‟un modèle à un autre via des transformations de modèles. Ainsi, après l‟élaboration des modèles métier à base de service multivues, nous avons défini deux transformations pour la génération de code :
La première transformation permet la génération de la description de chaque service multivues composant le PIM d‟un système donné. En effet, nous avons défini une légère extension du standard WSDL pour la description de service multivues, appelé MVWDL. Cette extension de WSDL permet la représentation en XML aussi bien des interfaces des services que les informations concernant les acteurs interagissant avec le service. Pour permettre l‟automatisation de la génération du code du MVWSDL, nous avons défini un ensemble de règles de transformation en utilisant le langage ATL comme langage de transformation de modèles.
La deuxiéme transformation concerne la génération du code constituant l‟implémentation de chaque service multivues selon la plateforme cible J2EE.
Chaque transformation de modèles a été décomposée en deux étapes : la première concerne la spécification de correspondances. La deuxième permet la définition des transformations en se basant sur le langage de transformation de modèle ATL. En fait, la spécification de correspondances vise à spécifier les correspondances entre les éléments des métamodèles source et cible, et la définition de transformations permet de décrire en détail et d‟exécuter les étapes de la transformation d‟un modèle en un autre modèle en respectant la spécification de correspondances. Cette approche va dans le sens même de la vision de l‟OMG pour développer les systèmes informatiques à savoir la séparation des préoccupations. En fait, une spécification de correspondances peut être vue comme un PIM et une définition de transformations comme un PSM. Les deux décrivent la même chose mais à des niveaux différents.
Une fois générées la description de chaque service multivues et son implémentation, nous avons illustré comment faire l‟adaptation des services en prenant en compte les acteurs interagissant avec le service suivant l‟architecture SOA.
Présentation de ce mémoire
Le travail réalisé est présenté dans ce mémoire selon une structure de quatre chapitres.
Le premier chapitre présente l‟état de l‟art du domaine. Dans un premier temps, nous nous intéressons plus particulièrement aux approches de modélisation et de conception des systèmes orientés service. Ensuite, nous présentons les différentes approches permettant l‟adaptation des systèmes orientés services. Après, nous décrivons les approches MDA de développement des systèmes orientés services ainsi que les approches MDA pour la prise en compte de l‟utilisateur des systèmes orientés services. Enfin, nous concluons ce premier chapitre par une synthèse de l‟état de l‟art en identifiant les fondements de chaque approche.
Le deuxième chapitre expose le profil VSoaML à base des services multivues en identifiant les stéréotypes de ce profil ainsi que son métamodèle. Chaque stéréotype a été décrit tout en spécifiant les contraintes y associées. Enfin, nous illustrons la faisabilité de ce profil en se basant
sur une étude de cas concernant le système d‟enseignement à distance.
Le troisième chapitre est dédié à la définition du processus de développement des systèmes orientés services associé au profil VSoaML. Ce processus définit les phases, les activités et les artéfacts pour l‟identification, la spécification et l‟implémentation des services multivues.
Le quatrième chapitre présente les aspects applicatifs de ce travail. Il décrit premièrement le fonctionnement de l‟outil support à VSoaML. Cet outil se base notamment sur les principes et les standards de l‟ingénierie dirigée par les modèles pour la génération de code à partir des modèles métiers de haut niveau.
Enfin, nous concluons ce rapport en récapitulant les points forts de notre approche, les aspects traités et les perspectives de ce travail.
I. Etat de l’art
I.1. Introduction
SOC (Service-Oriented Computing) a émergé récemment comme un nouveau paradigme informatique prometteur pour le développement rapide et à moindre coût des applications distribuées, interopérables et évolutives (Papazoglou, 2007). SOC se base principalement sur l‟élément Service et sur l‟architecture orientée service SOA (Service Oriented Architecture). SOC propose une nouvelle manière de développement des systèmes distribués en se basant exclusivement sur la composition de services pour la construction d‟applications logicielles distribuées à grande échelle, évolutives, interopérables et facilement composables.
SOC a introduit plusieurs défis aux différents acteurs s‟intéressant à la construction des systèmes à base de services. Plus particulièrement, le défi de l‟ingénierie de tels systèmes (Papazoglou et al., 2008) qui consiste en la définition des approches de modélisation, des processus, des techniques et outils pour faciliter la construction de ces systèmes en optimisant les coûts et les délais. La définition de ces approches est d‟une importance capitale pour la réussite de projets de développement des SOSs (Service Oriented Systems).
Par ailleurs, la prise en compte de l‟utilisateur et de son environnement est d‟une importance capitale pour la construction de systèmes logiciels surtout avec l‟émergence de l‟informatique sensible aux contextes (Dey, 2000). Cette dernière insiste sur la prise en compte de l‟utilisateur final pour le développement de systèmes logiciels.
L‟objectif de ce premier chapitre est de :
(1) étudier les différentes approches de modélisation des systèmes orientés services
(2) étudier certaines approches visant la prise en compte de l‟utilisateur dans les systèmes orientés services
compte de l‟utilisateur des ces systèmes.
Ce chapitre est structuré en plusieurs sections. Après la présente introduction, la deuxième section a pour objectif de définir brièvement les concepts et les termes en relation avec le paradigme SOC tels que : le concept de service, l‟architecture orientée service (SOA), un système orienté service ainsi que la technologie des services Web. La troisième section traite les approches de modélisation des systèmes orientés services. La quatrième section traite les approches à même de permettre la prise en compte des différentes dimensions des besoins des utilisateurs. La cinquième section met l‟accent sur les approches MDA pour le développement des systèmes orientés services. Enfin, nous clôturons ce chapitre en dressant un bilan comparatif des différentes approches étudiées.
I.2. Systèmes Orientés Services (SOS) : concepts et définitions
Dans le cadre de cette thèse, nous définissons SOA comme un style d‟architecture permettant le développement des applications en couplage faible à travers des standards, et indépendamment des protocoles et plateformes. L‟architecture orientée services définit trois acteurs : le fournisseur de services, l‟annuaire de services et le client de service. Elle définit aussi trois opérations standards : find, bind et publish (Papazoglou, 2007). Le fournisseur de services qui possède l‟implémentation de service procède à la publication de la description du service dans un annuaire de services. Ce dernier contient l‟ensemble des descriptions de services publiés par les différents fournisseurs de services. Il fournit les moyens nécessaires pour la publication et la découverte des services. Le client de service pour un besoin donné, recherche dans l‟annuaire le service qui lui convient.
Nous définissons aussi un Système Orienté Service (SOS par la suite) comme étant un système qui se constitue principalement des services et se base sur l‟architecture SOA comme un style architectural.
La technologie des services web constitue une implémentation prometteuse de l‟architecture SOA. Un service Web est défini selon le W3C (W3C, 2004):
(URI), dont les interfaces publiques et les liens (binding) sont définis et décrits en XML. Sa définition peut être découverte dynamiquement par d‟autres systèmes logiciels. Ces autres systèmes peuvent ensuite interagir avec le service Web d‟une façon décrite par sa définition, en utilisant des messages XML transportés par des protocoles Internet ».
La technologie des services web se base principalement sur les protocoles et les standards suivants : SOAP, WSDL et UDDI.
SOAP est le protocole d‟échange de messages permettant d‟interagir avec les services Web. Ces messages sont délivrés sous la forme de documents XML qui sont structurés par : une entête contenant les informations non fonctionnelles liées au message telles que la sécurité ainsi qu‟un corps contenant les données métiers du domaine de l‟application. SOAP est générique et extensible puisque les autres spécifications sont définies par dessus en définissant par exemple de nouveaux entêtes (sécurité, garantie de livraison). Ce protocole n‟est pas lié à un type particulier de protocole de transport de données, mais il est fréquent qu‟il soit associé à HTTP ou SMTP. WSDL est le standard basé sur XML permettant de décrire les services Web.
Il permet de générer des documents structurés en deux parties : une partie abstraite décrivant l‟interface fonctionnelle du service en termes d‟opérations et de messages, ainsi qu‟une partie concrète qui contient les détails des protocoles à utiliser et de l‟adresse physique des opérations.
UDDI est une spécification technique définissant un registre permettant la publication et la découverte des services Web. Un registre UDDI est un registre basé sur XML qui contient des informations à propos d‟entités d‟affaire fournissant des services Web ainsi que des métadonnées concernant ces services (informations techniques ou légales). En outre, UDDI spécifie plusieurs API pour interagir avec le registre, demander ou publier un service.
I.3. SOS : Approches de modélisation
Aujourd'hui, le monde industriel et académique s‟intéresse de plus en plus à la modélisation des systèmes orientés services indépendamment des plates-formes technologiques ou des langages de
programmation. La modélisation est d‟une importance capitale pour le développement des SOSs (Papazoglou et al., 2008) dans la mesure où elle définit les éléments de modélisation capables de représenter de tels systèmes à un haut niveau d‟abstraction.
Dans cette section, nous illustrons différentes approches de modélisation des systèmes orientés services telles que les approches à base du « service component » (Stojanovic, 2004) (Zhang, 2006). Nous présentons aussi le Service Component Architecture (SCA) (Biesiegel et al. 2005) comme un ensemble de spécifications pour la modélisation des systèmes orientés services indépendamment des technologies et des standards. Finalement, nous présentons des travaux définissant des profils UML pour l‟analyse/conception des systèmes orientés services (Johnston, 2006) (Amir et al., 2004) (López Sanz et al., 2007) (Ermagan et al., 2007) (Benatallah et al., 2009).
I.3.1. Approches à base de « Service Component »
Zhang et al. (Zhang et al., 2006) ont introduit un framework de modélisation des systèmes orientés services. Ce framework se base sur le concept de « service component » permettant l‟analyse/conception des systèmes orientés service. Le « service component » est traité comme étant une entité de modélisation de première classe permettant de capturer des unités fonctionnelles relatives à des services abstraits. Le «service component » possède plusieurs interfaces découvrables et accessibles à travers le réseau. Chaque « service component » est autonome, auto-descriptif et peut exposer et délivrer des fonctionnalités à d‟autres «service component » à travers des interfaces sans se soucier des détails d‟implémentations.
Le «service component » est utilisé pour la description de la structure d‟un système loin de toute technologie ou plate-forme (intergiciel, système d‟exploitation, architecture matérielle, etc.).
La figure 1 illustre le métamodèle du « service component ». Le métamodèle est présenté dans le but d‟assurer l‟interopérabilité et l‟intégration des systèmes orientés service. Le méta-modèle du « service component » se compose des éléments suivants :
Specification déclare les interfaces du service et les contrats du service. Une déclaration d‟interfaces spécifie les ports du service et possède des propriétés fonctionnelles et non fonctionnelles et les contraintes associées. Le contrat du
service guide le consommateur à utiliser le service. Il spécifie le rôle que le « service component » doit jouer et il inclut les informations de configuration qui spécifient les versions des services, les pré-conditions, les post-conditions et les conditions de coordination. Ainsi, elle facilite la modification, le remplacement, et l‟évolution du service.
Contents représente l’implémentation du composant service avec un langage donné (C, C#, Java, etc.). Les détails de cette implémentation sont invisibles au consommateur de ce service ainsi qu‟à l‟environnement extérieur.
Le contexte définit l‟environnement dans lequel le service existe.
La chorégraphie permet d‟indiquer si le service component est un service composite ou pas. Le patron de composition est fourni dans la spécification de la chorégraphie.
Dans le même objectif que (Zhang et al, 2006), (Stojanovic et al., 2004) proposent une approche pour la modélisation et la conception des solutions SOA. Cette approche se base aussi principalement sur le concept « service component» et sur des extensions apportées au langage UML.
Le « component service » est défini dans le cadre de cette approche, comme une entité logicielle autonome qui réalise des services à travers des interfaces de façon contractuelle sans exposer sa réalisation interne.
Pour la modélisation et la conception des solutions SOA, deux types de « service component » de différente granularité ont été définis :
Business Service Component (BSC) qui est un type de « service component » fournissant des services et des opérations significatifs, perçus avec une valeur mesurable dans le contexte Business. Il permet de réaliser des parties d‟un processus métier en coordination et en coopération avec d‟autres BSC pour réaliser des objectifs business plus compliqués.
Atomic Service Component (ASC) qui est un type de « service component » fournissant des opérations de granularité fine n‟ayant pas une réelle valeur Business. Chaque ASC collabore et coordonne avec d‟autres ASC pour fournir un comportement métier représenté par un BSC qui les encapsule.
I.3.2. Approches à base de « Service Component Architecture » (SCA)
Le Service Component Architecture (SCA) (Biesegel et al., 2005) est un ensemble de spécifications décrivant un modèle de composant pour développer des applications SOA. Les
applications basées sur SCA sont en fait un assemblage de composants. Chaque composant modélise une partie de la logique métier et peut dépendre de services fournis par d‟autres composants.
L‟objectif principal de SCA est de décrire des applications SOA en se focalisant sur la logique métier indépendamment des standards, des plateformes et des langages utilisés (i.e. Java, C#, BPEL, etc). Ainsi, avec SCA, les services se traitent tous de la même manière quelles que soient leurs caractéristiques techniques. Le fait de pouvoir s'abstraire des considérations techniques des applications, simplifie énormément leur conception en utilisant les services.
Le modèle de SCA proposé, se focalise essentiellement sur les interfaces pour représenter les fonctionnalités du composant fournies à d‟autres composants. Il se base aussi sur les références pour désigner les interfaces requises que le composant peut utiliser pour répondre aux besoins de ses utilisateurs. Figure 2 présente le modèle de composant SCA.
Figure 2–Composant SCA
La Figure 3 présente un modèle d‟un système d‟une agence de voyages, représenté par quatre
Figure 3–Modélisation à base de SCA du système de l’agence de voyage
services avec leurs interfaces fournies et leurs références. Ce système est représenté sans tenir références Component Service CarReservation HotelReservation BookTravel AirReservation
compte des détails des plates-formes technologiques qui sont prises ultérieurement dans le cycle de développement des systèmes orientés services à base de SCA.
I.3.3. Approches à base de profils UML
UML est un langage de modélisation destiné à un grand nombre de domaines. Pour l‟adapter à un domaine particulier, il est nécessaire de définir des extensions (stéréotypes, valeurs étiquetées, contraintes) structurées et regroupées dans ce qu‟on appelle un profil. Dans le contexte de SOA, plusieurs profils ont été proposés pour la spécialisation d‟UML en vue de la modélisation des applications SOA. Dans cette section, nous présentons principalement trois profils : le profil défini par (Johnston et al., 2006), le profil défini par (López-Sanz et al., 2007) ainsi que le profil SoaML proposé par l‟OMG.
Johnston et al. (Johsnston et al., 2006) ont proposé un profil UML2.0 pour la modélisation des services et des solutions orientées services. Ce profil fournit un langage commun pour la modélisation des services. Il définit aussi un ensemble d‟activités le long du cycle de vie du développement tout en fournissant un ensemble de vues des services aux différents stakeholders. De telles vues permettent de modéliser une perspective du système correspondant à un point de vue donné (stakeholder). Ainsi, le profil fournit les fonctionnalités nécessaires à l‟architecte pour organiser les services le plus tôt dans le cycle de développement en utilisant les partitions logiques pour la description de l‟ensemble de services à l‟échelle de l‟entreprise. Cette vue est raffinée par les concepteurs qui ont pour mission le développement des spécifications de services aussi bien structurelles que comportementales. Les spécifications de services jouent un rôle de contrat entre les fournisseurs de services et les clients de services. La vue message permet aux concepteurs de réutiliser les modèles d‟informations pour la définition des données manipulées par le service. La Figure 4 présente les différents stéréotypes définis ainsi que leurs relations.
Figure 4–Métamodèle du profil UML (Johsnston et al., 2006). Le tableau 1 présente chaque stéréotype, sa description ainsi que leurs métaclasses sources UML 2.0 :
Nom du stéréotype Metaclasse Commentaire
Message Class Ce stéréotype définit les
structures de données
échangées. Il spécifie aussi la propriété “Encoding” pour spécifier l‟encodage SOAP ou RPC.
Message Attachment Property Ce stéréotype indique si le
contenu d‟un message est un attachement ou pas
Service Port Ce stéréotype permet de
déterminer le couple specification/binding
Service Channel Connector Ce stéréotype décrit une
connexion entre services.
Service Collaboration Collaboration Ce stéréotype permet la
modélisation du
de services qui coopèrent.
Service Consumer Classifier Ce stéréotype désigne un
consommateur de service.
Service Gateway Port Ce stéréotype permet la
modélisation d‟une connexion entre partitions
Service Partition Node Ce stéréotype définit un
groupement logique ou physique d‟un ensemble de services
Service Provider Class
Ce stéréotype permet la modélisation d‟un fournisseur d‟un ou de plusieurs services
Service Specification Class, Interface Ce stéréotype permet la
spécification des opérations et leurs messages associés qui définissent le service.
Tableau 1–Stéréotypes et métaclasse de base
Dans le même objectif (López-Sanz et al., 2007) (López Sanz et al. 2008) ont proposé des profils UML pour la modélisation des systèmes orientés services. Ainsi, Lopez-Sanz et al. (López-Sanz et al., 2007) ont défini plusieurs stéréotypes permettant la spécification des systèmes orientés services. Le tableau 2 présente les stéréotypes définis, les métaclasses UML de base, les concepts définis ainsi que leurs sémantiques.
Notation Concept associé Métaclasse UML de
base
Sémantique
<<outerProvider>> Outer provider Package Un fournisseur de service externe <<businessContract>> Business contract Dependency Le contrat établi
entre fournisseurs de services
<<FrontEnd>> System Front-End Classifier Les composants qui interagissent avec l‟utilisateur
<<CompServ>> Composite service Classifier Un service composé d‟autres services <<BasicServ>> Basic service Classifier Ce stereotype
représente une fonctionnalité basique
<<OrchServ>> Orchestrator service Classifier Ce stéréotype joue le rôle d‟un
orchestrateur dans une chorégraphie
<<ServContract>> Service contract Association Class Ce stéréotype joue le rôle d‟un connecteur entre service
<<contractClause>> Restriction clause Classifier Les pre/post conditions qui doivent être vérifiées
<<servOp>> Service operation Property Une fonctionnalité atomique d‟un service
Tableau 2–Profil PIM4SOA
La figure 5 présente le métamodèle du profil défini. Ce métamodèle définit la structure des différents stéréotypes ainsi que leurs associations.
Figure 5–Métamodèle du profil PIM4SOA(López-Sanz et al., 2007)
Pour sa part, L‟OMG est dans la phase de la standardisation d‟un profil UML appelé SoaML (Service oriented architecture Modeling Language) (OMG, 2009) dans l‟objectif de la modélisation des applications SOA. SoaML s'intéresse à l'architecture et non pas aux composants
techniques sous-jacents. Son objectif est de fournir aux utilisateurs du langage UML, les moyens de modéliser une architecture orientée services -comprenant des notions de clients et de fournisseurs de services, de collaboration de services ainsi que la notion de contrats. Le profil SoaML définit plusieurs stéréotypes. Le tableau 3 illustre les stéréotypes SoaML ainsi que leur sémantique associé.
Stéréotype Métaclasse UML Sémantique
Agent Class Agent est une classification
d‟entités autonomes qui s‟adaptent et interagissent avec leur environnement. Les agents en SoaML sont les participants fournissant et utilisant les services.
Collaboration Collaboration Collaboration permet la
description d'un patron d'interaction entre les différents rôles.
Attachment Property Attachment désigne une partie
d‟un Message qui est un attachement.
CollaborationUse CollaborationUse CollaborationUse montre comment une collaboration (ServiceContracts et ServiceArchitectures) est accomplie.
MessageType Class, DataType, Signal MessageType permet la
spécification des informations échangées entre les fournisseurs et les consommateurs de services.
Expose Dependency Expose désigne une
dépendance qui indique si un Capability doit être exposé ou pas.
Milestone Comment Milestone permet d‟indiquer
le progrès dans les comportements ayant une durée considérable.
Participant Class participant désigne un
fournisseur ou un
Provider Interface, Class Provider modélise le type d‟un fournisseur de services. Consumer Interface, Interface Consumer modélise un type
d‟un consommateur de service.
Request Port Request désigne un port qui
définit un point de connexion à travers lequel un participant répond à ses besoins via la consommation des services fournis par d’autres
fournisseurs.
Service Port Service représente un port qui
définit le point de connexion par lequel un participant offre ses capacités à ses clients.
Capability Class Capability dénote une
capacité d‟un service donné.
Service Contract Collaboration ServiceContract est la
formalisation de l‟échange d‟information, des biens et des obligations entre les parties définissant un service.
Service Interface Class, Interface ServiceInterface fournit la
définition d‟un service. Il définit la spécification de l‟interaction «Service» ou «Request»
ServiceChannel Connector ServiceChannel désigne un
chemin de communication entre requêtes et services
Services Architecture Collaboration ServiceArchitecture définit
une vue de haut niveau d‟une architecture orientée service qui définit comment un ensemble de participants travaillent ensemble pour atteindre un objectif donné en fournissant et utilisant des services.
I.3.4. Discussion
Les approches de modélisation des SOS jouent un rôle très important dans la construction des SOS en définissant les concepts et les formalismes/notations nécessaires pour la description de tels systèmes indépendamment des technologies et des standards. Elles permettent de décrire les aspects structurels et dynamiques des SOS, ce qui facilite la compréhension, la vérification la validation et la simulation de tels systèmes. Tout de même, le développement des SOSs se base principalement sur la technologie des services web qui définit un ensemble de technologies (XML, etc.) et de standards (e.g., WSDL, UDDI, BPEL4WS, etc.). Cependant, pour faciliter et rationaliser le développement de tels systèmes, il faut les décrire à un haut niveau d‟abstraction vu la diversité des profils des acteurs (les analystes métier, les architectes, les développeurs, les utilisateurs finals, etc.) s‟intéressant à leur développement sans en comprendre nécessairement les détails technologiques.
Par ailleurs, les différentes approches de modélisation proposées ne permettent pas de rendre productifs les modèles élaborés. Ces derniers permettent de représenter des SOS à différents niveaux d‟abstraction mais ne facilitent pas la génération automatique des artefacts d‟un SOS (Description de services WSDL, Implémentation de services en Java ou C#, Composition de services BPEL, Fichiers de configuration, etc.) en se basant sur des outils logiciels appropriés.
Aussi, ces différentes propositions ne prennent pas en compte l’aspect multidimensionnel des
besoins des acteurs interagissant avec le service. En effet, un service en SOC interagit avec
plusieurs clients de services. Chaque client de service a un profil donné avec des besoins différents. Ainsi, les approches de modélisation doivent tenir compte de cette réalité pour mieux la représenter.
I.4. SOS : Concepts d’adaptation
L‟utilisateur final joue un rôle crucial dans le développement des systèmes d‟information orientés services. En effet, c‟est lui qui exploite et utilise le système. Pour prendre en compte ses besoins, plusieurs approches définissant différents mécanismes et concepts, ont été proposées. Ainsi, nous présentons dans cette section, en premier lieu, les approches utilisant les vues pour la prise en compte des différents aspects des besoins des utilisateurs tels que l‟utilisation des vues
pour l‟adaptation des services au contexte de l‟utilisateur (Benslimane et al., 2005), la gestion de ses droits d‟accès (Fink et al., 2003) et l‟adaptation des services aux types des utilisateurs de service (Fuchs, 2004). Dans un deuxième lieu, nous présentons les approches qui se basent sur la variabilité de service pour la prise en compte de l‟utilisateur final (Chang et al., 2007a). En troisième lieu, nous présentons les approches permettant l‟adaptation de services se basant sur le concept de service différencié (Tao et al., 2007a) (Tao et al., 2008). Finalement, nous présentons autres approches qui définissent des extensions aux standards de la technologie des services web pour la prise en compte de l‟utilisateur final (lopez-velasco et al., 2005) (Kouadri Mostefaoui, 2006) .
I.4.1. Concept d’adaptation : les Vues
L‟objectif de cette section est de présenter les différents travaux combinant entre le concept de vue et celui de service pour la prise en compte de l‟utilisateur final. Généralement, les vues sont largement utilisées dans plusieurs domaines de l‟informatique. Elles sont utilisées dans les SGBD (Rafanelli et al. 2003), la gestion des connaissances, les workflows, les approches orientées objets, etc. Aussi, notre équipe a déjà développé des méthodes en se basant sur le concept de vue telles que la méthode VBOOM (Kriouile, 1995) ou l‟approche VUML (Nassar et al., 2005). De même, pour accompagner l‟évolution de l‟ingénierie logicielle vers les approches à base de composants (Szyperski, 2002), un modèle du composant multivues (El Asri, 2005) a été proposé.
Dans cette section, nous nous intéressons tout particulièrement aux approches se basant sur les vues pour la prise en compte de l‟utilisateur final pour le développement des SOSs.
I.4.1.1
Vues à base de l’adaptation par rôles
Les vues ont été largement utilisées pour l‟adaptation des services aux rôles des utilisateurs. Dans cette optique, Torsten et al. (Fink et al. 2003) proposent une approche à base de vue pour la gestion des droits d‟accès de chaque acteur interagissant avec un service donné. Cette approche se base sur un modèle appelé VBAC (View Based Access Control) et sur un langage déclaratif permettant de spécifier les différentes vues. Nous commençons par présenter l‟exemple d‟application avant d‟expliquer les concepts de base de cette approche.
(1) L’exemple d’application
« Video central » est une application qui repose sur un ensemble de services web développé par IBM (IBM, 2002). Cette application définit six services web représentés par le diagramme de classe UML dans la figure 6 suivante.
Figure 6 –Diagramme de classe et les rôles de l’application «video central » (Fink et al, 2003) « Video central » se compose de six services web représentés sous forme de diagramme de classes UML : CustomerRentedList, MovieSearch, BusinessRegistartion, CustomerRegistration et CustomerInfraction. Ce diagramme illustre aussi les rôles qui interagissent avec les différents services web : Customer et Staff. Chaque rôle a ses propres besoins sur les services. En d‟autres termes, chaque acteur a ses droits d‟accès sur un service donné. En effet, dans le cadre de cet exemple, le rôle Customer ne peut pas exécuter les opérations : processRegisterRequest, ou getCustomerGUID réservées seulement au rôle Staff.
(2) Le modèle VBAC et le langage VPL
VBAC est un modèle de contrôle d‟accès conçu pour supporter la conception et la gestion des politiques de contrôle d‟accès dans les systèmes distribués. VBAC (Fink et al.,2003) est une extension du modèle de contrôle d‟accès à base de rôles (RBAC) par les concepts de vue et de schéma. Une vue regroupe les permissions ou les interdictions pour la gestion de l‟accès à des objets (un fichier, une méthode,…). Chaque vue est associée à des rôles. Un sujet (un utilisateur,
WishList processAddRequest(businessGuid,registrationKey,customerGuid,titleList):int processQueryRequest(businessGuid,registrationKey,customerGuid,maxNumRecords):String processRemoveRequest(businessGuid,registrationKey,customerGuid,titleList):int CustomerInfraction processAddRequest(loginBusinessID,loginBusinessPassword,firstName,lastName):int processQueryRequest(loginBusinessID,loginBusinessPassword,customerGUID,beginDate,endDate):String CustomerRegistration getCustomerGUID(loginBusinessID,loginBusinessPassword,firstName,lastName):int processRegisterRequest(loginBusinessID,loginBusinessPassword,firstName,lastName):int Staff MovieSearch processRequest():String BusinessRegistration processRegisterRequest():int Customer CustomerRentedList processAddRequest(loginBusinessGuid,loginBusinessPassword,userID,titleIDList):int processQueryRequest(loginBusinessID,loginBusinessPassword,customerGuid):String
un processus,…) peut accéder à un objet s‟il a un rôle auquel une vue est assignée. Si la vue n‟existe pas pour un rôle donné, le sujet ne peut pas accéder à l‟objet en question. Un schéma spécifie les assignations dynamiques aux différents rôles. Ces assignations sont effectuées automatiquement à chaque invocation d‟une opération donnée.
Dans le but de spécifier les politiques VBAC, un langage déclaratif appelé VPL (View Policy Language) a été défini. VPL est utilisé pour spécifier les rôles, les vues et les schémas. Les rôles sont définis dans une déclaration en utilisant le mot clé role. Les schémas sont définis en utilisant le mot clé schema.
La clause role définit les différents rôles dans la politique ainsi que leurs vues initiales. La figure 7 montre la définition des rôles pour l‟application «Video central».
Figure 7–Déclaration des vues en VPL (Fink et al., 2003).
La figure 7 montre la déclaration de deux rôles : Client et Staff. Le rôle staff possède initialement la vue BusinessRegistration (mot clé holds). Le rôle Client n‟a initialement aucune vue. Une vue VPL définit les autorisations à un sous-ensemble d‟opérations d‟un seul service web. Une vue est référencée par la clause de contrôle. Par exemple, la vue BusinessRegistration donne la permission pour invoquer l‟opération processRegisterRequest du service web BusinessRegistration. Une Vue VPL peut être statiquement restreint à certains rôles.
I.4.1.2
Vues à base de l’adaptation contextuelle
Pour adapter les services aux types de leurs utilisateurs ou à leur contexte, plusieurs approches ont adopté les vues. Ainsi, (Maamar et al. 2005) (Benslimane et al. 2005) présentent une
role customer
staff holds BusinessRegistration
view BusinessRegistration controls BusinessRegistration restricted to staff
{ processRegisterRequest }
view CustomerRegistration controls CustomerRegistration restricted to staff
{
getCustomerGUID(loginBusinessID, , , ) if caller = loginBusinessID
processRegisterRequest(loginBusinessID, , , ) if caller = loginBusinessID
}
view CustomerInfraction controls CustomerInfraction restricted to staff {
processAddRequest( loginBusinessID, , ) if caller = loginBusinessID
processQueryRequest( loginBusinessID, , , , ) if caller = loginBusinessID
