Numéro d'ordre : Année 2008 Institut National des Sciences Appliquées de Lyon EDIIS : École Doctorale d'Information et Information pour la Société Interconnexion des processus Interentreprises : une approche orientée services THESE DE DOCTORAT (Spécialité informatique) Par Sodki CHAARI (Ingénieur en informatique) Soutenue publiquement le 18 Décembre 2008 devant la commission d'examen composée de : Rapporteurs : Pr. Mohamed JMAEIL (École Nationale d'Ingénieurs de Sfax, Tunisie) Pr. Hervé PINGAUD (École des Mines d’Albi‐Carmaux) Examinateurs : Pr. Frédérique BIENNIER (Institut National des Sciences Appliquées de Lyon) Pr. Patrick Burlat (École des Mines de Saint Etienne) Directeurs de thèse : Pr. Joël FAVREL (Institut National des Sciences Appliquées de Lyon) Pr. Chokri BEN AMAR (École Nationale d'Ingénieurs de Sfax, Tunisie)
177
Embed
Interconnexion des processus Interentreprises : une ...theses.insa-lyon.fr/publication/2008ISAL0134/these.pdf · Interentreprises : une approche orientée ... increasing customer
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Numéro d'ordre : Année 2008
Institut National des Sciences Appliquées de Lyon
EDIIS : École Doctorale d'Information et Information pour la Société
Interconnexion des processus Interentreprises : une approche orientée
services
THESE DE DOCTORAT (Spécialité informatique)
Par
Sodki CHAARI (Ingénieur en informatique)
Soutenue publiquement le 18 Décembre 2008 devant la commission d'examen composée de :
Rapporteurs : Pr. Mohamed JMAEIL (École Nationale d'Ingénieurs de Sfax, Tunisie)
Pr. Hervé PINGAUD (École des Mines d’Albi‐Carmaux)
Examinateurs : Pr. Frédérique BIENNIER (Institut National des Sciences Appliquées de Lyon)
Pr. Patrick Burlat (École des Mines de Saint Etienne)
Directeurs de thèse :
Pr. Joël FAVREL (Institut National des Sciences Appliquées de Lyon)
Pr. Chokri BEN AMAR (École Nationale d'Ingénieurs de Sfax, Tunisie)
‐i‐
Remerciements Tout d’abord, je tiens à exprimer mes plus vifs remerciements et ma gratitude à mes directeurs de
thèse, M. Joël FAVREL et M. Chokri BEN AMAR, pour leurs encadrements continus, pour les
remarques constructives qu’ils m’ont fournies ainsi que pour leurs précieux conseils durant toute
la période de mon travail. Je les remercie également pour la confiance qu’ils m’ont accordée et
pour la grande liberté d’idées et de travail qu’ils m’ont donnée. En dehors de leurs apports
scientifiques, je n’oublierai pas aussi de les remercier pour leurs qualités humaines, leur
hospitalité et leur soutien qui m’ont permis de mener à bien ma thèse de doctorat.
Ma reconnaissance va à Mme Frédérique BIENNIER pour sa disponibilité et ses connaissances
dans de nombreux domaines. Elle a ainsi largement contribué au bon déroulement de mes
travaux, et a ensuite été présente au quotidien pour m’aider à surmonter les diverses difficultés,
m’encourager, et me prodiguer de bons conseils.
Je remercie Monsieur Mohamed JMAEIL, Professeur à l’École Nationale d'Ingénieurs de Sfax et
Monsieur Hervé PUNGAUD, Professeur à École des Mines d’Albi‐Carmaux d'avoir accepté de
rapporter cette thèse. Merci aussi à Monsieur Patrick Burlat, Professeur à École des Mines de
Saint‐Etienne d'avoir accepté d'être parmi les examinateurs de ma thèse.
Un grand merci également au Professeur Mohamed Adel ALIMI pour ses conseils et ses
encouragements.
Ma reconnaissance à Mme Nadira MTAR pour ces encouragements et son soutien surtout dans
les moments difficiles.
Je remercie les membres des laboratoires LIESP et REGIM que j’ai pu côtoyer durant la période de
ma thèse et qui ont su rendre mon travail agréable, par leur simple présence et l’ambiance qu’ils
ont su créer.
Je dédie du plus profond de mon cœur ce travail, à mes chers parents Habib et Saloua, à ma
grand‐mère Monjia, à ma sœur Fatma et mon frère Helmi. C’est grâce à leur soutien, leur
patience et leur amour que je suis là aujourd’hui. Je leur suis très reconnaissant pour les sacrifices
qu’ils ont dû faire pendant mes longues années d’études et d’absence.
Merci à tous ceux qui y ont cru à moi et m'ont soutenu.
Sodki CHAARI
‐ii‐
Résumé
La variabilité importante des demandes des clients et la difficulté de répondre à leurs
besoins avec des coûts de production acceptables ont poussé les entreprises à revoir
en profondeur leurs processus et à devenir plus agiles. Cette conséquence qui est
aussi le résultat de l'expansion des technologies d'information et de communication
et le raccourcissement du cycle de vie des produits, explique l'effort des entreprises,
plus spécialement les PME à orienter leurs réflexions sur le niveau interentreprises et
à tisser des relations de collaboration et de coopération. Ceci a donné naissance à un
nouveau mode de travail notamment la collaboration interentreprises à la demande.
Pour répondre à ces exigences, deux préoccupations majeures doivent être prises en
compte. La première consiste à se focaliser sur l'entreprise elle‐même et agir sur son
Système d'Information de manière qu'elle soit plus agile. La deuxième préoccupation
prend en considération la construction du processus collaboratif interentreprises à
partir de l'interconnexion des différents processus d'entreprises.
L'Architecture Orientée Services (SOA) est actuellement présentée comme étant une
opportunité pour répondre à ces types de préoccupations. Nous nous sommes basés
sur ce style d'architecture et les principes qu'elle a apporté pour l'étendre à
l'ensemble du Système d'Information et développer une Entreprise Orientée
Services. Le résultat est un Système d'Information formé par un ensemble de services
de différents niveaux d'abstraction qui sont réutilisables et autonomes. La
construction des processus collaboratifs interentreprises dans le cadre d'une
Entreprise Orientée Services sera assurée par une phase de composition de services.
Afin d'assurer une composition dynamique et à la demande, notre Framework de
composition de service tient compte principalement des paramètres non
fonctionnels de services.
Mots clés : Collaboration interentreprises, Architecture Orientée Services (SOA), Web Service, Entreprise Orientée Services, composition de services.
‐iii‐
Abstract
Today, enterprises are operating in a quickly changing market characterized by
increasing customer demands for low cost and short time to market. To cope with
these business conditions, enterprises must adopt a two‐level solution. The former is
on the inter‐organizational side in which enterprises collaborate together in order to
provide the best products or services. The later is on the organization side where
enterprises must be more agile to survive.
A contemporary approach for addressing these critical issues is the Service Oriented
Architecture (SOA). Accordingly, we extend this architecture style to the global
enterprise level, and not only to the IT level. The result is a flexible, agile, managed
SOA ecosystem that supports dynamic enterprise collaboration. This architecture is
based on SOA and extends it to a Service Oriented Enterprise. Typically, a Service
Oriented Enterprise is an enterprise which implements and exposes its business
processes through a set of well defined services. In order to guarantee a dynamic and
on‐demand collaboration, we develop a Framework for composing enterprise
services with a particular attention to their non‐functional descriptions.
Key‐words: Service Oriented Architecture (SOA), enterprise collaboration, Service Oriented
Enterprise, Web service, service composition.
‐iv‐
Table de Matière
Chapitre 1 Introduction générale .................................................................................. 1 1.1 Contexte de travail ......................................................................................................... 1 1.2 Organisation du document ............................................................................................. 2 Chapitre 2 Problématique ............................................................................................. 5 2.1 Cadre du travail : la coopération interentreprises ......................................................... 6
2.1.1 La coopération interentreprises : Motivations et conséquences .......................... 6 2.1.2 Le processus interentreprises ................................................................................ 8
2.2 La Coopération interentreprises : Problèmes ................................................................ 8 2.2.1 Problèmes liés au Système d'Information de l'entreprise ..................................... 9 2.2.1.1 Le manque d'agilité ............................................................................................ 9 2.2.1.2 Problème concernant l'ouverture du SI à l'extérieur ....................................... 10
2.2.2 Les problèmes liés à l'interconnexion de processus ............................................ 11 2.3 L'orientation Service ..................................................................................................... 12
2.3.1 Le concept de service ........................................................................................... 13 2.3.2 Pertinence et bénéfices de l'orientation service .................................................. 13
2.4 Approche proposée et objectif..................................................................................... 15 2.4.1 Réorganiser l'entreprise selon l'orientation service : l'EOS ................................. 16 2.4.1.1 L'Entreprise Orientée Services ......................................................................... 16 2.4.1.2 Construction de l'Entreprise Orientée Services ............................................... 16
2.4.2 Interconnexion de processus via la composition de services d'entreprises ........ 17 2.5 Conclusion .................................................................................................................... 18 Chapitre 3 Modélisation d'entreprise ......................................................................... 19 3.1 Introduction .................................................................................................................. 20 3.2 Les processus métier de l'entreprise ............................................................................ 20 3.3 Modélisation d'entreprise : définitions, concepts et composants ............................... 23
3.3.1 Les différentes vues de la modélisation ............................................................... 23 3.3.2 Constructs de la modélisation .............................................................................. 24
3.4 Panorama des méthodologies de modélisation d'entreprise ...................................... 25 3.4.1 Un exemple de démarche orientée "décisionnel" : GRAI‐GIM ............................ 25 3.4.2 Exemples de démarche orientée Système d'Information : ARIS .......................... 29 3.4.3 Vers un premier cadre intégrateur : CIMOSA ...................................................... 30 3.4.4 PERA : une méthodologie orientée ressources humaines ................................... 33 3.4.5 Une architecture fédératrice : GERAM ................................................................. 35 3.4.6 Vers un langage de modélisation unifié : UEML ................................................... 38 3.4.7 Synthèse des méthodes de modélisation d'entreprise ........................................ 39
3.5 Processus et outils de workflow ................................................................................... 40 3.5.1 Définition d'un workflow ...................................................................................... 40 3.5.2 Système de gestion de workflow ......................................................................... 41
4.2.1 Définition de la SOA .............................................................................................. 44 4.2.2 Les Concepts de la SOA ........................................................................................ 45 4.2.3 Migration vers une Architecture Orientée Services ............................................. 46 4.2.3.1 Les méthodes sont mal acceptées et présentent un manque ......................... 46 4.2.3.2 Démarches de mise en place d'une SOA .......................................................... 47
‐v‐
4.3 Mécanismes d'interconnexion de processus interentreprises .................................... 48 4.3.1 Echange de données informatisées : Electronic Data Interchange ...................... 49 4.3.2 Communication entre processus par envoi de messages .................................... 52 4.3.3 Mécanisme d'interconnexion de processus par échange de services ................. 53 4.3.3.1 Les composants de CORBA ............................................................................... 54 4.3.3.2 Les composants d'EJB ....................................................................................... 54 4.3.3.3 Les Web services .............................................................................................. 55 4.3.3.4 Synthèse des mécanismes d'interconnexion de processus par échange de services 61
4.3.4 Composition de service ........................................................................................ 63 4.3.4.1 Les approches de composition ......................................................................... 63 4.3.4.2 Paramètres non fonctionnels de services ........................................................ 65
5.2.1 Définition de l'Entreprise Orientée Services ........................................................ 69 5.2.2 Positionnement de l'EOS par rapport à l'entreprise traditionnelle ..................... 69
5.3 Présentation des concepts de l'Entreprise Orientée Services ..................................... 70 5.3.1 Architecture de l'Entreprise Orientée Services .................................................... 71 5.3.2 Le méta‐modèle de l'Entreprise Orientée Services .............................................. 72 5.3.2.1 Survol du méta‐modèle de l'EOS ...................................................................... 72
5.3.3 Typologie des services dans l'Entreprise Orientée Services ................................. 75 5.3.3.1 Classification suivant la nature de service ....................................................... 75 5.3.3.2 Classification des services suivant le degré de visibilité .................................. 76 5.3.3.3 Classification suivant le niveau de granularité des services ............................. 77 5.3.3.4 Synthèse de la typologie des services de L'Entreprise Orientée Services ........ 77
5.4 Présentation détaillée des concepts du niveau métier de l'EOS .................................. 78 5.4.1 Les composants métier ........................................................................................ 78 5.4.1.1 Définition du composant métier ...................................................................... 78 5.4.1.2 Méta‐modèle du composant métier ................................................................ 79
5.4.2 Les objets métiers ................................................................................................ 80 5.4.2.1 Définition et présentation de l'objet métier .................................................... 80 5.4.2.2 Anatomie de l'objet métier .............................................................................. 81
5.4.3 Service métier de l'Entreprise Orientée Services ................................................. 82 5.4.3.1 Présentation et caractéristiques générales d'un service métier ...................... 82 5.4.3.2 Modélisation du service métier ....................................................................... 84
5.4.4 Les services Virtuels ............................................................................................. 87 5.4.4.1 Motivation derrière le concept de service virtuel ............................................ 87 5.4.4.2 Présentation du service virtuel ........................................................................ 88 5.4.4.3 Anatomie du service virtuel : un service multi‐facettes .................................. 90
5.5 Présentation détaillée des concepts du niveau informatique de l'EOS ....................... 93 5.5.1 Relation entre les deux niveaux du méta‐modèle de l'EOS ................................. 93 5.5.2 Les services Informatiques ................................................................................... 93 5.5.2.1 Les services applicatifs ..................................................................................... 94 5.5.2.2 Les services d'infrastructure ............................................................................. 95
5.6 Conclusion .................................................................................................................... 95 Chapitre 6 FErOS‐ Framework de définition de l'Entreprise Orientée Services ............. 97 6.1 Introduction.................................................................................................................. 98 6.2 Cycle de vie des services dans l'EOS ............................................................................. 98 6.3 FErOS: Framework de définition de l'Entreprise Orientée Services ............................. 99
6.3.1 Phase 1 : Analyse de l'existant ........................................................................... 101
‐vi‐
6.3.2 Phase 2 : Identification des Services .................................................................. 102 6.3.2.1 Principes de base pour l'identification des services ....................................... 103 6.3.2.2 Identification des composants métier ............................................................ 104 6.3.2.3 Identification des services métier .................................................................. 113 6.3.2.4 Identification des services virtuels ................................................................. 114 6.3.2.5 Identification des services Informatiques ...................................................... 114
6.4 Conclusion .................................................................................................................. 116 Chapitre 7 Construction du processus collaboratif interentreprises .......................... 117 7.1 Introduction ................................................................................................................ 118 7.2 Les paramètres non fonctionnels (PNF) des services ................................................. 118
7.2.1 Les paramètres non fonctionnels et la description des services ........................ 119 7.2.2 Exemple de motivation....................................................................................... 119
7.3 Modèle de services orienté paramètres non fonctionnels ........................................ 120 7.3.1 Les catégories des PNF ....................................................................................... 121 7.3.1.1 Catégorie des paramètres reliés à la QoS ...................................................... 121 7.3.1.2 Catégories des paramètres reliés au contexte ............................................... 122 7.3.1.3 Utilisation d'une ontologie pour la représentation des PNF .......................... 122
7.3.2 Les échelles de mesure pour les propriétés non fonctionnelles ........................ 123 7.4 L'utilisation des politiques pour la modélisation de paramètres non fonctionnels ... 124
7.4.1 Le standard WS‐Policy ........................................................................................ 124 7.4.2 Extension du WS‐Policy pour les paramètres non fonctionnels des services .... 125 7.4.2.1 Les nouveaux composants ajoutés à la spécification du WS‐Policy ............... 126 7.4.2.2 Modèle d'ontologie ........................................................................................ 127
7.4.3 Publication des politiques des paramètres non fonctionnels ............................ 129 7.4.3.1 Extension de l'UDDI pour attacher les politiques de PNF .............................. 129 7.4.3.2 Les communautés des paramètres non fonctionnels .................................... 130 7.4.3.3 L'assistant des politiques des PNF .................................................................. 131
7.5 La construction du processus collaboratif .................................................................. 131 7.5.1 Le schéma du processus collaboratif .................................................................. 132 7.5.2 Framework de découverte et de sélection de service ....................................... 133 7.5.2.1 Le moteur de matching des PNF .................................................................... 135 7.5.2.2 L'évaluation de la compatibilité des politiques .............................................. 136 7.5.2.3 La phase de sélection : calcul de distance, classification et négociation ....... 139
7.6 Évaluation et prototype.............................................................................................. 142 7.6.1 Test et Évaluation de la méthode de sélection de service ................................. 142 7.6.2 Prototype générale pour la construction du processus collaboratif .................. 145 7.6.2.1 Architecture du prototype.............................................................................. 146 7.6.2.2 Technologies utilisées et prise d'écran du le prototype développé ............... 147
7.7 Conclusion .................................................................................................................. 150 Chapitre 8 Conclusion générale et perspectives ........................................................ 153 8.1 Bilan des travaux ........................................................................................................ 153 8.2 Résumé des contributions .......................................................................................... 155 8.3 Perspectives et travaux futurs .................................................................................... 157
‐vii‐
Liste des Figures
Figure 1.1: Organisation et relations des différents chapitres de la thèse ........................................ 3 Figure 2.1: Evolution de l'architecture de l'entreprise (Tewoldeberhan, 2005), page 3 ................... 7 Figure 2.2: Les demandes de changement réduisent l'agilité du système d'information ............... 10 Figure 2.3 : Approche proposée ....................................................................................................... 16 Figure 3.1 : Définition d'un processus .............................................................................................. 22 Figure 3.2 : Décomposition d'un processus ..................................................................................... 22 Figure 3.3 : Définition d'une activité ................................................................................................ 22 Figure 3.4 : Contructs et relation entre constructs (Chen and Vernadat, 2004), page 241 ............. 24 Figure 3.5 : Principaux modèles d'entreprise ou approches de modélisation ................................. 25 Figure 3.6 : Les outils GRAI ............................................................................................................... 26 Figure 3.7 : Méta‐modèle de la grille GRAI (Bennour, 2004), page 23 ............................................ 27 Figure 3.8 : Méta‐modèle du réseau GRAI (Bennour, 2004), page 23 ............................................. 28 Figure 3.9 : L'architecture d'ARIS ..................................................................................................... 29 Figure 3.10 : Méta‐modèle d'ARIS ................................................................................................... 30 Figure 3.11 : Cube CIMOSA .............................................................................................................. 31 Figure 3.12 : Domaines et Processus Maîtres définis dans CIMOSA ................................................ 32 Figure 3.13 : Méta‐modèle de CIMOSA ........................................................................................... 33 Figure 3.14 : Composants des phases de conceptualisation, définition et réalisation .................... 35 Figure 3.15 : Les éléments méthodologiques de GERAM (IFIP‐IFAC, 1999), page 5 ........................ 36 Figure 3.16 : Cycle de vie de GERAM ............................................................................................... 37 Figure 3.17 : Méta‐modèle d'UEML ................................................................................................. 39 Figure 3.18 : Environnement d'exécution de processus .................................................................. 42 Figure 4.1 : Méta‐modèle de l'architecture orientée service .......................................................... 46 Figure 4.2 : Différentes interactions dans l'EDI (Medjahed et al., 2003a), page 63 ........................ 50 Figure 4.3 : Principaux standards du Web service (W3C, 2002b) .................................................... 56 Figure 4.4 : Ontologie OWL‐S ........................................................................................................... 58 Figure 4.5 : Structure d'un message SOAP (Newcomer, 2002), page 83 ......................................... 59 Figure 4.6 : Méta‐modèle de l'UDDI ................................................................................................. 60 Figure 5.1 : Architecture générale de l'Entreprise Orientée Services .............................................. 72 Figure 5.2 : Méta‐modèle de l'Entreprise Orientée Services ........................................................... 73 Figure 5.3 : Typologie des services ................................................................................................... 76 Figure 5.4 : Classification des services de l'EOS selon le niveau de granularité............................... 77 Figure 5.5 : Le composant métier comme il est perçu dans notre travail ....................................... 79 Figure 5.6 : Méta‐modèle du composant métier ............................................................................. 80 Figure 5.7: Objet métier ................................................................................................................... 81 Figure 5.8 : Anatomie d'objet métier et relation entre objet métier .............................................. 82 Figure 5.9 : Méta‐modèle du service métier .................................................................................... 84 Figure 5.10 : Modélisation du service métier: vue métier ............................................................... 85 Figure 5.11 : Modélisation du service métier : vue opérationnelle ................................................. 86 Figure 5.12 : Modèle de performance métier .................................................................................. 87 Figure 5.13 : Service virtuel: Vue opérationnelle ............................................................................. 89 Figure 5.14 : Anatomie du service virtuel : un service multi‐facettes ............................................. 92 Figure 5.15 : Architecture liée à la facette de monitoring du service virtuel (Chaari et al., 2007a), page 526 ........................................................................................................................................... 92 Figure 5.16 : Méta‐modèle de l'EOS partie informatique ................................................................ 94 Figure 5.17: Principe d'encapsulation de l'objet métier par des services applicatifs ...................... 95 Figure 6.1 : Différentes phases du cycle de vie de services ............................................................. 99 Figure 6.2 : Vue générale de FErOS ................................................................................................ 100
‐viii‐
Figure 6.3: Préparation du projet et collecte d'information .......................................................... 101 Figure 6.4 : Démarche d'identification des composants métier .................................................... 105 Figure 6.5 : Détermination des objets métier par la méthode de décomposition spectrale ......... 109 Figure 6.6 : Bonne pratique pour la décomposition d'un diagramme de classe............................ 110 Figure 6.7 : Diagramme d'objet métier d'un processus de commande client ............................... 110 Figure 6.8 : ABOM .......................................................................................................................... 111 Figure 6.9 : BABOM ........................................................................................................................ 112 Figure 6.10 : Composants métier découverts à partir du matrice du groupement ....................... 112 Figure 6.11 : Identification des services métier ............................................................................. 113 Figure 6.12 : Identification des services virtuels ............................................................................ 114 Figure 6.13 : Identification des services informatiques ................................................................. 114 Figure 6.14 : Relation entre service appalicatif, service métier et objet métier ............................ 115 Figure 6.15 : Identification des services applicatifs à partir des activités métier .......................... 115 Figure 6.16 : Relation entre opération des services applicatifs et méthodes de l'objet métier .... 116 Figure 7.1 : Les catégories des paramètres non fonctionnels ........................................................ 123 Figure 7.2 : Forme normale du WS‐Policy ...................................................................................... 125 Figure 7.3 : Le problème de matching entre deux assertions du WS‐Policy .................................. 125 Figure 7.4 : L'ontologie représentant le WS‐Policy ........................................................................ 127 Figure 7.5 : Le modèle d'ontologie ................................................................................................. 128 Figure 7.6 : Exemple de politique représentant un PNF ................................................................ 128 Figure 7.7 : L'enregistrement de la politique non fonctionnelle dans le tModel ........................... 130 Figure 7.8 : Les 6 types de connecteurs ......................................................................................... 133 Figure 7.9 : Exemple de schéma de processus collaboratif............................................................ 133 Figure 7.10 : Framework de découverte et de sélection de services ............................................. 134 Figure 7.11 : L'algorithme du MMP ................................................................................................ 136 Figure 7.12 : Évolution du nombre de services retenus par le moteur de sélection suivant le nombre de paramètre non fonctionnel ......................................................................................... 145 Figure 7.13 : Évolution du temps d'exécution par rapport au nombre de paramètres dans la requête ........................................................................................................................................... 145 Figure 7.14 : Architecture générale du prototype ......................................................................... 146 Figure 7.15 : Interface principale du prototype ............................................................................. 147 Figure 7.16 : Conception du schéma du processus et configuration des Goal Templates ............ 148 Figure 7.17 : Chargement de l'ontologie représentant les différentes catégories des PNF et l'ajout des paramètres non fonctionnels .................................................................................................. 149 Figure 7.18 : La sélection du service correspondant à la description du Goal Template ............... 149 Figure 7.19 : Enregistrement du schéma du processus ................................................................. 150 Figure 7.20 : Prise d'écran de la description du processus générée .............................................. 150
‐ix‐
Liste des tableaux
Tableau 4.1 : Récapitulatif sur l'EDI et l'EDIINT ................................................................................ 52 Tableau 4.2 : Récapitulatif sur le MOM ........................................................................................... 53 Tableau 4.3 : Récapitulatif de l'interconnexion par échange de services ........................................ 62 Tableau 5.1 : récapitulatif des différents services de l'EOS et leurs caractéristiques ...................... 78 Tableau 6.1 : Étapes de l'algorithme ROC ...................................................................................... 111 Tableau 7.1 : Exemples de paramètres non fonctionnels pour les services de transport ............. 120 Tableau 7.2 : Exemple de Web services avec leurs paramètres non fonctionnels ........................ 143 Tableau 7.3 : Vérification de la compatibilité ................................................................................ 144 Tableau 7.4 : Vérification de la compatibilité ................................................................................ 144 Tableau 7.5 : Calcul de distance globale entre service requête ..................................................... 144 Tableau 7.6 : Caractéristique de l'environnement de test ............................................................. 145
1
Chapitre 1 Introduction générale
"The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it
Mark Weiser
1.1 Contexte de travail
Le contexte économique des dernières décennies a été marqué par de multiples mutations qui ne
cessent de remettre en cause les stratégies d'entreprises. En effet, on assiste à une
mondialisation des marchés, à une sévère concurrence en termes de prix, de délai, de qualité et
de flexibilité. De plus, la variabilité importante des demandes des clients et la difficulté de
répondre à leurs besoins avec des coûts de production acceptables ont poussé les entreprises à
revoir en profondeur leurs processus et à devenir plus flexibles et plus agiles. Cette conséquence
qui est aussi le résultat de l'expansion des technologies d'information et de communication et le
raccourcissement du cycle de vie des produits, explique l'effort des entreprises, plus spécialement
les PME à orienter leurs réflexions sur le niveau interentreprises et à tisser des relations de
collaboration et de coopération. Ceci a donné naissance à un nouveau mode de travail
notamment la coopération interentreprises à la demande.
Cette grande dynamicité introduit par le contexte économique actuel exige des différents acteurs,
participant à un scénario de collaboration, une forte capacité d'adaptation et de réactivité. Ces
deux derniers facteurs reflètent la capacité de l'entreprise à interagir d'une manière efficace avec
l'ensemble des acteurs constituant son environnement. Il est indispensable par conséquent que
les entreprises fassent tomber les barrières culturelles, fonctionnelles, organisationnelles et
technologiques pour que l'ensemble des entreprises collaboratives soit perçu comme un tout
homogène et cohérent.
2
Pour répondre à ces exigences, deux préoccupations majeures doivent être prises en compte. La
première consiste à se focaliser sur l'entreprise elle‐même et agir sur son Système d'Information
de manière qu'elle soit plus agile. La deuxième préoccupation prend en considération la
construction du processus collaboratif interentreprises à partir de l'interconnexion des différents
processus d'entreprises.
L'Architecture Orientée Services (SOA) est actuellement présentée comme étant une opportunité
pour répondre à ces types de préoccupations. En effet c'est un style d'architecture qui permet de
garantir une certaine réactivité au sein de l'entreprise que ce soit au niveau métier ou au niveau
Système d'Information. En plus le paradigme d'interconnexion de processus d'entreprise via la
composition de services paraît la meilleure solution pour assurer une collaboration à la demande.
Cependant, malgré l'acceptation, la grande popularité et les avantages de l'Architecture Orientée
Services sur le plan métier et informationnel d'une entreprise, on peut dire qu'elle est encore au
stade rudimentaire en ce qui concerne sa mise en œuvre concrète.
Fort de ce constat, nous nous sommes intéressés dans cette thèse sur la manière d'implanter une
SOA au sein de l'entreprise. Nous avons en premier temps présenté une nouvelle architecture de
l'entreprise que nous avons appelée l'Entreprise Orientée Services (EOS). En second lieu, nous
avons traité le problème de construction de processus collaboratifs via la composition de services.
La démarche de composition que nous avons développée tient compte des paramètres non
fonctionnels qui décrivent les services.
1.2 Organisation du document
Ce mémoire de thèse est organisé de la manière suivante :
Le chapitre 2 présente la problématique que nous avons traitée dans cette thèse. Il commence
par présenter la coopération interentreprises et ce que cette pratique engendre comme
problèmes à l'entreprise. Ce chapitre exposera la solution retenue pour résoudre ces problèmes,
à savoir l'orientation service et se termine par la représentation de nos contributions : (i)
l'Entreprise Orientée Services et (ii) l'approche de composition de services.
Le chapitre 3 est le premier chapitre de l'état de l'art dans lequel nous nous sommes intéressés à
la modélisation de l'entreprise. Durant ce chapitre, nous allons évoquer la notion de processus et
nous présenterons quelques méthodologies de modélisation d'entreprise. Ce chapitre a été
développé dans le but de formuler une idée sur l'entreprise et les différents concepts qui la
constituent. En effet, une partie de notre travail consiste en un travail de réingénierie de
l'entreprise, donc il est indispensable d'avoir une vue générale sur notre sujet de travail ainsi que
les différents éléments qui le composent afin d'être en mesure de bien placer notre contribution
(le concept de service) par rapport à ce qui existe déjà.
Le chapitre 4 est le deuxième chapitre de l'état de l'art. Son but est double. En premier lieu, il
présente l'Architecture Orientée Services (SOA) ainsi que les démarches de mise en œuvre d'une
telle architecture. En second lieu, il expose une revue des différents mécanismes de
3
l'interconnexion des processus avec une attention particulière sur le paradigme d'interconnexion
de processus via la composition de services.
Le chapitre 5 est le premier chapitre de contribution. Il présente le concept de l'Entreprise
Orientée Services et met en exergue les différents éléments qui la constituent à travers le
développement de plusieurs méta‐modèles. Ces derniers présentent les différents concepts
introduits par l'EOS selon plusieurs points de vue et montrent les relations qui existent entre eux.
Le chapitre 6 est consacré à l'exposition des grands traits d'une démarche pour le développement
d'une Entreprise Orientée Services.
Le chapitre 7 présente notre démarche de composition de services dans le but de construction
d'un processus collaboratif interentreprises. Le chapitre s'intéresse particulièrement à
l'introduction des paramètres non fonctionnels dans le processus de sélection des services à
composer.
Ce mémoire de thèse se termine par nos conclusions et nos perspectives qui présenteront le bilan
des différents travaux réalisés dans la thèse, les différentes contributions et les travaux futurs.
La Figure 1.1 résume les différents chapitres présentés ainsi que les relations entre eux.
Figure 1.1: Organisation et relations des différents chapitres de la thèse
4
5
Chapitre 2 Problématique
"To raise new questions, new possibilities, to regard old problems from a new angle, require creative imagination and marks real advance in science."
2.1 Cadre du travail : la coopération interentreprises
La coopération est un concept très employé dans différents domaines et champs d'application.
L'utilisation du concept de la coopération dans le monde des organisations trouve son origine aux
années 1970. Toutefois, il n'existe pas de consensus autour d'une définition exacte de la
coopération. Si on considère son origine étymologique1, on perçoit facilement le sens original,
assez simple, de ce concept : "faire quelque chose conjointement avec quelqu'un". Néanmoins, la
notion de coopération présente une certaine proximité et ressemblances avec d'autres notions.
Une confusion existe toujours avec d'autres notions comme la coordination, la sous‐traitance et
surtout la collaboration. Dans certains cas, la coopération est un cas particulier de la collaboration
et dans d'autre c'est le contraire.
Nous rejoignons dans notre travail l'avis de ((Benali, 2005), pp. 13) : "Travailler ensemble par le
biais de la coopération, de la collaboration ou de tout autre moyen, signifie se mettre en groupe et
former une organisation particulière à court, moyen ou long terme. Cette organisation facilitera
les échanges et la circulation des flux de tout genre, accroîtra la synergie, et permettra d'instaurer
un climat de confiance entre les partenaires".
Le plus important c'est que la coopération est désormais un véritable enjeu pour les entreprises. Elle est devenue une source de valeur ajoutée et constitue dans certains cas un avantage concurrentiel et un défi dans le fonctionnement des entreprises. Dans le reste du rapport, les mots collaboration et coopération seront considérés comme synonymes.
2.1.1 La coopération interentreprises : Motivations et conséquences
Le contexte économique actuel est fortement évolutif, et les entreprises font face à une
concurrence exacerbée et à des marchés saturés. Les entreprises doivent améliorer leur
productivité, leur rentabilité et détenir une grande souplesse face aux exigences du marché tout
en restant à la pointe dans leurs secteurs de compétences. En outre, les clients deviennent de
plus en plus exigeants envers les produits et les services offerts par les entreprises impliquant
ainsi un "time‐to‐market" plus court, une réduction des coûts et une grande personnalisation.
Face à tous ces nouveaux enjeux, la coopération interentreprises est devenue un impératif
économique indispensable pour la survie de l'entreprise (Cullen, 2000). Dans la majorité des cas,
une entreprise seule ne possède pas les compétences nécessaires, les ressources ainsi que les
connaissances suffisantes pour la réalisation de tels produits et à la satisfaction des demandes des
clients (Cullen, 2000, Pal and Lim, 2005, Yusuf et al., 2004). Par conséquent, les entreprises ont vu
l'importance de se focaliser sur leur cœur métier et d'externaliser les tâches secondaires à des
partenaires, pour pallier ce manque de compétences et de ressources pour la réalisation de leurs
objectifs et la satisfaction de leurs clients.
Face à ces pressions, les acteurs de cette nouvelle économie se sont mis à réfléchir sur leur
manière de travailler et d'organiser le travail. Les structures traditionnelles des entreprises ont
1 http://www.cnrtl.fr/etymologie/coopérer
7
été mises en cause et de nouvelles formes organisationnelles sont sollicitées (Detrie, 2005). On a
assisté ainsi à des changements radicaux dans l'organisation de l'entreprise, sa façon d'opérer et
surtout dans ses relations avec l'extérieur. Dans ce mouvement, les architectures traditionnelles
verticales et horizontales des entreprises ont été abandonnées donnant lieu à de nouvelles
formes organisationnelles appelées les réseaux métiers ou les réseaux d'entreprises (Hakansson
and Ford, 2002) (voir Figure 2.1).
Figure 2.1: Evolution de l'architecture de l'entreprise (Tewoldeberhan, 2005), page 3
Ces nouvelles formes organisationnelles mettent en relation plusieurs acteurs. Elles impliquent le
fournisseur, le distributeur jusqu'au consommateur final. Elles se sont multipliées ces dernières
années dans le but de répondre aux changements perpétuels dans le marché et aux contraintes
imposées par l'environnement de travail des entreprises. Dans ce nouvel écosystème, les
entreprises se sont mises à adhérer de plus en plus à des scénarios de coopération. Leurs
compétitivités se mesurent aujourd'hui par leurs capacités à coopérer avec d'autres entreprises :
"Les entreprises qui l'emporteront seront celles qui sauront fonder durablement leur avantage
concurrentiel sur la meilleure conjonction des intelligences, des savoirs et des compétences
qu'elles agrègent, pour créer sans cesse une valeur ajoutée qui fasse la différence" (Serieyx, 2000)
((Benali, 2005), pp. 15).
Par ailleurs, ce mouvement de réorganisation des entreprises vers des réseaux métier a trouvé
son essor grâce à l'évolution des Nouvelles Technologies de l'Information et de la Communication
(NTIC) et leur démocratisation. Il a permis aux personnes et aux entreprises de pouvoir
communiquer et échanger de grandes quantités de données presque instantanément,
indépendamment des distances. De plus, la prolifération des technologies de l'Internet ainsi que
le faible coût de la communication à travers le Web a rendu la coopération via le Web à la portée
de tout le monde. De ce fait, des espaces coopératifs dans lesquels les entreprises travaillent et
réagissent ensemble ont émergé sous diverses formes : entreprise virtuelle, réseau d'entreprises,
entreprise réseau, etc. Ce qui nous intéresse le plus dans ce travail est le concept de l'entreprise
virtuelle notamment les entreprises à la demande (Camarinah‐Matos et al., 1998, Crawford et al.,
2005, Sayah and Zhang, 2005) : "Une entreprise virtuelle à la demande est un regroupement
temporaire de partenaires distribués dans l'espace, dans le temps et dans les organisations. Son
objectif est de mettre en commun des compétences et des ressources appartenant aux différentes
organisations physiques pour la réalisation d'un certain nombre d'activités coopératives (projets,
échanges commerciaux, etc.) suite à une opportunité saisie dans le marché. Les entreprises
virtuelles bénéficient du faible coût et de la vitesse des communications via Internet pour
8
minimiser (voire éviter) les déplacements des partenaires, réduire les coûts et raccourcir les délais
de réalisation des projets".
Un tel scénario implique la collaboration de différentes parties au sein d'un processus collaboratif
composé à partir de plusieurs processus exécutés par les différents partenaires dans le but de
répondre à un but commun ou saisir une opportunité dans le marché. On parle de processus
coopératif (collaboratif) ou processus interentreprises.
2.1.2 Le processus interentreprises
La coopération interentreprises se traduit par la formation de processus interentreprises construit
à partir de l'interconnexion de divers processus d'entreprise. Cette interconnexion n'est pas
arbitraire et ne se fait pas d'une manière ad‐hoc. Au contraire, elle doit être faite selon des
contraintes et suivant des règles de construction bien précises.
L'interconnexion de processus conduit à un nouveau modèle de processus qui représente un
nouveau processus métier. Elle consiste à instaurer une synergie entre les différents processus
participant dans le scénario de coopération. Cette synergie est obtenue en créant une
harmonisation et un agrément entre ces processus, de manière que les processus métier, issus de
diverses sources et exposés selon des technologies particulières, puissent adhérer ensemble dans
un macro‐processus ou processus interentreprises. On définit un processus interentreprises de la
manière suivante : Un processus interentreprises est un processus métier complexe qui implique
plusieurs entreprises. A l'opposé des processus traditionnels (intra‐entreprise), où les activités font
partie de la même entreprise, le processus interentreprises est le résultat de la coordination de
plusieurs activités issues de plusieurs entreprises. Ces différentes activités échangent des
informations et des services entre elles.
Cependant la formation de tels processus interentreprises impose plusieurs contraintes et
problèmes sur les entreprises et surtout leurs Systèmes d'Information. Dans la section suivante,
nous allons détailler ces différentes contraintes et problèmes afin de bien situer notre
contribution dans ce travail de thèse.
2.2 La Coopération interentreprises : Problèmes
Nous avons préalablement motivé les besoins de l'établissement d'une coopération
interentreprises. La coopération est en fait un choix stratégique que toutes les entreprises doivent
prendre en compte. Néanmoins, une telle direction n'est pas facile à entreprendre. En effet, les
entreprises ne sont pas prêtes pour adhérer à des scénarios de coopération malgré le grand
progrès dans les technologies de l'information qui se sont adaptées peu à peu. Une évolution
nécessaire était en suspens : donner à l'entreprise l'agilité nécessaire pour évoluer dans un
environnement économique et concurrentiel en perpétuel changement (Cao and Dowlatshahi,
2005, Giachetti et al., 2003, Sharifi and Zhang, 2000, Yusuf et al., 2003).
Nous avons classé les problèmes qui existent en deux parties. La première concerne les
problèmes liés au Système d'Information (SI) de l'entreprise et la deuxième concerne les
9
problèmes liés directement à l'interconnexion de processus interentreprises en tant que pratique
(comment et avec quelle manière on va interconnecter les processus d'entreprises ?).
2.2.1 Problèmes liés au Système d'Information de l'entreprise
2.2.1.1 Le manque d'agilité
L'agilité de l'entreprise est un paradigme émergeant qui considère la capacité de l'entreprise à
agir et à répondre aux changements d'une manière dynamique et efficace comme des éléments
clés pour la survie de l'entreprise dans un environnement instable et imprévisible (McCoy and
Plummer, 2006, Overby et al., 2005). L'agilité est souvent considérée comme un des éléments clés
pour la survie de l'entreprise dans un environnement en perpétuel changement. Cet
environnement est caractérisé principalement par l'augmentation de la concurrence sur des
aspects multiples, simultanés et potentiellement contradictoires. Parmi ces aspects on peut noter
la diversité, la quantité, les coûts, les délais, la qualité, et les services (Everaere and Perrier, 1999,
Pal and Lim, 2005, Sarkis, 2001). L'agilité de l'entreprise se répercute directement sur son Système
d'Information (SI) qui doit être agile :
supporter les demandes de modifications et
s'aligner avec les nouveaux besoins de l'entreprise.
Le SI représente l'épine dorsale de l'entreprise. Il est responsable de l'exécution de ses processus
métier. Il est directement impacté par le contexte actuel des entreprises et se trouve au cœur de
ces nouvelles exigences qui caractérisent l'environnement actuel de l'entreprise. Les métiers lui
demandent d'être extrêmement réactif pour aider à mettre sur le marché de nouvelles offres et
être capable de répondre et de s'adapter facilement à des demandes d'adhésion dans des réseaux
de coopération (Overby et al., 2006).
Cependant, le SI de l'entreprise est souvent perçu comme résistant aux changements. En effet, il
souffre dans la majorité des cas d'un manque d'agilité et d'efficacité (Gallagher and Worrell, 2007,
Overby et al., 2006, Tallon, 2007). Le manque d'agilité se traduit par le fait que les entreprises
n'arrivent pas à projeter rapidement les exigences métier sur leur SI ce qui limite leur temps de
réponse. Quant à l'inefficacité, elle résulte du coût élevé de la réalisation des modifications sur le
SI qui dépassent dans certains cas les bénéfices attendus de ces modifications.
En effet, en examinant un SI typique d'une entreprise, on se rend compte qu'il présente au début
une phase initiale d'agilité (Figure 2.2). Durant cette phase, les demandes de changements sont
accomplies d'une manière relativement rapide et efficace. Cependant, après un certain seuil, la
capacité du SI à accueillir de nouveaux changements et implémentations devient très limitée et la
maintenance du système devient une tâche extrêmement difficile et coûteuse.
10
Figure 2.2: Les demandes de changement réduisent l'agilité du système d'information au cours du temps (Krafzig et al., 2004), page 2
Ce manque d'agilité s'explique par le fait que le SI de l'entreprise montre un empilement des
fonctions au fil du temps ce qui conduit à une situation intenable de "silos étanches" (Fournier‐
Morel et al., 2006). L'absence de solution architecturale efficace pour résoudre ce problème a
plongé les SI dans une situation de blocage vis‐à‐vis des nouvelles exigences des métiers. Chaque
silo est généralement autonome et isolé en termes de processus, d'interface homme‐machine et
de support technique. Dans ce contexte, les communications inter‐applicatives sont souvent
gérées au cas par cas, par des liens un à un en fonction des besoins : c'est le fameux syndrome du
"plat de spaghettis" (Fournier‐Morel et al., 2006).
2.2.1.2 Problème concernant l'ouverture du SI à l'extérieur
Les SI ont été conçus, d'une part, pour fonctionner dans un environnement relativement stable où
les changements dans le contexte de l'entreprise sont cernés et peu fréquents et d'autre part,
leurs missions ne concevaient pas la possibilité d'une éventuelle collaboration et ouverture sur
l'extérieur.
Les SI de l'entreprise sont à l'origine conçus pour fonctionner dans un environnement fermé où
les frontières sont bien déterminées. L'interaction avec l'extérieur est strictement régie par les
formes d'échanges d'informations qui doivent êtres fixées et prévues a priori. Par contre, dans le
contexte de la coopération interentreprises, les SI impliqués doivent être conçus pour être prêts à
collaborer au sens large, c'est‐à‐dire inter opérer dans un processus coopératif.
Pour ces différentes raisons, les entreprises doivent avoir une réflexion profonde concernant leurs
SI, sur lesquels, elles doivent procéder nécessairement à une mise à niveau et une rénovation. Un
tel projet nous amène à penser et à trouver des solutions aux questions suivantes :
Comment rendre le SI de l'entreprise plus agile et réactif à n'importe quels changements
au niveau métier ?
11
Comment ouvrir son SI et permettre aux SI hétérogènes de communiquer facilement ?
Comment atteindre les objectifs métiers sans endommager l'entreprise ?
2.2.2 Les problèmes liés à l'interconnexion de processus
La mise en place d'un processus coopératif commence par le choix des partenaires. Une étape
initiale pour toute entreprise avant l'ouverture de leur organisation est la définition de ce qu'elle
peut offrir aux éventuels partenaires. Les entreprises peuvent proposer leurs ressources ou les
résultats de leurs processus métiers comme offres. Par suite, en plus de la description de ces
offres, les entreprises doivent spécifier les contraintes, les conditions et les moyens nécessaires
qui en définissent l'accès. Ces informations vont être utiles surtout dans la phase de découverte
et de sélection des partenaires. Bien évidemment, les offres des entreprises ne correspondent pas
dans la majorité des cas aux besoins recherchés ce qui implique par conséquent une étape de
négociation et de discussion de contrat entre les éventuels partenaires.
Plusieurs problèmes peuvent être identifiés dans le cas d'une coopération entre deux ou plusieurs
partenaires. D'une part, bien que toute entreprise soit consciente du grand besoin de coopérer,
réaliser des projets communs et s'ouvrir à l'extérieur, chacune souhaite malgré tout conserver son
autonomie. D'autre part, le fait que le processus interentreprises soit une composition de
plusieurs processus privés appartenant aux différents participants, on se trouve dans l'obligation
d'apporter un niveau d'abstraction suffisant pour les décrire sans que le savoir‐faire des
entreprises ne soit divulgué aux partenaires. En effet, c'est le dilemme de ce genre de projet qui
consiste à mettre en partenariat, sur une durée limitée, des entreprises qui sont concurrentes le
reste du temps et qui hésitent à partager des données et des activités. De plus, ces entreprises
sont hostiles au moindre changement dans leurs processus respectifs. La seule chose qui les
intéresse, c'est d'avoir un support, mais en aucun cas un processus ou des règles qui les obligent à
modifier leur propre manière de procéder.
Un autre problème clairement identifié concerne l'ouverture des systèmes de l'entreprise d'une
façon générale. A cause de leur potentielle concurrence, leur modèle de coopération doit prendre
en compte les aspects de confidentialité des processus. Les entreprises doivent donc faire une
distinction entre informations/processus privés et informations/processus partagés. Pour cette
raison, chacun des partenaires essaie de ne dévoiler que le minimum nécessaire d'information
concernant la réalisation des activités au sein de son entreprise. En même temps, la coordination
des partenaires exige des informations pour l'avancement de leur travail. On a donc besoin d'un
niveau d'abstraction suffisant pour représenter les propositions des partenaires et leurs
réalisations sans donner accès aux informations privées. Même au niveau des processus de
coopération, le besoin de confidentialité des partenaires exige également une vue restreinte.
Chacun des partenaires ne devra recevoir que les informations sur le déroulement des activités
auxquelles il participe, mais il n'a souvent pas de vue globale sur tout le processus.
L'interconnexion de processus interentreprises doit ainsi gérer le besoin de différentes vues.
Une troisième contrainte très importante est que la coopération doit être dynamique. Notre
cadre de travail ne concerne pas la coopération planifiée dans laquelle les partenaires sont déjà
12
connus et l'interconnexion de processus est assurée par le développement de simples passerelles
entre les processus. Le type de coopération que nous envisageons est une coopération à la volée
ou à la demande. Elle est caractérisée par des partenaires qui ne sont pas connus à l'avance et un
but de coopération à satisfaire qui n'est pas défini à l'avance. Il s'avère donc très difficile, même
impossible, de décrire des scénarios de coopération qui définissent à priori toutes les possibilités
d'interactions entre les processus d'entreprises. Pour cette raison, ces dernières doivent assurer
ce besoin de dynamicité. Elles doivent être équipées de mécanismes spécifiques leurs permettant
de sélectionner dynamiquement leurs partenaires et modifier aussi dynamiquement leurs offres
afin d'être en mesure de participer à des scénarios de coopérations à la demande.
Enfin, les entreprises passent souvent beaucoup de temps à sélectionner et identifier leurs
partenaires stratégiques. L'étape de sélection est en réalité une étape très importante dans le
cycle de vie d'une coopération interentreprises. Des partenaires potentiels peuvent être éliminés
pour deux raisons : d'une part ils ont mal décrit leurs offres et d'autre part le processus de
sélection n'a pas pu dégager la compatibilité de la demande et de l'offre. De ce fait,
l'interconnexion de processus doit passer essentiellement à travers une meilleure description des
offres et avoir les outils nécessaires pour identifier la compatibilité demande/offre.
2.3 L'orientation Service
Pour résoudre les problèmes évoqués ci‐dessus, une réingénierie de l'entreprise semble être très
importante. Le challenge actuel est de construire un SI d'entreprise capable à la fois d'assurer
l'agilité de l'entreprise et de favoriser et faciliter l'interconnexion des processus d'entreprises.
Comme réponse à ce challenge, Nous avons décidé de réorganiser l'entreprise selon une
Architecture Orientée Services (SOA). Le concept de service peut apporter une solution aux
différents problèmes évoqués précédemment. De nos jours, le concept de service a le vent en
poupe et il est largement répondu et utilisé dans différents domaines et champs d'application.
Nous avons fondé cet avis en se basant sur trois constatations principales. En premier lieu, l'idée
d'un système (applications ou composants), qui offre des services au profit de ses utilisateurs ou
d'autres systèmes est en plein expansion dans le monde du "software engineering" (Cervantes
and Hall, 2005, Zhou and Niemela, 2005). En second lieu, le concept de service attire de plus en
plus l'attention dans beaucoup d'autres disciplines. En effet, le développement économique est
de plus en plus axé sur les services, non seulement dans les entreprises de services
traditionnelles, mais aussi dans les entreprises manufacturières et les prestataires publics de
services. On parle souvent de l'économie de service (Bitner and Brown, 2008, Spohrer et al., 2007)
dans laquelle les entreprises offrent leurs produits sous forme de services. Finalement, le concept
de service joue un rôle primordial dans la gestion des services informatiques (service IT ou
technique) (Steen et al., 2005). Cette discipline vise à améliorer la qualité des services IT et la
synchronisation de ces services avec les besoins de leurs utilisateurs.
Ces trois derniers constats, dans lesquels le concept de service joue un rôle capital, en plus de la
grande prolifération de l'Architecture Orientée Services (SOA) et des Web services nous laissent
13
penser que les services peuvent jouer un rôle plus important dans la future architecture de
l'entreprise.
2.3.1 Le concept de service
Il est nécessaire de présenter une définition précise et claire de concept de service possédant une
signification et un sens dans le domaine métier et le domaine technique. Pour une définition
assez générique, nous nous sommes référés aux propositions de (Vissers and Logrippo, 1986) et
(Quartel et al., 1997) dans lesquelles un service est défini comme "le comportement observable
d'un système (le fournisseur de service). Il est décrit en termes des interactions qui puissent
survenir au niveau de ses interfaces entre le système et son environnement " ((Steen et al., 2005),
pp. 139). Le terme système est utilisé au sens large impliquant à la fois les applications et les
unités organisationnelles. Une définition plus détaillée sera donnée dans les chapitres suivants.
Le concept de service est le résultat de la séparation entre le comportement externe et interne. Il
doit présenter une autonomie (indépendance) au niveau de ses fonctionnalités et doit posséder
un objectif clair et précis qui le différencie des autres services. Le comportement interne du
service représente la tâche que ce service est censé établir. De point de vue consommateur de
service, le comportement interne d'un système ou d'une organisation n'est pas important à
connaître. Ce qui compte le plus est la fonctionnalité ainsi que la qualité de service qui vont être
fournies.
2.3.2 Pertinence et bénéfices de l'orientation service
Interopérabilité
L'interopérabilité entre deux composants ou deux applications d'un même système hétérogène
distribué ou deux systèmes différents est définie comme étant l'aptitude de ces applications ou
de ces composants à échanger entre eux des données et des fonctionnalités (Vernadat, 2007a,
Wegner, 1996). Dans cette orientation, l'approche service favorise l'interopérabilité entre les
systèmes. En effet, les Web services (le plus important standard utilisé dans l'implémentation de
services) et leur pile de standards basés sur XML sont annoncés comme un vrai support
d'interopérabilité au niveau technologique (Jardim‐Goncalves et al., 2006). Toutefois, l'orientation
service favorise également l'interopérabilité à un niveau sémantique élevé. En effet, elle minimise
les exigences d'une compréhension partagée entre le fournisseur et le consommateur de service.
Une description de service ainsi qu'un protocole de collaboration et de négociation seront les
seules exigences pour instaurer une compréhension partagée.
Agilité
Il est important de souligner que l'agilité au niveau métier peut être atteinte selon deux
manières : d'une part, l'aptitude à modifier les processus métier afin de répondre aux
changements du marché et des clients tout en réduisant les coûts, et d'autre part, l'aptitude à
exécuter ou créer rapidement de nouveaux processus métier. La rapidité et la capacité d'une
entreprise à accélérer ses réponses aux changements du marché ou d'anticiper des opportunités
14
sont sans doute un grand avantage. La rapidité concerne à la fois la rapidité d'une action métier et
la rapidité de la réponse des composants du Système d'Information correspondants à cette action
métier. L'amélioration de la rapidité exige parfois l'installation ou le développement de nouveaux
systèmes à la volée. Cependant le cycle de développement de logiciel est assez lent pour
permettre au métier de répondre dans les bons délais aux exigences du marché ce qui influe
négativement sur l'agilité de l'entreprise.
L'approche service garantit l'agilité de l'entreprise (Schroth, 2007, Uram and Bill, 2005, Vernadat,
2007b, Zhao et al., 2007). Elle permet d'assurer la rapidité nécessaire via la réutilisation des
composants déjà développés en interne ou en externe de l'entreprise. Elle accélère le cycle de
développement pour la réalisation et le déploiement de nouvelles applications contribuant à leurs
tours dans l'accélération du temps de réponse de l'entreprise aux changements dans son
environnement. En effet, l'approche service permet la mise en œuvre de nouveaux processus
métiers à partir des services qui peuvent devenir à leur tour de nouveaux services consommables
par de futurs processus métiers. En outre, l'agilité de l'entreprise se manifeste à travers la
substitution d'un service par un autre en cas d'échec d'exécution ou encore en cas de non
adéquation avec les orientations stratégiques de l'entreprise. De plus, l'approche service offre la
possibilité de changer un fournisseur de service par un autre en fonction des paramètres de coût
et de qualité et afin de répondre aux besoins du marché.
En somme, l'approche service permet à l'entreprise d'acquérir une certaine agilité en lui offrant la
possibilité de répondre aux besoins du marché et de participer à de nouvelles opportunités.
Alignement SI/ besoins métier
La mise en place d'une approche orientée service au sein de l'entreprise permet de garantir
l'alignement du SI sur les besoins métier de l'entreprise. En effet, le point de départ de l'approche
service doit être les processus métier de l'entreprise. Elle doit remettre la logique métier au cœur
des fonctionnalités du SI. Les services sont mieux perçus par les responsables de processus. C'est
une démarche qui favorise l'implication des métiers dans la construction du SI. Par la suite,
l'ambition de l'approche service est de construire et d'organiser le SI à partir des réalités métiers,
qui doivent se retrouver dans ses constituants.
La mise en place d'une approche service doit être pensée en termes de besoin métiers et pas en
termes de besoins techniques. De ce fait la construction du Système d'Information de l'entreprise
doit se baser sur la problématique métier qu'elle tend à résoudre (ou sur le(s) service(s) qu'elle
essaie de rendre).
Réduction des coûts
L'approche service garantit la réduction des coûts grâce à la réutilisation des services. Par la suite,
le cycle de développements est raccourci : le développement de composants de services
réutilisables focalise sur la construction de nouveaux services par combinaison de services
existants. Ceci permet de réduire en retour les coûts de développement de nouveaux systèmes.
15
L'approche service : une interconnexion de processus plus facile et plus efficace
Le concept de "publication de service" permet d'intégrer plus fortement les partenaires, les
clients et les sous‐traitants dans la chaîne de valeur de l'entreprise, en ouvrant le SI de manière
sécurisée. La SOA offre, en plus des mécanismes élémentaires d'interconnexion (échange de
message, contrat de service), de nouvelles fonctionnalités assurant un haut niveau
d'interconnexion et de coopération des processus interentreprises. La coopération selon ce type
d'architecture se base sur les paradigmes de composition. Grâce à leur intégration, les services
permettent de construire des systèmes à la volée. De plus, les services permettent de réduire la
complexité des systèmes en encapsulant les détails d'implantation des services qui les
composent. Un service, fourni par une entreprise, pourrait spécifier la quantité de travail qu'une
entreprise promet de réaliser sous un contrat de coopération (Georgakopoulos et al., 1999,
Klingemann et al., 1999, Casati et al., 2000, Grefen et al., 2000). Après validation des contrats de
coopération, les services sont composés ensemble pour former le processus interentreprises.
2.4 Approche proposée et objectif
Notre objectif dans cette thèse est d'assurer l'interconnexion des processus d'entreprise afin
d'aboutir à un processus de coopération porteur de valeur ajoutée. Cependant, il s'est avéré que
l'état actuel de l'entreprise présente un handicap. En effet, le manque d'agilité au niveau de son
Système d'Information freine souvent l'aptitude de l'entreprise à participer à des scénarios de
coopération. Notre point de départ sera par conséquent une phase de réingénierie de
l'entreprise. Cette étape vise à réorganiser et à restructurer l'entreprise de manière qu'elle soit
plus agile et que nous puissions garantir un alignement entre le niveau SI, d'une part, et les
besoins métier de l'entreprise d'autre part. Nous nous sommes basés sur l'Architecture Orientée
services (SOA) pour atteindre cet objectif.
Pour atteindre la vision de la SOA, il faut penser à la manière avec laquelle les exigences métier
peuvent être éventuellement transférées et projetées sur le SI. Nous avons choisi comme point de
départ les processus métier de l'entreprise. Ces derniers serviront comme le contexte métier
nécessaire pour le développement de service afin d'aboutir concrètement à une entreprise axée
sur l'Architecture Orientée Services. Dans cette direction, le niveau métier de l'entreprise sera
perçu comme un ensemble de processus métier (des séquences d'activité ordonnées
partiellement et synchrones) et de services métier (des activités ou ensemble d'activité en ligne et
asynchrones). Le service métier est un ensemble de fonctionnalités offert par un fournisseur de
service (une unité organisationnelle par exemple) qui présente une valeur ajoutée. Il peut être
invoqué à l'intérieur ou à l'extérieur de l'entreprise. Sa différence majeure avec une activité
métier ordinaire de l'entreprise est qu'une activité ne peut fonctionner qu'au sein d'un processus
métier; par contre un service métier peut être invoqué tout seul comme il peut être sollicité au
sein d'un autre processus métier. Les services métier vont agir comme une couche d'abstraction
entre le niveau métier et le niveau informatique de l'entreprise qui, à son tour, sera transformé
en un ensemble de service informatique. Cette restructuration de l'entreprise va aboutir à une
16
nouvelle architecture d'entreprise plus agile que nous avons appelée l'Entreprise Orientée
Services (EOS).
Une fois ce but atteint, l'interconnexion de processus sera assimilée à un problème de
composition de services d'entreprise qui seront publiés dans des registres publics. Les services
d'entreprise (ceux qui sont publiables) seront décrits de manière à favoriser une collaboration
dynamique et à la demande. Pour cette raison, nous avons donné une grande importance aux
paramètres non fonctionnels dans la description des services et le Framework de construction de
processus collaboratif que nous avons développé tient compte de ce genre de paramètre.
La Figure 2.3 représente l'approche que nous allons suivre pour atteindre notre objectif :
l'interconnexion des processus d'entreprises ainsi que la phase qui est en amont, à savoir la
reconstruction et la réingénierie de l'entreprise.
Figure 2.3 : Approche proposée
2.4.1 Réorganiser l'entreprise selon l'orientation service : l'EOS
2.4.1.1 L'Entreprise Orientée Services
L'Entreprise Orientée Services (EOS) est une reconstruction du Système d'Information de
l'entreprise. Elle a été conçue de manière à apporter une séparation de préoccupation entre
niveau "métier" et niveau "informatique" du Système d'Information. Dans cette optique,
l'Entreprise Orientée Services est considérée comme une juxtaposition de deux modèles : une
SOA métier pour le niveau métier et une SOA informatique pour le niveau informatique. L'EOS
définit différents types de services allant des services appartenant au niveau métier (les services
métier et les services virtuels) jusqu'à des services informatiques (les services applicatifs et les
services d'infrastructure). Notre architecture est basée aussi sur le concept d'objet métier qui joue
un rôle très important dans notre architecture de l'Entreprise Orientée Services.
2.4.1.2 Construction de l'Entreprise Orientée Services
Construire une Architecture Orientée Services à l'échelle d'une entreprise est une tâche difficile et
risquée à la fois. Bien que les principes sont connus, il n'y a pas encore d'approche
17
méthodologique unifiée permettant de construire une Architecture Orientée Service d'une façon
efficace. Déployer une SOA ne se ramène pas simplement à empaqueter des entités logicielles
existant au sein de l'entreprise sous forme de blocs fonctionnels munis des interfaces adéquates
pour pouvoir interagir avec eux. En revanche, un tel déploiement nécessite la mise en œuvre de
démarches efficaces afin d'assurer l'identification, la modélisation et la spécification des services.
Dans cette direction, nous avons présenté les grands traits d'une démarche de construction d'une
Entreprise Orientée Services.
2.4.2 Interconnexion de processus via la composition de services d'entreprises
L'Entreprise Orientée Services est perçue comme un ensemble de services dont certains seront
exposés pour être utilisés par des acteurs externes à l'entreprise. Par conséquent, l'entreprise
pourra ainsi participer à des scénarios de coopération en intégrant ses services dans des
processus de coopération interentreprises. C'est le paradigme d'interconnexion de processus par
la composition de services. Concrètement, il existe plusieurs manières de compositions de
services ; nous avons opté dans ce travail à une composition semi‐automatique dans laquelle le
processus de coopération sera spécifié manuellement tandis que la phase de recherche sera faite
d'une manière automatique.
Cette façon d'interconnecter les processus d'entreprise à travers la composition de services
comprend des phases en amont très importantes qui sont : la description de services, la
publication et finalement la découverte et la sélection de services.
Description et publication de services
La première phase dans le processus de composition de service est la phase de publication. En
effet, pour décrire ses compétences, ses capacités et les faire communiquer aux différentes
entreprises, celles‐ci doivent être en mesure de munir leurs propres services d'une description
adéquate. Dans la majorité des cas, cette description des services se base essentiellement sur la
présentation des paramètres fonctionnels. Cependant, en vu d'une collaboration dynamique et à
la demande, nous devons tenir compte, de plus, des critères de sélection plus pragmatiques qui
prennent en considération les paramètres non fonctionnels des services. Plus spécifiquement,
dans notre cadre d'interconnexion de processus, les services publiés par l'entreprise seront munis
d'une description de leurs paramètres contextuels et des paramètres de qualité de services. Pour
atteindre cet objectif, nous avons utilisé le WS‐Policy auquel nous avons ajouté des annotations
sémantiques en utilisant des ontologies pour pouvoir décrire les paramètres contextuels et les
politiques de services. Ces nouvelles descriptions seront ajoutées au niveau du registre de service
afin d'être pris en considération dans la phase de recherche de service.
Découverte et sélection de services
La phase de découverte et de sélection de service commence par la spécification de la requête de
sélection suite à laquelle les services seront identifiés. Comme il a été déjà mentionné, nous
allons utiliser une approche de composition semi‐automatique. Le premier point dans cette
direction est la définition du processus abstrait qui représentera le schéma du processus de
18
coopération et l'ensemble de contraintes relié à ce processus. Le schéma de processus est un
ensemble de Templates qui représentent, d'une manière abstraite, les descriptions des services à
sélectionner. La sélection de service se base sur des algorithmes de matching et de calcul de
distances pour déterminer la compatibilité des services avec les contraintes de la collaboration.
2.5 Conclusion
Dans le but de bien cerner notre problématique de travail dans cette thèse ; nous avons dû
procéder en plusieurs étapes. En premier lieu, nous nous sommes concentrés sur les principaux
enjeux qui caractérisent l'environnement actuel des entreprises. Ceci nous a permis de constater
qu'en quête de compétitivité, ces dernières doivent êtres agiles, flexibles et doivent s'approprier
une stratégie de collaboration afin de se concentrer sur leur cœur de métier et déléguer les
tâches secondaires de leurs processus à des partenaires. En second lieu, nous avons présenté les
freins qui existent dans l'architecture actuelle des entreprises et qui peuvent les empêchent
d'être agiles et adhérer à des scénarios de collaboration. Par la suite, nous avons proposé la
notion de service et détaillé les apports que peut apporter une Architecture Orientée Services sur
le plan "agilité de l'entreprise" et sur le plan de "la coopération interentreprises". Forts de ces
constats, nous avons proposé comme solution à notre problème d'adopter l'orientation service.
En fin, nous avons développé l'objectif de la thèse en exposant notre approche de construction de
services au sein de l'entreprise et de la coopération interentreprises via la composition de
services.
19
Chapitre 3 Modélisation d'entreprise
"He who loves practice without theory is like the sailor who boards ship without a rudder and compass and never knows where he may cast."
GRAI a fait l'objet de plusieurs extensions ce qui a donné naissance à la méthodologie GIM (GRAI
Integrated Methodology) vers les années 90. GIM reprend les vues de modélisation
informationnelle, fonctionnelle et décisionnelle et intègre les méthodologies suivantes afin de
représenter ces différentes vues :
Vue informationnelle : les formalismes MERISE (entité‐relation),
Vue fonctionnelle et physique : la méthodologie IDEF0/SADT,
Vue décisionnelle : la grille et le réseau GRAI.
En somme, la spécificité de GRAI et de GIM est la mise en évidence des aspects décisionnels au
côté des aspects fonctionnels, physiques (le métier), informationnels et processus. Ces points
spécifiques, ne font pas partie de notre problématique initiale et ne correspondent pas à notre
objectif.
Objectif Variable de décision Critère
Indicateur de performance
Règle
Ressource
Information
Opérateur logique
Entité complexe
1
1
1
1
Activité
Entitén
1
n
1
1..n
0..n1
1
0..1
0..n
1
résultat 1
1..n
support
0..n
evénement
0..1
0..n
Activité décisionnelle Activité operationnelle
29
3.4.2 Exemples de démarche orientée Système d'Information : ARIS
ARIS (ARchitecture for integrated Information Systems) est à la fois un cadre de modélisation
générique et un outil de modélisation des processus d'entreprise (Scheer, 1993, Scheer, 2002,
Scheer et al., 1994). Elle se focalise surtout sur l'ingénierie des logiciels et sur les aspects
organisationnels pour conception des systèmes intégrés au sein de l'entreprise. Le cadre de
modélisation ARIS (voir Figure 3.9) est bâti sur une approche multi‐niveaux et multi‐vues. Elle est
structurée en quatre vues (fonction, données, organisation et contrôle) et trois niveaux de
modélisation (modèle conceptuel, modèle technique et implémentation).
Figure 3.9 : L'architecture d'ARIS
Le méta‐modèle d'ARIS est présenté dans la Figure 3.10.
30
Figure 3.10 : Méta‐modèle d'ARIS
3.4.3 Vers un premier cadre intégrateur : CIMOSA
Présentation de CIMOSA
CIMOSA (Computer Integrated Manufacturing Open System Architecture) (AMICE, 1989, AMICE,
1993, Vernadat, 1993, Vlietstra, 1993) est une architecture pour la construction des systèmes
intégrés de production. CIMOSA a été développée par le Consortium AMICE dans le cadre du
projet ESPRIT. Cette architecture comprend un cadre de modélisation, une infrastructure
d'intégration et un langage de modélisation (AMICE, 1993, Vernadat, 1993).
Le cadre de modélisation de CIMOSA, connu sous le nom du cube CIMOSA (Figure 3.11), présente
une structure à trois axes qui se base sur trois principes fondamentaux (Vernadat, 1999):
1. L'axe d'instanciation qui se compose de trois différents niveaux : le premier niveau étant
le niveau générique dans lequel il s'agit de définir les constructs du langage de
modélisation, le deuxième niveau correspond au niveau partiel qui contient des modèles
partiels, c'est‐à‐dire des structures prédéfinies et réutilisables pour un domaine
d'application particulier, et finalement le niveau particulier qui correspond aux modèles
spécifiques de l'entreprise.
Ressource machine
Hardware
nn
n nn n
alloué
Sortie humainennn
alloué
n
Structure organisationnelle
Application logicielle
Output
n
nn
n
nn
But communn
nnn
Fonction
n
n
n
n
execute
n
n
n
n
Input
n
n
n
n
Output
n
n
n
n
supporte
n
n
n
n
Unité Organisationneln
n
n
nalloué
n
n
n
n
responsableModèle donnée
Medium donnée
Objet information
n nn ndéclenchen nn n
sortie donnéen nn n
entrée donnée
n nn nest créé
n
n
n
n
privilège acces
n
n
n
n
n
n
n
n
n
n contrôle
n
n
Structure output
31
2. L'axe de dérivation qui sert à modéliser l'objet d'étude selon trois niveaux de modélisation : le niveau de définition des besoins permettant d'exprimer les besoins précis de l'entreprise, le niveau des spécifications de conception qui consiste à spécifier et analyser des solutions répondant aux besoins exprimés (analyse conceptuelle, conception du système d'information, évaluation des performances, choix de ressources) et finalement le niveau de description de l'implantation qui permet de construire des modèles exécutables.
3. L'axe de génération ou l'axe de vue qui consiste à modéliser selon quatre vues
essentielles :
la vue fonction, utilisée pour décrire le comportement ainsi que la fonctionnalité
d'une entreprise en termes d'opérations, d'activités et de processus.
la vue information, utilisée pour décrire les objets de l'entreprise, les différentes
relations entre eux ainsi que leurs états possibles, en d'autres termes, quels sont
les objets traités et comment ils sont gérés ?
la vue des ressources, utilisée pour décrire les moyens nécessaires à mettre en
œuvre pour la réalisation des fonctions de l'entreprise. Elle montre aussi les rôles
des ressources ainsi que leur mode de gestion, c'est‐à‐dire qui fait quoi, quand et
comment.
la vue organisation sert à la description des autorités et des responsabilités
intervenant dans les prises de décision, c'est‐à‐dire qui est responsable de quoi ?
Figure 3.11 : Cube CIMOSA
Vision de la modélisation d'entreprise selon CIMOSA
CIMOSA considère l'entreprise comme un ensemble de domaine (Kosanke et al., 1999). Chaque
domaine présente des objectifs et des contraintes particuliers. Les fonctionnalités globales et le
comportement d'un domaine sont représentés comme étant des processus maîtres (Domain
32
Process: DP). Ces processus maîtres sont déclenchés grâces à des événements et échangent entre
eux des vues d'objets.
Les processus maîtres sont composés d'activité d'entreprise (Enterprise Activity : EA) et de
processus métiers (Business Process : BP) qui sont aussi, à leur tour, composés d'activités
d'entreprise. Les activités d'entreprises sont exécutées par un ensemble de règles procédurales
formant un réseau d'activités. Les activités d'entreprise utilisent et créent des objets d'entreprise
(objets physiques ou entités d'information) définis dans le modèle comme des vues d'objets
(Object Views).
De cette manière, un processus maître de CIMOSA correspond à un réseau d'activités d'entreprise
inter‐reliées ainsi qu'un ensemble de trois flux (Figure 3.12) :
Flux de contrôle composé des événements et des règles procédurales (connecteurs ET,
OU, XOR)
Flux informationnel sous forme de diagrammes de flux de données, en considérant les
vues d'objets informationnelles (objets de nature information).
Flux matière qui considère les vues d'objets physiques (objets de nature matérielle).
Figure 3.12 : Domaines et Processus Maîtres définis dans CIMOSA Méta‐modèle de CIMOSA
L'ensemble de concepts ainsi que les relations entre les concepts qui sont définis par CIMOSA
sont représentés dans le méta‐modèle suivant (Figure 3.13):
33
Figure 3.13 : Méta‐modèle de CIMOSA
3.4.4 PERA : une méthodologie orientée ressources humaines
PERA (Purdue Enterprise Reference Architecture) (Li and Williams, 1997, Williams, 1994, Williams
and Li, 1997) est une méthodologie complète d'ingénierie des environnements industriels
développée par le Prof. Williams, à l'université de Purdue (USA). La finalité de l'approche PERA est
de décrire en détail toutes les phases du cycle de vie d'un système depuis les besoins initiaux
jusqu'à sa mise en opération. Par rapport à CIMOSA qui définit quatre vues : fonctionnelle,
ressources, informationnelle, et organisationnelle, PERA tient compte seulement deux vues à
savoir la vue fonctionnelle et la vue d'implémentation. La vue fonctionnelle comporte deux
architectures à savoir : une architecture fonctionnelle d'information et une architecture
fonctionnelle de production. Quant à la vue d'implémentation, elle suit la vue fonctionnelle et elle
comporte à son tour une architecture d'information et une autre de production.
La Figure 3.14 illustre l'architecture de la méthodologie organisée en cinq phases :
Relation DomaineDomaine
Autorité
Cellule Organisationnelle
Processus Métier
Vue Objet
Schéma Externe
Activité
Ressource
Opération Fonctionnelle
Capacité
Processus Domaine
Evènementnn
lié par
nn
n
1
décrit par
n
1
n
n
emploien
n
exige
n
n
exige n
n
n n
utilise
n n
n
n
emploie
n
n1..n
1
fournit
1..n
1
n1
demande
n1
1..n1..n
n
n
emploie
n
n
1..n
n
déclenche
1..n
n 0..1
1déclenche
0..1
1
Responsabilité
Profil compétenceObjet Entreprise
n
n
n
n
dérivé de
Entité fonctionnelle
1..n
1
1..n
1
possède
nn nn
exécutée par
1
1
1
1
fournit
Unité Organisationnelle
1..n
1
1..n
1possède
nn
1..n
1
1..n
1
1..n
1
1..n
1possède1..n
1
1..n
1
à autorité sur
associé à
34
Phase de conceptualisation : cette phase englobe une étape d'identification suivie d'une étape de
concepts. L'étape d'identification sert à identifier l'entité de l'entreprise à modéliser (système
industriel, atelier, usine…). L'étape de concepts permet de définir la mission de la direction
concernant l'entité à modéliser en termes de politiques : de produits, du système opérationnel,
de gestion du personnel et de la production. Ces ensembles d'information sont nécessaires pour
la définition des besoins.
Phase de définition : c'est une phase d'analyse fonctionnelle qui permet de définir deux types de
besoins : les besoins de gestion (gestion de la production, des informations...) et les besoins de
production (opérations de fabrication). Cette phase permet également de définir les tâches, les
modules ainsi que les diagrammes de flux ou autres modèles de l'entité.
Phase de conception : cette phase se déroule en deux étapes majeures : une étape de
spécification (ou de conception fonctionnelle) et une étape de conception détaillée. L'étape de
spécification permet de spécifier les architectures d'information et de production ainsi que les
choix initiaux relatifs à l'architecture humaine et organisationnelle.
L'étape de conception détaillée complète l'étape de spécification et permet de traduire les
architectures fonctionnelles déjà identifiées en architectures d'implantation.
Phase d'installation et de construction : cette phase permet la mise en place d'une implantation
effective (équipements, machines, systèmes informatiques, etc.) conformément aux modèles
définis dans la phase de conception.
Phase de mise en œuvre et de maintenance : cette phase permet l'utilisation effective de
l'installation et la prise en compte de certaines opérations de maintenance qui peuvent apparaître
au cours de la vie du système en question.
35
Figure 3.14 : Composants des phases de conceptualisation, définition et réalisation (Vernadat, 1996), page 57
3.4.5 Une architecture fédératrice : GERAM
Il existe plusieurs méthodes de modélisation d'entreprise. Chacune d'elle apporte une spécificité
particulière et essaie d'atteindre un objectif précis. On ne peut pas dire, en aucun cas, que l'une
soit meilleure que l'autre car elles sont adaptées à des contextes différents. Cette caractéristique
représente la limite de chacune des méthodes vue précédemment. En effet, aucune méthode ne
traite l'entreprise en sa totalité. Plutôt, chacune d'elle essaie de cibler une vue partielle et
particulière de l'entreprise. L'idée de créer un cadre fédérateur à toutes ces méthodes est très
importante. Ceci permettra d'appréhender l'entreprise dans sa globalité en se basant sur les
points de vue de chacune des méthodes. La meilleure solution est de lier et rassembler les
différentes méthodes de modélisation existantes dans un cadre de modélisation générique qui
36
satisfera la grande diversité des objectifs rencontrés dans la modélisation de l'entreprise. C'est le
rôle de GERAM.
GERAM (Generalized Enterprise Reference Architecture and Methodology) (Bernus and Nemes,
1997, IFIP‐IFAC, 1999) est une architecture de référence développée au sein du groupe IFAC/IFIP2.
GERAM est considérée comme une architecture en cours de développement résultant de la
synthèse des concepts de trois principales approches : CIMOSA, GIM et PERA. Elle définit un
ensemble de concepts pour modéliser n'importe quel type d'entreprise durant toutes les étapes
de sa vie. La Figure 3.15 montre le cadre général proposé par GERAM. Dans ce qui suit, nous
allons décrire en détail les différents éléments méthodologiques composant le cadre de GERAM.
Figure 3.15 : Les éléments méthodologiques de GERAM (IFIP‐IFAC, 1999), page 5
GERAM distingue les méthodologies pour la modélisation d'entreprise (EEMs) et les langages de
modélisation (EMLs) qui sont employés par ces méthodologies :
2 IFAC/IFIP Task Force on Architecture for Enterprise Integration
37
Les EEMs (Enterprise Engineering Methodology) décrivent le processus de l'ingénierie
d'entreprise. Pour chaque type d'activité du changement, elles décrivent des chemins
d'évolution, identifient les tâches ainsi que les outils permettant ce changement.
Les EMLs (Enterprise Modelling Languages) définissent des concepts (constructs) capables
de modéliser à la fois la partie humaine de l'activité de l'entreprise, les processus métier
et leurs technologies de support associées. Les constructs définissent les objets qui seront
utilisés dans les vues définies dans GERA.
Les langages et les méthodologies sont supportés par les outils de modélisation d'entreprise
(Enterprise Engineering Tools, EETs). Ces derniers permettent de gérer la création, l'utilisation et
la gestion des modèles d'entreprise. La sémantique des langages de modélisation est assurée
grâce à Generic Enterprise Modelling Concepts (GEMCs). Ces derniers définissent trois formes de
concepts génériques : les glossaires (utilisés pour la terminologie des modèles), les méta‐modèles
(décrivent les concepts utilisés) et les ontologies (introduites pour formaliser les concepts
utilisés).
La démarche de modélisation proposée par GERAM produit :
Les modèles d'entreprise (Enterprise Models, EMs) représentent l'ensemble des activités
de l'entreprise, son organisation et sa gestion ainsi que ses systèmes de pilotage et
d'information. Ils contiennent des descriptions, des conceptions ainsi que les modèles
formels de l'entreprise. Ces modèles sont utilisés pour guider l'implémentation du
système opérationnel de l'entreprise (Particular Enterprise Operational Systems, EOS).
Les modèles partiels (Partial Entreprise Model, PEMs) représentent les modèles
réutilisables par exemple pour les rôles, les processus ou les technologies.
Les modules d'entreprise (Enterprise Modules, EMOs) représentent les composants
matériels ou logiciels nécessaires pour l'implémentation du système opérationnel.
Chaque entité de GERAM possède un cycle de vie. Le cycle de vie proposé comporte sept phases
(Figure 3.16) :
Figure 3.16 : Cycle de vie de GERAM
38
Phase d'identification du contenu : il s'agit de l'ensemble des activités qui identifient une entité
particulière. Ces activités considèrent les limites de l'entité en question ainsi que ses relations
avec son environnement.
Phase de définition des concepts de l'entité : il s'agit des activités indispensables pour
développer les concepts relatifs à l'entité en question. Ces concepts englobent la mission de
l'entité, ses politiques, ses objectifs, ses concepts opérationnels, etc.
Phase de définition des besoins : il s'agit des activités nécessaires pour définir les besoins
opérationnels de l'entité, ses processus ainsi que tous ses besoins fonctionnels,
comportementaux, et informationnels. Cette définition comprend à la fois le service, les
exigences de fabrication, de gestion et de contrôle de l'entité.
Phase de conception : il s'agit des activités définissant les spécifications de l'entité. Ces activités
englobent aussi la conception de toutes les tâches humaines (tâches des individus et des entités
organisationnelles) et de toutes les tâches machine.
Phase d'implémentation : il s'agit des activités qui définissent les tâches nécessaires pour
construire ou reconstruire l'entité.
Phase de fonctionnement de l'entité : il s'agit de l'ensemble des activités nécessaires au bon
fonctionnement de l'entité tout au long de son existence.
Phase de démantèlement et recyclage de l'entité : il s'agit des activités nécessaires pour recycler,
réaffecter ou dissoudre un composant ou une entité tout entière en fin de sa vie.
3.4.6 Vers un langage de modélisation unifié : UEML
La grande diversité des langages de modélisation d'entreprise disponibles crée des difficultés
pour les utilisateurs. Ces derniers se trouvent parfois incapables de les comprendre et par la suite
de choisir le plus pertinent tenant compte du contexte d'utilisation. Par conséquent, le besoin
est fort pour développement d'un langage unifié. Ce constat motive le langage UEML dont l'idée
maîtresse consiste à combiner différents langages de base afin de créer plusieurs vues du même
modèle (par exemple CIMOSA, GRAI/GIM, ARIS, …). Une réflexion s'est engagée depuis un certain
temps et qui est en cours de réalisation concernant un processus de rapprochement entre ces
approches en vue de leur unification en un langage unique. Ce processus a donné naissance au
méta‐modèle d'UEML et de son ontologie associée (Figure 3.17). Une telle approche combinée
bénéficie des avantages de chaque langage de base et offre, par la suite, au modélisateur les
moyens de représenter de manière plus précise et plus complète ses besoins tenant compte des
objectifs de son modèle. Pour atteindre cette finalité, deux démarches étaient envisageables. La
première, descendante, s'appuie sur une analyse conceptuelle du domaine et des besoins pour
aboutir à un langage commun. En revanche, la seconde, ascendante, se base sur les langages de
modélisation d'entreprise existants pour définir une méthode de représentation unifiée autour
d'un langage pivot. Étant plus pragmatique et rapide que la première, la démarche ascendante a
été retenue lors de la définition de UEML (UEML, 2002, Vernadat, 2002).
39
En pratique, UEML propose un consensus à la communauté scientifique au niveau de la
terminologie et bien évidement au niveau des structures conceptuelles qui peuvent être
employées pour représenter une entreprise.
Il est important de souligner qu'UEML est bâti sur la compréhension de la modélisation
d'entreprise et tient compte d'un ensemble de principes (Vernadat, 2002):
1. Le langage doit proposer un ensemble fini d'éléments de modélisation,
2. La distinction entre les processus et les ressources,
3. La distinction entre le comportement et les fonctionnalités de l'entreprise : cette
séparation tient au fait que les fonctionnalités renseignent sur ce qui peut être fait, tandis
que le comportement renseigne sur comment le faire. Ainsi, une modélisation séparée
pour doit être réalisée donnant au modèle une plus grande flexibilité,
4. La distinction entre les ressources et les unités organisationnelles : il s'agit de séparer les
unités organisationnelles, comme étant des unités décisionnelles, des ressources
considérées comme responsables à l'exécution des décisions.
Figure 3.17 : Méta‐modèle d'UEML
3.4.7 Synthèse des méthodes de modélisation d'entreprise
Les méthodes de modélisation d'entreprise sont très variées. Elles différent les unes par rapport
aux autres suivant leurs champs de compétences et les vues qu'elles traitent dans la modélisation
Qualification
Capacité
Activité
Produit Ordre
Application Humain Machine
Rôle
1..n
1..n
1..n
1..n
nécessite
1..n 1..n1..n 1..n
1..n
1..n
1..n
1..n
Ressource1..n 1..n1..n
utilise
1..n
Processus
1..n
1
1..n
1
comprend
1
1..n
1
1..nEvénement
1..nn 1..nn
déclenche
Unité Organisationnel
1..n 11..n 1
a autorité surObjet Entreprise
n nn n
entrée/sortie0..1
n
0..1
n
associé à
1..n
11
a autorité sur
1..n
40
d'entreprise. Parmi les méthodes présentées, il y en a celles qui se focalisent le plus sur un aspect
particulier, comme le cas d'ARIS par exemple pour les Systèmes d'Information. D'autres méthodes
permettent de modéliser l'entreprise de manière plus globale comme le cas de GRAI et de
CIMOSA par exemple qui prend en considération plusieurs vues de l'entreprise.
D'après notre analyse de ces différentes méthodes, nous pouvons affirmer que GRAI/GIM et PERA
sont loin de notre problématique dans cette thèse. ARIS nous a donné une vue d'ensemble sur le
Système d'Information.
Quant à CIMOSA, elle a présenté un point de départ pour connaître les différents concepts qui
constituent l'entreprise. L'idée de processus de domaine évoqué dans CIMOSA nous a semblé très
intéressante et un premier pas pour la restructuration de l'entreprise. UEML, comme CIMOSA,
nous a permis de connaître les différents constructs qui peuvent exister dans une entreprise en
plus des relations qui puissent exister entre eux.
En prenant en considération le principe de l'agilité de l'entreprise, le besoin est fort pour des
approches de modélisation et de gestion de processus différentes de celles qui sont présentées
précédemment. En effet, les processus métier sont formés d'un ensemble d'activités définies avec
une grande précision et une forte intégration entre elles. Toutes demandes de modification aux
niveaux données et règles de gestion, nécessitera une refonte du processus entraînant coûts,
délais, et surtout manque de réactivité et risque de déstabilisation du fonctionnement de
l'entreprise. En revanche, les processus, qu'ils soient internes ou qu'ils participent dans des
scénarios de coopération, peuvent être le sujet de plusieurs demandes de changement. Ils
doivent, par conséquent, être modélisés selon une logique de couplage faible entre les différents
modules qui les constituent pour permettre une simple reconfiguration des processus quand les
fonctions métiers évoluent ou changent.
Une modélisation faiblement couplée des processus se base sur une approche de modularisation
dans laquelle les modules peuvent être ajoutés, modifiés ou même retirés avec un impact
minimal sur l'ensemble de processus. Par conséquent, la modélisation de processus doit apporter
de nouveaux constructs et principes afin d'atteindre un certain niveau d'agilité. En effet,
modéliser le niveau métier de l'entreprise, moyennant des processus, des activités et des
événements, ne résoudra pas seul le problème. De nouveaux modules vont être intégrés dans la
modélisation de processus pour assurer le couplage faible dans les processus. Cette orientation
ne va, en aucun cas fausser l'orientation processus au sein de l'entreprise. Plutôt, elle se base sur
l'orientation processus et elle l'améliore pour une quête d'agilité largement recherchée.
3.5 Processus et outils de workflow
3.5.1 Définition d'un workflow
Une fois les processus métier sont modélisés, analysés et évalués, quelques‐uns seront
automatisés dans le but d'améliorer l'efficacité de l'entreprise. Un processus métier qui va être
41
automatisé doit être spécifié et implémenté sous forme de workflow. Le WFMC3 définit le
workflow comme l'automatisation de tout ou partie d'un processus d'entreprise, au sein duquel
les participants échangent des informations en vu de réaliser une action tout en tenant compte
d'un ensemble de règles de gestion (WFMC, 1999).
En d'autres termes, un workflow est représenté comme un ensemble semi ordonné de tâches qui
sont placées sous la responsabilité d'un acteur particulier. Ces tâches sont exécutées de manière
séquentielle ou parallèle afin d'atteindre des objectifs initiaux. Un workflow peut gérer à la fois
plusieurs processus et a pour finalité de gérer le partage des ressources, et donc les flux
d'information.
3.5.2 Système de gestion de workflow
Les systèmes de Gestion des Workflows (SGWf) sont des systèmes logiciels qui permettent la
modélisation, l'exécution, l'enregistrement et le contrôle des flux de travail.
Le modèle du processus, appelé également définition de workflow, se base sur la représentation
explicite de sa logique d'exécution ce qui permet le support informatique. Il définit les tâches, les
participants et les échanges qui vont avoir lieu entre eux.
Les outils de workflow considèrent que chaque tâche sera accomplie par un participant. Du point
de vue du système, un participant avec la qualification nécessaire va sélectionner ou se verra
attribuer une tâche, exécutera le travail nécessaire et rendra le résultat attendu.
Généralement, les systèmes de gestion des workflows disposent de moyens graphiques pour la
modélisation et le suivi de l'évolution du travail. C'est un des points forts de ces outils car il
permet leur utilisation par un large spectre d'utilisateurs. De plus, la représentation du niveau
d'avancement de l'exécution du processus aide à la formation de la conscience de groupe. Par
contre, tous les participants ont une vue complète sur le processus et les données qu'il manipule,
ce qui est contraire aux besoins de confidentialité qui exige des vues restreintes.
Pour exécuter un processus, le système de gestion des workflows crée une instance de processus
à partir de son modèle (Figure 3.18). Un modèle peut être instancié plusieurs fois et plusieurs
instances peuvent être exécutées en même temps. Le système de gestion des workflows gère
l'ordre d'exécution des activités (flux de contrôle) et le transfert des données entre tâches (flux de
données). Grâce à la formalisation, il dirige le travail en utilisant des règles strictes et claires. Il
gère automatiquement les flux de données entre tâches, mais seulement après une modélisation
Dans le chapitre précédent, nous avons présenté l'Entreprise Orientée Services (EOS) et les méta‐
modèles qui s'apparentent avec les différents services qui y existent. Nous avons appliqué le style
de l'Architecture Orientée Services aux différents niveaux du Système d'Information de
l'entreprise. Le résultat est un ensemble de services de différentes catégories.
L'EOS distingue quatre catégories de services. Les deux premières sont les services du niveau
métier dans lequel nous avons défini les services métier (exposés par les composants métier de
l'entreprise) et les services virtuels (composition de service métier). Les deux dernières catégories
caractérisent le niveau informatique de l'entreprise dans lequel les services applicatifs et les
services d'infrastructures sont orchestrés par les services du niveau supérieur (le niveau métier).
L'Entreprise Orientée Services s'articule autour du concept du service métier et toutes les autres
entités de l'entreprise sont situées par rapport à ce concept. Dans ce sens, une mise en place
d'une EOS doit se focaliser sur ce concept et déployer tous les moyens nécessaires pour réussir
une identification et une définition des services métier. De ce fait, développer une Architecture
Orientée Services à l'échelle de l'entreprise s'avère une tâche complexe, qui nécessite plus qu'un
simple empaquetage des applications existantes avec le développement des interfaces
adéquates. En effet, la complexité de la mise en place d'une EOS dépasse de loin la complexité de
développement d'une simple SOA au niveau informatique de l'entreprise. Ce ne sont pas les
mêmes contraintes de définition de service ni les mêmes objectifs. Pour maîtriser cette
complexité, la mise en place d'une démarche peut se révéler nécessaire.
Dans ce chapitre, nous allons essayer de présenter notre démarche de mise en place d'une
Entreprise Orientée Services. A l'encontre des démarches existantes qui traitent la SOA du point
de vue technique, la démarche que nous avons développée met en exergue la notion de service
métier et présente ce concept comme étant le centre de gravité de toute l'architecture de l'EOS.
Tous les concepts identifiés dans cette dernière sont mis en relation par rapport à ce concept.
Notre démarche est de type "meet in the middle" qui consiste à étudier les processus métier de
l'entreprise, le patrimoine applicatif et faire une étape de croisement entre les deux études. Notre
travail rejoint le principe de l'urbanisation fonctionnelle de point de vue découpage du Systèmes
d'Information sauf que notre découpage est orienté service grâce à l'utilisation des objets métier.
Le but de ce chapitre est de présenter le Framework FErOS dans lequel nous exposons notre
démarche de mise en place de l'EOS. Nous allons commencer par représenter le cycle de vie des
services de l'entreprise. Ensuite, le Framework FErOS sera exposé et toutes ses phases seront
détaillées.
6.2 Cycle de vie des services dans l'EOS
L'Entreprise Orientée Service est une conglomération de services de différents types. Son cycle de
vie dépend essentiellement du cycle de vie des services qu'elle contient. Dans la littérature,
plusieurs auteurs ont proposé d'étudier le cycle de vie des services (Arsanjani, 2004, Chang and
Kim, 2007, Erl, 2005, Papazoglou and Heuvel, 2006). En fonction de la vision poursuivie, chacun
99
propose un ensemble d'étapes. Dans le cadre de nos travaux, nous proposons un cycle de vie des
services qui comporte cinq phases (Figure 6.1) :
1. La phase d'analyse de l'existant qui se préoccupe de la cartographie de l'architecture
d'entreprise (existante et cible aussi),
2. La phase d'identification des services qui se base sur les cartographies déjà élaborées
pour identifier les services d'entreprise (services métier, services virtuels et services
informatiques),
3. La phase de définition des services qui se concentre sur la spécification des services
(modèles de données, interfaces, etc). Cette phase est indispensable pour la phase
suivante qui est la phase de réalisation,
4. La phase de réalisation propose de développer les services et de les déployer pour être
invoqués,
5. La phase de test et de supervision des services est à la charge de la maîtrise d'œuvre qui
veille à tester les services une fois réalisés.
Figure 6.1 : Différentes phases du cycle de vie de services
6.3 FErOS: Framework de définition de l'Entreprise Orientée Services
L'objectif du Framework FErOS est de fournir une démarche pour l'analyse, l'identification et la
définition des services au sein d'une entreprise selon les spécifications apportées par l'Entreprise
Orientée Services. Il est important de mentionner que notre approche dans FErOS est
principalement itérative et incrémentale : l'identification d'un livrable dans une phase permet
l'identification d'une activité qui, par ailleurs, utilise d'autres entités pour produire un résultat.
Ces dernières sont produites par d'autres activités et ainsi de suite.
Le Framework FErOS est constitué de trois étapes différentes qui traitent les deux premières
phases du cycle de vie de service que nous avons mentionné dans la section précédente. La Figure
6.2 présente une vue d'ensemble de FErOS.
100
Figure 6.2 : Vue générale de FErOS
101
Dans la suite de cette section, nous allons présenter en détail chacune de ces différentes phases.
6.3.1 Phase 1 : Analyse de l'existant
Dans le but de découvrir les services convenables, ceux qui auront une signification pour le
métier, il faut commencer par analyser et modéliser les besoins de l'entreprise. Cela peut paraître
évident, mais généralement c'est trop souvent oublié. On ne peut pas avoir une génération
spontanée de services et en plus, Il est inutile de traiter d'emblée la question concernant la
catégorie et la granularité des services si l'on ne modélise pas les besoins. Cette modélisation n'a
rien à voir avec la démarche SOA. Néanmoins, elle devra garantir, dans une seconde étape, la
découverte des services adéquats.
Dans cette direction, la première phase du Framework FErOS (Figure 6.3) est de nature
exploratrice qui souligne l'importance du projet d'implantation d'une Architecture Orientée
Services au sein de l'entreprise. La réalisation de ce projet est longue, fastidieuse et nécessite
l'implication des experts métier aussi bien que des experts techniques. La première phase
comporte trois sous‐phases :
L'analyse et la modélisation des processus métier existants (As‐Is) et cibles (To‐be),
L'analyse des applications existantes,
La mise en correspondance (mapping) entre les processus métier cibles et les applications
existantes.
Figure 6.3: Préparation du projet et collecte d'information
La première sous‐phase consiste à analyser les processus métier afin de définir les services
nécessaires à leurs réalisations. L'analyse des processus métier existant "As‐Is" fournit une
description générale des métiers de l'entreprise indispensable dans le cadre d'une démarche Top‐
Down. Guidée par la migration vers une architecture SOA, cette sous‐phase propose notamment
la révision des stratégies et des objectifs métier. Par conséquent, elle consiste à conduire une
analyse critique de l'existant et à construire, par la suite, les processus métier en cohérence avec
la stratégie de l'entreprise. Nous appelons ces processus les processus métier cibles.
102
L'alignement des processus métier sur la stratégie d'entreprise passe, d'une part par la
compréhension de la stratégie de l'entreprise et d'autre part, par l'analyse des processus existants
et la définition des processus cibles qui sont alignés sur la stratégie de l'entreprise. Par la suite, les
analystes métier identifieront les processus métier qui devraient exister dans l'entreprise et
procèdent à leur modélisation. Cette première sous‐phase s'avère importante dans le sens où elle
permet d'obtenir une évaluation des processus métier existant et détermine les processus métier
cibles.
La deuxième sous‐phase permet de cartographier les applications développées au sein de
l'entreprise. En effet, l'entreprise a accumulé au fil du temps un patrimoine applicatif
considérable. Applications sur mesure, logiciels standard, voire solutions de type Web plus
récentes. Cet acquis applicatif contribue à divers degrés au capital stratégique et tactique de
l'entreprise. Il s'agit d'analyser ces applications afin de déterminer les fonctionnalités qui sont
utilisées pour implémenter les processus métier. De plus, l'analyse des applications permet de les
documenter en spécifiant pour chacune d'entre elles la technologie utilisée, ses interfaces avec
d'autres entités ou applications. Une telle analyse combine à la fois les techniques tels que les
interviews, les questionnaires des experts IT de l'entreprise (développeurs, responsables IT, etc.)
et les outils d'assistance pour l'analyse des applications (comme par exemple IBM Asset Analyzer
et Websphere). Ces derniers permettent de créer des méta‐données pour chaque application
existante. Ces méta‐données peuvent être combinées avec les questionnaires et permettent,
ainsi, d'obtenir une cartographie détaillée des applications de l'entreprise.
La troisième sous‐phase récupère les résultats produits par les deux précédentes. La mise en
correspondance (ou le mapping) entre les processus métier et les applications existantes permet
de montrer quelles applications ou, précisément, quelles fonctionnalités contenues dans une
application implémentent quels processus métier. Ceci permet ainsi de mettre en évidence la
relation entre la vue métier et la vue informatique de l'entreprise. Par conséquent, il est possible
de savoir quelle application peut donner naissance à un ensemble de services informatiques,
quelle application peut être qualifiée d'obsolète et aussi quel processus métier (ou activités du
processus en question) ne lui correspond aucune application et à besoin d'être automatisé.
En sommes, la première phase du Framework FErOS poursuit plusieurs objectifs et réalise un
ensemble de livrables. Elle permet de disposer des cartographies du patrimoine applicatif existant
et des processus de l'entreprise afin d'acquérir une vision globale et transversale du SI. A partir de
ces cartographies, les dirigeants disposent d'une connaissance formalisée et partagée des
processus métiers, de l'architecture applicative et technique, nécessaires pour analyser et
construire une Architecture Orientée Services alignée sur les enjeux métiers et les objectifs de
l'entreprise. Cet acquis est considéré comme le support permanent à la réflexion pour tout le
reste des phases du Framework FErOS.
6.3.2 Phase 2 : Identification des Services
La deuxième phase du Framework FErOS se base sur les livrables de la phase précédente
(cartographie des processus métier existants et cibles, cartographie des applications et la mise en
103
correspondance entre les processus et les applications) afin de définir les services d'entreprise.
Comme nous l'avons déjà souligné, nous identifions deux types de services : des services qui
existent au niveau métier de l'entreprise et des services informatiques.
Cette phase de FErOS propose de mener deux démarches de construction de la SOA : SOA métier
et SOA informatique au sein de l'entreprise. Elle intègre trois sous‐phases fondamentales :
l'identification des différents composants métier,
l'identification des services du niveau métier de l'entreprise à savoir les services métier et
les services virtuels,
l'identification des services informatique responsables de l'implémentation des services
du niveau métier.
6.3.2.1 Principes de base pour l'identification des services
L'identification des services au sein d'une entreprise doit tenir compte de deux principes
fondamentaux à savoir : une cohésion forte dans un service et un couplage faible entre les
services. Ceci est dans le but de minimiser l'interdépendance entre les services, limiter l'impact de
changement et maximiser la réutilisation des services.
La cohésion de service adresse le degré de relation fonctionnelle et sémantique qui existe entre
les opérations accomplies par un service. Une forte cohésion d'un service implique que ce dernier
représente une abstraction unique de façon à ce que les opérations qu'il expose sont fortement
reliées entre elles. Plusieurs directives peuvent guider le concepteur pour avoir un service cohésif
tel que, par exemple : les opérations doivent utiliser les mêmes entrées et les mêmes sorties. Le
principe de cohésion est important pour garantir la clarté et la qualité de la conception des
services. Souvent ce principe simplifie en retour les efforts de maintenances et d'améliorations
futures.
Le couplage de service se réfère au degré de relation entre les services. En d'autres termes, il
désigne l'impact de changement d'un service sur le reste des services existants. Un couplage
faible entre les services peut être assuré en réduisant le nombre de connexions et de
dépendances entre les services. En plus, le couplage faible de services doit se répercuter aussi sur
les interfaces de services. Ces dernières doivent être définies de manière à ce qu'elles soient
indépendantes avec l'implémentation de service.
Un autre point important lors de l'identification des services au niveau métier concerne les
interfaces des services. Ces dernières doivent être exprimées en termes d'opérations métiers qui
possèdent un sens plutôt que des interfaces assez génériques ou de fines granularités comme par
exemple les CRUD (Create, Read, Update, Delete).
Au‐delà du respect des principes de cohésion et de couplage, on introduit une autre contrainte
qui est la contrainte de granularité des services. La granularité de service est considérée comme
une contrainte fondamentale dans la démarche de construction des services. La granularité d'un
service se rapporte à la taille de service et l'ensemble des fonctionnalités (opérations de service)
104
qu'il expose ainsi que leurs portées. La granularité de service peut être évaluée, d'une part suivant
le nombre de services utilisés suite à un appel d'opération de service à travers une interface et
d'autre part suivant le nombre de ressources manipulées.
L'utilité des services de fine granularité est limitée vis‐à‐vis des processus métier. Quant aux
services de granularité moyenne, ils peuvent offrir une utilité rudimentaire. En revanche, les
services de fortes granularités sont plus intéressants pour les gens métier puisqu'ils satisfont des
besoins métier. Toutefois, dans le cas où le service posséderait un niveau de granularité très
élevé, le nombre de messages échangés sera très grand et parfois on sera amené à traiter des
données inutiles. En outre, les interfaces seront plus complexes et leur gestion sera plus difficile.
Il n'existe pas une théorie et une méthode précises pour la définition exacte du niveau de
granularité de service. Cependant, nous avons fixé quelques directives qui peuvent guider dans le
choix du niveau de granularité convenable pour un service :
La réutilisation : les services doivent être assez génériques de manière à ce qu'ils puissent
être réutilisés dans plusieurs scénarios. Augmenter la réutilisation (ou la réutilisabilité)
implique le développement de services qui présentent plusieurs contrats d'utilisation. Ces
services peuvent couvrir par conséquent plusieurs scénarios d'utilisations en altérant
simplement le comportement indispensable tenant compte du contrat fixé.
Alignement sur les métiers : les services exposés au niveau métier de l'entreprise doivent
apporter une valeur métier tangible et supporter des cas d'utilisation métier.
La capacité d'être assemblé : il est important que l'interface de service soit définie de telle
manière à ce que les fonctionnalités qu'il présente puissent être utilisées et composées
facilement dans différents contextes. Les services provenant d'un simple empaquetage
des applications demandent, dans la majorité des cas, des efforts considérables de la part
des consommateurs.
6.3.2.2 Identification des composants métier
Le composant métier est un empaquetage d'activités métier et d'objet métier que ces dernières
manipulent. Le but d'introduire le composant métier dans notre architecture de l'Entreprise
Orientée Services est d'assurer une meilleure compréhension de la structure de l'entreprise et de
la manière avec laquelle les ressources métier, les acteurs, les processus et les technologies sont
répartis dans l'entreprise. Les composants métier servent aussi à instaurer l'un des principes de
l'Architecture Orientée Services qui est le principe des trois entités : fournisseur de service,
consommateur de service et registre de service. En effet les composants métier de l'entreprise
sont à la fois les fournisseurs et les consommateurs de service.
Notre démarche d'identification des composants métier comporte trois étapes qui sont
présentées dans la Figure 6.4:
1. Identification des domaines métier et identification de l'ensemble des activités
appartenant au processus d'un domaine particulier.
105
2. Construction de la cartographie des objets métier.
3. Construction des matrices de regroupement.
Figure 6.4 : Démarche d'identification des composants métier
Étape 1 : Identification des domaines et des activités métier
Cette étape consiste à décomposer le niveau métier de l'entreprise en des domaines métier. Par
la suite, on réalise une modélisation des différents processus métier appartenant à un domaine
métier particulier afin d'en déduire l'ensemble des activités qui le constituent. Cette étape permet
de recenser les différents domaines métier de l'entreprise et exploite les livrables de la phase
précédente du Framework FErOS (cartographie des processus) afin d'identifier les processus
relatifs à chaque domaine.
Le concept de domaine permet non seulement de gérer la complexité du système d'entreprise
mais aussi de faciliter le partitionnement des processus, pour réaliser l'un des objectifs de
l'entreprise. La décomposition de l'entreprise en des domaines métier est inspirée de la notion
des processus maîtres présentée par CIMOSA. Chaque domaine métier identifié possède un
ensemble de caractéristiques. Des exemples de caractéristiques incluent les objectifs qu'il
poursuit, la cartographie des processus métiers qu'il contrôle, les entités et les ressources qu'ils
lui appartiennent et aussi les règles et les politiques métiers qui le gouvernent.
Étape 2 : Réalisation du diagramme d'objets métier
Cette étape consiste à cartographier les objets métier par domaine métier. Un objet métier se
réfère intuitivement à tout ce sur quoi un processus peut agir soit pour l'utiliser soit pour le
façonner et le créer. Un objet métier est un élément concret ou informationnel utilisé ou produit
par un processus métier (ou activité d'un processus). Par exemple, les matières premières
(éléments concrets), les produits finis (éléments concrets), les instructions de fabrication
(éléments informationnels), le personnel (éléments concrets), les machines (éléments concrets),
les programmes informatiques (éléments concrets) sont des objets métier utilisés et/ou produits
par les processus de l'entreprise.
Les objets métier jouent un rôle primordial dans notre architecture de l'EOS et leur identification
est une étape importante dans le Framework FErOS. Une cartographie des objets métier est
réalisée à partir de l'analyse des différents processus métier et des différents scénarios métier qui
s'y rattachent. Elle consiste à dresser un diagramme qui présente l'ensemble d'objets métier ainsi
106
que les différentes relations entre eux. Plusieurs techniques existent pour représenter ce genre de
diagramme comme par exemple la représentation Entité‐Association ou encore le diagramme de
classes de l'UML. Dans ce dernier cas, on commence par regrouper les classes du diagramme de
classes sous forme de modules. Ce regroupement forme la notion d'objet métier. Chaque objet
métier encapsule un ensemble de classes qui sont fortement reliées entre elles et faiblement
couplées avec d'autres classes appartenant à d'autres objets métier. Le partitionnement du
diagramme de classes est conforme à un ensemble de règles de bonnes pratiques. Ces dernières
s'attardent sur la définition du périmètre de l'objet métier :
règle d'unicité : les objets métier ne doivent pas se chevaucher entre eux. Cette
considération se répercute au niveau des classes encapsulées. Par conséquent, une classe
doit appartenir à un et un seul objet métier,
règle d'autonomie : les objets métier qui seront identifiés sont autonomes les uns des
autres. Chaque occurrence d'un objet métier est indépendante des autres objets,
règle de consistance : en termes de contenu, chaque objet métier doit être pertinent et
possède un sens métier bien défini,
règle de durabilité : les objets métier identifiés doivent avoir une durée de vie plus
grande que celle des projets. Ceci ne nie pas que chaque objet métier peut être enrichie
et réutilisé par plusieurs projets.
Outre l'ensemble des règles déjà mentionnées, le partitionnement d'un diagramme de classe en
un ensemble d'objets métier peut être réalisé en utilisant des algorithmes de partitionnement de
graphe. Ces derniers permettent de regrouper les classes en un ensemble homogène de groupes
qui peuvent représenter les objets métier dans notre cas. Rappelons que le but de ces méthodes
est de présenter la faisabilité de notre démarche et qu'elle peut être supportée par plusieurs
outils de travail.
Dans la littérature, on peut trouver plusieurs travaux qui ont traité le problème de
partitionnement. Chacun de ces algorithmes possède des caractéristiques de groupement et ses
propres fondements mathématiques. La méthode de clustorisation présentée dans (Xanthos,
2005) nous a semblé très intéressante et peut être utilisée dans le cadre de notre travail pour
identifier les objets métier. Cette méthode se base sur un algorithme de partitionnement spectral
qui opère sur les graphes (spectral graph partitioning technique). Parmi les outils de
partitionnement de graphes, l'analyse spectrale occupe une place importante. En effet,
l'ensemble des études et des expérimentations des algorithmes de partitionnement spectral ont
prouvé leur efficacité dans différents domaines comme l'extraction des connaissances à partir des
données, l'analyse des images ou encore dans le cadre de l'ingénierie inverse des applications. La
technique de partitionnement spectral a été proposée par Fiedler (Fiedler, 1975) au milieu des
années 70 et puis elle a été largement étudiée dans plusieurs travaux.
107
Afin de partitionner le diagramme de classes (au sens UML) en un ensemble d'objets métier, nous
proposons l'utilisation d'une méthode basée sur la théorie spectrale des graphes et les extensions
proposées par l'algorithme de Fiedler (Xanthos, 2005).
Nous allons commencer par présenter la théorie spectrale du graphe ainsi que l'algorithme de
Fiedler pour entamer par la suite la manière avec laquelle cet algorithme est utilisé pour
l'identification des clusters de classes considérés, dans notre cas, comme des objets métier.
Théorie spectrale du graphe et vecteur de Fiedler
Soit un graphe , avec
l'ensemble des sommets du graphe et
est l'ensemble des arcs entre deux sommets et .
La matrice d'adjacence du graphe G est la matrice de taille avec est le poids
de l'arc .
Soit la matrice de degré de taille avec
0
La matrice Laplacienne associée à G est la matrice de taille et symétrique.
L'exploitation de cette matrice est très importante. En effet Fiedler confirme dans ses travaux que
le vecteur propre associé à la deuxième petite valeur propre de la matrice L permet de
diviser le graphe en deux sous‐graphes suivant les valeurs correspondantes à chaque sommet du
graphe. Dans le premier sous graphe, on rassemble les sommets de graphes dont les valeurs
correspondantes dans le vecteur propre sont positives et dans le deuxième sous‐graphe les
sommets dont les valeurs du vecteur propre sont négatives. En se basant sur ce qui précède, on
peut énoncer un algorithme (voir ci‐dessous) pour le partitionnement spectral d'un graphe. Ainsi,
un graphe G est divisé en deux sous‐graphes et en utilisant le vecteur de Fiedler.
Func { Etape 1 Etape 2 0 return , }
108
Pour l'application de cette méthode de partitionnement de graphe pour l'identification des objets
métier, le diagramme de classe est considéré comme étant un graphe avec les classes comme
sommets des graphes et les arcs entre les classes correspondent aux appels de méthodes entre
les classes. Les poids des arcs sont désignés par le nombre de méthodes appelées entre deux
classes. Le graphe obtenu est partitionné d'une manière itérative en des sous‐graphes (voir
algorithme ci‐dessous). Les itérations s'arrêtent quand au moins un des sous‐graphes possède une
cohésion plus faible que son graphe père. La mesure de cohésion est assurée en examinant si le
nombre des arcs internes dans chaque sous‐graphe est inférieur au nombre d'arc externe qui relie
les sommets du sous‐graphe aux autres sommets. Si le nombre d'arcs externes du sous‐graphe est
supérieur au nombre d'arcs internes, l'algorithme s'arrête.
Proc { Input: le diagramme de classe transformé en graphe G Output: un ensemble de sous‐graphe représentant les sous‐graphes , , }
Une fois exécuté, l'algorithme produit un ensemble de partitions qui peuvent être considérées
comme les objets métier. La Figure 6.5 montre un exemple d'identification d'objet métier par la
méthode de décomposition spéctrale.
109
Figure 6.5 : Détermination des objets métier par la méthode de décomposition spectrale
Outre l'utilisation des méthodes de partitionnement des diagrammes de classe, de bonnes
pratiques ont été développées dans le but de faciliter le découpage du diagramme de classe en
des ensembles de classes que nous pouvons considérer comme des objets métier. Dans cette
optique, on peut considérer le travail présenté par (Bonnet, 2005) dans lequel il expose une
bonne pratique pour la décomposition d'un diagramme de classe en des groupes de classes que
nous pouvons voir comme étant des objets métier. Cette décomposition se base sur l'étude de la
cardinalité qui existe entre les différentes classes.
La Figure 6.6 montre les pratiques présentées pour découper le diagramme de classe. Le trait
vertical dans cette figure montre le lieu de coupure entre les deux classes. Le cas "C1=C2"
implique que la coupure entre les classes peut se faire des deux côtés de la relation.
110
Figure 6.6 : Bonne pratique pour la décomposition d'un diagramme de classe
La Figure 6.7 montre un exemple d'une décomposition d'un diagramme de classe en des objets
métier.
Figure 6.7 : Diagramme d'objet métier d'un processus de commande client
Étape 3 : Réalisation de la matrice de groupement (Activity‐Business Object Matrix ABOM)
Cette étape est la dernière étape de la procédure d'identification des composants métier (Chaari
et al., 2007b). Comme nous l'avons déjà mentionné, un composant métier regroupe un ensemble
d'objets métier et un ensemble d'activités qui les utilisent. Ainsi, l'objectif de cette étape étant de
définir les relations entre les différentes activités et l'ensemble d'objets métier définis dans la
deuxième étape de la procédure d'identification. Pour se faire, nous proposons d'utiliser la notion
de matrice de groupement (activités/objets métier) dont les colonnes représentent les objets
métier et les lignes représentent les différentes activités. Cette dernière permet de recenser les
111
relations qui existent entre les activités et les objets métier (Figure 6.8). A cet égard, nous
identifions deux types de relation :
1. la relation "Utilise" (U) qui spécifie qu'une activité A utilise un objet métier O
2. la relation "Crée" qui signifie qu'une activité A crée un objet O.
OM
1
OM
2
OM
3
OM
4
OM
5
OM
6
OM
7
OM
i‐1
OM
i
OM
i+1
OM
n‐2
OM
n‐1
OM
n
Activité1 U U Activité2 U C Activité3 C C Activité4 U U Activité5 U C Activité6 C Activité7 U U Activitéi‐1 Activitéi U U Activitéi+1 U U Activitén‐2 U C Activitén‐1 U U Activitén U U
Figure 6.8 : ABOM
La matrice de groupement est transformée par la suite en une matrice binaire dont les valeurs
sont soit 0 soit 1. Chaque case de la matrice contenant "U" et "C" est remplacée par la valeur 1
alors que les cases vides sont remplacées par la valeur 0.
Afin de partitionner la matrice de groupement et obtenir par conséquent l'ensemble de
composants métier, nous avons fait recours à l'algorithme ROC (Rank Order Clustering) introduit
par (King, 1980). ROC est un algorithme de clusterisation qui opère sur des valeurs booléennes 0
et 1 conçu à l'origine pour le regroupement de machines en production. Cet algorithme nous
permet de construire des matrices bloc‐diagonales. Les blocs sur la diagonale de la matrice
contiennent les valeurs 1. Les étapes de l'algorithme ROC sont présentées dans le Tableau 6.1.
Etape 1: Pour chaque colonne j, calculer l'équivalent décimal tel que
∑ 2
Etape 2: Si les sont dans un ordre ascendant, aller à l'étape 3. Si non
ordonner les colonnes dans un ordre ascendant
Etape 3: Pour chaque ligne i calculer l'équivalent décimal tel que
∑ 2
Etape 4: Si les sont dans un ordre ascendant, Terminer. Sinon,
ordonner les lignes dans un ordre ascendant. Aller à l'étape 1 et
continuer jusqu'à ce qu'il n y aurai plus de changements
Tableau 6.1 : Étapes de l'algorithme ROC
112
Par la suite, il s'agit de remplacer dans la matrice partitionnée les valeurs 1 par leurs valeurs
d'origine (U ou C). On obtient ainsi une nouvelle matrice partitionnée que nous appelons BABOM
(Block Activity Business Object Matrix) (voir Figure 6.9). Ces blocks ne sont autres que les
composants métier candidats, qui nécessitent des raffinements par les experts métier de
l'entreprise afin de répondre aux spécificités des composants métier déjà mentionnées
auparavant (mérite des explications). Il est important de souligner qu'outre les blocs identifiés, le
partitionnement de la matrice de groupement identifie un ensemble de valeurs qui
n'appartiennent à aucun bloc. En exploitant ces valeurs, on obtient un graphe de composants
métier avec l'ensemble de relations qui les relient (Figure 6.10).
OM
1
OM
4
OM
i+1
OM
2
OM
5
OM
3
OM
7
OM
i‐1
OM
N
OM
6
OM
n‐2
OM
n‐1
OM
I
Activité1 U Activité2 C C U Activité3 U U Activité4 U C Activité5 U U Activité6 C Activité7 U U U Activitéi‐1 C U U Activitéi U C C Activitéi+1 C C C Activitén‐2 U C U U Activitén‐1 U C Activitén C
Figure 6.9 : BABOM
OM
1
OM
4
OM
i+1
OM
2
OM
5
OM
3
OM
7
OM
i‐1
OM
N
OM
6
OM
n‐2
OM
n‐1
OM
I
Activité1 Composan1 Activité2 U Activité3 Activité4 Com
posant 2
Activité5 Activité6 Activité7 U Activitéi‐1 Composant 3 Activitéi Activitéi+1 Composant 4 Activitén‐2 Activitén‐1 U Composant 5
Activitén
Figure 6.10 : Composants métier découverts à partir du matrice du groupement
113
Les composants métier, obtenus suite à l'utilisation des matrices de groupement, doivent passer
par une étape de raffinement et de vérification doit être mis en place afin de valider les différents
composants métier obtenus. Cette étape est très importante pour avoir un ensemble convenable
de services métier exposés par les composants métier. Le raffinement des composants métier
contient les activités suivantes:
La vérification de la clusterisation des objets métier et des activités. En effet, il faut noter
que le processus de clusterisation automatisé par ROC ne fait qu'aider les intervenants
dans ce projet et que le résultat issu de la matrice de regroupement doit être validé.
La vérification de la granularité du composant métier.
6.3.2.3 Identification des services métier
Un composant métier offre des services métier à son environnement. Les fonctionnalités (les
opérations) d'un service métier, exposés par un composant métier, représentent une ou plusieurs
activités de ce même composant.
D'une manière générale, ce ne sont pas toutes les activités encapsulées par le composant métier
qui seront représentées par les fonctionnalités d'un service métier. Les activités automatisées
sont le plus souvent les cibles pour être candidates dans un service métier.
L'identification des services métier se base principalement sur l'étude des processus métier de
l'entreprise et des activités qui les composent. Le choix des services métier qui seront développés
tient compte de l'orientation stratégique de l'entreprise et des différents objectifs métiers et
opérationnels qui ont été identifiés. En effet, un service métier doit répondre impérativement à
un objectif opérationnel précis, sinon, il est inutile de le mettre en place. Des KPI (Key
Performance Indicator) seront mis en place et attribués à chaque service métier pour mesurer sa
performance et voir si ce dernier répond exactement aux attentes exprimées par un objectif
opérationnel. Les pré‐conditions, les post‐conditions, les règles métier et les politiques métier
doivent être aussi définis pour chaque service métier.
Figure 6.11 : Identification des services métier
Comme le montre la Figure 6.11, l'étape d'identification des services métier se base sur les
entrées et les livrables suivants : (i) la liste des composants métier identifiés dans l'entreprise, (ii)
les processus métier, (iii) les objectifs métier de l'entreprise et (vi) les cibles métier et les
contraintes non fonctionnels. Les livrables de cette étape sont l'ensemble des services métier
114
(avec leurs fonctionnalités de services) ainsi qu'une partie des paramètres non fonctionnels qui
les décrivent.
6.3.2.4 Identification des services virtuels
La deuxième étape de la phase identification de services du Framework FErOS est l'identification
des services virtuels. Un service virtuel représente une structure de haut niveau qui orchestre un
ensemble de services métier. Le service virtuel est de très forte granularité. Il représente, en
quelque sorte, le processus que l'entreprise envisage d'exposer à son environnement extérieur
afin d'être sollicité dans des scénarios de coopération.
Le but des services virtuels est de présenter un service composite afin de minimiser le travail de
composition à effectuer par l'utilisateur des services et de répondre à des objectifs opérationnels
très grands qu'un seul service métier ne peut pas accomplir. Les processus ou les parties de
processus à publier par l'entreprise seront représentés par des services virtuels.
Comme le montre la Figure 6.12, cette étape utilise les livrables issues de la première phase
notamment la cartographie des processus métier cibles et les objectifs métier de l'entreprise ainsi
que des livrables issue de la deuxième phase à savoir l'ensemble des services métier.
Figure 6.12 : Identification des services virtuels
6.3.2.5 Identification des services Informatiques
Les services informatiques de l'Entreprise Orientée Services sont de deux types : les services
applicatifs et les services d'infrastructure. Nous allons mettre le point sur les services applicatifs et
montrer comment on peut les identifier et faire le lien entre ce type de service et les services
métier.
Les étapes pour l'identification des services applicatifs sont résumées dans la Figure 6.13.
Figure 6.13 : Identification des services informatiques
115
Un service applicatif permet d'implémenter un ou plusieurs services métier. Cependant, étant
donné que le service applicatif respecte les propriétés du couplage faible avec les autres services,
il ne peut pas appeler directement d'autres services appartenant à d'autres objets métier. Ceci
impose par la suite la mise en place d'une fonction d'orchestration qui se charge de l'appel des
différents services applicatifs au sein d'un service métier. La Figure 6.14 illustre la logique d'une
activité métier dans un service métier qui orchestre deux services applicatifs distincts appartenant
à deux objets métier différents.
Figure 6.14 : Relation entre service appalicatif, service métier et objet métier
Afin d'identifier les services applicatifs, nous proposons d'étudier le diagramme de séquence qui
décrit les enchaînements d'interactions entre l'activité métier en question et les objets métier
qu'elle peut utiliser (Figure 6.15). Les matrices de regroupement aident à définir les relations
existantes entre activités et objets métier. En faisant ainsi, chaque interaction n'est autre qu'une
invocation d'un service applicatif. De cette manière, on peut identifier l'ensemble des services
applicatifs qui seront orchestrés par le service métier contenant l'activité en question.
Figure 6.15 : Identification des services applicatifs à partir des activités métier
Le service applicatif propose un ensemble d'opérations. Ces opérations correspondent aux
méthodes issues des classes de l'objet métier qui expose ce service. Afin d'assurer la propriété de
couplage faible entre les services applicatifs, il est interdit qu'un service applicatif présente une
opération appartenant à une classe ne figurant pas parmi les classes de l'objet métier qu'il
expose. Dans la Figure 6.16, le service applicatif proposé par l'objet métier présente deux
opérations correspondant aux méthodes des classes 3 et 4 de cet objet métier.
116
Figure 6.16 : Relation entre opération des services applicatifs et méthodes de l'objet métier
Une fois ce stade est atteint, nous allons procéder à une étape de matching entre les services
applicatifs identifiés (correspondant à l'architecture cible) et l'ensemble des services applicatifs
existants (que nous pouvons déduire et développer à partir du patrimoine applicatif de
l'entreprise). Cette étape de matching a pour but d'ajuster les services existants et d'identifier les
nouveaux services à développer.
6.4 Conclusion
L'Entreprise Orientée Services ou l'Architecture Orientée Services d'une manière générale sont
des paradigmes assez intéressants que les différentes entreprises essaient d'adopter. Cependant
une implémentation pratique de telle architecture demande un planning précis et un Framework
servant de guide pratique pour leur mise en place. On note pour ce sujet la quasi‐absence de
travaux similaires dans le milieu académique dont la grande majorité des recherches concernent
les Web services ou les services du niveau technique. Dans le milieu industriel, la plupart des
travaux sont privés et manquent de détails.
Dans ce chapitre, nous avons proposé les grandes lignes d'une démarche pour la mise en place
d'une Entreprise Orientées Services. Nous avons tenu compte des différentes spécifications des
services que nous avons mis en place dans le chapitre précédent. Nous avons essayé d'introduire
une automatisation de quelques étapes de la démarche proposée à travers la représentation de
quelques algorithmes et des bonnes pratiques. Nous avons exploité la notion de composant
métier et d'objet métier pour faciliter l'identification de services et atteindre le but de l'EOS.
Spécialement, l'objet métier a permis de différencier notre démarche de l'urbanisation
fonctionnelle.
Nous avons dans ce chapitre et le chapitre précédent présenter la notion de l'EOS et sa démarche
de mise en œuvre. Le développement de l'EOS était dans le but de favoriser la coopération
interentreprises. Le chapitre suivant traitera ce sujet et présentera notre Framework de
construction de processus collaboratifs via la composition de services d'entreprises.
117
Chapitre 7 Construction du processus collaboratif interentreprises
SOMMAIRE
Chapitre 7 Construction du processus collaboratif interentreprises ..................................... 117
L'Architecture Orientée Services est un paradigme qui propose les services comme des éléments
de base pour le développement des applications distribuées dans des environnements
hétérogènes. La SOA a offert une nouvelle opportunité aux entreprises afin qu'elles puissent
adhérer facilement dans des scénarios de collaboration interentreprises.
Dans les deux chapitres précédents, nous avons présenté notre mise en œuvre de la SOA au sein
de l'entreprise que nous avons appelée l'Entreprise Orientée Services (EOS). Le but de l'EOS est
double : assurer d'une part l'agilité interne de l'entreprise et favoriser d'autre part la collaboration
interentreprises. Nous avons mis le point sur l'architecture de l'EOS et les différents types de
services qu'elle présente. Parmi ces services, les services virtuels sont destinés à participer dans
des processus de collaboration interentreprises. En effet, l'EOS publie les services virtuels (la
description des services virtuels) afin d'être invoqués par des clients externes qui peuvent être
soit des simples utilisateurs soit des entreprises. C'est le paradigme de la collaboration par
composition de services. Les services virtuels seront déployés sous forme de Web services.
Nous avons analysé les limites des approches existantes concernant la composition de services.
Nous avons constaté que le cadre de collaboration interentreprises est plus complexe qu'un
simple scénario de B2B vu la complexité du processus collaboratif à mettre en œuvre en termes
de flux de contrôle. En plus les méthodes de sélection de services se basaient principalement sur
les descriptions fonctionnelles des services publiés. Cependant, dans le cadre d'une collaboration
interentreprises, nous avons besoin de critères de sélections plus pragmatiques et plus concrètes
afin de s'assurer que les services qui ont été choisis répondent exactement aux attentes et aux
objectifs initiaux.
De ce fait, nous avons choisi de faire une composition de service semi‐automatique, dans le sens
où le processus de collaboration sera construit manuellement tandis que la phase de sélection des
services correspondants à ce processus sera faite d'une manière automatique. La sélection de
services tiendra compte des paramètres non fonctionnels des services publiés.
Dans la suite de ce chapitre, nous allons présenter notre Framework de construction de processus
interentreprises. Nous allons montrer l'importance des paramètres non fonctionnels dans la
phase de sélection des services candidats au processus de collaboration. Nous allons montrer, par
la suite, comment gérer ce type de descriptions et comment on peut les utiliser dans la sélection
de services. Finalement, le chapitre présentera notre démarche pour la construction du processus
collaboratif.
7.2 Les paramètres non fonctionnels (PNF) des services
La découverte et la sélection des services candidats sont des étapes importantes dans le cycle de
vie de formation du processus collaboratif interentreprises. Il y a eu toujours des confusions
autour de la définition de ces deux termes. Dans notre travail, nous considérons la découverte de
services comme étant la localisation de services (ou description de service) qui satisfassent
certains critères fonctionnels. La sélection de services correspond à l'évaluation et le classement
119
des services déjà découverts afin d'identifier ceux qui répondent le mieux aux attentes fixées par
l'utilisateur.
Dans notre démarche de sélection de services susceptibles de participer au processus collaboratif
nous avons porté une attention particulière aux paramètres non fonctionnels qui caractérisent les
services. En effet, lors d'une collaboration interentreprises, le faite de sélectionner des services
publiés sur Internet en se basant uniquement sur des descriptions fonctionnelles de services
risque de ne pas répondre exactement aux attentes des utilisateurs final d'une manière générale.
En plus, vu le nombre de services similaires de point de vue fonctionnel, il est incontournable de
se doter des descriptions et des mécanismes nécessaires afin de pouvoir les différencier et par
suite les classer. C'est le rôle que peuvent jouer les paramètres non fonctionnels des services dans
la phase de sélection.
Dans la section suivante, nous allons se concentrer sur les paramètres non fonctionnels des ainsi
que leur importance dans le processus de sélection de services.
7.2.1 Les paramètres non fonctionnels et la description des services
Les paramètres non fonctionnels (PNF) sont des propriétés qui caractérisent les services et qui
s'ajoutent à leurs descriptions fonctionnelles afin d'assurer un matching pertinent entre les
services et la requête de l'utilisateur. Les paramètres non fonctionnels peuvent représenter
n'importe quelles informations ou caractéristiques qui sont significatives aux utilisateurs des
services. Ils peuvent inclure par exemple des propriétés en relation avec la QoS comme par
exemple la performance, la fiabilité, le temps de réponse, la sécurité, etc. A l'encontre des
paramètres fonctionnels qui désignent ce que le service est capable de faire en termes
d'opérations, les paramètres non fonctionnels décrivent la manière avec laquelle le service peut
assurer ces opérations.
7.2.2 Exemple de motivation
Afin d'illustrer l'importance des paramètres non fonctionnels (PNF) dans la phase de sélection de
services, nous allons présenter un scénario dans lequel une entreprise a besoin d'un service de
transport pour livrer une marchandise de Lyon à Rome en Italie. Le service va être invoqué suite à
l'envoi d'un message qui contient des informations sur l'adresse de départ et de destination.
La sélection de services doit retourner ceux qui répondent, en premier lieu, aux besoins
fonctionnels (transport et livraison de marchandise). Cependant, le fait de ne sélectionner que les
services qui répondent aux besoins fonctionnels est généralement considéré comme insuffisant
pour garantir la fiabilité des services retrouvés. Les paramètres non fonctionnels doivent être pris
en considération dans la sélection des services. Ils sont des critères décisifs que les
consommateurs de services doivent évaluer avant de choisir un service particulier parmi d'autres.
Considérons par exemple deux services de transport offerts par deux fournisseurs de services
différents et qui possèdent les mêmes fonctionnalités en termes de transport et de livraison de
marchandises. L'entreprise cliente préfère normalement le service qui possède le temps
d'exécution le plus court ou le service le moins cher.
120
On peut citer plusieurs catégories de paramètres non fonctionnels qui peuvent être attachés aux
services de transport comme par exemple le coût, la réputation du service, le temps de livraison.
Des caractéristiques concernant la sécurité peuvent être aussi fournies comme par exemple les
clés de cryptage en plus des méthodes de payement possibles. En outre, les fournisseurs de
services peuvent offrir les mécanismes nécessaires pour assurer le monitoring de service comme
par exemple l'envoie automatique d'un email à la fin de la livraison ou lors d'un imprévue.
D'autres moyens peuvent être utilisés par exemple des appels téléphoniques ou à travers un
portail Web.
PNF Coût Réputation
Temps d'exécution
Lieu Sécurité Monitoring Méthode de Payement Service
S1 200 € 80% 1 days France, Italy
128‐ bit key Phone, email
VISA, MasterCard
S2 150 € 100% 12 hours France 128‐ bit key Web portal, phone
VISA, MasterCard
S3 120 $ 95% 8 hours France, UK, Germany
‐‐ email, Web portal
VISA
S4 200 € 70% 24 hours Italy, Germany
512‐ bit key ‐‐ MasterCard, Visa
Tableau 7.1 : Exemples de paramètres non fonctionnels pour les services de transport
Le tableau 7.1 présente quelques paramètres non fonctionnels reliés aux services de transport (S1,
S2, S3, S4). Ces services possèdent les mêmes fonctionnalités. Cependant, ils présentent des
descriptions non fonctionnelles différentes.
La grande diversité des paramètres non fonctionnels implique une grande difficulté dans leur
représentation. En plus la description de service doive être enrichie par les PNF et ils doivent être
pris en considération dans le processus de découverte et de sélection de servies. Plusieurs
questions peuvent être posées : comment les PNF vont être modélisés ? comment nous allons les
publier ? et comment nous allons les utiliser dans la sélection de services ?
7.3 Modèle de services orienté paramètres non fonctionnels
Il existe plusieurs définitions du concept de services. Elles varient depuis la plus générique au plus
spécifique et se concentrent spécialement sur l'apport du concept de service en matière de
couplage faible et d'interopérabilité et aussi sur les technologies les plus importantes utilisées
pour développer des services et interagir avec eux (exemple : XML, SOAP, WSDL).
Dans notre travail,nous proposons une vue très abstraite pour les services et on les considère
comme étant décris par deux ensembles de propriétés : fonctionnelles et non fonctionnelles. Les
propriétés fonctionnelles décrivent ce que les services sont capables de faire tandis que les
propriétés non fonctionnelles décrivent les façons avec lesquelles ils fonctionnent.
Définition 1 : Un Web service (WS) est défini comme étant l'union de deux ensembles de
propriétés : (i) fonctionnelles et (ii) non fonctionnelles.
121
où est l'ensemble des propriétés fonctionnelles qui
peuvent correspondre aux inputs, outputs et des aspects comportementaux des services et
, … , représente l'ensemble des tous les paramètres non fonctionnels reliés
aux services comme les paramètres reliés à la QoS ou au contexte des services.
7.3.1 Les catégories des PNF
La catégorisation des paramètres non fonctionnels est une étape importante pour le
développement d'un Framework qui prend en considération ce genre de paramètres. Malgré, les
efforts pour définir une taxonomie des PNF, il n'existe pas une catégorisation générique car ces
derniers varient selon le domaine d'utilisation et selon la nature des services. Nous proposons
dans ce qui suit, une catégorisation des PNF (Chaari et al., 2008b). On peut associer à chaque
service une ou plusieurs propriétés non fonctionnelles. Chaque paramètre appartient à une
catégorie spécifique qui peut être reliée soit à la QoS soit au contexte de service.
7.3.1.1 Catégorie des paramètres reliés à la QoS
Les paramètres reliés à la QoS représentent un aspect très important des descriptions non
fonctionnelles des services. Le standard international de qualité ISO 9000 décrit la qualité comme
"the totality of features and characteristics of a product or service that bear on its ability to satisfy
stated or implied needs" (Glass, 1998). La QoS englobe plusieurs paramètres de qualité qui
caractérisent le comportement des services quand ils offrent leurs fonctionnalités (Cardoso et al.,
2004, Conti et al., 2002). On considère deux principales catégories de QoS :
l'exécution : elle inclue les paramètres de performances qui caractérisent l'interaction avec les
services. On considère les paramètres suivants :
• le temps de réponse : le temps écoulé depuis la soumission de la requête jusqu'à reçu de
la réponse,
• disponibilité : elle représente le pourcentage de temps dans lequel un service est
opérationnel. Les valeurs les plus grandes montrent une disponibilité élevée tandis que
les petites valeurs impliquent une basse disponibilité,
• accessibilité : elle représente le pourcentage qu'un service soit capable de répondre à une
requête émise par un utilisateur,
• réussite (Successability en anglais) : elle représente le pourcentage de messages qui ont
reçu une réponse,
• conformité (compilance en anglais) : elle représente le degré de conformité du document
WDSL décrivant le service aux spécifications du WSDL,
la sécurité : elle représente la capacité d'un service à offrir des mécanismes de sécurité. Nous
tenons compte des paramètres suivants :
• cryptage : la capacité du service à supporter le cryptage des messages reçus et envoyés,
• authentification : la capacité d'un service à offrir les mécanismes qui traitent
l'identification de la partie qui invoque le service (le consommateur de service),
122
• contrôle d'accès : la capacité d'un service à offrir des outils pour restreindre l'invocation
des opérations et l'accès aux informations seulement aux parties autorisées.
7.3.1.2 Catégories des paramètres reliés au contexte
Les informations reliées au contexte constituent le deuxième volet des paramètres non
fonctionnels que nous tenons en compte dans notre catégorisation. Le terme contexte peut être
interprété différemment selon le domaine d'application. Plusieurs définitions se sont focalisées
sur le contexte qui caractérise les interactions entre un système et son environnement (Brezillon,
2003). D'autres définitions proposent le contexte comme l'ensemble des caractéristiques d'une
situation particulière (Brezillon and Pomerol, 2003, Dey et al., 2001).
D'une manière générale, les définitions et les catégories de contexte qui existent concernent
plutôt les domaines de l'informatique pervasive et mobile et surtout le domaine de l'interaction
homme‐machine. Dans notre travail, nous allons adopter une simple définition du contexte
proposée par (Martin, 2005) et qui est en parfaite adéquation avec le monde de l'entreprise et de
service : "le contexte est l'ensemble des connaissances utiles pour l'accomplissement d'une tâche
particulière comme par exemple résoudre un problème, prendre une décision, répondre à une
question, faire une action". En ce qui concerne les services, de telle tâche peut concerner la
découverte et la sélection de service.
Les propriétés contextuelles sont considérées comme une partie des paramètres non fonctionnels
d'un service. Elles interviennent, à l'instar des paramètres de la qualité de service, dans la
différentiation des services offrant les mêmes fonctionnalités. On considère deux principales
catégories pour les propriétés contextuelles : (i) les propriétés de l'environnement et (ii) les
propriétés métier. Les propriétés de l'environnement sont de deux types : (i) propriété de localité
et (ii) propriété temporelle. Les propriétés métier sont les suivantes :
le coût : il représente le prix que l'utilisateur de service devra payer pour utiliser le
service. Il représente le prix de l'invocation des opérations.
la réputation : elle mesure la réputation du service ou du fournisseur de service suit à des
feedbacks des utilisateurs.
la méthode de payement : elle représente les moyens de payement acceptés par le
fournisseur de service comme par exemple un transfert bancaire, une carte VISA…
le monitoring : correspond aux mécanismes offerts par le fournisseur de service pour
contrôler le déroulement de son service durant son exécution afin de détecter des signes
d'échec. De tels mécanismes peuvent inclure par exemple des appels téléphoniques, un
portail de contrôle, des échanges de mail à chaque étape de travail…
7.3.1.3 Utilisation d'une ontologie pour la représentation des PNF
Nous utilisons une ontologie pour la représentation et la structuration des différentes catégories
de PNF évoquées précédemment. D'une manière générale, une ontologie est définie comme
étant une spécification explicite et formelle d'une conceptualisation partagée (Gruber, 1993). De
point de vue des services et la découverte de services dans des registres distribués, l'ontologie des
123
paramètres non fonctionnels (Figure 7.1) sera utilisée comme un dictionnaire de telle sorte que
les registres de services et les mécanismes de découvertes partagent la même interprétation des
termes utilisés pour la description des services.
Figure 7.1 : Les catégories des paramètres non fonctionnels
7.3.2 Les échelles de mesure pour les propriétés non fonctionnelles
Dans le but de pouvoir évaluer les paramètres non fonctionnels nous serons amenés à faire
plusieurs opérations de mesure. Les caractéristiques de ces mesures varient en fonction des types
des paramètres. Il existe deux grands types de PNF : (i) les paramètres qualitatifs et (ii) les
paramètres quantitatifs. En outre, une distinction plus fine peut encore être considérée au sein de
ces deux grandes catégories, ce qui permet d'envisager différents niveaux de mesure pour les PNF
et, donc, différents types d'échelles.
Classer les PNF selon différentes échelles de mesure facilitera le choix de la fonction de calcul de
dissimilarité entre les paramètres non fonctionnels publiés et requiq dans la phase de sélection de
services. Les paramètres qualitatifs définissent deux échelles qui peuvent être soit nominale soit
ordinale (Fenton, 1994, Velleman and Wilkinson, 1993):
L'échelle nominale : elle correspond à un ensemble de catégories différentes les unes des
autres. Aucune relation d'ordre n'aura un sens entre ces catégories. Par exemple la propriété
méthode de payement appartient à l'échelle nominale. Elle est formée de trois catégories :
VISA, MasterCard et American express. Le fait de donner des valeurs numériques pour
désigner les catégories d'une échelle nominale ou ordonner les catégories d'une manière
particulière ne signifie en aucun cas que ces valeurs possèdent des propriétés arithmétiques.
L'échelle ordinale : si les différentes catégories peuvent être ordonnées, on est alors dans le cas d'une échelle ordinale. Les catégories correspondent alors à un ensemble de rapports
ordonnés. Cependant, les intervalles entre les valeurs ne sont pas forcément égaux et les
différences entre eux ne sont pas significatives. Considérons l'exemple de la section 2, bien
124
qu'une clé de cryptage de 512 bit soit plus meilleure qu'une clé de cryptage de 128 bit, on ne
peut pas dire qu'une clé de 512 bit est quatre fois plus sécurisée qu'une clé de 128 bit.
Les paramètres quantitatifs peuvent être soit des variables d'intervalle soit des variable de
rapport (ratio en anglais) :
L'échelle intervalle : l'ensemble de ces valeurs est constitué par la totalité de l'intervalle défini
selon l'étendue de la variable. La comparaison des intervalles est possible (par exemple on
peut déterminer si deux intervalles possèdent ou non la même étendue). Les opérations
d'addition et de soustraction ne sont pas permises dans l'échelle intervalle.
L'échelle rapport : de même que l'échelle intervalle, sauf qu'on peut effectuer des opérations
d'addition et de soustraction. Les échelles d'intervalles diffèrent des échelles de rapports dans
la position du point zéro. Dans une échelle d'intervalles, ce point est déterminé arbitrairement.
7.4 L'utilisation des politiques pour la modélisation de paramètres non
fonctionnels
Dans le but de pouvoir utiliser les paramètres non fonctionnels dans le processus de sélection, ces
derniers doivent être modélisés et attachés aux services lors de leurs publications. La
modélisation des paramètres non fonctionnels consiste à les représenter avec un langage facile et
sous un format exploitable. Plusieurs travaux ont introduit les paramètres non fonctionnels dans
les descriptions WSDL des services. Cependant, il serait plus judicieux de séparer les descriptions
fonctionnelles (WSDL) des descriptions non fonctionnelles vu que ces derniers changent
fréquemment et l'on sera ramené chaque fois à modifier tout le fichier WSDL. Nous avons choisi
de modéliser les PNF avec en utilisant un standard de la W3C qui est le WS‐Policy. Dans la suite de
cette section, nous allons présenter en premier le standard WS‐Policy. En second lieu, nous allons
exposer les extensions que nous avons faites pour adapter ce standard à la représentation des
PNF pour parler, finalement, de la manière avec laquelle nous allons gérer la publication des
paramètres non fonctionnels décrits par le WS‐Policy.
7.4.1 Le standard WS‐Policy
WS‐Policy est une grammaire extensible pour la représentation des possibilités, des contraintes,
et des caractéristiques des Web services qui se basent sur le langage XML. Une politique (ou
Policy) est définie comme un ensemble d'alternatives qui sont, elles‐mêmes définies comme une
collection d'assertions. Une assertion est utilisée pour exprimer une exigence, une capacité ou un
comportement d'un Web service (Bajaj et. al, 2006). En outre, une assertion peut inclure un
certain nombre de sous assertions ainsi qu'un ensemble d'attributs. Dans le cadre de notre travail,
une assertion est essentiellement utilisée pour spécifier les éléments qui influencent la sélection
d'un Web service au détriment d'un autre.
La grammaire proposée par WS‐Policy contient les trois étiquettes suivantes : l'étiquette "Policy"
qui permet de débuter et de finir une politique. "ExactlyOne" qui contient un ensemble
d'alternatives et "All" qui contient toutes les assertions d'une alternative. La Figure 7.2 (a)
125
présente un aperçu sur la grammaire proposée par WS‐Policy. La Figure 7.2 (b) illustre une
politique représentant un paramètre non fonctionnel (le temps de réponse) d'un service.
(a) Forme normale du WS‐Policy (b) Exemples de politiques représentant les PNF en
utilisant le WS‐Policy
Figure 7.2 : Forme normale du WS‐Policy
Le WS‐Policy permet la spécification de différents types de politiques appartenant à des domaines
divers, comme les secteurs opérationnels et de la sécurité. Cependant, en se basant uniquement
sur une comparaison syntaxique, l'intersection des politiques peut rejeter dans plusieurs cas des
partenaires potentiels, même avec des politiques compatibles. Nous démontrons l'utilité de la
comparaison sémantique à travers l'exemple de la Figure 7.3. Considérons un consommateur de
services qui exige une contrainte relative au paramètre non fonctionnel "temps de réponse"
(Figure 7.3 (a)). Considérons également un fournisseur de services qui garantit un "temps de
réponse" exprimé avec deux indicateurs : le "délai d'exécution" et le "temps réseau", comme le
montre la Figure 7.3 (b).
(a) Besoin de l'utilisateur en temps de réponse de service (b) Description du temps de réponse de service
offerte par le fournisseur de service
Figure 7.3 : Le problème de matching entre deux assertions du WS‐Policy
Le comparateur syntaxique établit une comparaison entre des chaînes de caractères afin de
déterminer si le fournisseur de services peut satisfaire la demande du consommateur de services.
Le comparateur conclut forcément que ces deux politiques ne sont pas compatibles bien que les
assertions sont équivalentes. Ainsi, un partenariat entre le consommateur et le fournisseur de
services sera rejeté. Par conséquent, l'intégration de l'aspect sémantique et des connaissances de
domaine lors l’intersection entre les politiques semble être très intéressante.
7.4.2 Extension du WS‐Policy pour les paramètres non fonctionnels des services
L'intégration de la sémantique et des connaissances de domaine dans le WS‐Policy va permettre
la spécification des politiques d'une manière assez expressive. Nous serons en mesure, par la
suite, de faire du raisonnement sur les politiques ce qui va améliorer, par conséquent, le résultat
126
du matching entre deux PNF pour déterminer leur compatibilité. En outre, les politiques enrichies
sémantiquement facilitent le processus de négociation entre fournisseur et consommateur de
services et améliorent le monitoring.
L'intégration de la sémantique dans les politiques consiste à utiliser des concepts d'ontologies
dans les assertions des politiques. Pour cette raison, nous avons fait une extension aux
spécifications initiales de la WS‐Policy en lui ajoutant de nouveaux composants. Nous avons
présenté aussi un modèle qui se base sur les ontologies pour la modélisation des politiques
représentant les PNF.
7.4.2.1 Les nouveaux composants ajoutés à la spécification du WS‐Policy
Afin de tenir compte des paramètres non fonctionnels, nous avons proposé une extension au WS‐
Policy en ajoutant de nouveaux éléments dans sa spécification intiale (Chaari et al., 2008a). Cette
extension nous a permis d'assurer un parsing et un raisonnement automatique sur les différentes
politiques qui seront traitées. Nous avons utilisé un modèle basé sur une ontologie pour
représenter ces différents éléments (Figure 7.4). Dans ce qui suit, nous allons décrire les différents
concepts qui constituent le WS‐Policy étendu :
Policy : il représente la racine de la WS‐Policy et indique une expression d'une,
Name et Id : ils servent à identifier une politique dans le WS‐Policy,
PolicyCategory : chaque politique appartient à une catégorie spécifique qui correspond à une catégorie bien particulière des paramètres non fonctionnels,
Service : décrit les détails des services, à qui, on va attacher la politique, PolicyOperators : les éléments ExactlyOne et All sont des opérateurs de la WS‐Policy,
L'opérateur ExactlyOne est une collection d'alternatives de politique. L'opérateur All rassemble
les assertions de politique dans les alternatives,
Une assertion d'une politique représentant un paramètre non fonctionnel est constituée des
attributs suivants :
MatchingType: indique le type de raisonnement qui sera tenu en compte par l'assertion lors du
matching de deux paramètres non fonctionnels. Nous avons défini deux types de matching:
• Le premier type est le "xsd" implique un matching qui ne prendra en compte que les
données dont les types sont supportés par le XML schema comme par exemple String et
float. Ce type de matching ne demande aucun raisonnement sur les assertions. C'est une
comparaison directe entre les données.
• Le deuxième type est "ont" qui indique qu'un raisonnement sémantique puisse avoir lieu
au moment du matching de l'assertion. Le type de matching est fixé lors de la définition
des assertions par le gestionnaire des politiques. Selon ses connaissances du domaine, il
peut déterminer si des règles de transformation peuvent être définies. Par exemple, un
administrateur peut définir deux assertions concernant le temps d'exécution "Execution
Time" et le temps de réseau "Network Time". Cependant, il peut savoir que la somme de
ces deux paramètres (le temps d'exécution et le temps de réseau) peut produire un
nouveau paramètre qui est le temps de réponse "Response Time". L'administrateur
127
indique qu'un raisonnement sémantique peut être appliqué en fixant l'attribut
MatchingType à "ont" lors de la définition de l'assertion.
ServiceOperation: une assertion peut être reliée à une opération particulière d'un service. Dans certain cas, l'assertion peut concerner un attribut particulier de l'opération de service.
Expression : cet élément garanti un parsing facile et un traitement automatique de l'assertion.
Il est formé de plusieurs sous‐éléments :
• Parameter : représente le paramètre non fonctionnel qui va être exprimé par l'assertion
comme par exemple le "Response Time",
• Value : la valeur de l'assertion,
• Unit : représente les unités de mesure reliées aux paramètres non fonctionnels,
• Operator : utilisé dans l'assertion pour représenter une relation entre le paramètre et sa
valeur.
Flexibilitymode : indique le niveau de flexibilité d'une assertion. Cet attribut peut avoir deux
valeurs, soit négociable (N) ou non négociable (NN). Il indique si l'assertion ou les paramètres
représentés par l'assertion peuvent être négociés en vu d'un éventuel changement,
Scale : représente l'échelle de mesure à qui le paramètre non fonctionnel représenté par
l'assertion appartient.
Figure 7.4 : L'ontologie représentant le WS‐Policy
7.4.2.2 Modèle d'ontologie
L'approche proposée pour la modélisation des paramètres non fonctionnels se base sur un
modèle d'ontologie. Le modèle que nous avons développé se compose de deux niveaux (Figure
7.5). Le premier niveau contient une ontologie indépendante du domaine (domain independent
ontology) qui représente les différents paramètres non fonctionnels. Elle correspond à l'ontologie
de catégories présentée dans la section précédemment.
128
Les paramètres non fonctionnels peuvent dépendre d'un domaine particulier en fonction du
service à décrire. Cette dépendance est supportée dans notre modèle d'ontologie par l'utilisation
de plusieurs ontologies de domaine. On peut citer l'ontologie des unités, l'ontologie des
opérateurs, l'ontologie géographique, etc. Durant le processus de matching des politiques, ces
ontologies sont utilisées, par exemple, pour déduire que Lyon est une ville située en France ou
pour déduire que 1 seconde est équivalente à 1000 milliseconde.
Figure 7.5 : Le modèle d'ontologie
L'exemple illustré dans la Figure 7.6 présente une politique d'un PNF en se basant sur l'extension
que nous avons ajoutée au WS‐Policy. Cet exemple présente le paramètre non fonctionnel temps
de réponse "Response Time". Les lignes (02‐05) contiennent les espaces de noms : wspes, nfpid,
nfpo, nfpu, qui correspondent respectivement aux URLs de WS‐Policy étendue, l'ontologie
indépendante de domaine (ontologie de catégories), les ontologies d'unité et d'opérateur. Les
lignes (08‐09) indiquent le nom de l'assertion (RTAssertion) qui est une assertion non‐négociable
et dont l'échelle de mesure est l'échelle rapport. L'expression de la politique est définie entre les
lignes (10) et (15) et qui indique que le temps de réponse doit être inférieur à 5 seconde.
Figure 7.6 : Exemple de politique représentant un PNF
129
7.4.3 Publication des politiques des paramètres non fonctionnels
Dans le but de pouvoir les utiliser dans la phase de sélection, les politiques représentant les
paramètres non fonctionnels des services doivent être publiées. Dans notre travail, nous avons
choisi de publier les services d'entreprise dans un registre de type UDDI.
Plusieurs organisations industrielles proposent les registres de services de type UDDI comme le
futur standard des registres de services. Ceci peut être confirmé par le nombre de registre UDDI
qui ne cesse d'augmenter sur le Web. Cependant, la spécification actuelle de l'UDDI n'est pas
encore assez mature pour tenir compte des paramètres non fonctionnels. En effet, les
mécanismes de publication et de découverte de services proposés par l'UDDI ne prennent pas en
considération de tels paramètres. L'UDDI assure en réalité qu'une découverte de service par
mots‐clés et gère uniquement l'aspect fonctionnel des services.
7.4.3.1 Extension de l'UDDI pour attacher les politiques de PNF
Pour la publication des politiques représentant les paramètres non fonctionnels des services, nous
avons choisi de les ajouter dans le champ tModel (W3C, 2006) existant dans la spécification UDDI.
Le tModel (technical model ou modèle technique) correspond à "l'empreinte digitale" technique
pour un service donné qui peut aussi fonctionner comme un espace de noms pour identifier
d'autres entités. Nous allons utiliser ce champ initialement vide pour enregistrer les PNF.
Chaque tModel sera référencé dans le "business service entry" d'un service publié. Le champ
tModel sera défini formellement de la manière suivante :
tModel=< ID_Policy, URL_Policy, ID_WS, Cg >, où
ID_Policy est l'identifiant de la politique à publier, URL_Policy reprèsente l'URL du fichier XML de
la politique, ID_WS correspond à l'identifiant du service à qui la politique fait référence et
finalement Cg désigne la catégorie de la politique représenté par le tModel. Cette catégorie
correspond à la catégorie du paramètre non fonctionnel présenté par la politique.
La Figure 7.7 présente un exemple de tModel. L'attribut tModelKey (ligne 1) dans la balise tModel
correspond à un identifiant unique généré par l'UDDI pour désigner le tModel. Cet identifiant
désigne aussi l'identifiant de la politique du PNF (ID_Policy) représentée par le tModel. Le premier
keyedReference (ligne 7‐10) définit l'URL du fichier XML qui représente la politique. Le deuxième
keyedReference (ligne 12‐15) correspond à l'identifiant du service à qui la politique du PNF sera
attachée. Le troisième keyedReference (ligne (17‐19) représente la catégorie du paramètre non
fonctionnel (aussi la catégorie de la politique). Sa valeur joue le rôle d'un index pour faciliter le
parcours du registre UDDI et la clusterisation des différents tModel.
130
Figure 7.7 : L'enregistrement de la politique non fonctionnelle dans le tModel
Chaque service peut avoir une ou plusieurs politiques qui lui seront attachées. Ceci dépend du
nombre de paramètres non fonctionnels qui le décrivent. Nous avons choisi pour des raisons de
simplicité de représenter chaque politique par un fichier XML séparé.
7.4.3.2 Les communautés des paramètres non fonctionnels
Plusieurs politiques représentant des PNF peuvent être attachées à un service. Chaque politique
est définie par le fournisseur de service et appartient à une catégorie bien particulière. En se
basant sur ces catégories nous avons classé ces politiques en plusieurs communautés. Il existe
plusieurs définitions de communauté. Les auteurs dans (Benatallah et al., 2003) définissent une
communauté comme une collection de services qui offrent les mêmes fonctionnalités. Ces
services n'ont pas forcément les mêmes propriétés non fonctionnelles. De plus, les auteurs dans
(Medjahed and Bouguettaya, 2005) présente une communauté comme étant un moyen pour
fournir une organisation ontologique des services qui partage le même domaine d'intérêt. Dans
notre travail, on considère une communauté comme un simple container qui va grouper un
ensemble de politiques représentant des paramètres non fonctionnels.
Une communauté est considérée comme un Web service appelé service de communauté (SC) qui
peut être créé et invoqué comme un Web service ordinaire. De ce fait, de nouvelles catégories de
PNF peuvent être ajoutées facilement. En effet, l'ajout d'une nouvelle catégorie de paramètre non
fonctionnel correspond à la création et le déploiement d'un nouveau service de communauté qui
possède la même catégorie. Les communautés sont construites par des fournisseurs de
communautés qui peuvent être par exemple un consortium particulier, un groupe d'organisation
qui contribue dans une place de marché ou tout simplement un administrateur.
131
Un service de communauté (SC) supervise toutes les politiques des PNF qu'il regroupe. Ces
politiques possèdent la même catégorie. Une communauté C est définie formellement de la
manière suivante :
C= < ID_Community, Cg, memberList, scale, RuleSet>, où
ID_Community représente l'identifiant de la communauté, Cg est la catégorie de la communauté
et correspond à la catégorie des PNF regroupés par la communauté. L'attribut memberList est
défini par le couple <ID_WS, ID_Policy> où ID_WS est l'identifiant du service et ID_Policy est
l'identifiant de la politique attaché à ce service et dont la catégorie est Cg. L'attribut scale
représente l'échelle de mesure relative aux politiques de la communauté. Finalement, l'attribut
RuleSet= {Ri, …Rn} représente l'ensemble des règles de transformation Ri attachées à la
communauté et qui sont utilisées dans le processus de matching entre deux politiques.
La mise à jour de l'attribut memberList d'un SC peut se faire avec deux techniques différentes : (i)
la méthode pull ou (ii) la méthode push. La méthode pull impose au service de communauté de
vérifier les mises à jour au niveau du registre UDDI en utilisant les deux méthodes spécifiques :
find_tModel et find_service (de l'API UDDI). Le problème principal avec cette technique réside au
niveau de la fréquence de mise à jour de la liste des membres : une grande fréquence implique
une surcharge au niveau du registre et une fréquence faible engendre une liste de membre
obsolète. La méthode push met à jour la liste des membres d'une communauté chaque fois
qu'une nouvelle politique est publiée.
7.4.3.3 L'assistant des politiques des PNF
La création des PNF est assurée par le fournisseur de service en utilisant un Assistant de Politiques
Non fonctionnelles (APN). Les APN sont des agents logiciels qui assistent l'interaction entre, d'une
part les fournisseurs de services et le registre UDDI pour enregistrer les politiques et d'autre part
entre le fournisseur de service et les services de communautés afin de mettre à jour la liste des
membres d'une communauté. Chaque fournisseur possède un APN qui lui est associé.
Un fournisseur de service peut créer plusieurs politiques en se basant sur le WS‐Policy étendu. Le
fournisseur de service doit fournir l'URL et la catégorie Cg de chaque paramètre non fonctionnel à
son APN qui se charge de créer les documents XML relatif à chaque paramètre (à chaque
politique). Par la suite, l'APN expose ce document comme étant un tModel et poursuit son
attachement au service dans le registre UDDI. Finalement, la communauté ayant comme
catégorie Cg va être notifié de la création d'une nouvelle politique afin qu'elle met à jour sa liste
de membres.
7.5 La construction du processus collaboratif
Pour la construction d'un processus collaboratif à base de composition de service, nous avons
opté pour un type particulier de composition que nous avons appelé configuration dynamique de
processus. Ce dernier se base sur la création manuelle d'un schéma de processus et utilise des
mécanismes de sélection automatiques de service pour construire un processus exécutable. Un
processus abstrait représente un processus dont les flux de donnée et de contrôle sont définis,
132
mais les services concrets qui supporteront le processus ne sont pas encore fixés. L'avantage
d'une telle approche est que la complexité des flux de contrôle peut être réduite en utilisant une
approche manuelle vu que les processus de collaboration sont assez complexes par nature.
La construction du processus collaboratif se fait en deux étapes :
1. la construction du schéma du processus collaboratif
2. la découverte et la sélection de service
7.5.1 Le schéma du processus collaboratif
Un Schéma de Processus Collaboratif (SPC) est la spécification du processus collaboratif
interentreprise. Nous avons choisi d'exprimer le SPC dans un langage orienté utilisateur en
utilisant une notation visuelle. En se basant sur ce schéma, les services d'entreprises vont être
sélectionnés et une description du processus avec les services concrets va être généré. Les
éléments de base du schéma du processus collaboratif sont les Goal Templates, les liens de
contrôle et les connecteurs. Formellement, un schéma de processus collaboratif est défini de la
manière suivante :
SPC = < GTs, C, L > où :
GTs est l'ensemble des Goal Templates.
C est l'ensemble de connecteurs.
L∈(GTs∪C)× (GTs∪C) est l'ensemble des liens de contrôle qui décrivent les connections
entre les Goal Templates.
Les Goal Templates représentent les unités de travail qui doivent être accomplies par les
entreprises collaboratives dans le but de répondre aux objectifs du processus collaboratif. Ils
jouent le rôle d'un patron qui va être utilisé pour l'identification des services candidats pouvant
être impliqués dans le processus collaboratif. Un Goal Template représente les exigences d'un
consommateur vis‐à‐vis du service à sélectionner. La spécification d'un Goal Template rejoint
l'abstraction que nous faisons pour la définition d'un service entant qu'une intersection de deux
ensembles de spécifications fonctionnelles et non fonctionnelles. Par conséquent un Goal
Template est défini formellement de la manière suivante :
GT= <ID_Template, PFset, PNFset> où:
• ID_Template est l'identifiant du Goal Template,
• PFset est l'ensemble de paramètres fonctionnels qui caractérisent le Template. Ils
correspondent aux caractéristiques fonctionnelles du service candidat à chercher.
• PNFset est l'ensemble de paramètres non fonctionnels qui caractérisent le Template. Ils
correspondent aux propriétés non fonctionnelles du service à chercher.
Les liens de contrôle décrivent les connexions entre les différents Goal Templates et définissent la
structure du flux qui correspond à l'ordre des Goal Templates dans le schéma et par suite l'ordre
des services dans le processus collaboratif. Un Goal Template peut avoir uniquement un seul lien
133
de contrôle en entrée et un lien de contrôle en sortie. Deux Goal Templates peuvent être
directement connectés par un lien de contrôle, sinon, on peut insérer des connecteurs particuliers
entre eux. On définit 6 types de connecteurs (Figure 7.8) :
Start et End qui sont utilisés pour modéliser le début et la fin du processus.
And‐fork : tout les Goal Template (ou dans un deuxième temps les services candidats)
vont s'exécuter d'une manière concurrente.
And‐join : tous les services prédécesseurs doivent se terminer avant de terminer
l'exécution du reste du processus.
OR‐fork : chaque lien de contrôle qui sort de ce type de connecteur est associé avec une
condition. Les conditions sont évaluées instantanément et ce n'est que les services qui
vérifieront leurs conditions qui seront déclenchées.
OR‐join : dès qu'un service parmi les prédécesseurs termine son exécution, le processus
passe au service suivant.
Figure 7.8 : Les 6 types de connecteurs
La Figure 7.9 présente un exemple d'un schéma de processus formé par trois Goal Templates.
Figure 7.9 : Exemple de schéma de processus collaboratif
7.5.2 Framework de découverte et de sélection de service
Une fois le schéma de processus collaboratif est défini avec tous les Goal Templates, les liens de
contrôle et les connecteurs, commence la deuxième étape dans notre démarche de construction
du processus collaboratif. Cette deuxième étape consiste à découvrir et sélectionner l'ensemble
des services qui correspondent aux descriptions faites dans les Goal Templates.
134
Nous allons tenir compte dans notre processus de découverte et de sélection que des paramètres
non fonctionnels des services. La sélection fonctionnelle des services ne sera pas traitée dans
notre démarche de sélection vu le nombre des travaux qui ont été fais dans ce domaine.
Notre Framework de découverte et de sélection de services est présenté dans la Figure 7.10 .
Figure 7.10 : Framework de découverte et de sélection de services
Le moteur de sélection (MS) envoie une Requête de Matching RM= match‐PNF(ID_template) au
Moteur de Matching des Paramètres non fonctionnels (MMP) où ID_Template est l'identifiant du
Goal Template à qui on va chercher le service correspondant (étape 1). Le MMP va récupérer les
différents paramètres non fonctionnels qui ont été mentionnés dans le Goal Template (étape 2).
Ces paramètres sont décrits sous forme de politiques. Par la suite, le MMP va décomposer la
requête de matching initiale (RM) en plusieurs sous‐requêtes SRM(Cg, ID_Policy) en se basant sur
les différentes catégories de politiques spécifiées dans le Goal Template. Chacune de ces sous‐
requêtes va être transférée au service de communauté de paramètres qui possède la même
catégorie Cg (étape 3). Les services de communautés vont tenir compte de ces sous‐requêtes et
vont procéder au matching des différentes policyTemplates avec les politiques appartenant à
leurs listes des politiques membres. Toutes les politiques compatibles vont être envoyées au
MMP (étape 4). Le MMP collecte les différentes listes de réponses envoyées par les services de
communautés pour entamer une phase d'intersection entre elles afin de déterminer une liste des
services candidats pouvant satisfaire les spécifications du Goal Template (étape 5). Cette liste va
être envoyée par la suite au moteur de sélection (MS). Finalement, le moteur de sélection va
calculer les dissimilarités entre les politiques demandées (politiques spécifiée dans le Goal
Template) et les politiques offertes (Politiques des services candidats) qui possèdent les mêmes
catégories pour calculer à la fin la distance entre chaque service candidat et le Goal Template
(étape 6). Le service possédant la plus petite distance sera le plus adéquat pour remplacer le Goal
135
Template dans le processus de collaboration final. Dans cette dernière phase, le MS peut entamer
une phase de négociation avec les fournisseurs de services dans le but de modifier les politiques
susceptibles d'être modifiées (politiques qui sont déclarées négociables par le fournisseur). Cette
étape de négociation va être présentée en détail dans la suite de ce chapitre.
7.5.2.1 Le moteur de matching des PNF
Le MMP est un élément clé dans notre Framework de découverte et de sélection de service. Il
reçoit la requête de matching depuis le moteur de sélection (MS) et retourne à la fin une liste des
services candidats susceptibles de remplacer le Goal Template dans le processus collaboratif. Le
MMP est développé comme étant un Web service qui possède quatre opérations : (i)
updateListOfCommunity, (ii) updateListOfNPA, (iii) notifyNPA et (iv) matchService. Les trois
premières opérations sont utilisées pour gérer les communautés et les agents des paramètres
non fonctionnels. D'une part, l'opération updateListOfCommunity est utilisée par les fournisseurs
de services quand une nouvelle communauté est créée dans le but de mettre à jour la liste
existante des communautés du MMP. Cette liste contient l'identifiant de chaque communauté
(ID_Community) ainsi que la catégorie Cg de la communauté. D'autre part, l'opération
updateListOfNPA est invoquée par les fournisseurs de services quand un nouvel agent est
déployé. Finalement, puisque le MMP contient une liste de toutes les communautés existantes,
l'opération notifyNPA est utilisée pour notifier les différents agents de la création d'une nouvelle
communauté. L'opération notifyNPA envoie l'identifiant de la nouvelle communauté ainsi que sa
catégorie.
L'opération la plus importante du MMP est l'opération matchService. Le but de cette opération
est de faire le matching entre les politiques représentant les paramètres non fonctionnels d'un
Goal Template avec les politiques des services publiés dans le registre de services. Elle retourne
un ensemble de service appelé les services candidats. Les politiques de ces services sont
compatibles avec les politiques spécifiées dans le Goal Template. Le moteur de sélection invoque
l'opération en envoyant l'identifiant du Goal Template en question.
La Figure 7.11 présente un aperçu sur l'algorithme exécuté par l'opération matchService.
L'algorithme est composé de deux phases. Le but de la première phase (lignes 2‐7) est d'invoquer
l'opération matchNFPpolicy du service de communauté approprié. Pour cette raison, le MMP
récupère toutes les politiques du Goal Template (ligne 4). Par suite, le MMP vérifie les catégories
de ces politiques (ligne 6) et récupère l'identifiant de la communauté (ID_Community) qui
correspond à chaque catégorie de politique (ligne 7).
A ce stade commence la deuxième phase (lignes 8‐13). Le MMP invoque l'opération
matchNFPpolicy exposée par le service de communauté correspondant à l'identifiant de
communauté récupéré (ligne 8). Chaque SC interrogé répond par l'envoie d'une liste des services
candidats. Cette liste contient les identifiants des services dont les politiques non fonctionnelles
sont compatibles avec une politique particulière du Goal Template (lignes 9‐11). Plus de détail
concernant matchNFPpolicy sera présenté dans la prochaine section. Les dernières instructions
(lignes 6‐15) sont répétées pour chaque politique identifiée dans le Goal Template. Finalement, le
136
MMP retourne la liste des services candidats au moteur de sélection (linge 16). Un service est
considéré comme un membre de cette liste si toutes ses politiques sont compatibles avec celles
extraites du Goal Template.
(01) Function matchService (ID_Template) matchedWS= { }; (03) response=1; WSPolicySet = getAllPolicy (ID_Template); (05) For P in WSPolicySet Do PolicyCategory = getCategory(ID_Policy); (07) ID_Community = getCommunityID(PolicyCategory, communityList); Invoke matchNFPpolicy(ID_Policy) Of ID_Community (09) candidateService = matchNFPpolicy(ID_Policy, ID_WS); If response == 1 Then (11) matchedService = candidateService; Else (13) matchedService = matchedWS candidateService; response = response+1; (15) End DO (16) return (ID_WS, matchedWS)
Figure 7.11 : L'algorithme du MMP
7.5.2.2 L'évaluation de la compatibilité des politiques
Le service de communauté gère les politiques non fonctionnelles qui ont la même catégorie. Le
service de communauté offre deux opérations : (i) updateCommunityListMember et (ii)
matchNFPpolicy.
L'opération updateCommunityListMember possède deux paramètres : ID_WS et ID_Policy. Elle est
invoquée par l'agent des politiques non fonctionnelles au moment de la création des politiques.
En effet, quand un fournisseur de service utilise son agent pour la création d'une nouvelle
politique (ID_Policy) attaché à un service (ID_WS), il doit impérativement communiquer sa
catégorie. A son tour, l'agent met à jour la liste des membres de la communauté possédant la
même catégorie que la politique. L'opération matchNFPpolicy est une opération de type in/out
qui va être invoquée par le MMP dans le but d'évaluer la compatibilité de deux politiques non
fonctionnelles. Comme c'est déjà mentionné dans la figure précédente, l'opération
matchNFPpolicy possède un seul paramètre qui est le ID_Policy et qui correspond à une politique
particulière du Goal Template. L'opération matchNFPpolicy vérifie la compatibilité de cette
politique d'entrée avec l'ensemble des politiques de la communauté.
Le matching entre deux politiques comporte deux phases : (i) la phase d'unification et (ii) la phase
d'évaluation de compatibilité.
La phase d'unification
La phase d'unification des politiques représentant les paramètres non fonctionnels consiste à
normaliser la forme ou la représentation des politiques dans le but de pouvoir les comparer.
137
Plusieurs exemples d'unification peuvent être cités comme par exemple mettre les politiques avec
la même unité de mesure ou transformer deux assertions de politique en une seule équivalente
(voir Figure 7.3). D'autres types d'unification peuvent être envisageables concernant les attributs
temporaires et les attributs de localité. Par exemple, on peut déduire que Lyon est une ville
localisée en France ou que Lyon est une ville européenne.
Afin d'assurer cette unification, les services de communauté utilisent des règles de transformation
et les connaissances de domaine pour raisonner sur les assertions des politiques. L'utilisation des
règles de transformation dépend de la valeur MatchPolicy déclaré dans l'extension que nous
avons faite au WS‐Policy. En effet, les transformations ne peuvent avoir lieu que si la valeur de
MatchPolicy est égale à "ont".
On peut considérer par exemple, le cas présenté dans la Figure 7.3 dans lequel une phase
d'unification est nécessaire pour unifier la représentation des deux politiques. C'est le rôle des
règles de transformation qui se base sur les connaissances du domaine pour accomplir cette
unification et aider à générer une nouvelle assertion pour le temps de réponse qui est plus utile
au processus de matching. Pour cet exemple on peut utiliser la règle de transformation suivante:
If there exists a policy P, which has an alternative ALT, which has an Assertion A1, which states
that "ExecutionTime = X" and an Assertion A2, which states that "NeworkTime = Y", then create a
new Assertion A3 which states that "ResponseTime = X + Y".
La phase d'évaluation
La seconde phase est la phase d'évaluation dans laquelle on vérifie la compatibilité de deux
politiques non fonctionnelles sans s'intéresser nécessairement au calcul exact de la dissimilarité
entre eux. Deux politiques fonctionnelles sont compatibles s'ils existent au moins deux
alternatives qui sont compatibles. D'une manière générale, la compatibilité entre deux
alternatives peut être définie comme la capacité d'une alternative à vérifier les exigences (les
besoins) d'une autre alternative. En d'autres termes, supposons qu'on a deux alternatives A et B,
A est compatible avec B ( ) si et seulement si les assertions de type capacités (CA) match
( ) avec les assertions de type exigence (RA) de l'alternative B et les assertions de type exigence de A match avec les assertions de type capacité de l'alternative B.
Soient CAset et RAset deux ensembles qui désignent respectivement les ensembles des assertions
de type "capacité" et "exigence" d'une alternative.
La compatibilité entre deux alternatives est définie de la manière suivante :
_ , . _ , . _
Une assertion de type capacité satisfait une assertion de type exigence si la valeur de la première
satisfait la valeur de la deuxième.
Le résultat de l'évaluation de la compatibilité deux politiques (politique source et politique
membre) est une valeur booléenne. On peut obtenir la valeur "vraie" dans deux cas différents :
138
Quand les deux politiques sont compatibles, c'est‐à‐dire quand la politique source est
compatible avec la politique membre.
Quand la politique source n'est pas compatible avec la politique membre, mais la
politique membre est de type négociable, c'est‐à‐dire qu'on peut négocier une éventuelle
modification de sa valeur avec le fournisseur de services.
La valeur "faux" est obtenue, par conséquent, quand les deux politiques ne sont pas compatibles
et la politique membre n'est pas négociable.
Le cas de non‐compatibilité est pris en compte car dans la décision finale de sélection des services
dépend du calcul de la distance global entre les politiques sources (les politiques définies dans le
Goal Template) et les politiques du service candidat. Dans certains cas, la meilleure distance (la
distance minimale) peut être obtenue avec un service possédant une ou plusieurs politiques non
compatible mais leurs valeurs sont négociables. Ce cas est traité dans notre Framework de
sélection et le moteur de sélection entame une phase de négociation avec le fournisseur de
services pour un éventuel changement des valeurs initiales de ses politiques de services dans le
but qu'elles correspondent aux valeurs demandées. Dans ce cas, le moteur de sélection recalcule
les distances en tenant compte des valeurs négociées et les majorations qui peuvent être
ajoutées.
Dans la phase d'évaluation de compatibilité, le service de communauté utilise des règles
d'évaluation afin de décider si une politique source est compatible avec une politique membre.
Chaque communauté possède son propre ensemble de règles d'évaluation enregistrées dans une
base de règles. La syntaxe d'une règle d'évaluation est le suivant :
La première règle d'évaluation prend en considération deux politiques de catégorie "Response
Time" et d'échelle de mesure "rapport". Cette règle d'évaluation précise que la politique membre
(P2) est compatible avec la politique source (P1) si elle est inférieure ou égale. La deuxième règle
d'évaluation traite la compatibilité entre deux politiques appartenant à la catégorie "Monitoring"
et l'échelle de mesure "nominale". Ces deux dernières sont compatibles quand au moins une
valeur de l'ensemble des valeurs de la politique membre (P2) appartient à l'ensemble des valeurs
de la politique source (P1).
Finalement, l'opération matchNFPpolicy envoie la liste des services candidats au moteur de
sélection. Quant une politique membre a été le sujet d'une unification, sa nouvelle valeur est
communiquée au moteur de sélection. Cette nouvelle valeur va être prise en compte dans la
dernière phase de sélection de services.
7.5.2.3 La phase de sélection : calcul de distance, classification et négociation
Après avoir reçu l'ensemble des services candidats envoyés par le MMP, le moteur de sélection
commence par construire la Matrice Initial de Sélection , 1 , 1 dans
laquelle chaque ligne correspond à un service particulier et chaque colonne représente un paramètre non fonctionnel.
, , … ,
, , … ,
, , ,
(1)
Vu que nous avons tenu compte des paramètres négociables dans l'étude de la compatibilité des
politiques, la matrice , sera examinée et les lignes dont plus que la moitié de leurs
valeurs sont "non compatibles mais négociables" seront éliminées. De cette façon, nous pouvons
le temps d'exécution de la procédure de sélection en évitant plusieurs tentatives de négociation
avec les fournisseurs de services. La matrice résultante est appelée la matrice finale de sélection
, 1 , 1 :
140
, , … ,
, , … ,
, , ,
(2)
La sélection de service est basée sur le calcul de la distance entre les services présentés dans la
matrice FSM et le Goal Template. Nous avons utilisé pour ce calcul la distance de Minkowski :
, , , (3)
Où correspond au service candidat et est le Goal Template. est la formule qui calcul la
dissimilarité entre deux politiques , et , .. , est la k ème politique d'un service i de la
matrice FSM. , est la politique du Goal Template s. La formule utilisée pour le calcul de
dissimilarité dépend de l'échelle de mesure des politiques.
7.5.2.3.1 Les formules de dissimilarité
Pour chaque type d'échelle de mesure, nous allons définir la formule de calcul de dissimilarité
correspondante entre deux politiques. Toutes les dissimilarités qui vont être calculées seront
normalisées.
Cas de l'échelle "rapport"
Les politiques qui appartiennent à l'échelle "rapport" sont des politiques quantitatives. On a
identifié deux sous‐classes dans les paramètres appartenant à l'échelle de mesure rapport :
des paramètres négatifs : plus la valeur du paramètre est petite plus elle est mieux
convenable, comme par exemple le paramètre temps de réponse ou le paramètre coût,
des paramètres positifs : plus la valeur est grande, plus elle convient le mieux, comme par
exemple la fiabilité.
Pour les paramètres négatifs la dissimilarité est calculée selon les équations 4 et 5. Pour les
paramètres positifs on utilise les équations 6 et 7.
, ,
1 , ,
max (4)
, ,
1 , ,
max
(5)
, ,
1 , ,
max
(6)
, ,
141
1 , ,
max
(7)
Cas de l'échelle "nominale" et "intervalle"
L'échelle "nominale" représente des paramètres qualitatifs qui sont décris par un ensemble de
valeur. L'échelle intervalle représente des paramètres qui sont décris par des intervalles. Dans ces
deux cas, nous allons utiliser la fonction de dissimilarité d'Ichino ‐ Yaguchi (Ichino and Yaguchi,
1994)qui se base sur l'opérateur de l'union jointe :
, , , , , ,12
2 , , , , (8)
où | | représente le cardinal de l'ensemble des valeurs dans le cas de l'échelle "nominale" et
l'étendue de l'intervalle dans le cas d'une échelle "intervalle". est l'opérateur de l'union jointe
qui est défini de la manière suivante:
, , , , , si , et , représentent deux intervalles
, et , . , , , , si , and , représentent deux ensembles de valeurs.
Dans le but d'avoir des dissimilarités normalisées, la dissimilarité de Ichino‐Yaguchi sera divisée
par la valeur .
, ,, , où
| , , , | dans le cas d'une échelle "intervalle". = le nombre des valeurs distinctes dans le cas d'une échelle "nominale".
Cas de l'échelle "ordinale"
Dans le cas d'une échelle "ordinale", les valeurs des politiques sont ordonnées dans une table X.
Ces valeurs seront remplacées par leurs rangs respectifs , 1, 2, … , où est le
nombre des valeurs distinctes dans les deux politiques. Ces valeurs seront traitées en utilisant la
formule suivante qui offre une variation entre 0 et 1.
11 (9)
Les nouvelles valeurs obtenues seront traitées comme des valeurs appartenant à l'échelle de
mesure "rapport".
7.5.2.3.2 Phase de classement et de négociation
Le moteur de sélection calcule les dissimilarités entre les politiques sources (politiques extraites
du Goal Template) et les politiques des services candidats. Par la suite, le moteur de sélection
calcule la distance globale (distance de Minkovski) entre chaque service candidat et le Goal
Template. Les services candidats seront classés en fonction de leurs distances globales. Le premier
service dans le classement de la liste ordonnée est celui qui convient le mieux à la description du
142
Goal Template. En effet, ce service dispose de la distance la plus courte. Toutefois, le service
sélectionné peut avoir des paramètres non fonctionnels qui ne sont pas compatibles mais ont été
pris en compte dans les calculs car ils sont négociables. Dans ce cas, le moteur de sélection
commence une phase de négociation avec le fournisseur de services afin de négocier ces
paramètres. Le moteur de sélection demande aux fournisseurs de service de modifier les valeurs
concernées afin de mieux répondre à la demande. Les valeurs négociées seront modifiées, mais le
fournisseur de services peut demander des frais supplémentaires Dans ce cas (ajout de frais
supplémentaires), le moteur de sélection calcule de nouveau les dissimilarités entre les politiques
et calcule également les distances globales pour offrir finalement une nouvelle liste ordonnée des
services candidats. Si le service qui a fait l'objet d'une négociation est toujours classé en premier,
il sera choisi comme étant le service le plus adéquat à la description du Goal Template et par
ailleurs, le plus approprié au processus de collaboration. Sinon, le moteur de sélection répète le
même processus avec le nouveau premier service dans le classement jusqu'à aboutir à un choix
final.
7.6 Évaluation et prototype
7.6.1 Test et Évaluation de la méthode de sélection de service
Afin de mieux présenter les différentes phases de la méthode de sélection que nous avons
exposées dans ce chapitre nous allons proposer un exemple d'étude de 10 services présentés
dans le tableau suivant (Tableau 7.2). Nous allons supposer que tous les services possèdent les
mêmes fonctionnalités, mais présentent des paramètres non fonctionnels différents. Les colonnes
qui représentent les services sont divisées en deux parties. La première partie contient les valeurs
correspondantes aux paramètres non fonctionnels (Temps de réponse, Coût et Méthode de
Payement). La deuxième partie expose la flexibilité du paramètre. Rappelons qu'un paramètre
peut être soit négociable (N) ou non négociable (NN).
143
Services Temps de Réponse Coût Méthode de payement
S1 85 100 VISA;MasterCard;AmericanExpress N N NN
S2 91.75 93 VISA;MasterCard N NN NN
S3 117 90 MasterCard NN NN NN
S4 70 90 VISA;MasterCard;AmericanExpress NN NN NN
S5 105.2 90 VISA;MasterCard N N NN
S6 224 90 VISA NN NN NN
S7 99.2 89 VISA;AmericanExpress NN NN NN
S8 108.2 88 VISA N NN NN
S9 125.2 88 AmericanExpress N NN NN
S10 110.3 87 MasterCard N NN NN
Tableau 7.2 : Exemple de Web services avec leurs paramètres non fonctionnels
Nous allons effectuer une sélection de service selon la requête suivante :
Requête= (Temps de Réponse =100, Coût= 90, Méthode de Payement=MasterCard)
La première phase est la phase de matching qui consiste en une étape d'unification et une étape
d'évaluation. Pour des raisons de simplicité nous allons considérer que tous les paramètres ont la
même forme et sont exprimés avec la même unité. La phase d'évaluation vérifie la comptabilité
entre la politique source et la politique cible. Le degré de flexibilité est pris en compte dans la
phase d'évaluation et on peut remarquer que les services numéro 5 et 10 (voir tableau 7.3) sont
inclus quoique leurs temps de réponse soient plus grands que la valeur demandée dans la
requête, mais leurs valeurs sont négociables.
Dans le Tableau 7.4, nous avons calculé les dissimilarités entre les paramètres en utilisant la
bonne formule en se basant sur l'échelle de mesure à qui appartient le paramètre non
fonctionnel. Le tableau 7.5 contient les distances globales. Le premier service correspond le mieux
à la requête. Dans le cas où le premier service posséderait un paramètre qui n'est pas compatible,
le moteur de sélection doit commencer une phase de négociation avec le fournisseur de service
afin de la modifier pour correspondre à la requête. Dans le cas d'un extra coût, le moteur de
sélection doit recalculer les distances et refaire un nouveau classement.
144
Requête 100 90 MasterCard
S1 85 100 VISA;MasterCard;AmericanExpress N N NN
S4 70 90 VISA;MasterCard;AmericanExpress NN NN NN
S5 105.2 90 VISA;MasterCard N N NN
S10 110.3 87 MasterCard N NN NN
Tableau 7.3 : Vérification de la compatibilité
Requête 100 90 MasterCard
S1 0.6277916 1.7692308 0.3333333 N N NN
S4 0.2555831 1.0 0.3333333 NN NN NN
S5 1.1290321 1.0 0.25 N N NN
S10 1.2555832 0.7692308 0.0 N NN NN
Tableau 7.4 : Vérification de la compatibilité
Services Distances finales S4 1.0846353311832513S10 1.4724826052663202S5 1.5287947920618226S1 1.9066754476082728
Tableau 7.5 : Calcul de distance globale entre service requête
Afin de montrer l'importance des paramètres non fonctionnels dans l'amélioration du processus
de sélection des services et la pertinence de notre méthode, nous l'avons appliqué sur une base
de service qui compte 364 Web services. Cette base a été présentée la première fois par (Elmasri
et al, 2007). Nous nous sommes basés sur cette base à laquelle nous avons ajouté de nouveaux
paramètres et modifié la représentation. Nous avons supposé que tous les services présentent les
mêmes fonctionnalités. La première requête que nous avons appliqué se basait sur des mots‐clés
et à chaque fois on ajoutait un nouveau paramètre à la requête. L'évolution du nombre des
services retenus et le nombre de paramètres dans la requête sont présentés dans la Figure 7.12.
145
Figure 7.12 : Évolution du nombre de services retenus par le moteur de sélection suivant le nombre de paramètre non fonctionnel
Le temps de réponse de notre moteur de sélection augmente avec le nombre de paramètres non
fonctionnels à traiter. Les tests que nous avons faits sont exécutés dans un environnement de test
qui possède les caractéristiques résumées dans le tableau suivant (Tableau 7.6)
Système d'exploitation Windows Vista business Java Virtual machine Sun Java Run Time Environment
1.5.0_10 RAM 2 GB Processeur Intel centrino
Tableau 7.6 : Caractéristique de l'environnement de test
L'évolution du temps d'exécution selon le nombre de paramètres non fonctionnels est présentée
dans la Figure 7.13.
Figure 7.13 : Évolution du temps d'exécution par rapport au nombre de paramètres dans la requête
7.6.2 Prototype générale pour la construction du processus collaboratif
L'objectif de cette section est d'exposer le prototype que nous avons développé pour la sélection
de services et de construction de processus collaboratif.
0
50
100
150
200
250
300
350
400
0 2 4 6 8 10 12
Nombre de service
Web service returned by the request
Nombre de PNF
0
500
1000
1500
2000
2500
0 2 4 6 8 10 12
Execution time (ms)
Execution time
Number of NFPs
146
7.6.2.1 Architecture du prototype
Le prototype que nous avons développé se compose de quatre modules (Figure 7.14):
1. Module de construction du schéma de processus
Ce module se préoccupe de la réalisation du schéma de processus collaboratif. C'est un
environnement de conception qui permet de dessiner le processus sous forme de Goal Templates
et d'activités de contrôle.
2. Module de génération de description XML.
Ce module permet de générer des fichiers de type XML. En premier lieu, il permet de construire
des fichiers WS‐Policy à partir des Goal Templates. En second lieu, après la phase de sélection ce
module assure la génération d'un fichier de description du processus collaboratif avec les services
retenus. Nous nous sommes contentés d'une simple description en XML du processus et on
envisage de l'étendre par la suite pour avoir une description exécutable en BPEL.
3. Module de sélection de service
Ce module permet de découvrir et de sélectionner les services selon l'approche qui a été
présentée dans ce chapitre. Il est composé de deux sous module : (i) le module de matching des
paramètres non fonctionnels et le module de sélection de service selon les calculs de dissimilarité
que nous avons déjà exposés.
4. Module d'ontologie et de gestion de communauté
Ce module permet la gestion de l'ontologie de catégorisation des paramètres non fonctionnels
que nous avons développée et les autres ontologies de domaine (ontologie d'unité et
d'opérateur) ainsi que la gestion des communautés de paramètres non fonctionnels.
Figure 7.14 : Architecture générale du prototype
147
7.6.2.2 Technologies utilisées et prise d'écran du le prototype développé
Technologies utilisées
Le prototype a été développé avec le langage Java et avec l'environnement de développement
Eclipse 3.2. Nous avons utilisé le JUDDI pour le développement du registre de service. L'API Jena
et l'outil Protégé ont été utilisés pour le développement et la manipulation des ontologies.
Finalement, l'API JDOM a été utilisé pour la génération et la manipulation des fichiers XML.
Prise d'écran du prototype
L'interface principale du prototype est présentée dans la Figure 7.15. Elle correspond à une partie
de conception de processus, une barre d'outils contenant les différents éléments de dessin, un
explorateur de processus qui permet de naviguer facilement dans les différents éléments du
processus (à gauche), et finalement une partie représentant les différentes actions réalisées ainsi
que le résultat du processus de sélection (en bas).
Figure 7.15 : Interface principale du prototype
Cet outil nous permet de dessiner le schéma du processus collaboratif à l'aide des Goal Templates
et des activités de contrôle (Figure 7.16 (a)). Les Goal Templates doivent être par la suite
configurés en leur attribuant un nom, un descriptif (Figure 7.16 (b)) et l'ensemble des paramètres
non fonctionnels (Figure 7.16 (c)).
148
(a): Schématisation du processus collaboratif (b): Vue de l'interface spécifique à la configuration
des paramètres non fonctionnels
(c): Configuration des paramètres non fonctionnels du Template
Figure 7.16 : Conception du schéma du processus et configuration des Goal Templates
Pour la configuration des paramètres non fonctionnels, on commence par télécharger l'ontologie
de catégorisation des paramètres non fonctionnels. Les paramètres sont configurés un par un et
ajoutés à la description de la Goal Template (Figure 7.17).
149
Figure 7.17 : Chargement de l'ontologie représentant les différentes catégories des PNF et l'ajout des paramètres non fonctionnels
Une fois l'attribution des paramètres non fonctionnels nécessaires au Goal Template est
terminée, nous pouvons ainsi commencer la phase de recherche en prenant comme requête la
description de cette Template. Le résultat de la recherche est affiché dans la partie inférieure du
prototype (Figure 7.18).
Figure 7.18 : La sélection du service correspondant à la description du Goal Template
150
Après avoir terminé la description du processus et lancer la procédure de sélection de service
(Figure 7.19), le prototype nous permet de générer une description en XML du processus de
collaboration (Figure 7.20).
Figure 7.19 : Enregistrement du schéma du processus
Figure 7.20 : Prise d'écran de la description du processus générée
7.7 Conclusion
Dans ce chapitre, nous avons présenté notre démarche de construction du processus collaboratif
interentreprises à base de composition de service. Nous avons mis le point sur le rôle que jouent
les paramètres non fonctionnels dans la sélection de service. Nous avons commencé par identifier
151
les différentes catégories des paramètres non fonctionnels et apporté une extension au WS‐Policy
pour modéliser ces paramètres non fonctionnels sous forme de politiques. Une autre extension
est apportée aussi à l'UDDI pour attacher ces paramètres aux services lors de leurs publications.
La construction de processus collaboratif se base sur une manière spéciale de composition de
service : la composition semi‐automatique. On commence par établir le schéma de processus
dont les éléments clés sont les Goal Templates. Ces derniers jouent le rôle de patron et servent à
spécifier les exigences vis‐à‐vis des services à sélectionner. Les Goal Templates seront remplacés
par les services d'entreprise dans un deuxième temps. En effet, une fois le schéma de processus
collaboratif est établi, on commence la phase de découverte et de sélection orientée paramètres
non fonctionnels. Nous avons utilisé des formules de calcul de dissimilarités entre les paramètres
offerts et requis. Finalement une distance globale est calculée entre le Goal Template et les
services qui lui sont compatibles pour sélectionner le service le plus adéquat.
152
153
Chapitre 8 Conclusion générale et perspectives
" Je ne campe pas sur le passé, j'en tire des conclusions pour le présent ".
Eric Fisher
8.1 Bilan des travaux
Cette thèse a traité le problème de la collaboration interentreprises d'un point de vue particulier.
Son but final était de présenter le concept de l'Entreprise Orientée Services comme étant une
solution permettant aux entreprises de surmonter les problèmes qui freinaient ce genre de
pratique et assurer, par la suite, une collaboration dynamique qui satisfait les attentes de
l'entreprise.
Dans notre démarche, pour argumenter le choix du développement de l'Entreprise Orientée
Services, nous avons procédé par étapes. Cette argumentation était le sujet du chapitre 2 dans
lequel nous avons exploré, dans un premier temps les principaux enjeux spécifiques à
l'environnement actuel des entreprises. Nous avons conclu qu'en quête de compétitivité, les
entreprises doivent forcément présenter des architectures agiles et s'approprier impérativement
les pratiques de collaborations interentreprises. Dans un second temps, ce chapitre a exposé les
limites qui caractérisent les architectures actuelles des entreprises et qui réduisent leurs
compétitivités notamment les limites concernant son Système d'Information. Par la suite, nous
avons pris en détail la notion de services et nous avons énuméré les différentes caractéristiques
et avantages que peut apporter une telle orientation service. Finalement, nous avons croisé les
limites des architectures de l'entreprise déjà identifiées et les apports de l'orientation service.
Nous avons conclu qu'une telle orientation peut apporter des solutions aux différents problèmes
et contraintes énoncés. Fort de ce constat, nous avons choisi de restructurer l'entreprise selon
une Architecture Orientée Services (SOA) ce qui a constitué notre première contribution à savoir
le concept de l'Entreprise Orientée Services. Par la suite, nous avons développé une approche
154
pour la sélection et la composition de services afin de construire les processus de collaboration
interentreprises.
Notre travail dans la première partie de la thèse était principalement un travail de reconstruction
et de réingénierie de l'entreprise. Il est indispensable, par conséquent, de connaître les différents
éléments qui la constituent. Ces éléments doivent être modélisés afin de maîtriser leurs
complexités et être en mesure de les restructurer. Dans cette orientation, le premier chapitre de
l'état de l'art (chapitre 3) a exposé quelques méthodes de modélisation de l'entreprise. Nous
avons mis l'accent sur les différents méta‐modèles proposés par chaque méthode afin de capturer
les différents concepts existants dans l'entreprise et les relations qui existent entre eux. Cette
revue de la littérature a noté l'absence de la notion de service dans toutes les méthodes de
modélisation de l'entreprise. De plus, nous avons remarqué que ces dernières aboutissent à des
systèmes fortement couplés et à des architectures monolithiques qui ne favorisent pas l'agilité de
l'entreprise. Néanmoins, ces méthodes de modélisation s'avèrent être un acquis primordial dans
notre travail poiur bien placer le concept de service dans l'entreprise et le situer convenablement
par rapport aux autres concepts en s'assurant qu'ils sont en harmonie totale.
La deuxième partie de l'état de l'art (chapitre 4) a été consacrée à l'étude de l'Architecture
Orientée Services (SOA) et les mécanismes d'interconnexion des processus interentreprises. Dans
un premier temps, nous avons exposé le concept la SOA en exposant plusieurs définitions. Nous
avons pu constater la domination de la vision technique sur la SOA. En effet, la majorité des
travaux traite la notion de service d'un point de vue technologique et met l'accent spécialement
sur la technologie des Web services, négligeant par ce fait les besoins réels de l'entreprise qui
dépassent le niveau technologique. Nous avons exposé, par la suite, les démarches de migration
vers une Architecture Orientée Services au sein de l'entreprise. Nous avons identifié trois angles
d'attaque : (i) top‐down, (ii) bottom‐up et (iii) meet in the middle. Ce dernier nous a semblé être
le plus intéressant vu qu'il nous permet d'aboutir à un ensemble de services pouvant satisfaire les
attentes de l'entreprise envers la SOA. Finalement, nous avons évoqué les mécanismes
d'interconnexion de processus interentreprises en prêtant plus d'attention au paradigme
d'interconnexion de processus via la composition de services. La constatation que nous avons pu
en tirer se résume dans le manque de pragmatisme dans ces méthodes. En effet, la majorité des
travaux se basent sur une étape de sélection de services qui tient compte uniquement des
paramètres fonctionnels et négligent les paramètres non fonctionnels. Dans le cas d'une
collaboration interentreprises, ces derniers doivent être bien explicités afin de garantir une
collaboration dynamique, à la demande et qui répond aux attentes des entreprises partenaires.
De plus, les scénarios de collaboration interentreprises sont assez complexes sur le niveau lien de
contrôle entre services de sorte qu'une composition automatique s'avère impossible. A la suite de
ce constat, nous avons pensé à introduire la notion de composition semi‐automatique pour la
construction des processus de collaboration.
Dans le chapitre 5, nous présenté le concept de l'Entreprise Orientée Services (EOS). Cette
dernière est considérée comme étant une agglomération de services avec différents niveaux
d'abstraction. Nous avons conçu L'EOS de manière à assurer une séparation de préoccupation
155
entre niveau métier et niveau informatique. Dans cette optique, l'Entreprise Orientée Services est
considérée comme une juxtaposition de deux modèles : une SOA Métier pour le niveau métier de
l'entreprise et une SOA informatique pour le niveau informatique de l'entreprise. Nous avons
commencé par dresser un méta‐modèle général de l'Entreprise Orientée Services puis nous avons
détaillé chacun des nouveaux concepts introduits en présentant un méta‐modèle qui les détaille.
Nous avons défini des services de différents types allant des services du niveau métier à savoir les
services métier et les services virtuels jusqu'à des services informatiques qui sont les services
applicatifs et les services d'infrastructure. Notre architecture s'est aussi basée sur le concept
d'objet métier qui joue un rôle très important dans notre architecture de l'Entreprise Orientée
Services.
A ce stade de la thèse, nous avons exposé l'architecture de l'Entreprise Orientées Services et les
éléments qui la constituent. Cependant, sa mise en œuvre n'est pas une tâche facile. Elle doit être
assurée par une démarche claire et un Framework de guidage. Ce travail, était l'objet du chapitre
6 dans lequel nous avons proposé les grandes lignes d'une démarche pour la mise en place d'une
Entreprise Orientées Services. Nous avons tenu compte des différentes spécifications des services
que nous avons mises en place dans le chapitre précédent.
Nous avons choisi le paradigme de collaboration interentreprises à base de composition de
service. Le chapitre 7 a traité ce sujet en présentant notre Framework de construction de
processus collaboratif interentreprises via la composition de services. Ce Framework met en
œuvre une méthode de composition semi‐automatique se basant, dans un premier temps, sur
une étape de spécification du schéma de collaboration en utilisant des Goal Templates. Ces
derniers résument la description en paramètres non fonctionnels des services à trouver. Dans un
deuxième temps, nous procédons à une phase de sélection de services qui tient compte
principalement des paramètres non fonctionnels. Nous avons prêté toute cette attention à ce
type de description vu son importance dans la construction dynamique d'un processus
collaboratif à la demande. Nos avons traité ce type de paramètre depuis sa description et jusqu'à
son exploitation dans la phase de composition de services. Dans cette direction, Nous avons
exposé une large catégorisation de paramètres non fonctionnels qui, à l'encontre de la majorité
des autres travaux, a comporté des paramètres qualitatifs et quantitatifs. Nous avons ajouté des
extensions au Framework WS‐Policy du W3C pour décrire les paramètres non fonctionnels. Quant
à leur publication, nous avons développé une méthode pour attacher la description non
fonctionnelle au registre de services de type UDDI. Finalement, la sélection de service se fait grâce
à des calculs partiels de dissimilarités entre les paramètres non fonctionnels offerts par les
services et ceux qui sont requis par le Goal Templates, pour calculer à la fin une distance globale
entre les services et les Goal Templates. Le service correspondant à la petite distance est le plus
convenable pour participer dans le processus collaboratif interentreprise.
8.2 Résumé des contributions
Dans la section précédente, nous avons repris l’ensemble des travaux effectués au cours de cette
thèse. Les différentes contributions réalisées dans notre travail sont résumées dans cette section :
156
1. Introduction du concept de l'Entreprise Orientée Services
L'Architecture Orientée Services intervenait principalement sur le niveau informatique de
l'entreprise. La plupart des travaux qui traitent l'orientation service regardaient le problème d'un
point de vue technique et leur point de départ était toujours le niveau informatique. L'Entreprise
Orientée Services , que nous avons développée, a étendu les principes de la SOA sur la totalité du
Système d'Information de l'entreprise. Elle a apporté de nouveaux concepts et elle a restructuré
l'architecture de l'entreprise de manière qu'elle soit plus agile et capable de participer à des
collaborations à la demande. Nous avons détaillé les différents concepts introduits par l'EOS en
présentant plusieurs méta‐modèles.
2. FErOS: une démarche de construction d'Entreprise Orientée Services
On note presque l'absence de démarche complète de construction d'une Entreprise Orientée
Services. La majorité des travaux existants sont des travaux à l'échelle industrielle qui ne présente
pas des détails. Cette contribution consiste à présenter une démarche de construction d'une EOS
tenant compte des spécifications de ses différents éléments. La démarche que nous avons
développée est de type "meet in the middle" dans laquelle nous avons présenté une
systématisation des différentes étapes. FErOS s'est basé sur la notion des objets métier qui
différencie notre démarche de celle de l'urbanisation.
3. Interconnexion de processus interentreprises : approche par composition de service
Notre troisième contribution se situe au niveau de la composition de service pour la construction
de processus interentreprises. Nous avons proposé une démarche de composition consistant à
concevoir le schéma de processus interentreprises manuellement et procéder par suite à une
phase de découverte et de sélection de service automatique. Cette méthode de composition
semi‐automatique est due à la complexité du processus de collaboration au niveau flux de
contrôle.
A l'encontre de la majorité des travaux de découverte et de La sélection de services, notre
méthode prête une grande attention aux paramètres non fonctionnels qui décrivent les services.
Elle dépasse l'utilisation des paramètres fonctionnels de services pour se focaliser sur les
propriétés non fonctionnelles, qui à notre avis, sont très importantes pour la réussite d'une
collaboration interentreprises à la demande. Les différentes contributions dans cette partie sont
les suivantes :
a) une large catégorisation des paramètres non fonctionnels selon leurs natures et les
échelles de mesure. Nous avons tenu compte des paramètres non fonctionnels
quantitatifs et qualitatifs,
b) la modélisation des paramètres non fonctionnels comme étant des politiques et l'ajout
d'une extension au standard WS‐Policy du W3C afin de pouvoir l'utiliser dans la
représentation de ce genre de paramètres. Cette extension est faite grâce à l'ajout de
concept d'ontologie dans la spécification initiale du WS‐Policy. Cette extension a facilité la
157
manipulation de ces paramètres non fonctionnels notamment dans la phase matching
entre deux politiques,
c) la définition d'une fonction de sélection de service qui mesure les dissimilarités entre les
paramètres non fonctionnels décrivant les services. Les formules de calculs varient selon
l'échelle de mesure du paramètre à traiter et de sa catégorie. La phase de sélection
intègre aussi une phase de négociation entre fournisseur de service pour ajuster les
paramètres non fonctionnels,
d) le développement d'un outil qui permet la construction du schéma de processus, la
création des descriptions WS‐Policy et la sélection de service selon les distances que nous
avons définies.
8.3 Perspectives et travaux futurs
Les travaux réalisés dans le cadre de cette thèse ouvrent diverses perspectives et plusieurs
travaux futurs peuvent être envisagés :
1. Amélioration de la démarche de construction d'une Entreprise Orientée Services
Nous nous sommes limités dans la démarche que nous avons présentée dans cette thèse aux
deux premières phases du cycle de vie de service à savoir : l'étude des besoins et l'identification
des services. Il reste trois phases que nous n'avons pas détaillées. Ce point constitue un point de
départ important pour développer une démarche complète de bout en bout.
Nous envisageons aussi de faire des études empiriques afin de valider et raffiner la démarche
proposée. Nous pensons développer un outil pour supporter FErOS. Cet outil va intégrer une base
de connaissance et une base de bonnes pratiques pour présenter le soutien et l'aide au cours d'un
projet de construction d'une EOS.
2. Amélioration de la méthode de sélection de service.
La méthode de sélection que nous avons développée tient compte des paramètres non
fonctionnels qui décrivent les services. Nous avons utilisé une version enrichie par des concepts
ontologiques de WS‐Policy pour la description de ces paramètres sous forme de politique. Les
types de raisonnement que nous avons faits sur les assertions sont assez simples et plusieurs
extensions et nouvelles règles d'inférences peuvent être prises en compte. En plus, d'autres
ontologies de domaine peuvent être définies afin d'améliorer la description des politiques et aussi
le processus de matching. En outre les fonctions de calcul que nous avons définies peuvent être
améliorées pour tenir compte de paramètres flous.
3. Conception et développement d'un Bus de service qui tient compte des spécifications de
service de l'EOS
L'idée de développer un bus de service (Enterprise Service Bus ou ESB) pour supporter la
communication des services définis au sein de l'Entreprise Orientée Services s'avère être très
intéressante vu l'importance d'une telle technologie dans la mise en place d'une SOA. En effet, la
technologie ESB, relativement jeune, est actuellement une piste prioritaire de l’outillage de la
158
philosophie SOA. Plusieurs particularités peuvent être attribuées à ce bus de service comme par
exemple la gestion de sécurité et la gestion de la sémantique des messages de services.
159
Bibliographies
Ali, L., 2008, Gestionnaire d'Infrastructure Distribuée, INSA of Lyon. Alonso, G., Casati, F., Kuno, H. and Machiraju, V., 2004, Web services Concepts, Architectures and
Application, Springer Verlag. AMICE, 1989, Open System Architecture for Cim Springer‐Verlag. AMICE, 1993, CIMOSA : Open System Architecture for CIM, Springer‐Verlag. Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu, K., Roller, D., Smith,
D., Thatte, S., Trickovic, I. and Weerawarana, S., 2003, Business Process Execution Language for Web Services , avalable at http://www.ibm.com/developerworks/library/specification/ws‐bpel/.
Arsanjani, A., 2004, Service‐oriented modeling and architecture available at: http://www.ibm.com/developerworks/library/ws‐soa‐design1/.
Bajaj et. al, 2006, Web Services Policy Framework (WS‐Policy) published on line at: http://www‐128.ibm.com/developerworks/library/specification/ws‐polfram/.
Benali, M., 2005, Une modélisation des liens de coopération et des trajectoires d’évolution des réseaux d’entreprises, l’ecole nationale supérieure des mines de Saint‐Etienne.
Benatallah, B., Sheng, Q. Z. and Dumas, M., 2003, The Self‐Serv environment for Web services composition, IEEE Internet Computing, 7(1), pp. 40‐84.
Bennour, M., 2004, Contribution à la Modélisation et à l’Affectation des Ressources Humaines dans les Processus, Université Montpellier II.
Bernus, P. and Nemes, L., 1997, Requirements of the generic enterprise reference architecture and methodology, Annual Reviews in Control, 21(pp. 125‐136.
Bitner, M. J. and Brown, S. W., 2008, The service imperative, Business Horizons, 51(1), pp. 39‐46. Bonnet, P., 2005, Cadre de Référence Architecture SOA : Meilleures Pratiques. Bonnet, P., Detavernier, J.‐M. and Vauquier, D., 2008, Le système d'information durable: la refonte
progressive du SI avec SOA, Lavoisier. Brezillon, P., 2003, Focusing on Context in Human‐Centered Computing, IEEE Intelligent Systems,
18(3), pp. 62‐66. Brezillon, P. and Pomerol, J.‐C., 2003, Context Proceduralization in Decision Making, Modeling and
Using Context, pp. 491‐498. Camarinah‐Matos, L. M., Afsarmanesh, H., Garita, C. and Limadoi, C., 1998, Towards an
architecture for virtual enterprises, Journal of Intelligent Manufacturing, 9(2), pp. 189‐199. Cao, Q. and Dowlatshahi, S., 2005, The impact of alignment between virtual enterprise and
information technology on business performance in an agile manufacturing environment, Journal of Operations Management 23(5), pp. 531–550.
Cardoso, J., Sheth, A., Miller, J., Arnold, J. and Kochut, K., 2004, Quality of service for workflows and web service processes, Web Semantics: Science, Services and Agents on the World Wide Web, 1(13), pp. 281‐308.
Casati, F. and Discenza, A., 2000, Supporting Workflow Cooperation Within and Across Organisations, In 15th ACM Symposium on Applied Computing (SAC’00)Como, Italy, pp. 9‐21.
Casati, F., Ilnicki, S., Jin, L.‐J., Krishnamoorthy, V. and Shan, M.‐C., 2000, eFlow : an Open, Flexible, and Configurable Approach to Service Composition, In 2nd International Workshop on Advance Issues of ECommerce and Web‐Based Information Systems (WECWIS’00)Milpitas, California, pp. 125‐132,.
Casati, F. and Shan, M.‐C., 2001, Dynamic and adaptive composition of e‐services, Information Systems, 26(3), pp. 143‐163.
Cervantes, H. and Hall, R. S. (2005) In Service Oreinted Software System Engineering: Cahllenges ans PracticiesIDEA Group, pp. 1‐26.
160
Chaari, S., Ali, L., Biennier, F., Favrel, J. and Benamar, C., 2007a, Enhancing Enterprise collaboration by Using Multifaceted services, In the 8th IFIP International conference on virtual enterprise, PRO‐VE 2007Guimaraes, Portugal, pp. 521‐528. .
Chaari, S., Badr, Y. and Biennier, F., 2008a, Enhancing web service selection by QoS‐based ontology and WS‐policy, In 23 ACM Symposium on Applied ComputingBrasil, pp. 2426‐2431.
Chaari, S., Badr, Y., Biennier, F., Benamar, C. and Favrel, J., 2008b, Framework for Web Service Selection Based on Non‐Functional Properties, International Journal of Web Services Practices, 3(2), pp. 94‐109.
Chaari, S., Biennier, F., Benamar, C. and Favrel, J. (2006a) In Knowledge Enterprise: Intelligent Strategies in Product Design, Manufacturing, and Management, Shanghai, China, pp. 920‐925.
Chaari, S., Biennier, F., Favrel, J. and Benamar, C., 2006b, Dynamic process organization, In 7 th IFIP International conference on virtual enterprise PRO‐VE 2006Springer, Helsinki, Finland, pp. 229‐236.
Chaari, S., Biennier, F., Favrel, J. and Benamar, C., 2007b, Towards Service Oriented Enterprise Based on Business Component Identification, In 3rd International Conference on Interoperability for Enterprise Software and ApplicationsSpringer, Madeira, Portugal, pp. 495‐506.
Chang, S. H. and Kim, S. D., 2007, A Service‐Oriented Analysis and Design Approach to Developing Adaptable Services, In the IEEE International Conference on Services Computing (SCC 2007), pp. 204‐211
Chen, D., Vallespir, B. and Doumeingts, G., 1997, GRAI integrated methodology and its mapping onto generic enterprise reference architecture and methodology, Computers in Industry, 33(2‐3), pp. 387‐394.
Chen, D. and Vernadat, F., 2004, Standards on enterprise integration and engineering‐state of the art, International Journal of Computer Integrated Manufacturing, 17(3), pp. 235‐253.
Chun, S. A., Atluri, V. and Adam, N. R., 2005, Using Semantics for Policy‐Based Web Service Composition, Distributed and Parallel Databases, 18(1), pp. 37.
Conti, M., Kumar, M., Das, S. K. and Shirazi, B. A., 2002, Quality of service issues in Internet web services, IEEE Transactions on Computers, 51(6), pp. 593‐594.
Crawford, C. H., Bate, G. P., Cherbakov, L., Holley, K. and Tsocanos, C., 2005, Toward an on demand service‐oriented architecture, IBM Systems Journal (Refereed), 44(1), pp. 81‐107.
Cugola, G., Nitto, E. D. and Fuggetta, A., 1998, Exploting an Event‐based Infrastructure to Develop Complex Distributed Systems, In the 20th International Conference on Software Engineering (ICSE'98)Kyoto, Japan, pp. 261‐270
Cullen, P.‐A., 2000, Contracting, co‐operative relations and extended enterprises, Technovation, 20(7), pp. 363‐372.
Daniel, J., 2000, Au coeur de CORBA, Vuibert informatique. Darras, F., 2004, Proposition d’un cadre de référence pour la conception et l’exploitation d’un
progiciel de gestion intégré, PhD thesis, available at: http://www.univ‐valenciennes.fr/GDR‐MACS/these/These_f_darras.pdf.
Detrie, J.‐P., 2005, Strategor : Politique générale de l'entreprise, DUNOD. Dey, A. K., Abowd, G. D. and Salber, D., 2001, A Conceptual Framework and a Toolkit for
Supporting the Rapid Prototyping of Context‐Aware Applications, Human‐Computer Interaction, 16(2), pp. 97‐166.
Diamadopoulou, V., Makrisa, C., Panagis, Y. and Sakkopoulos, E., 2008, Techniques to support Web Service selection and consumption with QoS characteristics, Journal of Network and Computer Applications, 31(2), pp. 108‐130.
Dogramaci, O., Gangopadhyay, A., Yesha, Y. and Adam, N. R., 1998, Electronic Commerce: Technical, Business, and Legal Issues, Prentice Hall.
Doumeingts, G., 1984, Méthode GRAI : méthode de conception des systèmes en productique, thèse d’Etat, Université de Bordeaux 1.
161
ebxml, 2001a, ebXML Business Process Specification Schema Version 1.01, available at http://www.ebXML.org/specs/ebBPSS.pdf.
ebXML, 2001b, ebXML Technical Architecture Specification v1.0.4 avalable at www.ebxml.org/specs.
ebXML, 2002, Collaboration‐Protocol Profile and Agreement Specification Version 2.0 available at http://www.ebxml.org/specs/.
ebXML, 2007, available at http://www.ebxml.org/. Emmelhainz, M., 1993, EDI = L'echange de donnees informatisées, Masson. ENV‐12204, 1996, Advanced Manufacturing Technology Systems Architecture ‐ Constructs for
Enterprise Modelling, CEN TC 310/WG1. Erl, T., 2005, Service‐Oriented Architecture (SOA): Concepts, Technology, and Design Prentice Hall
PTR Everaere, C. and Perrier, P., 1999, La flexibilité dans les organisations industrielles available at:
Fenton, N., 1994, Software measurement: a necessary scientific basis, IEEE Transaction on Software Engineering, 20(2), pp. 199‐206.
Fiedler, M., 1975, A property of eigenvectors of nonnegative symmetric matrices and its applications to graph theory. , Czechoslovak Mathematical Journal, 25(100), pp. 619‐633.
Fournier‐Morel, X., Grojean, P., Plouin, G. and Rognon, C., 2006, SOA, Le guide de l'architecte DUNOD.
Fujii, K. and Suda, T., 2005, Semantics‐based Dynamic Service Composition, the IEEE Journal on Selected Areas in Communications (JSAC), special issue on Autonomic Communication Systems, 23(12), pp. 2361‐2372.
Fujii, K. and Suda, T., 2006, Semantics‐based Dynamic Web Service Composition, the International Journal of Cooperative Information Systems (IJCIS), special issue on Service‐Oriented Computing, 15(3), pp. 293‐324.
Gallagher, K. and Worrell, J., 2007, Organizing IT to promote agility, Information Technology and Management.
Georgakopoulos, D., Shuster, H., Cichocki, A. and Baker, D., 1999, Managing process and service fusion in virtual enterprises., Journal of Information Systems, 24(6), pp. 429‐456.
Giachetti, R. E., Martinez, L. D., Saenz, O. A. and Chen, C. S., 2003, Analysis of the structural measures of flexibility and agility using a measurement theoretical framework, International Journal of Production Economics 86(1), pp. 47‐62.
Glass, R. L., 1998, Defining Quality Intuitively, IEEE Software, 15(3), pp. 103‐104. Grefen, P., Aberer, K., Hoffner, Y. and Ludwig, H., 2000, CrossFlow: Cross‐Organizational Workflow
Management in Dynamic Virtual Enterprises, International Journal of Computer Systems Science & Engineering, 15(5), pp. 277‐290.
Gruber, T., 1993, A Translation Approach to Portable Ontology Specifications, Knwledge Acquisition, 5(2), pp. 199‐220.
Hagen, C. and Alonso, G., 1999, Beyond the Black Box: Event‐based Inter‐Process Communication in Process Support Systems, In 19th IEEE International Conference on Distributed Computing Systems (ICDCS'99)Austin, Texas, USA, pp. 450‐457.
Hakansson, H. and Ford, D., 2002, How should companies interact in business networks, Journal of Business Research, 55(2), pp. 133‐139.
Harrington, J., 1991, Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness McGraw‐Hill.
Huemer, C., Quirchmayr, G. and Tjoa, A. M., 1997, A Meta Message Approach for Electronic Data Interchange (EDI), In the 8th International Conference on Database and Expert Systems Applications, Vol. 377‐386.
Ichino, M. and Yaguchi, H., 1994, Generalized Minkowski Metrics for Mixed Feature‐Type Data Analysis, IEEE Transactions on Systems, Man and Cybernetics, 24(1), pp. 698–708.
162
IETF, EDIINT available at http://www.ietf.org. IFIP‐IFAC, 1999, GERAM: Generalised Enterprise Reference Architecture and Methodology,
available at: http://www.cit.gu.edu.au/~bernus/taskforce/geram/versions/geram1‐6‐3/GERAMv1.6.3.pdf.
Jardim‐Goncalves, R., Grilo, A. and Steiger‐Garcao, A., 2006, Challenging the interoperability between computers in industry with MDA and SOA, Computers in Industry, 57(8‐9), pp. 679‐689.
Kalakota, R. and Whinston, A. B., 1996, Frontiers of Electronic Commerce, Addison‐Wesley. Khalaf, R. and Leymann, F., 2003, On Web Service Aggregation, pp. 1‐13. King, J. R., 1980, Machine‐Component Group Formation in Group Technology, OMEGA Journal of
Management Science, 8(2), pp. 193‐199. Klingemann, J., Wasch, J. and Aberer, K., 1999, Adaptative outsourcing in cross organizational
workflows, In 11th International Conference on advanced Information Systems Engineering (CaiSE’99),Heidelberg, Germany, pp. 14‐18.
Kosanke, K., Vernadat, F. and Zelm, M., 1999, CIMOSA: enterprise engineering and integration, Computers in Industry, 40(2‐3), pp. 83‐97.
Krafzig, D., Banke, K. and Slama, D., 2004, Enterprise SOA: Service‐Oriented Architecture Best Practices Prentice Hall.
Li, H. and Williams, T. J., 1997, Some extensions to the Purdue Enterprise Reference Architecture (PERA): I. Explaining the Purdue architecture and the Purdue methodology using the axioms of engineering design, Computers in Industry, 34(3), pp. 247‐259.
Limam, S., 1999, Contribution à la modélisation et la simulation des systèmes de production de services PhD thesis, available at: http://www.univ‐valenciennes.fr/GDR‐MACS/local/Grenoble/www‐lag.ensieg.inpg.fr/publications/theses/THESES/these1999‐13.pdf
Maamar, Z., Benslimane, D., Thiran, P., Ghedira, C., Dustdar, S. and Sattanathan, S., 2006, Towards a context‐based multi‐type policy approach for Web services composition, Data & Knowledge Engineering.
Malhotra, A., Gosain, S. and Lee, Z., 1997, Push‐Pull: The Information Tug of War: A Framework for Information Delivery and Acquisitions System Design, In the 3th Conference of the Association for Information Systems (AIS '97)Indianapolis, USA.
Martin, D., 2005, Putting Web Services in Context, In International Workshop on Context for Web Services in conjunction with the 5th International and Interdisciplinary Conference on Modeling and Using Context, pp. 3‐16.
Martin, D., Paolucci, M., McIlraith, S., Burstein, M., McDermott, D., McGuinness, D., Parsia, B., Payne, T., Sabou, M., Solanki, M., Srinivasan, N. and Sycara, K., 2004, Bringing Semantics to Web Services: The OWL‐S Approach, In SWSWPC(Eds, Cardoso, J. and Sheth, A.).
Maximilien, E. M. and Singh, M. P., 2004, A Framework and Ontology for Dynamic Web Services Selection, IEEE Internet Computing, 8(5), pp. 84 ‐ 93
McCoy, D. W. and Plummer, D. C., 2006, Defining, Cultivating and Measuring Enterprise Agility, Gartner Research.
Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, A. H. H. and Elmagarmid, A. K., 2003a, Business‐to‐business interactions: issues and enabling technologies, The VLDB Journal, 12(1), pp. 59‐85.
Medjahed, B. and Bouguettaya, A., 2005, A Dynamic Foundational Architecture for Semantic Web Services, Distributed and Parallel Databases, 17(2), pp. 179–206.
Medjahed, B., Bouguettaya, A. and Elmagarmid, A. K., 2003b, ComposingWeb services on the Semantic Web, Very Large Data Base, 12(4), pp. 333‐351.
Microsoft, 2000, Microsoft BizTalk Server : BizTalk Framework 2.0 : Document and Message Specification, available at: www.biztalk.org.
Newcomer, E., 2002, Understanding Web service XML, WSDL, SOAP et UDDI, Addison‐Wesley Professional.
163
O’Sullivan, J., Edmond, D. and Hofstede, A. t., 2002, What’s in a Service? Towards Accurate Description of Non‐Functional Service Properties, Distributed and Parallel Databases, 12(2‐3), pp. 117‐133.
OBI, OpenBuy available at http://www.openbuy.org. OMG‐CORBA, 1997, The Common Object Request Broker: Architecture and Specificationhttp,
available at http://www.omg.org/docs/formal/97‐02‐25.pdf. OMG‐CORBA, 2004, Common Object Request Broker Architecture: Core Specification, available at:
http://www.omg.org/docs/formal/04‐03‐01.pdf. OMG, 1997, Business Object DTF Common Business Objects, available at:
http://www.omg.org/docs/bom/97‐12‐01.pdf. Overby, E., Anandhi Bharadwaj and Sambamurthy, V. (2005) In Business Agility and Information
Technology Diffusion, pp. 295‐312. Overby, E., Bharadwaj, A. and Sambamurthy, V., 2006, Enterprise agility and the enabling role of
information technology, European Journal of Information Systems 15(2), pp. 120‐131. Pal, N. and Lim, M., 2005, The Agile Enterprise, Springer Panetto, H., 2006, Meta‐modèles et modèles pour l’intégration et l’interopérabilité des
applications d’entreprises de production, available at: http://tel.archives‐ouvertes.fr/tel‐00119423/en/.
Papazoglou, M. P. and Heuvel, W.‐J. v. d., 2006, Service‐oriented design and development methodology, International Journal of Web Engineering and Technology (IJWET), 2(4), pp. 412‐442.
Poler, R., Lario, F. C. and Doumengets, G., 2002, Dynamic modelling of decision system, Computer in Industry, 49(2), pp. 175‐193.
Quartel, D. A. C., Pires, L. F., Sinderen, M. J. v., Franken, H. M. and Vissers, C. A., 1997, On the role of basic design concepts in behavior structuring, Computer Networks and ISDN Systems, 29(4), pp. 413‐436.
Rosenblum, D. S. and Wolf, A. L., 1997, A Design Framework for Internet‐Scale Event Observation and Notication, In the 6th European conference held jointly with the 5th ACM SIGSOFT international symposium on Foundations of software engineeringZurich, Switzerland, pp. 344‐360
Sarkis, J., 2001, Benchmarking for agility, Benchmarking Journal, 8(2), pp. 88‐117. Sayah, J. Y. and Zhang, L.‐J., 2005, On‐demand business collaboration enablement with web
services Decision Support Systems 40(1), pp. 107‐127 Scheer, A.‐W., 1993, Architecture of Integrated Information System (ARIS), In JSPE‐IFIP WG 5.3
Workshop on the Design of Information Infrastructure Systems for Manufacturing (DIISM’93)Tokyo, Japan, pp. 177‐191.
Scheer, A.‐W., 2002, ARIS — Des processus de gestion au système intégré d'applications, Springer‐Verlag.
Scheer, A. W., Galler, J. and Kruse, C., 1994, Workflow Management within the ARIS framework, In European Workshop on integrated manufacturing systems engineeringChapman & Hall, Grenoble, France.
Schroth, C., 2007, The service oriented enterprise, Journal of Enterprise Architecture 3(4), pp. 73‐80.
Serieyx, H., 2000, La Nouvelle Excellence, Maxima. Sharifi, H. and Zhang, Z., 2000, A methodology for achieving agility in manufacturing
organizations, International Journal of Operations Production Management 20(4), pp. 496‐512.
Shorter, D., 1999, CEN standardization activities related to CIMOSA Computers in Industry, 40(2‐3), pp. 305‐310
Sirin, E. and Parsia, B., 2004, Planning for semantic web services, In the Semantic Web Services Workshop at 3rd International Semantic Web Conference.
164
Spohrer, J., Maglio, P. P., Bailey, J. and Gruhl, D., 2007, Steps Toward a Science of Service Systems, IEEE Computer Society, 40(1), pp. 71‐77.
Steen, M. W. A., Strating, P., Lankhorst, M. M. and Doest, H. W. L. t. (2005) In Service Oreinted Software System Engineering: Cahllenges ans PracticiesIDEA Group, pp. 132‐154.
Sun, 1999, Enterprise JavaBeans Specification 1.0, available at: http://java.sun.com/products/ejb/docs.html.
Sun, 2001, Enterprise JavaBeans Specification 2.0, available at: http://java.sun.com/products/ejb/docs.html.
Tallon, P., 2007, Inside the adaptive enterprise: an information technology capabilities perspective on business process agility, Information Technology and Management.
Tewoldeberhan, T. W., 2005, Gaining insight into business networks : a simulation based support environment to improve process orchestration Delft University of Technology.
Thakkar, S., Ambite, J. L. and Knoblock, C. A., 2004, A Data Integration Approach to Automatically Composing and Optimizing Web Services, In International Workshop on Planning and Scheduling for Web and Grid Services.
Thakkar, S., Ambite, J. L., Knoblock, C. A. and Shahabi, C., 2002, Dynamically Composing Web Services from On‐line Sources, In AAAI Workshop on Intelligent Service Integration1‐7.
Thakkar, S., Knoblock, C. A. and Ambite, J. L., 2003, A View Integration Approach to Dynamic Composition of Web Services, In the 1st ICAPS International Workshop on Planning for Web Services (P4WS 2003).
TheOpenGROUP, 2007, TOGAF, http://www.opengroup.org/architecture/togaf8. UEML, 2002, Report on the State of the Art in Enterprise Modelling. Unilog, 2005, SOA et urbanisme: Le rôle des Architectures Orientées Services dans l’alignement
métier des Systèmes d’Information. Uram, M. and Bill, S. (2005) In The Agile Enterprise, pp. 49‐85. Velleman, P. F. and Wilkinson, L., 1993, Nominal, ordinal, interval, and ratio typologies are
misleading, The American Statistician, 47(1), pp. 65‐72. Vernadat, F., 1993, CIMOSA : Enterprise Modelling and Enterprise Integration Using a Process‐
Based Approach, In thef JSPE‐IFIP WG 5.3 Workshop on the Design of Information Infrastructure Systems for Manufacturing (DIISM’93)Tokyo, Japan, pp. 65‐84.
Vernadat, F., 1996, Enterprise Modeling and Intergration: Principles and Applications, Chapman & hall.
Vernadat, F., 1999, Techniques de modelisation en entreprise: Application aux processus opérationnels, Economica.
Vernadat, F., 2002, UEML: towards a Unified Enterprise Modelling Language, International Journal of Production Research, 40(17), pp. 4309‐4321.
Vernadat, F., 2007a, Interoperable enterprise systems: Principles, concepts, and methods, Annual Reviews in Control, 31(1), pp. 137‐145.
Vernadat, F. (2007b) In Service Enterprise Integration(Ed, US, S.) Springer, pp. 77‐101. Vissers, C. A. and Logrippo, L., 1986, The importance of the service concept in the design of the
data communications protocols, In Fifth International Workshop on Protocol Specification, Testing and Verification, pp. 3‐17.
Vlietstra, J., 1993, CIMOSA : integrating the production, In the IFIP TC5/WG5.3 Conference on Towards World Class Manufacturing Arizona, USA pp. 195‐213.
W3C, 2000, Simple Object Access Protocol (SOAP) 1.1 Published online at http://www.w3.org/TR/soap/.
W3C, 2001, Web Services Description Language (WSDL) 1.1 available at line http://www.w3.org/TR/wsdl.
W3C, 2002a, Universal Description, Discovery, and Integration (UDDI), available at http://www.uddi.org.
W3C, 2002b, Web Services Architecture, available at http://www.w3.org/TR/2002/WD‐ws‐arch‐20021114/.
165
W3C, 2004a, OWL‐S: Semantic Markup for Web Services Published online at http://www.w3.org/Submission/OWL‐S/.
W3C, 2004b, OWL Web Ontology Language Overview Published online at http://www.w3.org/TR/owl‐features/.
W3C, 2004c, Web Services Glossary, available at: http://www.w3.org/TR/ws‐gloss. W3C, 2006, Web Services Policy Attachment, available at http://www.w3.org/Submission/WS‐
PolicyAttachment. Waqar, S. and Racca, F., 2004, Business services orchestration: The hypertier of information
technology, Cambridge University Press. Wegner, A. P., 1996, Interoperability, ACM Computing Survey, 28(1), pp. 285‐287. WFMC, 1999, Workflow Management Coalition Terminology and Glossary, Technical Report
WFMC‐TC‐1011. Williams, T. J., 1994, The Purdue Enterprise Reference Architecture, Computer in Industry, 24(2‐3),
pp. 141‐158. Williams, T. J. and Li, H., 1997, The task force specification for GERAM and its fulfillment by PERA,
Annual Reviews in Control, 21(pp. 137‐147. Wu, D., Parsia, B., Sirin, E., Hendler, J. and Nau, D., 2003, Automating DAML‐S web services
composition using SHOP2, In International Semantic Web Conference, pp. 195‐210. Xanthos, S., 2005, Clustering Object‐Oriented Software Systems using Spectral Graph Partitioning,
In ACM Student Research Competition, available at: www.acm.org/src/subpages/papers/Grand%20Finals%202005/SpirosXanthosACMSRC.pdf.
Xu, Z., Martin, P., Powley, W. and Zulkernine, F., 1007, Reputation‐Enhanced QoS‐based Web Services Discovery, In IEEE International Conference on Web Services (ICWS 2007), pp. 9‐13
Yusuf, Y., Oadeleye, E. and Sivayoganathan, K., 2003, Volume flexibility: the agile manufacturing conundrum, Management Decision Support Systems, 41(7), pp. 613.
Yusuf, Y. Y., Gunasekaran, A., Adeleye, E. O. and Sivayoganathan, K., 2004, Agile supply chain capabilities: Determinants of competitive objectives, European Journal of Operational Research, 159(2), pp. 379‐392.
Zhao, J. L., Tanniru, M. and Zhang, L.‐J., 2007, Services computing as the foundation of enterprise agility: Overview of recent advances and introduction to the special issue, Information Systems Frontiers, 9(1), pp. 1‐8.
Zhou, J. and Niemela, E. (2005) In Service Oreinted Software System Engineering: Cahllenges ans PracticiesIDEA Group, pp. 27‐47.