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 Pr. Joël FAVREL (Institut National des Sciences Appliquées de Lyon)
thèse :
Pr. Chokri BEN AMAR (École Nationale d'Ingénieurs de Sfax, Tunisie)
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

‐i‐
 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.

‐ii‐
 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.

‐iii‐
 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
3.6 Conclusion .................................................................................................................... 42
Chapitre 4 Architecture Orientée Services et interconnexion de processus ................. 43
4.1 Introduction .................................................................................................................. 44
4.2 Architecture Orientée Services (SOA) .......................................................................... 44
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

‐iv‐
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
4.4 Conclusion .................................................................................................................... 66
Chapitre 5 Entreprise Orientée Services ......................................................................67
5.1 Introduction.................................................................................................................. 68
5.2 Entreprise Orientée Services : définition et présentation ........................................... 68
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

‐v‐
 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

‐vi‐
 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

‐vii‐
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

‐viii‐
 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

‐ix‐
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.

1
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

2
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

3
4
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."

Albert Einstein

SOMMAIRE

Chapitre 2 Problématique ....................................................................................................... 5

2.1 Cadre du travail : la coopération interentreprises ...................................................................... 6

2.2 La Coopération interentreprises : Problèmes.............................................................................. 8

2.3 L'orientation Service .................................................................................................................. 12

2.4 Approche proposée et objectif .................................................................................................. 15

2.5 Conclusion ................................................................................................................................. 18

5
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

6
é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

7
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

8
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.

9
 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 ?

10
 ƒ 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à

11
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

12
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

13
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.

14
 ™ 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

15
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

16
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

17
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.

18
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."

Leonardo da Vinci

SOMMAIRE

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.4 Panorama des méthodologies de modélisation d'entreprise.................................................... 25

3.5 Processus et outils de workflow ................................................................................................ 40

3.6 Conclusion ................................................................................................................................. 42

19
3.1 Introduction

Nous envisageons dans cette thèse de proposer une démarche pour la construction de
l'entreprise selon une orientation service afin d'aboutir à une nouvelle architecture lui permettant
d'être à la fois plus agile et capable d'intégrer des scénarios de coopération à la demande d'une
manière simple.

Ce premier chapitre de l'état de l'art portera sur la modélisation de l'entreprise. Le choix de faire
cette étude se base essentiellement sur les deux arguments suivants. En premier lieu, afin
d'entamer un projet de reconstruction ou de réingénierie, il est indispensable de connaître les
différents éléments qui constituent le sujet de travail : l'entreprise. Ces éléments doivent être
modélisés afin de pouvoir maîtriser leurs complexités et d'être en mesure par la suite de les
restructurer. Par conséquent, la modélisation de l'entreprise se pose comme un pré requis
indispensable pour atteindre ce but.

En second lieu, l'orientation service au sein de l'entreprise ne remplacera en aucun cas

l'orientation processus ou l'approche à base de processus métier au sein de l'entreprise. En effet,
elle vient pour combler le manque constaté sur l'approche processus induit par les grands
changements au niveau de l'environnement des entreprises. En plus, afin de garantir un
alignement entre le Système d'Information de l'entreprise et les besoins métier, la spécification
des services que nous allons développer sera conforme aux besoins et aux attentes métier de
l'entreprise. Les services seront en partie issus de l'analyse des processus de l'entreprise. Dans ce
sens, les processus métier doivent être formalisés ainsi que les objets qu'ils manipulent, les
informations qu'ils génèrent ou qu'ils utilisent, les ressources nécessaires pour leurs exécutions et
finalement les rôles qui les contrôlent. C'est encore une fois la tâche de la modélisation de
l'entreprise.

En somme, la modélisation d'entreprise constitue un point de départ essentiel sur le chemin de la

restructuration de l'entreprise selon une orientation service. Elle va nous doter des outils et des
connaissances nécessaires pour comprendre l'entreprise, les concepts qui la constituent et la
manière dont elle fonctionne.

Dans ce chapitre, nous allons présenter la notion de processus métier ainsi que les différentes
méthodologies de modélisation de l'entreprise. Nous avons essayé de mener notre étude d'une
manière différente des études précédentes et se concentrer particulièrement sur les méta‐
modèles des différentes méthodologies présentées. Ces derniers serviront par la suite pour la
construction de notre méta‐modèle de l'Entreprise Orientée Services. On n'aura pas un objectif
d'exhaustivité vis‐à‐vis des nombreuses méthodologies de modélisation d'entreprise existantes.
Nous présenterons plutôt les plus importantes.

3.2 Les processus métier de l'entreprise

La notion de processus est assez générale et elle est existante dans plusieurs domaines
scientifiques et applicatifs. On trouve, par conséquent, une multitude de définitions qui présente

20
le terme processus. L'étude de ces définitions permet d'avoir une idée claire et précise de ce que
représente un processus.

D'un point de vue général, la définition littéraire (d'après le dictionnaire Larousse) d'un processus
est comme suit : "Un processus est un développement plus ou moins réglé ou régulier de
phénomènes. C'est une suite continue de faits ou d'opérations aboutissant à un résultat
déterminé. Un processus peut être vu comme une succession ordonnée d'états par lesquels passe
un système physique au cours de son évolution. On caractérise un processus par les états initiaux
et finaux correspondants".

Du point de vue des domaines de l'automatique et de la productique, plusieurs définitions ont été
proposées ((Limam, 1999), pp.95) :

Selon CIMOSA (AMICE, 1993), " un processus est déclenché par des événements provenant du
système lui‐même ou du monde extérieur (par des machines, commandes clients, ordres de
gestion, etc.). Il est constitué d'un ensemble d'activités et de sous‐processus. C'est en fait une
chaîne d'activités spécifiées par le biais des règles procédurales qui déterminent le comportement
de l'entreprise en fonction des événements reçus et de l'état du système. Une activité permet la
description d'une tâche réalisée dans l'entreprise au moyen de ressources au cours du temps. Elle
transforme des entrées en des sorties en tenant compte de certaines contraintes".

D'après ((Vernadat, 1999), pp.22), "Un processus métier est une succession de tâches selon un
ordre partiel qui contribue à la réalisation des objectifs d'une entreprise. D'une façon générale, un
processus peut être défini comme un enchaînement d'activités qui seront exécutées pour atteindre
un but prédéfini. Cet enchaînement forme le flux de contrôle du processus, c'est‐à‐dire sa logique
d'exécution".

Du point de vue organisationnel, (Harrington, 1991) définit un processus comme "n'importe quelle
activité ou ensemble d'activités qui opèrent sur une entrée en lui ajoutant de la valeur et la
transformant en une sortie pour un client interne ou externe. Les processus utilisent les différentes
ressources disponibles dans l'organisation pour fournir les résultats attendus".

Des auteurs du domaine du génie informatique proposent les définitions suivantes : "un processus
est un ensemble d'étapes partiellement ordonnées, conçues pour atteindre un but. Un processus
est décomposable en étapes et composants".

De telles définitions sont utilisées pour modéliser, concevoir et implémenter des processus métier
permettant ainsi d'organiser des réseaux complexes d'activités interdépendantes, en partant
d'étapes de processus simples et linéaires.

Par déduction, on peut définir un processus d'une entreprise de la manière suivante : Un

processus correspond à un ensemble enchaîné d'activités. Le processus est déclenché via des
événements (internes ou externes). Pour répondre à son objectif de définition, le processus agit sur
des objets qu'il reçoit comme entrée et leurs ajoute de la valeur par le biais des ressources (Figure
3.1). Les objets de sortie (produit ou service) remplissent les exigences d'un client à l'intérieur ou à
l'extérieur de l'entreprise. Un processus peut communiquer avec d'autres processus et peut être
décomposé en plusieurs sous‐processus (Figure 3.2). Les activités d'un processus transforment,

21
pendant une durée bien définie, des entrées en des sorties par l'influence d'objets de contrôle et en
utilisant les ressources disponibles (Figure 3.3).

Figure 3.1 : Définition d'un processus

Figure 3.2 : Décomposition d'un processus

Figure 3.3 : Définition d'une activité

22
3.3 Modélisation d'entreprise : définitions, concepts et composants

La modélisation d'entreprise est un terme générique qui couvre l'ensemble des activités,
méthodes et outils servant à modéliser les différentes parties d'une entreprise (Vernadat, 1996).
Elle est un outil indispensable pour capitaliser la connaissance de l'entreprise et l'appréhender
sous ses différents aspects : structurel, fonctionnel, comportemental, informationnel,
organisationnel ou autre (Vernadat, 1996). Cette étude de l'existant permet de le superviser, de le
simuler, de l'analyser ou même dans notre cas de le restructurer et de la réorganiser afin d'en
améliorer les performances.

Un modèle d'entreprise sert à décrire les flux d'information, de matière, etc., ainsi que les
interactions pouvant exister entre les différentes entités de l'entreprise (processus, information,
acteur, ...). Un modèle permet une analyse plus fine de l'entreprise. Plus spécialement, il sert à la
représentation et la compréhension de la manière avec laquelle l'entreprise fonctionne afin de
capitaliser ses connaissances et son savoir‐faire et améliorer son fonctionnement pour une
utilisation future (Panetto, 2006).

En somme, les objectifs et les attentes d'un modèle d'entreprise, comme ils ont été présentés
dans ((Vernadat, 1999), pp. 7), peuvent se résumer dans les points suivants :

1. comprendre et analyser la structure et le fonctionnement de l'entreprise,

2. prévoir les performances et le comportement des processus opérationnels de l'entreprise

avant leur implantation,

3. choisir la (ou les) meilleure(s) alternative(s) d'implantation(s),

4. détecter les risques d'implantation à prendre en considération,

5. argumenter les choix d'implantation tenant compte d'un ensemble de critères tels que les
ressources et les coûts,

6. construire une vision commune du fonctionnement de l'entreprise et la communiquer au

personnel.

3.3.1 Les différentes vues de la modélisation

La modélisation d'entreprise se base sur la représentation de plusieurs points de vue qui vont
exposer le fonctionnement de l'entreprise selon une vision particulière. Un point de vue de
modélisation est une perception spécifique de l'entreprise qui souligne et met en évidence des
aspects particuliers et rend transparent les autres ((Darras, 2004), pp. 94).

La norme ENV 40003 (Shorter, 1999) identifie quatre points de vue ((Darras, 2004), pp. 94) :

23
 ƒ la vue fonctionnelle qui présente une hiérarchie de fonctions, des flux de l'entreprise
tenant compte des entrées et des sorties de chaque fonction en plus de la logique
d'enchaînement des fonctions dans le temps,

ƒ la vue informationnelle qui représente, d'une manière structurée, l'ensemble d'entités de

l'entreprise munies des informations qui les caractérisent ainsi que les relations de
dépendance qui puissent exister entre ces informations,

ƒ la vue des ressources qui représente l'organisation des ressources de l'entreprise

nécessaires pour mettre en œuvre les activités,

ƒ la vue de l'organisation qui représente l'organisation structurelle de l'entreprise qui peut

inclure, par exemple, les responsabilités des individus au sein de l'entreprise.

3.3.2 Constructs de la modélisation

Un modèle est exprimé en utilisant des constructs. Ces derniers sont des éléments à caractère
générique qui permettent de représenter les éléments d'un modèle que ce soit d'une manière
graphique ou textuelle ((Darras, 2004), pp. 93).

La norme ENV 12204 (ENV‐12204, 1996) a détaillé ces constructs. De plus, elle a défini les
primitives de base de la modélisation tout en mettant l'accent sur la possibilité d'application de
ces constructs.

La Figure 3.4 expose quelques constructs spécifiques à la modélisation d'entreprise:

Figure 3.4 : Contructs et relation entre constructs (Chen and Vernadat, 2004), page 241
Parmi les constructs de première importance pour la modélisation d'entreprise, qui sont entérinés
par la norme (ENV‐12204, 1996), nous pouvons noter ((Darras, 2004), pp. 93).:

ƒ un objet d'entreprise est une entité élémentaire (concrète ou abstraite) qui possède une
utilité dans les opérations d'une entreprise,

ƒ un objet est doté d'un ensemble d'informations qui le décrivent et d'un ensemble de
comportements,

24
 ƒ un objet est qualifié par un cycle de vie constitué d'un ensemble d'états,

ƒ le processus est un ensemble d'activités qui utilisant des ressources et obéissent à une
logique de changement d'état fixée par une séquence d'événements,

ƒ les objets de l'entreprise sont en relation, ils peuvent échanger toutes sortes de flux.

3.4 Panorama des méthodologies de modélisation d'entreprise

De nombreux modèles d'entreprise ont été développés depuis une vingtaine d'années pour
comprendre et étudier le fonctionnement des processus en entreprise. Les principaux modèles
d'entreprise (ou méthode de modélisation en entreprise) développés au cours des vingt dernières
années sont représentés dans la Figure 3.5 :

Figure 3.5 : Principaux modèles d'entreprise ou approches de modélisation

en entreprise (Chapron, 2006), page 55

Les modèles d'entreprises, ne considèrent pas, dans la majorité des cas, tous les aspects d'une
entreprise. Ils sont particulièrement adaptés à un type de problème particulier. Durant le
processus de modélisation, l'accent peut être mis sur différentes facettes donnant par suites
plusieurs démarches de modélisation possibles. Par exemple, il est possible de se concentrer sur
la modélisation fonctionnelle, organisationnelle, ou informationnelle.

3.4.1 Un exemple de démarche orientée "décisionnel" : GRAI‐GIM

La méthode GRAI (Doumeingts, 1984) acronyme de "Graphe de Résultats et Activités Inter‐reliés"
est une méthodologie de modélisation et d'analyse des systèmes de décision des entreprises de
production. GRAI s'appuie sur deux outils : la grille GRAI et les réseaux GRAI (Chen et al., 1997)
(voir Figure 3.6).

25
 Figure 3.6 : Les outils GRAI
Le modèle de GRAI est un système hiérarchisé qui peut être décomposé en trois sous‐systèmes
(Poler et al., 2002):

ƒ Système de Décision, comporte des niveaux de décisions qui sont caractérisés par un
horizon de prise de décisions et une période de remise en question.

ƒ Système d'Information qui lie le Système de Décision et le Système Physique.

ƒ Système Physique (appelé aussi système opérant) qui décrit la transformation des
produits par les ressources.

Le Système de Décision comprend des "niveaux de décision" et des "centres de décision". Un

niveau de décision est caractérisé par un horizon (H) et une période (P) représentant les deux
critères de décomposition relatifs aux caractéristiques temporelles des décisions.

L'horizon représente la durée de la portée de la décision, tandis que la période correspond à

l'intervalle de temps au bout duquel il est indispensable de vérifier et de remettre en question les
décisions faites auparavant sur l'horizon fixé. Chaque niveau de décision comporte différentes
activités. Les activités d'un même niveau de décision sont regroupées selon leurs objectifs.

Un centre de décision est un ensemble d'activités de décision qui appartiennent à un même

niveau horizon / période et remplissant la même fonction. Chaque centre de décision comporte
des activités d'informations nécessaires à la préparation des données pour les activités de
décision.

Les relations existantes entre les différents centres de décision sont modélisées à travers la Grille
GRAI. Elle place les centres de décision ensemble et met en évidence les principaux liaisons
décisionnels (cadre de décision) et informationnels de l'organisation analysée. Cette grille permet
d'avoir une confrontation entre un point de vue fonctionnel et informationnel et des niveaux de
prise de décision.

26
Le méta‐modèle de la grille GRAI présenté dans la figure suivante (Figure 3.7) met en évidence
l'orientation vers l'aspect décisionnel traité par la méthodologie.

n Niveau de décision appartient

Fonction n
1 0..n
Information
0..n

Information Externe Information interne

reçoit

1..n
+emet 1 1..n +emet
Lien d'Information
Frame décision Centre de décision

0..n +receptionne
+receptionne 0..n
1..n

décrit

1
Réseau GRAI

Figure 3.7 : Méta‐modèle de la grille GRAI (Bennour, 2004), page 23

La grille GRAI est complétée par le réseau GRAI. Ce dernier représente la structure de tout ou
d'une partie d'un centre de décision déjà identifié dans la grille GRAI. Le méta‐modèle du réseau
GRAI, présenté dans la Figure 3.8, met en évidence les différents constructs qui servent à la
définition de la nature d'une activité (décisionnelle ou opérationnelle) ainsi que les entités
déclencheurs, supports et résultats qui caractérisent les activités d'opération ou de décision.

27
 Activité décisionnelle Activité operationnelle

résultat 1 Activité 0..n evénement

1..n Information

support

Ressource
0..1
0..n
1
Entité Règle
n

Indicateur de performance

Entité complexe Objectif Variable de décision Critère

1
Opérateur logique

Figure 3.8 : Méta‐modèle du réseau GRAI (Bennour, 2004), page 23

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.

28
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.

29
 Structure
organisationnelle
n
Ressource alloué n
Hardware
machine
n n alloué
n n
n Sortie humaine
alloué

n
Unité Organisationnel
n
n

responsable n
Modèle privilège acces But commun n
donnée
entrée donnée n
supporte
n
n n n
sortie donnée n
n n n
n n Fonction
Objet n déclenche n
information n
n n n
est créé n
n n
n
n
execute
Medium
n
donnée Input
n contrôle Application
logicielle

n
n
Structure Output
output n Output
n

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.

30
 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

31
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):

32
 à autorité sur

Domaine lié par Relation Domaine

Evènement
n n
n
0..1
Cellule Organisationnelle
déclenche
déclenche
1..n
1 n
Processus Domaine 1
Unité Organisationnelle
1..n
1
n 1 1
1..n possède
emploie possède
1..n
Objet Entreprise 1..n
n
Autorité Profil compétence
n Processus Métier

n 1..n Responsabilité
dérivé de
emploie
n n associé à
Vue Objet exige Activité demande Capacité
1 n 1
n 1..n
n
fournit
1
1
décrit par exige n Ressource
emploie
fournit
1..n
n possède
n
1
Schéma Externe utilise Opération Fonctionnelle exécutée par Entité fonctionnelle 1
n n n n

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 :

33
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.

34
 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

35
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

36
 ƒ 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

37
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).

38
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.

a autorité sur

1
Evénement déclenche Processus
1..n 1..n
n
n 1
associé à comprend
0..1 1
1..n
Objet entrée/sortie Unité
Activité a autorité sur
Entreprise Organisationnel
1..n n n 1..n 1
1..n

nécessite

1..n
Produit Ordre Ressource utilise Rôle Qualification
1..n 1..n 1..n 1..n
1..n

Capacité
1..n
Application Humain Machine

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

39
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

40
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
complète.

3
Workflow Management Coalition: http://www.wfmc.org

41
 Figure 3.18 : Environnement d'exécution de processus
L'inconvénient majeur de ces systèmes est leur rigidité. Leur comportement est prédéfini et les
règles de coordination sont établies à l'avance. N'importe quel changement au niveau logique des
processus métier demande une redéfinition du workflow et des règles de coordinations qui est
une tâche assez complexe et très coûteuse. Les systèmes de gestion des workflows sont perçus
généralement comme des systèmes résistant aux changements.

3.6 Conclusion

Dans cette partie de l'état de l'art, nous avons présenté quelques méthodologies de modélisation
d'entreprise. Nous avons choisi de commencer par cette étude bibliographique pour deux
raisons : d'une part, un travail de réingénierie doit commencer impérativement par connaître les
différents éléments qui constituent le sujet de travail. C'est le rôle de la modélisation de
l'entreprise qui met en valeur les différents concepts qui constituent l'entreprise et les relations
qui existent entre eux. D'autre part, les processus métier de l'entreprise sont le centre de toute
approche de migration vers une Architecture Orientée Services, d'où la nécessité de les
modéliser. Nous avons donné une attention particulière pour les méta‐modèles de chaque
méthodologie. Ces derniers sont la base de notre réflexion autour de l'architecture et des
différents méta‐modèles qui représente l'Entreprise Orientée Services. En effet, les services que
nous allons introduire doivent être placés et situés par rapport aux concepts déjà existant dans
l'entreprise.

Nous avons souligné l'insuffisance de ces méthodologies pour aboutir à une modélisation
d'entreprise agile. Généralement, les systèmes que nous allons obtenir se caractérisent par une
rigidité importante et qui s'opposent à toutes demandes de changements ou d'adaptation.

L'étape suivante dans nos recherches bibliographiques s'est focalisée sur l'Architecture Orientée
Services. Le chapitre suivant présente quelques définitions de la SOA ainsi que les démarches de
migration vers ce style d'architecture. Nous avons exposé aussi les mécanismes d'interconnexion
de processus et plus particulièrement ceux qui se basent sur le paradigme de composition de
services.

42
Chapitre 4

Architecture Orientée Services et

interconnexion de processus

"You cannot create experience. You must undergo it."

Albert Cames

SOMMAIRE

Chapitre 4 Architecture Orientée Services et interconnexion de processus ............................ 43

4.1 Introduction ............................................................................................................................... 44

4.2 Architecture Orientée Services (SOA)........................................................................................ 44

4.3 Mécanismes d'interconnexion de processus interentreprises .................................................. 48

4.4 Conclusion ................................................................................................................................. 66

43
4.1 Introduction

Nous avons donné un premier aperçu sur le concept de service et l'Architecture Orientée Services
de manière générale dans le chapitre qui a exposé notre problématique de travail. Dans le
premier chapitre de l'état de l'art, nous avons présenté une revue sur les méthodologies de
modélisation de l'entreprise. Cette revue a pour but de connaître les différents concepts qui
constituent l'entreprise et par la suite d'intégrer et de situer le concept de service par rapport à
l'existant. Dans ce deuxième chapitre de l'état de l'art, nous allons présenter dans sa première
partie l'Architecture Orientée Services avec plus de détails. Nous allons exposer plusieurs
définitions issues de plusieurs domaines pour montrer que le concept de la SOA varie selon le
point de vue et selon le champ d'application et qu'il n'y a pas un consensus autour d'une
définition standard. Nous allons parler des démarches de migration vers une Architecture
Orientée Services en mettant l'accent sur l'urbanisation des Systèmes d'Information comme étant
un outil préalable pouvant être utilisé dans un tel projet.

Dans la deuxième partie de ce chapitre, nous nous sommes intéressés au problème

d'interconnexion de processus interentreprises, nous avons fait la revue de quelques technologies
qui existaient en prêtant plus d'attention à la technologie de Web service. Comme nous l'avons
déjà argumenté dans notre choix concernant l'interconnexion de processus, nous avons présenté
le paradigme de composition de services et plus particulièrement les travaux qui ont tenu compte
des paramètres non fonctionnels de services dans leurs processus de composition.

4.2 Architecture Orientée Services (SOA)

Dans la première section de ce chapitre, nous allons présenter le concept de l'Architecture

Orientée Services pour introduire les démarches de migration vers une SOA.

4.2.1 Définition de la SOA

Il existe plusieurs façons de percevoir et de définir une Architecture Orientée Services. La plupart
de ces définitions se concentrent sur l'aspect technique de la SOA, quoique d'autres présentent
des caractéristiques métiers. Voici une liste (non exhaustive) de définitions proposées et issues de
plusieurs sources. Ces définitions sont intéressantes puisqu'elles illustrent plusieurs points de vue
sur la SOA.

Nous allons commencer par une définition très courte qui est celle du W3C :

"SOA is a set of components which can be invoked, and whose interface descriptions can be
published and discovered (W3C, 2004c)."

Cette définition du W3C présente avec une manière très simpliste ce qui peut être fait avec un
service ou avec sa description. Elle ne s'est pas occupée de la notion d'architecture ni de la
manière avec laquelle le service peut être conçu.

Une définition technique a été présentée dans (Krafzig et al., 2004):

44
"A Service‐Oriented Architecture (SOA) is a software architecture that is based on the key concepts
of service, service repository, and service bus. A service consists of a contract, one or more
interfaces, and an implementation."

Les auteurs mettent le point sur l'aspect technique de la SOA qui consiste en une application
frontale qui utilise un ou plusieurs services. Ces services sont publiés dans des registres de
services et la communication entre ces services est assurée par un bus de service.

D'un point de vue métier (Marks, 2006) présente la SOA comme suit :

"SOA is a conceptual business architecture where business functionality, or application logic, is

made available to SOA users, or consumers, as shared, reusable services on an IT
network."Services" in an SOA are modules of business or application functionality with exposed
interfaces, and are invoked by messages."

Cette définition prête une grande attention à l'orientation métier dans la SOA de manière que
nous pouvons avoir l'impression que la SOA est un concept purement métier et que le niveau
technique n'existe que pour le maintien des réseaux et la communication entre les services.

On se basant sur ces différentes définitions et les principes que nous avons énoncés dans le
chapitre 2 de la thèse, nous définirons la SOA de la manière suivante:

La SOA est un style d'architecture qui permet la réorganisation du Système d'Information. Elle
permet l'encapsulation des fonctionnalités d'un système d'information en un ensemble de services
faiblement couplés appartenant à la fois au niveau métier et au niveau technique de l'entreprise.
Les services, munis d'un contrat d'utilisation et d'une interface de description, seront publiés dans
des registres de services afin qu'ils puissent être invoqués par d'autres services.

Notre définition donne une double vision à l'Architecture Orientée Services une vision métier et
une vision technique. Cette séparation de préoccupation a pour but de garantir l'agilité de
l'entreprise.

4.2.2 Les Concepts de la SOA

Dans une Architecture Orientée Services trois rôles clés sont communément identifiés : (i) le
fournisseur de services, (ii) le client du service et (iii) l'annuaire de services. L'interaction entre ces
trois rôles est décrite par la Figure 4.1. Le fournisseur de services crée le service, puis publie sa
description dans un annuaire de services. Cette description précise à la fois les opérations
disponibles et leur mode d'invocation. Le client du service accède à l'annuaire pour effectuer des
recherches afin de trouver les services désirés. Ensuite, une liaison s'établit entre le client et le
fournisseur de service afin d'assurer l'invocation du service en question.

45
 Figure 4.1 : Méta‐modèle de l'architecture orientée service

4.2.3 Migration vers une Architecture Orientée Services

L'Architecture Orientée Services apporte la promesse d'un meilleur alignement du Système

d'Information sur les besoins du métier grâce à la réutilisation des services qui font toute sa
valeur. Manifestement, pour tirer toutes les bénéfices des services réutilisables, il faut se doter
d'une nouvelle démarche pour construire son SI, différente de celles qui sont utilisées auparavant.
Elle ne doit pas viser seulement le niveau technique de l'entreprise, mais elle doit porter plutôt
sur tout le Système d'Information de l'entreprise. En d'autres termes, le défit principale est le
développement d'une démarche pragmatique pour la mise en place d'une Architecture Orientée
Services au sein de l'entreprise.

4.2.3.1 Les méthodes sont mal acceptées et présentent un manque

Les auteurs dans (Bonnet et al., 2008) affirment qu'il y a une réserve des entreprises vis‐à‐vis des
méthodes : "Quand on parle de méthodes, on prend souvent le risque d'entre dire que cela ne sert
à rien, que c'est trop théorique, trop lourd et trop complexe". Il semble qu'il existe déjà un vécu
considérable en méthodologies dans les entreprises. Serait‐il alors judicieux d'ajouter encore de la
méthode ? Ce déficit méthodologique est la conséquence directe de l'absence du mode
opératoire des méthodes, rien n'explique comment réaliser les produits attendus ce qui impose
aux intervenants d'inventer leurs façons de faire ce qui augmente ainsi considérablement les
risques de non qualité.

D'autant plus nous avons montré dans le chapitre précédent de l'état de l'art que les méthodes
classiques de modélisation d'entreprise sont insuffisantes pour faire face à une demande de
systèmes agiles qui nécessitent à la fois des qualités d'expansivité et d'évolutivité. En effet, très
souvent les méthodologies existantes aboutissent à des systèmes monolithiques résistants aux
changements. La notion de service est pratiquement absente de toutes les méthodologies
évoquées.

En outre, les meilleures pratiques proposées comme par exemple TOGAF (TheOpenGROUP,
2007), ne sont pas vraiment des méthodes. Elles décrivent souvent des principes, souvent de bon
sens, mais en vrac. Les interprétations de ces principes sont variables. Par exemple l'objectif en
SOA concernant le couplage faible entre les services peut être interprété de différentes manières
comme par exemple avec une communication synchrone, l'échange de message de XML,
l'utilisation d'un socle technique d'intermédiation ou finalement la mise en place d'un

46
orchestrateur. Ces interprétations multiples ne permettent pas une mise en œuvre assez rapide
et homogène.

4.2.3.2 Démarches de mise en place d'une SOA

Au niveau des démarches, il existe trois angles d'attaque différents pour aborder un tel projet de
mise en place d'une Architecture Orientée Services dans l'entreprise.

Le premier angle d'attaque part de la couche technique de l'entreprise (démarche Bottom‐up). Il

s'agit dans ce cas d'extraire les services à partir des applications existantes. Le retour de cette
démarche est assez clair et bien établi. On aboutit à un ensemble de services techniques dont le
processus d'identification est assez facile, avec par contre un niveau de granularité assez fin et
une profusion de services trop importante ce qui engendre une grande difficulté pour s'aligner
avec le métier.

Le deuxième angle d'attaque est relié directement au métier de l'entreprise (démarche top‐
down). Il consiste à identifier des services réutilisables en se basant sur les descriptions du niveau
métier de l'entreprise. Le résultat est un ensemble de services réutilisables de point de vue
métier. Cependant, cette méthode néglige l'aspect architectural de service. En effet, un service
est une notion d'architecture et le fait de définir des services à partir du niveau métier n'implique
pas forcément que ces derniers peuvent être projetés sur le niveau technique afin d'assurer leur
fonctionnement.

Les méthodes top‐down et bottom‐up ne nous permettent pas d'aboutir à une identification de
services fiables répondant à la finalité de l'Entreprise Orientée Services. La première aboutit à un
ensemble de services très abstraits avec aucune garantie pour leur réalisation du point de vue
technologique, quand à la deuxième, elle concourt à un ensemble de services très techniques qui
n'implique pas forcément un alignement avec les besoins métier.

Le troisième angle d'attaque est le "meet in the middle" qui mène en parallèle une approche top‐
down pour définir des services de haut niveau nécessaires à la réalisation des processus métiers,
ainsi qu'une approche bottom‐up dans le but de cartographier l'existant applicatif de l'entreprise
pour supporter les services métiers. Ensuite, un croisement entre les deux résultats est fait afin de
déterminer comment seront réalisés les processus métiers. Cette démarche paraît la plus
intéressante et la plus concrète.

Cette démarche rejoint la démarche de l'urbanisation fonctionnelle que nous avons jugée
intéressante comme étant un outil préalable pour mener un projet de migration vers une
Entreprise Orientée Services. Cette considération vient du fait que le principe de l'urbanisation
reprend, en quelque sorte, celui de l'Architecture Orientée Services, c'est‐à‐dire le principe de la
modularisation. En effet, face à l'augmentation de la complexité des Systèmes d'Information,
l'urbanisation cherche à créer une grande carte des systèmes, d'abord existants puis en cibles.
Généralement, elle adopte la métaphore de l'urbanisation des villes, le Système d'Information est
comparé à une ville dont on veut maîtriser le développement ; le système est décomposé en des
modules de différentes tailles : des quartiers, des îlots et des blocs.

47
Malgré la convergence entre SOA et urbanisation de SI de point de vue modularité, l'urbanisation
fonctionnelle ne peut pas satisfaire les attentes d'un projet de migration vers un SOA. En effet,
cette démarche va reproduire les silos qu'on avait dans l'analyse fonctionnelle et peu de services
seront vraiment réutilisables transversalement dans le Système d'Information. De plus,
l'urbanisation pratique une découpe fonctionnelle qui est le reflet de l'état des systèmes existants
et laisse subsister une importante redondance. En particulier, les données sont souvent
dupliquées, à l'origine dans le système existant, mais encore trop souvent dans les systèmes cibles
de l'urbanisation. Une démarche SOA qui se base sur l'urbanisation va induire dans ce cas une
redondance au niveau service ce qui contredit le principe de la réutilisation de services. Cette
défaillance vient du fait que l'approche objet est totalement ignorée par les "urbanistes".

Ce principe d'objet est étrange aux urbanistes qui traitent le Système d'Information du point de
vue fonctionnalité. Cependant, il est très intéressant dans le sens que cela va nous permettre de
diminuer la redondance et mettre un premier pas vers les services. Pour cette raison, nous avons
pensé à structurer le Système d'Information autour des grands blocs d'information correspondant
aux objets métier. Ces derniers représentent certaines fonctions du SI, celles qui ne dépendent
pas de l'organisation et que nous pourrions qualifier par la suite de services métier.

Notre démarche de migration vers une EOS se base rejoint le principe de l'urbanisation de point
de vue découpage du Système d'Information selon une approche "meet in the middle".
Cependant notre principal apport par rapport à l'urbanisation consiste à ce que nous traitons ce
problème de point de vue SOA et que notre but est d'aboutir à un ensemble de services
réutilisables qui essaient d'éliminer les silos fonctionnels. Nous avons utilisé le concept d'objet
métier pour éliminer les redondances fonctionnelles et construire des interfaces entre les silos
afin d'assurer la transversalité.

4.3 Mécanismes d'interconnexion de processus interentreprises

La deuxième partie de ce chapitre va traiter la question de l'interconnexion des processus

interentreprises. Ce problème a été déjà traité depuis plusieurs années et plusieurs solutions ont
été mises en œuvre, mais il reste toujours un sujet d'actualité dû aux nouvelles contraintes, aux
changements et aux demandes qui surgissent. Parmi les mécanismes les plus importants pour la
connexion de processus, L'EDI (Electronic Data Interchange) constitue le plus ancien Framework
permettant aux entreprises de partager et d'échanger leurs données via des réseaux privés. Par la
suite, le grand progrès dans le développement logiciel a donné naissance à une nouvelle
génération de logiciels fonctionnant dans des réseaux publics et munis de mécanismes avancés
pour communiquer et échanger des messages.

Afin de mieux cerner les différences qui existent entre les différents mécanismes traités, nous
allons les comparer selon les critères suivants :

1. Communication : ce critère indique le protocole utilisé pour l'échange de messages et

l'interaction entre les différents partenaires.

48
 2. Présentation du contenu : ce critère précise les langages et les modèles utilisés pour la
description et l'organisation des informations échangées entre les partenaires. Ces
informations doivent être interprétées et utilisées correctement par les différents
intervenants.

3. Processus métier : ce critère met le point sur la façon dont le processus final (processus
coopératif) est obtenu et comment il est modélisé.

4. Couplage : ce critère précise le degré de la relation entre les entreprises (les applications)
et la durée de cette relation.

5. Hétérogénéité : ce critère montre le degré de dissimilitude entre les entreprises (de point
de vue messages, sémantique…).

6. Autonomie : ce critère permet d'évaluer et de renseigner sur la capacité d'une technique

d'interconnexion à assurer l'autonomie d'une entreprise coopérante. En effet, les
systèmes des partenaires doivent être autonomes dans leurs spécifications, leurs
communications et leurs exécutions. Dans une interconnexion entre processus de
partenaires autonomes, chaque partenaire est considéré comme une "boite noire"
capable d'échanger des messages. L'interaction entre les partenaires dans ce cas est
assurée via des interfaces bien définies.

7. Coopération : ce critère précise le type de coopération (planifiée, longue durée, à la

demande) supporté par la technique d'interconnexion en question.

4.3.1 Echange de données informatisées : Electronic Data Interchange

L'EDI (Electronic Data Interchange) est défini comme l'échange informatisé de documents
commerciaux structurés entre différentes organisations. Cet échange se fait d'ordinateur à
ordinateur (ou d'application à application) selon des messages préétablis et normalisés via un
mode de communication électronique. Son premier objectif est de minimiser les coûts, les efforts
et le temps demandé pour l'échange de document papier. L'échange de données informatisées
peut être utilisé afin de transmettre, au moyen de l'électronique, des documents comme des
demandes d'achat, des avis d'expédition, des accusés de réception et d'autres types de
correspondance commerciale standardisées entre partenaires commerciaux (Emmelhainz, 1993).
Les entreprises communiquent avec leurs partenaires en utilisant un réseau tiers, connu
également sous le non de Réseau à Valeur Ajoutée (RVA) en anglais VAN (Value Added Network).
Ce dernier sert d'intermédiaire entre des partenaires commerciaux. Il maintient une boite à
lettres à la fois pour l'expéditeur et pour le destinataire pour la réception des différents messages.

49
 Figure 4.2 : Différentes interactions dans l'EDI (Medjahed et al., 2003a), page 63
La figure ci‐dessus (Figure 4.2) présente deux partenaires "Fabriquant_Ordinateur" et
"Fournisseur_CarteMère" en train d'échanger des documents. Le document (Bon de commande)
doit être créé par l'application informatique correspondante de l'expéditeur (fabriquant
d'ordinateur). Les informations doivent d'abord êtres "converties" ou restructurées afin d'être
interprétées par le logiciel de mise en forme ou de traduction. La mise en forme consiste en la
traduction des données d'une forme spécifique à l'entreprise en une structure normalisée EDI
selon le standard utilisé. Le résultat constitue un message EDI prêt à être envoyé. Pour un
message EDI reçu, c'est le même processus qui sera appliqué.

L'avantage majeur de la mise en place d'une approche EDI tient au fait qu'elle est indépendante
vis‐à‐vis des problèmes de sécurité et d'hétérogénéité. En effet, l'EDI est basé sur l'échange de
documents via des réseaux privés. De ce fait, le souci de sécurité rencontré dans les réseaux
publics ne figure plus pour les utilisateurs de l'EDI. De plus, lors de leurs coopérations, les
partenaires sont obligés d'adopter les standards de l'EDI. Ceci permet de résoudre le problème
d'hétérogénéité et garantir par conséquent l'interopérabilité entre les différents systèmes
d'entreprises. En effet, l'EDI traite de l'interopérabilité au niveau du contenu des messages en
offrant un ensemble de types prédéfinis pour décrire les documents commerciaux. Cependant, la
syntaxe des documents EDI est très complexe et sa compréhension est une tâche difficile. De plus,
le nombre de documents supportés par le standard EDI est assez limité et les entreprises se
trouvent obligées de se contenter uniquement de cet ensemble de documents. Il s'avère très
difficile d'adopter de nouveaux modèles de transactions avec de nouveaux paramètres. Ce point
de blocage souligne le manque de flexibilité de l'approche EDI. Introduire de nouveaux types ou
changer des types existants de transaction est une tâche à la fois complexe et coûteuse pour les
entreprises.

Bien que plusieurs implémentations d'EDI aient donné satisfaction et aient montré de bons
résultats, le coût estimé pour intégrer cette technologie au sein d'une entreprise est très élevé.
En effet, l'EDI est basé sur des réseaux propriétaires coûteux rendant difficile aux petites et
moyennes entreprises d'adopter cette technologie dans leurs pratiques d'échange commercial.
De ce fait, ces entreprises ont été exclues des partenariats avec les grandes entreprises
utilisateurs d'EDI (Dogramaci et al., 1998, Kalakota and Whinston, 1996).

50
En outre, l'EDI est considéré comme une solution coûteuse dont le coût dépend de plusieurs
facteurs comme par exemple le volume des documents, la stratégie du logiciel de traduction de
l'EDI et du temps d'implémentation. Les frais de maintenance et les charges du RVA varient
considérablement ce qui affecte aussi le coût d'une solution EDI. Les frais des RVA dépendent du
nombre de documents envoyés et dans certains cas du nombre de caractères dans chaque
document. En plus, chaque déploiement d'EDI nécessite une négociation sur les standards et les
formats des documents qui vont être échangés. Ce processus de négociation et d'agrément ajoute
un coût supplémentaire à l'utilisation de l'EDI. Une étude aux États‐Unis a montré que 6% des 10
millions entreprises existantes peuvent adopter une telle solution (Medjahed et al., 2003a). Les
principaux efforts pour réduire le coût de l'utilisation des réseaux RVA se manifestent
essentiellement dans l'utilisation de solutions EDI basées sur l'Internet comme par exemple
l'EDIINT (IETF) et l'OBI (OBI).

EDIINT ressemble à l'EDI traditionnel, mais il utilise l'Internet comme medium de communication
à la place des RVAs. La finalité de l'EDIINT est de réduire les charges de communication de l'EDI
due à l'utilisation des RVA. EDIINT à été initié par l'Uniforme Code Council dans le but de
standardiser les échanges EDI à travers l'Internet. EDIINET est similaire à l'EDI en termes
d'interopérabilité au niveau contenu et processus. Sur le plan de la communication, le premier
standard d'EDIINET apparu en 2001 était l'EDIINET AS1 (Applicability Statement 1). L'EDIINT AS1
offre des règles pour l'échange de document en utilisant le protocole SMTP. Le deuxième
standard (complété en 2001) est EDIINT AS2 qui utilise le protocole http pour échanger des
documents EDI.

Les standards EDI/EDIINT se sont avérés, eux aussi, coûteux non seulement du point de vue du
débit de transmission, nécessaire à l'initialisation et le déroulement des échanges mais aussi du
point de vue de l'intégration des systèmes. Par conséquent, pour interconnecter leurs processus,
plusieurs entreprises (particulièrement les plus petites) construisent, d'une manière ad‐hoc, leurs
propres modèles électroniques de collaboration avec leurs partenaires, et contournent ainsi
l'utilisation de la norme EDI (Huemer et al., 1997).

Le Tableau 4.1 présente un récapitulatif des différents éléments de synthèse que nous avons
conclu lors de notre étude de l'EDI et de l'EDIINT. Ils ne peuvent pas présenter une solution à
notre problématique d'interconnexion de processus interentreprises vu que le type de
coopération qu'ils peuvent supporter est une coopération planifiée (pas de recherche dynamique
de partenaire) et de longue durée (vue le coût de mise en place d'un processus collaboratif
interentreprises).

51
 Communication Représentation Processus Couplage Hétéro‐ Autono Coopératio
métier généité mie n

EDI Réseaux à ANSI X12 et Processus faible et Oui: non Coopération

valeur ajoutée documents au métier de grâce au planifiée et
format EDIFACT prédéfini longue translate de longue
Asynchrone
durée ur durée
d'applica
tion

EDI SMTP et http ANSI X12 et Processus faible et Oui: non Coopération
INT documents au métier de grâce au planifiée et
Asynchrone
format EDIFACT prédéfini longue translate de longue
durée ur durée
d'applica
tion

Tableau 4.1 : Récapitulatif sur l'EDI et l'EDIINT

4.3.2 Communication entre processus par envoi de messages

En se basant sur les standards utilisés dans le codage et l'échange de données notamment le XML
(eXtensible Markup Langage), les mécanismes d’envoi de messages ont été introduits comme
étant l'une des meilleures solutions pour le problème d'interconnexion de processus d'entreprise
et l'intégration des applications d'entreprise (EAI : Enterprise Application Integration) ainsi qu'au
niveau interentreprises (IEI: Inter Enterprise Integration). Parmi les mécanismes d'envoi de
messages les plus connus on peut citer le mécanisme de "Publish and Subscribe" (Cugola et al.,
1998, Rosenblum and Wolf, 1997) qui se base sur la publication d'événements à travers une
troisième entité appelé le "gestionnaire d'événement". Ce dernier joue le rôle d'intermédiaire
entre les "subscribers" et les "publishers". Le routage d'événements entre ces deux types
d'acteurs se base sur une classification des événements publiés. Nous pouvons noter deux types
de classification possibles : (i) classification selon le sujet des (subject based system) ou (ii) une
classification selon les contenus des événements (contenent‐based system). D'autres mécanismes
d'envoi de messages existent à savoir le "push and pull" (Malhotra et al., 1997), l'invocation
synchrone et asynchrone d'opérations et les callbacks (Krafzig et al., 2004).

L'échange de messages repose sur des couches middlewares classiques orientés messages,
appelés MOM (Message Oriented Middleware). Une infrastructure MOM permet de stocker les
messages qui sont attente de livraison. De plus, elle garde une trace de l'expéditeur du message
et du moment de livraison. Dans le cas d'une interconnexion de processus basée sur le
déploiement d'un MOM, les entreprises publient leurs interfaces de processus dans le MOM qui
servira d'intermédiaire entre les fournisseurs de processus et les clients de processus. Ainsi, le
problème d'interconnexion de processus interentreprises devient un problème de communication

52
par échange de messages entre le fournisseur de service et le MOM, d'une part, et entre le MOM
et le client de service d'autre part. Beaucoup de technologies ont implanté le middleware MOM,
les plus connus étant le service d'événements de CORBA (CORBA Event Server) et le MMSMQ
(Microsoft Message Queue Server).

Parmi les travaux importants qui ont été développés et qui ont assuré l'interconnexion des
processus par des mécanismes d'envoi de messages, nous pouvons citer le travail de (Casati and
Discenza, 2000). Dans leur travail, les auteurs ont étendu le modèle du workflow traditionnel en
utilisant l'approche de "publish and subscribe". Le workflow est donc devenu capable de publier
et de recevoir des événements. Des points précis ont été définis aussi pendant l'exécution du
processus vers lesquels les événements doivent être envoyés. (Hagen and Alonso, 1999) ont
développé aussi une approche de coopération entre processus en se basant sur l'échange
d'événements. Ils ont aussi profité de la persistance des traces de messages transmis pour gérer
la gestion de la reprise et la compensation si l'un des deux workflows communiquant fait une
exception.

Synthèse

Le tableau suivant (Tableau 4.2) récapitule les caractéristiques d'une interconnexion de processus
via les middlewares d'échange de messages (MOM).

Communica Représentatio Processus couplag Hétérogén Autonomie Coopératio

tion n métier e éité n

MOM Réseaux Inexistant Ad hoc : Faible et Non Oui Coopération

privés programm de planifiée et
ation de la longue de longue
Message
logique durée durée
broker
d'intégrati
Asynchrone on

Tableau 4.2 : Récapitulatif sur le MOM

L'interconnexion des processus basée sur les paradigmes d'envoi de messages souffre de
plusieurs limites. En effet, cette approche est appropriée lorsque le nombre de partenaires est
réduit. Cependant, un processus de coopération peut s'étaler sur plusieurs partenaires. Le fait de
les faire communiquer via le MOM s'avère une tâche extrêmement difficile. Même dans le cas où
on concevrait le développement de plusieurs MOMs distribués, ceci va compliquer de plus en plus
l'interconnexion des processus.

4.3.3 Mécanisme d'interconnexion de processus par échange de services

L'interconnexion des processus via le paradigme de l'échange a permis d'atteindre un niveau de

coopération de haut niveau. Le service est un composant logiciel qui assure l’interopérabilité
entre les applications tout en minimisant les besoins de connaissances communes entre les
différentes entités qui vont coopérer. Grâce à leur intégration, les services permettent la

53
construction à la volée des systèmes. En outre, les services minimisent la complexité des systèmes
via l'encapsulation des détails d’implantation des autres services qui les composent.

4.3.3.1 Les composants de CORBA

CORBA (Common Object Request Broker Architecture) (OMG‐CORBA, 1997) est proposé par le
groupe OMG. CORBA fait partie d'une architecture générale appelée OMA (Object Management
Architecture). CORBA se base sur l'ORB (Object Request Broker) pour la communication entre les
composants. L'ORB facilite la tâche des développeurs pour assurer la communication entre les
applications. Quand un client cherche à invoquer une méthode d'un composant déployé dans un
serveur particulier, l'ORB intercepte cette invocation et fait son routage à travers le réseau
jusqu'au serveur. Les composants distribués dans différents ORBs peuvent aussi communiquer à
travers le réseau public Internet en utilisant le protocole IIOP (Internet Inter‐ORB Protocol).

Selon l'approche CORBA, la découverte des partenaires se fait à travers le Trade Center en
attribuant des propriétés descriptives aux composants. Cependant, ces propriétés, décrites sous
la forme (nom, valeur), sont assez simples pour assurer une recherche fiable et pertinente et qui
tienne en compte des contraintes d'une coopération dynamique et à la demande dans laquelle les
entreprises ne se connaissent pas. (Daniel, 2000).

Dans CORBA la communication entre les composants est assurée par des invocations de
méthodes. Les fichiers CIDL (Component Interface Description Language) qui décrivent les
interfaces du composant seront compilés en stubs et en skeletons. Le stub est utilisé dans le côté
client pour faire l'invocation d'une opération distante (remote operation) du skeleton
correspondant dans le côté serveur via l'ORB. Le skeleton reçoit les paramètres d'appel, invoque
l'opération adéquate, collecte les résultats et les retourne au client via l'ORB. Ce type de
communication par invocation de méthode met le point sur le couplage fort qui existe entre les
partenaires. En effet, n'importe quelle modification au niveau client ou fournisseur va induire des
changements au niveau de l'autre partenaire. Un autre reproche peut être aussi apporté à CORBA
concernant le manque de flexibilité vis‐à‐vis des changements.

4.3.3.2 Les composants d'EJB

L'EJB (Enterprise Java Beans) (Sun, 1999) est une technologie développée Par SUN dans la
spécification J2EE. EJB décrit un modèle de composants développés en langage JAVA et supporte
uniquement les composants java. L'idée de base de l'EJB est d'encapsuler la logique métier des
fonctions dans des entités et de les munir d'interfaces pour assurer la communication avec eux.
Ces entités (composants) sont appelées les Beans. Un composant EJB est hébergé dans un
contexte d'exécution appelé "Conteneur". L'infrastructure d'accueil des composants EJB
comprend également un environnement d'exécution appelé "le serveur" qui permet l'accès aux
mécanismes de gestion d'exception et de communication. La communication entre les Beans est
assurée par le RMI (Remote Method Invocation). Ce dernier permet de router les invocations de
méthodes entre les composants à travers le réseau d'une manière transparente.

Choisir EJB comme solution de l'interconnexion de processus permet d'instaurer une relation de
couplage fort entre les partenaires. De la même manière que CORBA, l'EJB est plutôt destiné à des

54
relations métier de longues durées vu que son adaptabilité aux changements est à la fois réduite
et coûteuse. Les développeurs doivent définir pour chaque Bean une interface RMI distante. Le
stub est installé chez le client et offre un Proxy local. Le stub implémente toutes les interfaces
distantes et délègue tout appel de méthode à travers le réseau au Bean distant.

Synthèse

Les techniques d'interconnexion de processus à base de composants sont plus adaptées à une
interconnexion de processus en intra‐entreprise et vu le couplage fort qui va être établi entre les
processus. Les plateformes existantes exigent un modèle de communication spécifique pas
toujours adapté aux besoins de l'interconnexion : la communication est intégrée dans le code
même des composants. Par conséquent, l'évolution de l'interconnexion ne peut pas se faire
indépendamment de l'évolution des composants eux‐mêmes.

Dans le but d'affaiblir le couplage fort, EJB par exemple a intégré dans sa spécification EJB 2.0
(Sun, 2001) le mécanisme de communication via l'échange de messages. On peut utiliser donc le
JMS (Java Messaging Service) pour supporter l'échange de messages entre les Beans. Le serveur
d'événement (Event Server) (OMG‐CORBA, 2004) de CORBA permet ainsi d'assurer une
communication entre les composants via l'échange d'événements permettant d'affaiblir le
couplage fort entre les partenaires.

De plus, CORBA et EJB n'offrent pas des outils pour assurer la découverte et la sélection de
composant d'une manière dynamique. En effet, dans la majorité des cas, les composants à
interconnecter sont connus auparavant. De ce fait, les composants sont plus adaptés à des
coopérations interentreprises planifiées et de longues durées.

4.3.3.3 Les Web services

Les Web Services sont considérés comme l'instanciation la plus importante du modèle SOA dans
le domaine industriel. Le consortium W3C définit un Web service comme étant une application ou
un composant logiciel (i) identifié par une URI, (ii) dont ses interfaces et ses liens (binding)
peuvent être décrits selon le standard XML, (iii) sa définition peut être découverte par d'autres
Web services et (iv) qui peut interagir directement avec d'autres Web services en échangeant des
messages codés en XML et utilisant des protocoles Internet (W3C, 2004c).

Les principaux apports de la technologie des services Web sont principalement : la

standardisation, l'universalité, le couplage faible entre les services et la virtualisation qui permet
de définir une indépendance vis‐à‐vis de la localisation et de l'implémentation des services.

Les Web services se basent sur une pile de protocoles constituée de plusieurs couches (Figure
4.3). Chaque couche s'appuie sur un standard particulier. Au‐dessus de la couche de transport,
trois initiatives de standardisation majeures ont été proposées au consortium W3C pour
supporter les interactions entre les Web services : SOAP (W3C, 2000), WSDL (W3C, 2001) et UDDI
(W3C, 2002a). Ces trois standards constituent l'infrastructure de base des Web services. Deux
types de couches ont été également proposées afin de compléter les trois premières : (i) les
couches transversales (exemple : sécurité, administration, transactions et qualité de services

55
(QoS)) afin d'inciter l'utilisation des Web services dans le monde industriel ; (ii) une couche
Business processus qui permet l'utilisation des Web services dans le domaine du e‐business.

Dans le reste de cette section, nous nous sommes intéressés principalement à la description et la
publication de services. Nous ne nous sommes pas limités aux standards présentés par le W3C
(W3C, 2002b), mais nous avons essayé d'évoquer d'autres technologies qui existent notamment la
description sémantique de services avec l'OWL et les propositions de ebXML.

Figure 4.3 : Principaux standards du Web service (W3C, 2002b)

4.3.3.3.1 Description de service

™ Web Service Definition Language (WSDL)

WSDL (W3C, 2001) représente une grammaire basée sur XML qui permet de décrire les services.
WSDL permet de spécifier ce que le service sait faire, sa localisation et les méthodes de son
invocation. En d'autres termes, WSDL permet la description de l'interface du service, des détails
techniques, du protocole d'accès et des points d'entrée. Un document WSDL définit un service
comme une collection de points d'entrée (endpoints) et sépare la définition abstraite de
l'implémentation. WSDL est utilisé avec SOAP et contient même un binding vers le SOAP.

WSDL contient trois parties principales. La première partie fournit une description abstraite des
messages et des types de ports. Ces derniers décrivent les opérations proposées par le service.
Une opération représente une séquence spécifique de messages d'entrée et de sortie. Les
opérations définies par WSDL sont atomiques et ne permettent pas une vision sur des
informations intermédiaires. La deuxième partie effectue le lien entre la définition abstraite et
l'implémentation concrète. Elle décrit comment les opérations peuvent être invoquées et spécifie
un ensemble concret de ports (désignés par une URL ou une liaison SOAP). La dernière partie
décrit la localisation du service. La définition du service peut également contenir la description
des types de données complexes utilisées par le service.

™ Collaboration Partner Profile (CPP) de ebXML

ebXML (ebXML, 2007) est une initiative de UN/CEFACT (United Nations Centre for Trade
Facilitation and Electronic Business) et OASIS (Organization for the Advancement of Structured
Information Standards) qui regroupe plus de soixante‐quinze entreprises mondiales.

56
La spécification d'un profil de collaboration (Collaboration Partner Profile, CPP) (ebXML, 2002)
dans ebXML permet à toute entreprise de décrire ses caractéristiques et ses capacités (métier et
technologique) et de les mettre à disposition à ses éventuels partenaires. Par exemple, le profil de
collaboration sert à décrire les processus métiers supportés par une entreprise, son rôle dans les
processus, les messages échangés, le protocole de transport des messages utilisés, etc. De plus,
une entreprise peut également créer de multiples CPP qui définissent plusieurs types de
collaborations.

Outre le CPP, ebXml propose un Agrément sur un Protocole de Collaboration (CPA) (ebXML,
2002). Un CPA définit les modalités avec lesquelles deux partenaires peuvent interagir et
s'engager dans une collaboration. Le CPA est créé en déterminant par calcul ou par négociation
l'intersection de deux CPPs : un CPA doit seulement contenir les éléments des CPPs qui sont
communs aux deux partenaires ou qui sont compatibles.

Le CPA tient compte uniquement des interactions publiques entre les deux parties. Les
interactions internes au sein de l'entreprise ne figurent pas dans le CPA. Chaque partie exécute
ses processus internes d'une manière autonome et essaie de garantir son interfaçage avec la
collaboration décrite dans le CPA et le document de Spécification de Processus (décrit dans le
schéma de spécification de processus métier (Business Process Specification Schema (BPSS)
(ebxml, 2001a)).

L'objectif du CPA est de fournir une spécification de haut niveau facile à comprendre et
suffisamment précise. Ceci permettra aux entreprises d'interpréter ces spécifications et bien
configurer, par conséquent, leurs modules destinés à la collaboration et la communication avec
les partenaires. De cette manière, on assure la compatibilité des messages échangés par les
partenaires même si leurs systèmes ne sont pas issus des mêmes vendeurs.

™ OWL‐S (Web Ontology Language for Services)

OWL‐S (W3C, 2004a) est une ontologie pour la description sémantique des Web services. Elle se
base sur le langage standard OWL qui permet de représenter des ontologies de façon
standardisées sur le Web (W3C, 2004b). L'objectif d'OWL‐S est de formaliser de façon non
ambiguë les Web services pour que les informations présentées par les services puissent être
exploitées et traitées (Martin et al., 2004). Ainsi, la notion d'ontologie joue un rôle indispensable
afin d'expliciter la sémantique des services, facilitant ainsi les communications hommes‐machines
d'une part, et les communications machines‐machines d'autre part. La sémantique, ainsi
exprimée, permettra l'automatisation des fonctionnalités de découverte et de sélection de
services.

OWL‐S est architecturée autour de quatre entités (Figure 4.4). La classe Service fournit le point
d'entrée pour la description d'un Web service. Le ServiceProfile renseigne sur les fonctionnalités
proposées par le Web Service, le ServiceModel décrit comment le service fonctionne et le
ServiceGrounding présente comment invoquer le service.

57
 Figure 4.4 : Ontologie OWL‐S
Synthèse

La description de service est une étape principale pour assurer une sélection pertinente de
services. Cependant, malgré les efforts qui sont faits, on remarque que toutes les méthodes de
description se sont limitées au niveau fonctionnel de service, c'est‐à‐dire ce que le service offre en
termes d'opérations, en termes technologiques, en termes de protocoles de communication et de
messages échangés. L'OWL‐S a apporté un apport important sur la description des services certes,
mais malheureusement les descriptions sémantiques ainsi introduites ont touché seulement le
niveau fonctionnel de service. Ces manques au niveau de la description des services ont été
invoqués car nous pensons que dans le cadre d'une collaboration dynamique interentreprises, et
compte tenu du nombre de services existant sur le marché, nous aurons besoin d'une description
plus pragmatique des capacités de services pour être en mesure de différencier deux services qui
sont semblables au niveau fonctionnel. C'est le rôle des paramètres non fonctionnels qui doivent
être ajoutés à la description de services. Les paramètres non fonctionnels constituent l'ensemble
des propriétés qui caractérisent un service et qui permettent d'avoir une idée sur la manière avec
laquelle le service est capable d'exécuter ces fonctionnalités. Les paramètres de qualité de
services (QoS) sont un exemple de ces paramètres non fonctionnels.

4.3.3.3.2 Communication entre services

Le SOAP (Simple Object Acess Control) (W3C, 2000) est un protocole d'échange de messages
entre les Web services. Le message SOAP est un document XML créé sous un format spécifique.
L'objectif de SOAP est d'assurer la simplicité de l'accès aux services, objets et serveurs distants.
Cet accès doit se faire indépendamment du langage de programmation, du modèle d'objets et des
plates‐formes. Cette indépendance explique son adoption comme le premier standard pour
l'échange de messages entre les Web services.

Un message SOAP contient deux sous‐messages : le premier invoque une méthode d'un objet
distant avec passage de paramètres et l'autre assure le retour de la réponse contenant le résultat
de la méthode. De cette manière, SOAP effectue un lien transparent entre le fournisseur et le
demandeur de service.

La Figure 4.5 montre que le message SOAP est formé de trois blocs: l'enveloppe (envelop),
l'entête (header) et le corps (body). L'enveloppe est une partie obligatoire du message qui
marque le début et la fin. L'entête du message est optionnelle. L'entête permet d'ajouter à un

58
message SOAP des attributs spécifiques qui ne sont pas acceptés par toutes les parties et qui
peuvent donc être "négociés" au cas par cas. Le corps du message permet de décrire le nom de la
procédure et la valeur des paramètres d'appel dans le cas d'une demande de service ou la valeur
des paramètres de retour après l'exécution du service. Le corps est un champ obligatoire et peut
contenir un ou plusieurs autres corps contenus dans le même message.

Figure 4.5 : Structure d'un message SOAP (Newcomer, 2002), page 83

4.3.3.3.3 Publication de services

™ Universal Description, Discovery and Integration (UDDI)

UDDI (W3C, 2002a) est un protocole qui permet la publication et l'interrogation des Web services.
Le composant principal de l'UDDI est son registre. Ce dernier représente une base de documents
XML qui contiennent des informations concernant les entreprises et les services que celles‐ci
proposent sur le Web. Ces informations sont contenues dans : des pages blanches, des pages
jaunes et des pages vertes. Les pages blanches contiennent des informations sur le fournisseur de
services comme par exemple : nom, adresses, personnes à contacter, identificateurs etc. Quant
aux pages jaunes, elles contiennent des informations sur les catégories industrielles (basées sur
des taxonomies standard). Les pages vertes contiennent des informations techniques concernant
les services publiés. Elles incluent des références vers les spécifications des services, les types de
documents que le demandeur peut recevoir, ainsi que les différents points d'entrée (URL) du
service. Pour permettre ces descriptions, l'UDDI, comme présenté dans le méta‐modèle suivant
(Figure 4.6), se base sur quatre structures de données définies selon un schéma XML bien défini :
BusinessEntity, businessService, bindingTemplate et tModel.

La structure busienssEntity représente les informations qui concernent les différentes

organisations. Le businessService inclut les informations non techniques relatives au service
comme son nom et une brève description. Chaque service peut avoir plusieurs bindingTemplate
qui définissent les points d'entrées du service (URL) et comment accéder au service (protocole
d'accès). Quant au tModel, il comprend des liens vers les informations techniques d'un service
comme par exemple un fichier WSDL.

59
 Figure 4.6 : Méta‐modèle de l'UDDI
En résumé, il est important de noter que l'UDDI se limite à l'indexation des services suivant des
catégorisations prédéfinies et ne traite pas la sémantique du contenu des informations publiées.

™ Registre ebXML

Le registre ebXML (ebXML, 2001b) contient des spécifications des processus métiers et des profils
de collaboration (CPP) de toutes les entreprises qui ont déjà participé dans des transactions
ebXML. En effet, les entreprises publient leurs profils dans le registre ebXML afin de les rendre
visibles aux éventuels partenaires. De plus, les entreprises peuvent à tout moment mettre à jour
leurs profils.

En plus, les scénarios de coopération sont stockés dans le registre ebXML. Ces modèles de
coopération seront instanciés en cas de besoin pour être utilisés dans les transactions
commerciales. Les entreprises peuvent étendre ces processus ou ajouter leurs propres scénarios
dans le registre. Pour initier une coopération, les entreprises publient dans le registre un scénario
de travail et spécifient les processus métiers qu'elles peuvent implanter.

Synthèse

Le registre UDDI et le registre d'ebXML ne peuvent supporter qu'une recherche de services par
mots‐clés. Les descriptions de services que ces deux registres peuvent contenir sont des
descriptions qui traitent principalement les paramètres fonctionnels, bien qu'on puisse trouver
d'autres descriptions (comme par exemple des informations concernant les fournisseurs, les
catégories de services, etc.). Cependant ces dernières sont d'ordre général et ne permettent pas
de trancher entre deux services présentant les mêmes fonctionnalités. La question à soulever
concernant la publication de service est comment attacher d'autres descriptions de type non
fonctionnel aux registres de services et comment on peut utiliser ces informations pour
déboucher à une sélection de services satisfaisant les attentes des utilisateurs ?

60
4.3.3.3.4 L'orchestration de services

L'orchestration de service permet de définir l'enchaînement des services selon un canevas

prédéfini, et de les exécuter à travers des "scripts d'orchestration". Ces scripts sont souvent
représentés par des processus métier ou des workflows inter/intra‐entreprises. Ils décrivent les
interactions entre applications en identifiant les messages, et en branchant la logique et les
séquences d'invocation (Waqar and Racca, 2004)

Le standard le plus important pour l'orchestration des services est le BPEL4WS (Andrews et al.,
2003) abrégé aussi en BPEL. Son objectif est la modélisation du comportement des services dans
les interactions au sein d'un processus intra ou interentreprises. BPEL4WS se base sur le standard
XML. Il offre une description de la coordination des services. La spécification de BPEL se base
essentiellement sur WSDL. Il définit le séquencement des opérations proposées par les services et
les données échangées entre eux. La spécification utilise la notion de partenaire. Un partenaire
est un service qui a fait appel ou a été invoqué par le processus. Chaque partenaire a un rôle
spécifique dans le processus.

La spécification BPEL supporte des activités élémentaires et des activités structurées. Une activité
élémentaire peut être considérée comme un composant qui interagit avec une entité externe au
processus lui‐même. Par exemple, les activités élémentaires s'occupent de la réception et de la
réponse aux requêtes de messages ainsi que de l'invocation des services externes. En revanche,
les activités structurées gèrent le flot global du processus. Elles indiquent quelle activité doit être
exécutée et dans quel ordre. Ces activités permettent aussi des boucles avec des conditions et des
branchements dynamiques. En effet, BPEL possède un bon pouvoir d'expression (des notions
d'agrégation, de branchement, de concurrence, d'itération, de compensation et de contraintes de
temps) et il propose également un cycle de vie et un modèle de corrélation des messages. BPEL
distingue les processus exécutables des processus abstraits et différencie clairement le niveau
public des processus abstraits du niveau privé de leur réalisation (processus exécutables). Un
processus exécutable modélise le comportement des participants au sein d'une interaction
spécifique. Les processus abstraits, appelés protocoles de travail (business protocols), spécifient
l'échange de messages entre les participants. Les protocoles de travail ne sont pas exécutables et
sont indépendants des interactions entre les partenaires. Les données sont transmises entre deux
(ou plusieurs) activités via un mécanisme de partage d'espaces globaux de stockage, appelé
container.

4.3.3.4 Synthèse des mécanismes d'interconnexion de processus par échange de services

Le tableau 4.3 expose un récapitulatif des différentes propriétés qui caractérisent l'interconnexion
de processus par échange de services.

61
 Communicat Représentat Processus coupla Hétérogéné Autonomie Coopérati
ion ion métier ge ité on

CORB ORB et IIOP Inexistant Ad hoc : très Différents Séparation Coopérati

A programmat fort et langages et entre on
Réseaux
ion de la de plateforme l'interface et planifiée
privés
logique longue s l'implémentat et de
Synchrone d'intégration durée ion (IDL) longue
durée

EJB RMI/JMS Inexistant Ad hoc : très Langage Séparation Coopérati

programmat fort et java et entre on
Réseaux
ion de la de différentes l'interface et planifiée
privés
logique longue plateforme l'implémentat et de
Synchrone d'intégration durée s ion (EJB longue
remote durée
interface)

Web SOAP WSDL WSFL, Faible Description Séparation Coopérati

servic XLANG, et WSDL à entre on
Internet et Possibilité
e BPEL4WS. courte base de l'interface planifiée
réseaux d'ajouter
durée XML pour WSDL et ou
privés une
ou de supporter l'implémentat coopérati
description
Synchrone et longue plusieurs ion on à la
sémantique
asynchrone durée types demande
via des
d'applicatio
concepts
n
d'ontologie

Tableau 4.3 : Récapitulatif de l'interconnexion par échange de services

On peut remarquer facilement l'avantage que peut apporter la technologie Web service pour
l'interconnexion et la coopération des processus interentreprises. Cette constatation confirme
notre choix dès le début pour le développement d'une interconnexion de processus via la
composition de services. Cependant, d'après notre étude, nous avons remarqué que la
technologie de Web service présente des problèmes surtout au niveau de la description de
services ce qui engendre par la suite un problème au niveau de la sélection de services à
composer. En effet, les Web services sont décrits suivant leurs paramètres fonctionnels
seulement. Aucune importance n'a été accordée à la description non fonctionnelle de services.

Nous avons donné, dans notre travail, une grande importance à la composition de services
prenant en compte les paramètres non fonctionnels et nous avons développé un Framework de
découverte et de sélection de services qui traite les paramètres non fonctionnels depuis leur
description, publication, et jusqu'à leur utilisation pour différencier deux services
fonctionnellement équivalents.

62
Dans le reste de chapitre, nous allons présenter les méthodes de composition de services en
prenant en détail les travaux de sélection de services qui ont traité les paramètres non
fonctionnels.

4.3.4 Composition de service

Un service possède l'avantage d'être composable avec d'autres services. D'ailleurs, cette
caractéristique constitue l'une des forces de ce concept. La composition de services a été définie
dans (Casati and Shan, 2001) comme étant "la capacité d'offrir des services à valeur ajoutée en
combinant des services existants offerts par différentes organisations". Le service ainsi résultant
du processus de composition de services est appelé service composite (Alonso et al., 2004). La
composition de services peut être accomplie en combinant soit des services élémentaires soit des
services composites. De cette manière, les services composites sont définis d'une manière
récursive comme une agrégation de services élémentaires et de services composites (Khalaf and
Leymann, 2003).

4.3.4.1 Les approches de composition

La composition de services est au centre d'une activité intense de recherche. Plusieurs

préoccupations ont motivé des chercheurs appartenant à différentes disciplines. Plusieurs
approches de composition ont été proposées dans la littérature. Dans le cadre de notre étude,
nous avons choisi de classer ces approches selon deux axes différents : le premier axe est la
composition statique vs. la composition dynamique et le deuxième axe est la composition
manuelle vs. la composition automatique.

a. Composition de services statique vs. dynamique

La composition statique se déroule pendant la phase de spécification de l'architecture d'un

système. Les services qui vont être incorporés dans la composition sont identifiés, interconnectés,
compilés et déployés pour être utilisés. Ce type de composition est plus adapté à un
environnement plus ou moins stable où la fréquence des changements aux niveaux partenaires et
services est très faible. Parmi les outils de composition statique on peut citer Biztalk de Microsoft
(Microsoft, 2000).

La composition statique devient inappropriée dans le cas où les fournisseurs de services

publieraient de nouveaux services ou dans le cas où les services déjà utilisés subiraient un
changement dans leurs structures ou fonctionnalités. Dans ce cas, il devient inévitable de modifier
l'application globale que se soit en introduisant de nouveaux services ou, dans le cas échéant, de
concevoir de nouveau l'application. Par conséquent, la composition dynamique s'avère très
intéressante et plus approprié à l'environnement actuel des entreprises qui cherchent à instaurer
les éléments nécessaires pour une coopération dynamique et à la volée. La composition est dite
dynamique, lorsqu'elle tient compte des services disponibles, de leurs fonctionnalités et du but à
atteindre que ce soit avant ou pendant l'exécution des services. Plusieurs types de composition
dynamique ont été développés. On note par exemple la composition basée sur les règles métier
(Chun et al., 2005) (Maamar et al., 2006), la composition déclarative (Medjahed et al., 2003b)

63
(Thakkar et al., 2004, Thakkar et al., 2002, Thakkar et al., 2003) et la composition sémantique
(Medjahed and Bouguettaya, 2005, Medjahed et al., 2003b) (Fujii and Suda, 2005, Fujii and Suda,
2006).

D'une façon générale, la composition dynamique de services dépend de trois éléments essentiels :
(i) la description des services et de la requête, (ii) le mécanisme de matching qui met en
correspondance la description des services avec la description de la requête utilisateur et (iii) le
processus d'intégration qui permet de récupérer les informations concrètes sur les services
choisis lors du processus de matching et de procéder aux différentes invocations de services pour
réaliser la requête utilisateur.

b. Composition de services manuelle vs. automatique

Plusieurs travaux ont abordé la composition de services et plusieurs approches ont été
développées. Ces approches varient depuis l'utilisation de la composition manuelle de services en
se basant sur des outils GUI (Graphical User Interface) jusqu'à l'utilisation des techniques de la
planification de l'intelligence artificielle (Wu et al., 2003) (Sirin and Parsia, 2004) afin d'assurer
une composition automatique.

L'avantage de la composition manuelle des services est double. D'une part, elle permet de
contrôler la spécification de la composition et d'autre part, elle permet de créer des flux de
contrôle complexes entre les services considérés souvent plus proches de la réalité. Quant à la
composition automatique, elle se base sur des techniques qui réduisent au maximum
l'intervention humaine lors de la création des flux de contrôle entre les services. Cependant, ces
techniques ne permettent pas de spécifier des flux de contrôle complexes comme par exemple le
parallélisme, les loops et le branching qui sont très présents dans les processus de coopération
interentreprises.

Synthèse et positionnement

Le point fort de la composition manuelle de services tient au fait qu'elle détient un contrôle total
sur la spécification des différentes étapes du processus global (service composite) ainsi que sur la
création des flux complexes entre les services. En revanche, la composition automatique réduit
l'intervention humaine lors de la création des flux de contrôle. Cependant, elle ne permet pas
d'atteindre un niveau de complexité élevé dans la définition des flux de contrôle complexes. Pour
cette raison, nous avons jugé qu'une combinaison des deux approches s'avère intéressante. En
effet, dans le cadre de nos travaux, nous proposerons une approche de composition semi‐
automatique dans laquelle le schéma de processus est défini manuellement tandis que les
services seront sélectionnés d'une manière automatique.

Concernant la composition statique vs. dynamique, notre approche de composition de services

combinera l'approche de composition à base de règles et la composition sémantiques. En effet,
dans notre travail, nous allons tenir compte des paramètres non fonctionnels (les règles) qui
décrivent les services d'entreprise. Ces paramètres vont être décris par des politiques enrichies
sémantiquement par des concepts ontologiques afin de faciliter leurs manipulations.

64
Afin de situer notre contribution sur les paramètres non fonctionnels, nous allons décrire dans la
section suivante quelques travaux qui ont abordé le sujet de la description non fonctionnelle ainsi
que la découverte et sélection de services suivant ce genre de paramètres.

4.3.4.2 Paramètres non fonctionnels de services

Les paramètres non fonctionnels de services permettent d'apporter des informations
supplémentaires sur la manière avec laquelle le service exécute ses fonctionnalités. La majorité
des travaux ont traité la description et la sélection des Web services d'un point de vue fonctionnel
et ont essayé de l'améliorer que ce soit par le développement de descripteur sémantique à l'instar
du standard OWL‐S et du Framework WSMO ou par l'ajout d'annotation sémantique dans le
standard WSDL comme par exemple le A‐WSDL (Annotated WSDL) ou le WSDL‐S (Semantic
WSDL).

Peu de travaux se sont investis sur les paramètres non fonctionnels de services. Le premier travail
qui a traité les propriétés non fonctionnelles et la description de service est (O’Sullivan et al.,
2002). Les auteurs ont montré que les paramètres non fonctionnels sont importants pour assurer
une sélection pertinente de services. Cependant, ce travail ne présente qu'une simple
énumération de paramètres non fonctionnels et ne traite pas la façon avec laquelle ces derniers
seront représentés ou utilisés par la suite. La majorité des travaux qui ont étudié les paramètres
non fonctionnels se sont focalisés sur les propriétés de qualité de service (QoS).Plusieurs études
académiques et industrielles ont proposé l'inclusion de la qualité de service dans les standards du
Web service. Leur challenge était comment utiliser ces propriétés de QoS pour améliorer la
description et par suite la sélection de services Dans (Maximilien and Singh, 2004), les auteurs ont
abordé le sujet de la sélection dynamique via un Framework d'agent couplé avec une ontologie de
qualité de service. Pour cette raison une ontologie de trois niveaux a été définie. L'ontologie du
niveau supérieur présente les concepts génériques de la qualité de service. L'ontologie du milieu
inclut les concepts de qualité qui sont applicables dans des domaines multiples. Cette ontologie
est complétée par l'ontologie du niveau inférieur qui est spécifique à un domaine particulier.
Cependant, les auteurs dans ce travail non pas traité la manière avec laquelle ils vont présenter
ces paramètres de qualité de service et comment ils vont les exposer pour pourvoir les utiliser. De
plus le problème de matching entre les propriétés de QoS n'a pas été traité.

Dans (Diamadopoulou et al., 2008), les auteurs ont proposé un modèle de composition de
services qui prend en considération les paramètres fonctionnels et non fonctionnels. Ils utilisent
un broker pour récupérer les informations concernant la qualité de service depuis les fichiers
WSDL. Les limites majeures de ce travail consistent dans la manière de publier et exploiter les
informations concernant la qualité de service. En effet, ils se contentent d'insérer les propriétés
de la QoS dans le fichier WSDL d'une manière non structurée, ce qui engendre par la suite une
grande difficulté pour les exploiter. En plus tout changement dans ces propriétés entraînera la
modification du fichier WSDL en entier. Finalement, les auteurs ne se sont intéressés qu'aux
paramètres quantitatifs de la QoS qui correspondent à des valeurs numériques. De cette façon, ils
ne peuvent pas répondre à une grande partie des requêtes des utilisateurs qui décrivent leurs
paramètres d'une manière nominale.

65
Le travail présenté dans (Xu et al., 1007) propose un modèle de sélection de services qui se base
sur les paramètres de qualité de service et la réputation des services. Ce travail développe par la
suite un algorithme qui permet de sélectionner les services et de les ordonner. La principale limite
de ce travail réside dans le fait que les auteurs injectent directement les paramètres non
fonctionnels dans le champ tModel de l'UDDI ce qui va rendre leur gestion difficile. En plus, leur
algorithme de matching entre les paramètres considère uniquement les paramètres numériques.
La gestion des paramètres quantitatifs n'a pas été traitée.

Synthèse

Les différents travaux qui ont été présentés n'ont pas traité en totalité les paramètres non
fonctionnels de services. Les manques qui ont été soulignés concernent la manière de description
des paramètres, la façon avec laquelle ils sont publiés et attachés au service, les types des
paramètres traités (généralement des paramètres quantitatifs) et finalement la manière de
comparaison ou de matching entre les paramètres.

Comparée à ces travaux, notre proposition développée ci‐après présente deux avantages majeurs.
En premier lieu, nous tenons compte de tout le cycle de vie des paramètres non fonctionnels
depuis leurs définitions, publication et exploitation dans la phase de sélection. En second lieu,
nous considérons tous les types de paramètres non fonctionnels que ce soit qualitatifs ou
quantitatifs.

4.4 Conclusion

Dans ce deuxième chapitre de l'état de l'art, nous avons présenté l'Architecture Orientée Services.
Nous avons aussi exposé les différentes démarches pour assurer la migration vers une telle
architecture dans l'entreprise. Par la suite, nous nous sommes intéressés à l'interconnexion des
processus d'entreprise en rappelant quelques technologies qui ont traité de ce sujet notamment
les Web services. Nous avons présenté avec plus d'attention le paradigme d'interconnexion de
processus d'entreprise via une méthode de composition de services. On a déduit que les
approches de composition ne favorisent pas le cas de collaboration interentreprises et on a
présenté notre solution sous forme d'une composition semi‐automatique qui tient compte
principalement des paramètres non fonctionnels des services.

66
Chapitre 5

Entreprise Orientée Services

"Once an organization loses its spirit of pioneering and rests on

its early work, its progress stops".

Thomas Watson, President de IBM

SOMMAIRE

Chapitre 5 Entreprise Orientée Services ................................................................................ 67

5.1 Introduction ............................................................................................................................... 68

5.2 Entreprise Orientée Services : définition et présentation ......................................................... 68

5.3 Présentation des concepts de l'Entreprise Orientée Services ................................................... 70

5.4 Présentation détaillée des concepts du niveau métier de l'EOS ............................................... 78

5.5 Présentation détaillée des concepts du niveau informatique de l'EOS ..................................... 93

5.6 Conclusion ................................................................................................................................. 95

67
5.1 Introduction

Nous avons préalablement motivé l'Architecture Orientée Services (SOA) comme étant une
solution à notre problématique de recherche. Cependant, à l'heure actuelle, l'Architecture
Orientée Services est principalement destinée à intervenir au niveau du système informatique des
entreprises en présentant leurs différentes applications sous forme d'un ensemble de modules
indépendants capables d'être composés appelés services. Néanmoins, en quête d'agilité, la SOA
doit dépasser le cadre technique liés au niveau l'informatique pour toucher le niveau métier de
l'entreprise. Dans ce sens, le vrai challenge consiste à étendre la SOA à l'ensemble du Système
d'Information de l'entreprise.

L'objectif de ce chapitre est de répondre à une telle finalité. Pour y aboutir, on propose d'étendre
l'Architecture Orientée Services sur l'ensemble du Système d'Information de l'entreprise en
totalité. Ainsi, le résultat est un écosystème orienté services qui englobe des services appartenant
à différents niveaux : le niveau métier et le niveau informatique. Les services résultants
garantissent l'agilité de l'entreprise d'une part et lui offre l'architecture et l'infrastructure
nécessaires pour adhérer à des scénarios de collaboration interentreprises dynamique et à la
demande. Nous avons appelé cette nouvelle architecture d'entreprise basée sur les services
l'Entreprise Orientée Services (EOS).

Pour le développement de ce chapitre, nous avons posé quelques questions directrices auxquelles
nous avons essayé de répondre :

ƒ Que représente un service pour l'entreprise ?

ƒ Quel sera sa position par rapport aux différents concepts de l'entreprise ?

ƒ Quels sont les différents types de services qui existent au sein d'une entreprise ?

ƒ Quelle est la relation entre les services et les processus d'entreprise ?

ƒ Quel niveau de granularité faut‐il définir pour les services afin d'assurer une gestion facile
et une réutilisation maximale ?

ƒ Quel degré de généricité faut‐il retenir ?

De nouveaux concepts ont été introduits dans l'Entreprise Orientée Services notamment le
concept de service métier et le service virtuel. Nous allons définir, dans ce chapitre, l'ensemble
des concepts qui constituent l'EOS ainsi que les relations qui existent entre eux. C'est le rôle des
méta‐modèles que nous allons présenter.

5.2 Entreprise Orientée Services : définition et présentation

Le but de cette section est de présenter une définition de l'Entreprise Orientée Services. En plus,
afin de mieux cerner son apport et ses avantages, nous allons effectuer une comparaison entre
l'Entreprise Orientée Services et une entreprise ordinaire.

68
5.2.1 Définition de l'Entreprise Orientée Services

L'Entreprise Orientée Service étend la vision de l'Architecture Orientée Services sur l'ensemble du
Système d'Information de l'entreprise. Lors d'un article précédent, nous l'avons défini dans
(Chaari et al., 2006a) de la manière suivante : l'Entreprise Orientée Services (EOS) est une
architecture d'entreprise qui étend la vision de la SOA sur l'ensemble du Système d'Information de
l'entreprise. Cette nouvelle architecture est basée sur un ensemble de modules indépendants
appelés services caractérisés par plusieurs niveau d'abstraction ; allant des services appartenant
au niveau métier de l'entreprise jusqu'à des services informatiques. Ces services, avec la manière
dont ils sont disposés et conçus, garantissent l'agilité de l'entreprise en assurant un meilleur
alignement du Système d'Information sur les besoins du métier.

L'Entreprise Orientée Services implémente et expose les processus métier de l'entreprise en se

basant sur une vision SOA. Elle favorise, en plus, la relation de l'entreprise avec son
environnement externe en lui offrant l'infrastructure et l'organisation nécessaires, tant au niveau
métier qu'au niveau informatique, pour faciliter sa participation à des projets de collaboration,
notamment à des collaborations à la demande.

Il faut bien noter la double vision qu'on peut apporter à l'Entreprise Orientée Services : une vision
métier et une vision informatique. Du point de vue métier, l'Entreprise Orientée Services permet
d'encapsuler les activités métier de l'entreprise en un ensemble de services appelés services
métier. Ces derniers peuvent être composés sous forme de services agrégats (ou composite) de
fortes granularités que nous avons appelés les services virtuels. Ces derniers sont des services
complexes dont l'exécution implique plusieurs services métiers. L'entreprise peut participer à des
scénarios de collaboration via la publication de ses services virtuels. Sur le plan informatique,
l'Entreprise Orientée Services se base sur l'orientation service pour structurer le système
informatique de l'entreprise. Cette structuration donne lieu à un ensemble de services
informatiques qui supportent l'exécution des services appartenant à la couche métier.

5.2.2 Positionnement de l'EOS par rapport à l'entreprise traditionnelle

Afin de mieux présenter le concept de l'Entreprise Orientée Services, nous allons essayer, dans ce
qui suit, de la situer par rapport à une entreprise traditionnelle (ordinaire). Nous avons structuré
ce positionnement selon quatre dimensions : métier, organisationnel, Système d'Information et
finalement la coopération interentreprises.

D'un point de vue métier, l'Entreprise Orientée Services présente un ensemble de services métier.
Ces derniers sont les responsables de la production des biens et des services de l'entreprise. Ils
sont définis de manière à s'aligner avec les objectifs métiers et la stratégie de l'entreprise. En
outre, les processus métier de l'entreprise sont perçus comme étant une orchestration d'un
ensemble de services autonomes, indépendants et réutilisables. Ainsi, les processus métier sont
plus flexibles et les demandes de changement peuvent être servies directement. Du côté de
l'entreprise traditionnelle, les processus métiers sont un ensemble d'activités qui sont plus au
moins statiques et les demandes de changements s'y répercutent difficilement.

69
D'un point de vue organisationnel, l'Entreprise Orientée Services favorise la structure horizontale
de l'entreprise. Ceci, est la conséquence directe de la manière avec laquelle l'Entreprise Orientée
Services est construite. En effet, l'EOS concrétise l'approche processus qui permet une
structuration horizontale de l'entreprise par le développement de services métier qui vont assurer
cette transversalité. En revanche, les entreprises traditionnelles sont modélisées en termes de
leurs fonctionnalités métier (finance, production, …) et les principaux flux qui circulent entre eux
(flux matériel et flux document/information). Cette structure hiérarchique, qui est principalement
de type vertical, a entraîné l'apparition des silos d'informations qui existent jusqu'à aujourd'hui et
dans lesquels les fonctionnalités et les données sont verrouillées.

Sur le plan Système d'Information (SI), l'Entreprise Orientée Services est construite à partir de
composants malléables (les services avec leurs différents types). Ces derniers peuvent être
assemblés et réassemblés d'une manière dynamique pour supporter les demandes de
changements dans l'entreprise. Par conséquent, l'EOS favorise le rôle Système d'Information dans
le support des besoins des métiers. Du côté de l'entreprise traditionnelle, le SI est perçu comme
résistant aux changements. Toute modification est servie difficilement entraînant une perte de
temps importante et un coût élevé.

Du point de vue collaboration interentreprises, les entreprises traditionnelles collaboraient

généralement d'une manière planifiée pour des longues durées. Les pratiques de collaboration se
résument par la création de passerelles entre les différents Système d'Information des
entreprises. En revanche, la collaboration selon la vision de l'Entreprise Orientée Services est une
coopération dynamique et à la demande. Elle se manifeste par la publication des services
d'entreprises qui seront composés avec d'autres services publiés par d'autres entreprises afin de
créer un processus interentreprises porteur de valeur ajoutée.

5.3 Présentation des concepts de l'Entreprise Orientée Services

L'Entreprise Orientée Services va apporter une nouvelle structuration du Système d'Information

de l'entreprise selon une perspective SOA. Notre principale contribution consiste en un travail de
réingénierie orienté services de l'entreprise. Dans cette direction, la modélisation d'entreprise,
étudiée dans le chapitre 3 s'avère un acquis incontournable oiur atteindre notre but. En effet, elle
nous a permis d'avoir une vision globale de l'entreprise et des différents concepts qui la
constituent.

Un nouveau concept va apparaître dans l'entreprise qui est le concept de service. Ce dernier doit
être placé par rapport aux concepts qui existaient déjà.

Pour cette raison, nous avons fait recours à la méta‐modélisation afin de mettre en évidence le
concept de service. Nous allons proposer un ensemble de méta‐modèles qui présente les
différents nouveaux concepts introduits par l'Entreprise Orientée Services.

Nous allons commencer par exposer l'architecture en niveaux de l'Entreprise Orientée Services
suivi de son méta‐modèle global. Nous allons faire un survol rapide des différents concepts
évoqués pour entamer, par la suite, une description plus détaillée.

70
5.3.1 Architecture de l'Entreprise Orientée Services

Selon l'EOS, l'entreprise devient une conglomération de services avec différents types
d'abstraction. En effet, l'Entreprise Orientée Services se base sur la définition de services sur deux
niveaux différents : le niveau métier et le niveau informatique (représentant les différentes
fonctionnalités qui sont offertes par la partie informatisée du Système d'Information de
l'entreprise). Ces deux niveaux permettent de différencier les services du niveau métier (services
plus abstraits) et les services informatiques (services plus concrets).

Cette double vision pour l'entreprise favorise la séparation des préoccupations d'ordre métier des
préoccupations d'ordre informatique, assurant par conséquent un meilleur alignement du
Système d'Information sur les besoins du métier. Cette orientation donne naissance à un double
aspect pour notre Entreprise Orientée Services : un aspect métier (architecture de services
métier) et un aspect purement technique (architecture de services informatiques).

En plus, l'Entreprise Orientée Services favorise la coopération interentreprises. En effet, le fait

d'avoir un Système d'Information organisé en services, permet de réduire les fonds nécessaires
pour commencer un projet de coopération. Les services sont déjà prêts pour être composés et
orchestrés dans de nouveaux processus. En outre, puisque les services possèdent une description
standard et interprétable automatiquement, leurs découvertes peuvent se faire de manière
automatique et dynamique permettant ainsi une coopération interentreprises à la demande. De
ce point de vue, l'Entreprise Orientée Services est organisée en un niveau intraentreprise et un
niveau interentreprises (Chaari et al., 2006b).

Vu ces caractéristiques, l'architecture en niveaux de l'Entreprise Orientée Services met en exergue

à la fois les différents types de services ainsi que la double préoccupation intra et interentreprises.
L'architecture en niveaux de l'EOS comporte (Figure 5.1) :

Le niveau intraentreprise qui est composé de quatre sous niveaux :

ƒ Le niveau des composants métier : il regroupe un ensemble de composants métier. Un

composant métier encapsule plusieurs activités métier et objets métier de l'entreprise. Il
expose son comportement sous la forme d'un ensemble de services métier.

ƒ Le niveau des services métier : regroupe les services métier qui sont exposés par les
composants métier.

ƒ Le niveau service informatique : il résulte de la construction d'une SOA technique au sein

de l'entreprise. Il s'agit de l'ensemble des services informatiques de l'entreprise qui
supportent le niveau métier.

ƒ Le niveau processus métier : les processus métier de l'entreprise seront construits suite à
une orchestration des différents services métier.

Le niveau interentreprises de l'EOS prend en considération l'aspect coopération interentreprises.

Il comporte deux sous‐niveaux à savoir :

71
 ƒ Les services virtuels : ce sont les services qui seront exposés par l'Entreprise Orientée
Services pour participer à des processus coopératifs. Un service virtuel est une
composition de plusieurs services métier.

ƒ Le niveau processus coopératifs : c'est le processus coopératif qui regroupe l'ensemble

des entreprises partenaires. Il est formé suite à la composition des services virtuels
sélectionnés d'une manière dynamique en fonction des besoins de la coopération.

Les différents éléments qui sont évoqués dans ces différents niveaux vont être expliqués et
présentés en détail dans le reste de ce chapitre.

Figure 5.1 : Architecture générale de l'Entreprise Orientée Services

5.3.2 Le méta‐modèle de l'Entreprise Orientée Services

Après avoir présenté l'architecture en niveaux de l'Entreprise Orientée Services qui a fourni une
première idée sur les différents concepts qui la constituent, nous allons, maintenant, les prendre
en détail et mettre en évidence les relations qui existent entre eux.

Cette section est dédiée à la représentation du méta‐modèle global de l'Entreprise Orientée

Services. Dans un premier temps, nous allons présenter un survol des différents concepts
introduits pour s'intéresser de près, par la suite, aux différents types de services qui coexistent
dans l'EOS.

5.3.2.1 Survol du méta‐modèle de l'EOS

La Figure 5.2 expose le méta‐modèle de l'EOS en utilisant le diagramme de classes UML.

72
Figure 5.2 : Méta‐modèle de l'Entreprise Orientée Services

73
Cette figure met en exergue les principaux concepts de l'Entreprise Orientée Services. L'élément
central de ce méta‐modèle est le service d'entreprise. Ce concept assez générique, sur lequel se
base tout le principe de l'EOS, est raffiné en deux concepts fils qui sont les services niveaux métier
et les services niveaux informatiques. Ce raffinement du concept de service d'entreprise en niveau
métier et niveau informatique est fondamental. Il permet de décomposer l'Entreprise Orientée
Services en deux niveaux complémentaires, mais qui sont faiblement couplés : le niveau métier et
le niveau informatique. Le but de cette dichotomie est de répondre en premier lieu au souci de
l'alignement de SI sur les besoins du métier de l'entreprise et permettre par conséquent
d'atteindre un certain niveau d'agilité.

Le concept clé du niveau métier de l'Entreprise Orientée Services est le service métier. Un service
métier est une brique réutilisable à un niveau métier. Il est issu de l'analyse et la modélisation des
processus métier de l'entreprise. Le service métier correspond à un périmètre fonctionnel que
l'entreprise désire exposer à des consommateurs de manière indépendante de son architecture
informatique.

Nous considérons le service métier comme étant un service atomique de point de vue métier. Il
peut être qualifié aussi de service exécutable ou "opérationnalisable" puisque la manière de le
rendre opérationnel est à la fois directe et simple. Cette particularité du service métier est
assurée par le fait que nous pouvons facilement définir l'ensemble des actions qui peuvent
supporter son exécution. Par exemple le service métier "effectuer le paiement d'une réservation
par une carte bancaire" est un service exécutable dans la mesure où les actions qui constituent le
processus de payement sont faciles à identifier.

Le deuxième type de service du niveau métier de l'entreprise est le service virtuel. Un service
virtuel est un service de très haut niveau d'abstraction. Il correspond à une composition de
plusieurs services du niveau métier (services métier ou autres services virtuels). Il permet
d'organiser les services métier de l'entreprise en des services de très forte granularité. A l'inverse
des services métier directement opérationnalisable, l'opérationnalisation du service virtuel
demande l'exécution de différents services qui le constituent. Dans le cadre d'une coopération
interentreprises, les services virtuels vont participer dans le processus de coopération. Dans cette
direction, Un service Virtuel est publié par l'entreprise dans des registres publics de services afin
d'être utilisé par les entreprises partenaires. Il existe deux types de services virtuels : les services
virtuels composites et les services virtuels à variation.

La description d'un service du niveau métier est assurée par trois concepts : (i) les pré‐conditions,
(ii) les post‐conditions et (iii) le contrat de service. Les pré‐conditions permettent d'énoncer les
règles à respecter pour le déclenchement des fonctionnalités ou des opérations des services
métier. Pour chaque pré‐condition on précise également la post‐condition qui définit les
conditions d'émission du résultat de l'opération. La somme des pré‐conditions constitue un
ensemble exhaustif des cas de déclenchement de l'opération. Une post‐condition est associée à
une ou plusieurs pré‐conditions. Elle décrit les propriétés que le résultat envoyé doit satisfaire (ex
: une liste de valeurs possibles) et la liste des exceptions susceptibles d'être levées. Les exceptions
correspondent à l'émission d'un résultat en erreur.

74
La deuxième partie du méta‐modèle de l'Entreprise Orientée Services concerne le niveau
informatique de l'EOS. Un service informatique représente un service exposé par la partie
informatisée du Système d'Information de l'entreprise. Les services informatiques seront
orchestrés par les services métiers afin d'assurer leurs exécutions et par suite l'exécution des
processus métiers et des services virtuels. Nous définissons deux types de services informatiques
qui sont les services techniques et les services applicatifs:

ƒ Services techniques : les services techniques de l'entreprise représentent les services

d'infrastructure qui assurent la gestion de l'infrastructure du Système d'Information de
l'entreprise comme par exemple les services d'authentification, de mesure, de réseau,
etc.

ƒ Services applicatifs : il s'agit des services du niveau applicatif de l'entreprise. Les services
applicatifs encapsulent les applications de l'entreprise sous forme de services. Les services
applicatifs correspondent à des services exposés par les objets métier de l'entreprise. Un
objet métier est considéré comme une représentation de la nature et du comportement
de tout objet ou de tout concept de manière à ce qu'il possède une description
significative d'un point de vue métier. Les objets métiers se trouvent au carrefour de la
préoccupation métier et l'architecture logicielle ou applicative de l'entreprise. Ils sont vus
par les gens métier ainsi que par les gens techniques. D'un point de vue informatique, un
objet métier correspond à un regroupement de classe.

5.3.3 Typologie des services dans l'Entreprise Orientée Services

L'Entreprise Orientée Services est une conglomération de services de différents types. Nous avons
classé ces services selon trois critères :

1. la nature des services,

2. le degré de granularité des services et

3. la visibilité des services.

5.3.3.1 Classification suivant la nature de service

Deux grands types de services existent. Les services du niveau métier et les services
informatiques. La Figure 5.3 résume les différents services de l'Entreprise Orientée Services et les
relations qui existent entre eux.

75
 Figure 5.3 : Typologie des services

5.3.3.2 Classification des services suivant le degré de visibilité

Les services au sein de l'EOS présentent deux niveaux de visibilités :

ƒ Une visibilité privée indiquant que le service est visible uniquement au sein de
l'entreprise, c'est‐à‐dire qu'il ne peut être invoqué qu'à l'intérieur de l'entreprise. Les
services privés dans le cas de l'EOS sont : les services informatiques et les services métier.

ƒ Une visibilité publique indiquant que le service est visible depuis l'extérieur de
l'entreprise, c'est‐à‐dire qu'il peut être invoqué par une entité externe à l'entreprise. Les
services publics dans le cas de l'Entreprise Orientée Services sont les services virtuels. En
effet, les services virtuels sont les services qui seront publiés par l'entreprise pour
participer à des scénarios de coopération.

On peut classer aussi les services de l'EOS selon un deuxième critère de visibilité qui découle
directement de la nature des services : (i) la visibilité métier et (ii) la visibilité informatique ou
technique:

ƒ Visibilité métier : un service est dit de visibilité métier s'il est visible par les gens métiers
ou les gens de la maîtrise d'ouvrage. Ce sont les services du niveau métier de l'entreprise
qui sont concernés par ce genre de visibilité.

ƒ Visibilité informatique ou technique : un service est dit de visibilité informatique ou

technique dans le cas où il est visible par les gens techniques ou les maîtrises d'œuvre. Ce
type de visibilité correspond aux services informatiques de l'entreprise.

76
5.3.3.3 Classification suivant le niveau de granularité des services

Les services dans l'Entreprise Orientée Services possèdent plusieurs niveaux de granularités. Ils
existent des services de fines granularités, de moyennes et de fortes granularités. La granularité
de service dépend en réalité du niveau d'abstraction auquel appartient le service. Plus le service
est abstrait, plus sa granularité est forte (Figure 5.4).

Figure 5.4 : Classification des services de l'EOS selon le niveau de granularité

5.3.3.4 Synthèse de la typologie des services de L'Entreprise Orientée Services

Le Tableau 5.1 représente un récapitulatif des différents services qui existent au sein de
l'Entreprise Orientée Services ainsi que leurs spécificités. La granularité des services est exprimée
sur une échelle de 4. Selon cette échelle le service virtuel est un service de forte granularité (4/4
sur l'échelle de granularité). En revanche, les services d'infrastructure sont des services de très
fines granularités (1/4 sur l'échelle de granularité).

77
 Nature de service Description et Spécificités Visibilité Granularité

Services du niveau métier

Service virtuel ƒ Service très abstrait Interne et 4/4
ƒ Favorise la coopération externe
interentreprises
ƒ Participe dans les processus de
coopération interentreprises
ƒ Encapsule un ou plusieurs
services métier
Service métier ƒ Service abstrait Interne et 3/4
ƒ Orchestre plusieurs services externe
informatiques
ƒ Participe dans les processus
d'entreprise
Services du niveau informatique
Service applicatif ƒ Service concret Interne 2/4
ƒ Service exposé par un objet
métier
ƒ Encapsule les applications de
l'entreprise
Service technique ƒ Service concret Interne 1/4
ƒ Service d'infrastructure du
système informatique de
l'entreprise

Tableau 5.1 : récapitulatif des différents services de l'EOS et leurs caractéristiques

5.4 Présentation détaillée des concepts du niveau métier de l'EOS

Dans cette section, nous allons détailler les différents concepts présentés dans le méta‐modèle de
l'Entreprise Orientée Services.

5.4.1 Les composants métier

5.4.1.1 Définition du composant métier

Les composants métier sont des éléments de base dans l'Entreprise Orientée Services (Chaari et
al., 2007b). Ils jouent un rôle fondamental lors de la mise en place d'une SOA métier au sein de
l'entreprise. Nous avons utilisé le concept de composant métier conjointement avec la notion de
service vu que la notion de service est une partie prenante du paradigme composant. Un
composant expose un service à son environnement. Le service, a son tour, représente la vue du
consommateur de service vis‐à‐vis des capacités offertes par le composant.

Le composant métier dans l'Entreprise Orientée Services n'a pas de connotation informatique
dans le sens où les composants identifiés ne seront pas par la suite implémentés. C'est une sorte
de modularisation que nous avons mis en place afin de faciliter le processus d'identification de
services. Cependant, dans le processus d'identification des composants métier, les principes qui
les caractérisent les composant d'une manière générale, doivent être pris en considération.

78
Dans le cadre de nos travaux, nous considérons le composant métier comme une partie ou bloc
de l'entreprise qui possède les capacités et le potentiel pour délivrer une valeur ajoutée à son
environnempent d'une manière autonome. Les composants métier sont perçus comme des blocs
spécialisés d'activités. En effet, chaque composant métier sert à réaliser un objectif particulier au
sein de l'entreprise et collabore avec les autres composants métier. Un composant métier est
contrôlé par une unité organisationnelle de l'entreprise et exerce un rôle et un métier bien défini.

Du point de vue service, les composants métier sont considérés comme des centres de services.
Ils doivent implanter les processus de l'entreprise à travers l'orchestration des différents services
métier qu'ils exposent.

Un composant métier encapsule un ensemble d'activités métier fortement couplées et les objets
métier manipulés par ces activités. Le couplage fort entre les activités signifie que ces dernières
échangent fréquemment des objets entre elles et que l'une est indispensable pour la réalisation
de l'autre.

La délimitation du périmètre du composant métier en termes d'activités et d'objet métier résulte

de l'étude des processus métier de l'entreprise et des objets métier qui sont invoqués où utilisés
par les activités constituants ces processus. La manière avec laquelle les composants métier
seront identifiés est explicitée dans le chapitre suivant.

L'identification des services métier sera plus facile puisque nous avons délimité, via les
composants métier, les périmètres d'identification des services. De cette manière notre plan
d'action sera composant métier par composant métier. Chaque composant métier expose un
ensemble de services métier qui possèdent un sens et une valeur mesurable dans un domaine
métier particulier. Les activités et les objets métiers encapsulés dans les composants métiers sont
des éléments essentiels pour la définition des services métiers.

La Figure 5.5 résume le concept de composant métier comme il est perçu dans notre travail.

Figure 5.5 : Le composant métier comme il est perçu dans notre travail

5.4.1.2 Méta‐modèle du composant métier

Les différents concepts que nous avons évoqués dans la définition du composant métier sont mis
en valeur dans le méta‐modèle représenté par la Figure 5.6. Un composant métier appartient à
une unité organisationnelle de l'entreprise, il encapsule un ensemble d'activités qui opèrent sur

79
un ensemble d'objets métier. Le composant métier possède un ou plusieurs comportements qui
sont exposés via un ou plusieurs services métier.

Figure 5.6 : Méta‐modèle du composant métier

5.4.2 Les objets métiers

Les objets métier ont été utilisés pour représenter des grands blocs d'information du Système
d'Information de l'entreprise. L'idée derrière l'introduction d'un tel concept dans notre
architecture et double. En premier lieu, éliminer grâce à la notion d'objet les redondances qui
puissent exister en faisant le découpage fonctionnel. En second lieu, les objets métier seront un
premier pas vers le développement des services. En effet, ces objets métier du SI vont offrir les
interfaces nécessaires (représentées par les services applicatifs) pour assurer un décloisonnement
entre les silos du SI et assurer, par conséquent la transversalité dans l'entreprise.

5.4.2.1 Définition et présentation de l'objet métier

L'Object Management Group (OMG) présente un objet métier comme suit :

"A business object captures information about a real world (business) concept, operations on that
concept, constraints on those operations, and relationships between that concept and other
business concepts. The business concept can then be transformed into a software design and
implementation. And a business application can be specified in terms of interactions among a
configuration of implemented business objects." (OMG, 1997).

80
Ainsi, l'OMG considère un objet métier comme d'une part, une représentation d'un concept du
monde réel qui ne possède pas une connotation informatique et d'autre part, comme une
abstraction informatique de ce concept.

Dans le cadre de nos travaux, nous considérons un objet métier comme une représentation de la
nature et du comportement de tout objet ou de tout concept de manière à ce qu'il possède une
description significative d'un point de vue métier. Les objets métiers englobent les entités, les
ressources et les acteurs qui peuvent exister au sein d'une entreprise et qui concourent à la
satisfaction des besoins métier. Ils sont manipulés par les activités constituant les processus de
l'entreprise. Nous allons les utiliser, par la suite, pour déterminer le degré de couplage qui existe
entre les activités. Comme exemples d'objets métier nous pouvons considérer : l'objet
commande, l'objet client, les individus qui travaillent dans une entreprise ainsi que leurs rôles
(magasinier, agent financier, etc.) et des lieux (entrepôts, magasin, etc.). Comme le montre la
Figure 5.7, un objet métier peut être :

ƒ Une ressource : est une spécialisation d'un objet métier. Elle peut être une ressource
matérielle ou informationnelle.

ƒ Un acteur : une spécialisation d'un objet métier. Il peut être un acteur humain ou un
automate (machine de production) qui permet de réaliser les actions demandées par une
activité.

Figure 5.7: Objet métier

5.4.2.2 Anatomie de l'objet métier

Un objet métier est un super type de tous les objets qui représentent les concepts métier d'une
organisation. Il possède une identité bien définie et encapsule la définition de ses attributs, de

81
son comportement ainsi que de ses relations avec d'autres objets métier. Les attributs d'un objet
métier représentent son état, alors que son comportement caractérise les méthodes (ou les
actions) indispensables pour la réalisation de ses objectifs.

D'un point informatique un objet métier est considéré comme une encapsulation ou un
empaquetage de classe (Figure 5.8). Ces empaquetages représentent les grands objets du
Système d'Information de l'entreprise. Un objet métier est formé généralement d'une classe pivot
représentant son concept clé (classe Commande par exemple) et de plusieurs classes qui lui sont
rattachées afin d'assurer sa description (la classe Item par rapport à la classe Commande). L'objet
métier ne peut pas contenir des classes qui appartiennent à d'autre objet métier, seules les
classes qui décrivent son concept métier peuvent y appartenir. Toutes les classes qui constituent
un objet métier doivent être en relation telle qu'on ne puisse pas trouver une classe isolée.

Figure 5.8 : Anatomie d'objet métier et relation entre objet métier

5.4.3 Service métier de l'Entreprise Orientée Services

Le service métier est le concept clé qui caractérise l'Entreprise Orientée Services. Cette section
présentera ce nouveau concept sous différents points de vue.

5.4.3.1 Présentation et caractéristiques générales d'un service métier

Le service métier correspond à un périmètre métier que l'entreprise veut exposer à des
consommateurs. L'idée du service métier est plus large que le fait de placer une qualification ou
une étiquette "métier" devant un service (technique) comme cela est perçu dans le contexte de
l'Architecture Orientée Services. En effet, il y a plusieurs différences entre un service du point de
vue métier et un service du point de vue technique. Ces différences viennent essentiellement de
la nature elle‐même du service, son but et les personnes qui sont derrière sa création. Afin de
mieux montrer ces différences, prenons par exemple le cas d'un simple service de "vérification de

82
crédit d'un client". Ce dernier, perçu d'un point de vue technique, correspond à une description
syntaxique et sémantique qui sert à son invocation, le format des messages échangés et les
composants logiciels qui sont impliqués dans son implémentation. En revanche, le service
"vérification du crédit d'un client", d'un point de vue métier, décrit les aspects métier et les
aspects opérationnels derrière sa mise en œuvre. La manière avec laquelle ce service est implanté
n'est pas trop importante.

Le concept de service métier possède des attributs qui sont pertinents pour la communication
entre les gens du métier, comme les différents termes et conditions qui sont associés à son
utilisation, les paramètres non fonctionnels notamment la qualité de service (QoS) qui le
décrivent. Une attention particulière est accordée aux paramètres non fonctionnels qui
constituent la base de notre démarche de construction du processus interentreprises. Le chapitre
7 exposera ce type de paramètres en détail et comment ils seront utilisés.

Dans notre travail, les services métier représentent le comportement et les aptitudes du
composant métier auquel il appartient. Un service métier tel qu'il est illustré par le méta‐modèle
de la Figure 5.9 représente un ensemble de fonctionnalités métier (opérations de service) issues
de l'analyse des activités métier de l'entreprise.

En ce qui concerne la granularité, un service métier n'est pas décomposable en d'autres services
métier. En effet, il est important de noter que le service métier est un service qui est considéré
comme un service atomique de point de vue métier. Cette atomicité est la conséquence directe
du fait que le service métier peut être mis en opération via l'exécution de l'ensemble des actions
qui le composent. Malgré cette atomicité au niveau métier, le service métier correspond à une
composition de services informatiques plus au moins complexes. En d'autres termes, la
granularité d'un service métier est faible de point de vue métier, mais elle est plus au moins
grande du point de vue informatique.

Les services métiers sont perçus comme des briques qui vont participer à la construction des
services métier de plus haut niveau que nous avons appelés les services virtuels.

83
 Figure 5.9 : Méta‐modèle du service métier

5.4.3.2 Modélisation du service métier

Les modèles de services qui sont largement publiés dans la littérature concernent principalement
les Web services. Ces derniers sont généralement conçus dans une perspective d'intégration des
applications et d'interopérabilité entre des systèmes hétérogènes. Ces modèles de services ne
sont pas adaptés pour la modélisation des services métier qui sont plus complexes et qui
n'appartiennent pas au même niveau d'abstraction. Nous avons besoin, en réalité, d'un modèle
de services qui met en exergue la vision des gens métier et qui montre bien la valeur ajoutée de
ce nouveau concept par rapport aux modèles de services déjà existants.

Pour cette raison, et pour bien éclaircir notre vision du concept de service métier, nous allons le
présenter selon plusieurs points de vue. Pour atteindre ce but, plusieurs modèles du service
métier seront présentés.

™ Modèle métier

Le modèle métier du service métier correspond à la description des gens métier pour ce service.
Cette description peut inclure, l'identification du service, sa portée, les pré‐conditions, les post‐
conditions, le contrat de service ainsi que les différents termes et conditions qui gouvernent la
consommation de service comme par exemple les politiques métiers et les règles métiers (Figure
5.10).

84
Le contrat de service est composé de plusieurs SLA (Service Level Agreement) qui correspondent
aux paramètres non fonctionnels décrivant le service métier.

Figure 5.10 : Modélisation du service métier: vue métier

™ Modèle opérationnel

Le modèle opérationnel du service métier met en exergue la manière avec laquelle le service
métier peut être opérationnel. Le service métier expose un ensemble de fonctionnalités métier.
Chaque fonctionnalité de service, appelé aussi opération de service par référence au modèle de
Web service, utilise un ensemble de services applicatifs. Les services applicatifs sont des services
de fines granularités par rapport au service métier et sont exposés par les objets métier de
l'entreprise.

La Figure 5.11 présente le modèle opérationnel du service métier.

85
 Figure 5.11 : Modélisation du service métier : vue opérationnelle
™ Modèle de performance métier

La construction de service métier s'inscrit dans un projet de migration ou d'implantation d'une

Architecture Orientée Services dans une entreprise. Ce projet de migration reflète un choix
stratégique que l'entreprise cherche à atteindre et qui comporte un ensemble d'objectifs métiers
bien précis. Dans cette optique, chaque service métier se voit accorder un objectif opérationnel
qui est relié à un objectif métier de l'entreprise. Cette dualité service métier‐objectif opérationnel
est très importante pour le développement des services métier et doit être prise en considération
par les gens métier en charge de spécifier et identifier les services métier de l'entreprise.

La supervision et le management de ces services métier est une étape clé dans l'Entreprise
Orientée Services. Des outils de monitoring orientée métier peuvent être sollicités comme le BAM
(Business Activity Monitoring). Le BAM assure les tâches de suivi des activités des processus
métier. Il est utilisé pour mesurer la performance de l'entreprise et fournir les informations
nécessaires pour que l'entreprise puisse agir dans les bons délais et choisir les bonnes décisions.
Dans ce dessein, le BAM possède la capacité d'offrir une vue quasi‐instantanée des différents
processus et propose des tableaux de bord faits à partir des indicateurs de performance KPI (Key
Performance Indicator). Les KPIs sont utilisés pour mesurer le degré de correspondance entre le
service métier et l'objectif opérationnel qui lui est accordé. Le BAM donne une vue métier à la
mise en œuvre des politiques de qualité de service ou des SLA (Service Level agreement).

Le modèle de performance métier du service métier présenté dans la Figure 5.12 met en évidence
tous les éléments cités ci‐dessus.

86
 Figure 5.12 : Modèle de performance métier

5.4.4 Les services Virtuels

5.4.4.1 Motivation derrière le concept de service virtuel

Le service virtuel est un nouveau concept introduit par l'Entreprise Orientée Services (Chaari et
al., 2007a). Ce sont des services avec un niveau d'abstraction très fort. Les services virtuels
correspondent à des compositions de services métier ou d'autres services virtuels. Ils peuvent
encapsuler jusqu'à des processus métier entiers de l'entreprise. Ils peuvent être publiés dans des
registres publics de services dans le but d'être invoqués dans des scénarios de collaboration
interentreprises. En effet, les services virtuels constituent, désormais, le point de contact de
l'entreprise avec son environnement externe. Par le biais des services virtuels, l'entreprise peut
participer dans des processus collaboratifs en le mettant à la disposition de ses différents
partenaires.

La question qui se pose est : quel est l'apport des services virtuels dans l'entreprise et pourquoi
ajouter un niveau d'abstraction encore plus élevé que celui des services métier et quelle est la
différence entre ces services et les services métier de l'Entreprise Orientée Services ? Ceci nous
amène à parler des motivations multiples qui sont derrières l'introduction d'un tel concept au sein
de l'EOS. La plus importante motivation est en relation directe avec les services métier de
l'entreprise. En effet, comme ces derniers sont de fines granularités, le fait de les publier dans des
registres publics à l'extérieur de l'EOS (sous forme de Web services par exemple) dans le but de
participer à des processus de collaboration, peut engendrer plusieurs problèmes. Ces problèmes
sont les suivants :

87
 ƒ l'entreprise sera obligée de publier des services relativement de fine granularité qui sont
dépourvus de signification vis‐à‐vis du monde externe. Dans ce sens, les services métier
sont de fines granularités et spécifiques à l'utilisation en interne de l'entreprise,
ƒ la tâche des consommateurs de services sera plus difficile puisqu'ils seront amenés à
composer plusieurs services pour atteindre leurs buts finaux,
ƒ le consommateur peut composer des services qui ne possèdent aucune signification et
qui n'ont aucune structure valide par rapport aux fournisseurs de services. En effet, le
service composite résultant de la composition du consommateur peut être dépourvue de
sens.

En plus, le service virtuel dépasse la caractéristique "boite noire" qui caractérise le concept de
service d'une manière générale. Ce dernier qui est seulement décrit par les messages qu'il
échange, ne possède aucune structure interne qui est visible à son environnement. Cependant,
dans le cas d'une collaboration interentreprises, les consommateurs de services exigent la
possibilité de "voir", en quelque sorte, l'intérieur du service. Dans ce sens, les services virtuels,
puisqu'ils peuvent participer à des processus de coopération interentreprises, doivent se doter de
mécanismes particuliers pour s'aligner avec cette contrainte. La vision "boite noire" du service
doit être améliorée vu que les entreprises partenaires veulent avoir la possibilité de contrôler
l'avancement de leurs processus externalisés et avoir les moyens d'exercer des activités de
monitoring ou demander des rapports sur l'avancement des travaux faits par le service virtuel.

5.4.4.2 Présentation du service virtuel

L'objectif du service virtuel ne consiste pas à définir de nouvelles APIs (Application Programming
Interfaces) ou un nouveaux standard, mais plutôt de construire à partir des services métier déjà
existants, une nouvelle structure de haut niveau qui cache les complexités de sélection et de
composition aux utilisateurs de services, simplifie la publication des services par les fournisseurs
de services et offre des capacités d'auto gestion.

Le service virtuel est un service du niveau métier de l'entreprise. Il est défini par les gens du
métier de l'entreprise. A l'instar du service métier atomique, le service virtuel possède une
spécification métier qui se préoccupe de sa description du point de vue métier et d'un modèle
opérationnel relatif à son opérationnalisation (Figure 5.13).

Le service virtuel est une composition de plusieurs services métier ou d'autres services virtuels.
Selon la nature de la composition qui peut se faire, on peut distinguer deux types de service
virtuel : (i) les services virtuels composites et (ii) les services virtuels à variation.

88
 Figure 5.13 : Service virtuel: Vue opérationnelle
Les services virtuels composites

Les services virtuels composites peuvent être de trois types différents. Cette typologie dépend de
la nature de composition elle‐même :

ƒ Composition séquentielle : c'est le cas le plus simple de la composition dans lequel les
services composants sont acheminés de manière séquentielle. La notion d'ordre est très
importante dans ce cas.
ƒ Composition parallèle : elle correspond à une exécution parallèle des services métier qui
forment le service virtuel. A l'encontre de la composition séquentielle, l'ordre d'exécution
des services n'est pas important.
ƒ Composition itérative : elle correspond à l'exécution itérative d'un service ou un ensemble
de services dans une composition de services jusqu'à la satisfaction d'une condition
particulière. L'opérateur d'itération peut être appliqué aux deux autres types de
composition à savoir séquentielle et parallèle.

89
 ™ Les services virtuels à variation

Les services virtuels à variation introduisent un concept très important qui est le concept du
"point de variation". Ce dernier est intégré dans le service virtuel pour ajouter une dimension de
flexibilité aux services de l'entreprise qui seront exposés aux partenaires externes. C'est un moyen
pour augmenter l'agilitéde l'entreprise et lui permettre de s'adapter à diverses situations.

Le service virtuel est considéré comme un service à variation dès qu'il propose plusieurs
alternatives de composition des services métier. Chaque alternative constitue un point de
variation qui n'est autre qu'une manière pour atteindre l'objectif métier du service virtuel.

Le service virtuel propose deux types de variations : (i) à choix alternatif et (ii) à choix de schéma.
Le premier type de variation correspond à une variation de type "OU exclusif" (XOR) entre
services métier et le deuxième correspond à une variation au niveau du schéma de composition
de services :

ƒ Service virtuel à choix alternatif : le service virtuel exprime un choix alternatif entre les
différents services métier qu'il orchestre. Chaque service métier propose une manière
pour répondre à l'objectif métier du service virtuel. Ainsi, le service virtuel regroupe
plusieurs services métier qui peuvent être mutuellement exclusifs et c'est au moment de
l'exécution qu'un seul service sera choisi parmi l'ensemble d'alternatives proposées.
ƒ Service virtuel à choix de schéma : la variation de schéma introduit une variation qui porte
sur des enchaînements alternatifs d'un ensemble de services métier. Ainsi, chaque service
virtuel peut avoir un ensemble de schémas de compositions alternatifs et exclusifs. Au
moment de l'exécution, le service virtuel sélectionnera le schéma d'orchestration le plus
adéquat qui correspond au mieux à son contexte d'utilisation.

5.4.4.3 Anatomie du service virtuel : un service multi‐facettes

Le service virtuel possède une anatomie particulière qui le caractérise et qui le différencie en
même temps du concept de service ordinaire. En effet, le service virtuel dépasse le principe du
"boite noire" introduit par le concept de service et qui se caractérise par une abstraction totale de
son intérieur.

Ce principe n'est pas en adéquation avec le but du service virtuel qui est conçu principalement
pour être utilisé dans des scénarios de collaboration interentreprises. En effet, le service virtuel
doit aller au‐delà de la caractéristique de la "boite noire" puisqu'en cas de collaboration
interentreprises, les consommateurs de services demandent à avoir des informations sur la
structure interne du processus de l'entreprise encapsulé par le service virtuel. En même temps, il
cherche à avoir une possibilité de contrôler leurs processus externalisés en cas de besoin et
effectuer un monitoring sur leurs exécutions.

Par exemple, dans le cas d'un service de livraison ou de production, le consommateur de service
veut avoir la possibilité de connaître l'évolution de ce processus et avoir une idée sur le lieu ou
l'état actuel du produit qu'il a commandé. L'utilisateur peut aussi changer des informations
personnelles comme par exemple le lieu de livraison.

90
Pour répondre à ces spécificités, nous avons conçu le service virtuel de manière à présenter
plusieurs facettes pour assurer ce genre d'interaction avec les consommateurs de service. Dans
cette direction, on trouve la facette 'SPEC' (Spécification) qui permet à l'utilisateur d'avoir une
vision globale sur le processus encapsulé par le service virtuel, En plus, on trouve aussi la facette
'CTRL' (Contrôle) qui est utilisée pour contrôler l'exécution du processus interne. Grâce à cette
facette, un consommateur peut contrôler l'exécution d'un service virtuel qui exécute un
processus à son profit. Les commandes envoyées via la facette de contrôle se basent sur des
informations obtenues par la facette de monitoring 'MON'.

Concernant la fonction de contrôle effectuée par la facette 'CTRL' du service virtuel, elle peut être
faite sur deux niveaux différents : (i) niveau service virtuel (niveau processus encapsulé) ou (ii)
niveau des services métier (orchestrés par le service virtuel). Dans le premier niveau de contrôle,
le consommateur de service peut influencer l'exécution du service virtuel en totalité via des
commandes de niveau processus comme par exemple "pause processus", "annuler processus" et
"continuer processus". Dans le deuxième niveau de contrôle, le consommateur de service peut
agir sur un service métier appartenant au service virtuel via l'envoi de commande de type par
exemple "arrêter exécution service" ou "reprendre exécution service".

Par ailleurs, le développement de fonctionnalités de monitoring pour le service virtuel implique la

connexion de la chaine de service, encapsulée par le service virtuel, à une chaine de Service Level
Agreement (SLA). Cependant, les Frameworks des Service Level Agreement qui existent
actuellement se contentent uniquement de traiter une vue technique très élémentaire et ne
permettent pas d'accorder un traitement complet à une chaîne de services comme c'est le cas du
service virtuel. Pour atteindre cet objectif, nous avons mené le service virtuel d'une facette pour
le Service Level Management 'SLM'. Cette facette est utilisée pour contrôler l'exécution de la
chaine globale de services via l'orchestration d'un ensemble d'agents mobiles. Une telle gestion
de bout en bout du niveau de service est une tâche assez complexe qui doit être adaptée
dynamiquement à la chaîne de services. Ce travail à été traité en détail par un travail de thèse
réalisé dans notre équipe de recherche (Ali, 2008).

La Figure 5.14 expose l'anatomie du service virtuel et met en évidence les différentes facettes que
nous avons conçues. Nous avons aussi introduit une partie de l'architecture de gestion des SLA.

91
 Figure 5.14 : Anatomie du service virtuel : un service multi‐facettes

La Figure 5.15 résume l'architecture de gestion des SLA associés avec le service virtuel.

Figure 5.15 : Architecture liée à la facette de monitoring du service virtuel (Chaari et al., 2007a), page 526

92
5.5 Présentation détaillée des concepts du niveau informatique de l'EOS

5.5.1 Relation entre les deux niveaux du méta‐modèle de l'EOS

Les services du niveau métier de l'Entreprise Orientée Services sont identifiés à partir de l'analyse
et de l'étude du niveau métier de l'entreprise. Cette identification est réalisée après une
décomposition des différents processus de l'entreprise afin d'aboutir à un ensemble de services
métier. Ces derniers seront composés sous forme de services virtuels d'une granularité
importante pour répondre à des finalités de collaboration interentreprises. En effet, ces services
seront publiés dans les registres publics et seront accessibles par des utilisateurs externes.

Les services du niveau métier sont opérationnalisables à partir des services du niveau
informatique de l'Entreprise Orientée Services. Ce niveau introduit la notion de service
informatique qui représente une entité opérationnelle se manifestant selon deux façons
différentes : (i) des services applicatifs et (ii) des services d'infrastructures. Ces deux types de
services sont derrière l'exécution ou la mise en opération des services du niveau supérieur c'est‐à‐
dire le niveau métier.

De ce fait, on peut dire que la relation entre les deux sous méta‐modèles de l'Entreprise Orientée
Services est une relation à double sens. D'un côté, les services du niveau métier sont
opérationnalisables via l'orchestration d'un ensemble de services informatiques. De l'autre côté,
les services informatiques offrent les traitements nécessaires pour que les services du niveau
métier puissent atteindre les objectifs pour lesquels ils ont été conçus.

Cette relation à double sens met en exergue une relation causale entre les deux niveaux de
service en plus d'un couplage faible. Ce type de relation favorise l'alignement entre le monde de
l'informatique et le monde des métiers concrétisant ainsi une propriété largement recherchée par
les entreprises.

5.5.2 Les services Informatiques

Le méta‐modèle du service informatique est illustré dans la Figure 5.16. Un service informatique
est un service de fine granularité, généralement manipulable par des programmeurs (les maîtrises
d'œuvre). Les services informatiques servent à implémenter les différents services métier. Pour
identifier les services informatiques, le patrimoine applicatif de l'entreprise doit être étudié pour
identifier les portions d'applications qui sont éligibles au rang de services.

Les services informatiques peuvent correspondre à des simples fonctionnalités logicielles (les
services applicatifs) ou encore à des fonctionnalités relatives à la gestion de l'infrastructure du
système Informatique (les services d'infrastructure).

Dans la suite de cette section, nous allons nous focaliser sur chacun de ces types de services en
mettant en exergue l'ensemble des concepts qu'ils manipulent. Quant à la démarche de leur
identification elle sera expliquée dans le prochain chapitre de cette thèse.

93
 Figure 5.16 : Méta‐modèle de l'EOS partie informatique

5.5.2.1 Les services applicatifs

Les services applicatifs sont les services qui assurent l'opérationnalisation des services métier de
l'entreprise. En effet, ils sont orchestrés par les services métier et permettent à ces derniers
d'atteindre leurs buts.

Les services applicatifs possèdent un ensemble de caractéristiques qui leur sont propres :

• Ils respectent le principe du couplage faible avec les autres services. Un service applicatif
ne peut pas appeler directement d'autres services, mais il délègue cette action à une
fonction d'orchestration (assuré par un service métier),

• Ils sont des services de fines granularités et de sémantique métier assez faible,

• Ils permettent d'implémenter les services métier issus de l'analyse des processus métier
de l'entreprise.

Les services applicatifs sont les services exposés par les objets métier. Ainsi, ils s'attardent sur les
traitements autour des préoccupations les plus stables du Système d'Information de l'entreprise à
savoir : les objets métier. Les services applicatifs encapsulent l'objet métier et exposent par la
suite les traitements que ce dernier offre. Désormais, l'accès aux fonctionnalités de l'objet métier

94
passe à travers un service applicatif qu'il expose. La Figure 5.17 montre que l'appel direct des
fonctions de l'objet métier est interdit.

Figure 5.17: Principe d'encapsulation de l'objet métier par des services applicatifs

5.5.2.2 Les services d'infrastructure

L'exécution des services informatiques passe obligatoirement par l'utilisation d'un ensemble de
briques basiques généralement techniques, accessibles, de façon transversale, à l'ensemble des
services applicatifs. Ce sont les services d'infrastructure. Dans ce qui suit on présente de façon
non exhaustive, quelques‐uns des services d'infrastructure (classification tirée de (Unilog, 2005)):

ƒ Services d'accès aux données (des référentiels, notamment),

ƒ Services de sécurité : authentification, cryptage, journalisation, gestion des incidents.
ƒ Services de stockage, de sauvegarde, d'archivage,
ƒ Services d'intégration, de réplication et de consolidation de données,
ƒ Services de transport et de routage,
ƒ Services de transformation,
ƒ Services d'émulation,
ƒ Services de système d'exploitation,
ƒ Services d'exploitation technique,
ƒ Services de remontée d'indicateurs de performance et de pilotage fonctionnel.

5.6 Conclusion

Plusieurs entreprises essaient de migrer vers une Architecture Orientée Services vu les avantages
majeurs que peut apporter une telle architecture. Cependant, une telle adoption est à la fois
risquée et non maîtrisée car l'expertise actuelle sur la SOA est limitée au système informatique de

95
l'entreprise. L'extension d'une telle approche, à l'échelle d'une entreprise, est un vrai challenge à
cause du manque de standards et d'expertises. Ce chapitre contribue dans cette direction par la
présentation d'une Architecture Orientée Services à l'échelle du Système d'Information de
l'entreprise que nous avons appelée l'Entreprise Orientée Services (EOS).

Tout au long de ce chapitre nous avons développé le concept de l'Entreprise Orientée Services. Le
principe de base de l'Entreprise Orientée Services se manifeste par une dichotomie ou une double
vision Métier / informatique. Dans cette direction, l'EOS est la 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. Cette dualité garanti l'alignement du Système d'Information sur les
besoins métier et permette ainsi à l'entreprise de gagner en agilité.

Nous avons tout d'abord commencé par dresser une vue générale de ce nouveau concept (EOS)
en présentant son architecture en couches et son méta‐modèle général. Nous avons détaillé par
la suite tous les éléments constituants l'Entreprise Orientée Services en présentant leurs
définitions et leurs méta‐modèles. Une attention particulière à été accordée au concept du
service métier et du service virtuel considérés comme des éléments pivots. Le concept d'objet
métier utilisé dans notre modèle de l'EOS est une pièce maîtresse aussi vu qu'il nous a permis de
faire des liens entre le niveau métier et le niveau informatique de l'entreprise tout en assurant un
couplage faible entre les deux niveaux. Les objets métier nous ont permis de faire le
décloisonnement entre les silos du Système d'Information de l'entreprise grâce aux services qu'ils
exposent.

Après avoir présenté dans ce chapitre les éléments introduits par l'Entreprise Orientée Services, le
chapitre suivant exposera les grands traits d'une démarche pour la réalisation d'une telle
architecture.

96
Chapitre 6

FErOS­ Framework de définition de

l'Entreprise Orientée Services

"Everything should be made as simple as possible, but not simpler".

Albert Einstein

SOMMAIRE

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.4 Conclusion ............................................................................................................................... 116

97
6.1 Introduction

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

98
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.

99
Figure 6.2 : Vue générale de FErOS

100
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.

101
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

102
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)

103
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.

104
 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

105
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.

106
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

return ,
}

107
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.

108
 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.

109
 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

110
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.

OM1

OM2

OM3

OM4

OM5

OM6

OM7

OMi‐1

OMi

OMi+1

OMn‐2

OMn‐1

OMn
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

111
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).
OM1

OM4

OMi+1

OM2

OM5

OM3

OM7

OMi‐1

OMN

OM6

OMn‐2

OMn‐1

OMI
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

OM1

OM4

OMi+1

OM2

OM5

OM3

OM7

OMi‐1

OMN

OM6

OMn‐2

OMn‐1

OMI

Activité1 Composan1

Activité2 U
Activité3
Activité4
Composant 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

112
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

113
(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

114
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.

115
 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.

116
Chapitre 7

Construction du processus collaboratif

interentreprises

SOMMAIRE

Chapitre 7 Construction du processus collaboratif interentreprises ..................................... 117

7.1 Introduction ............................................................................................................................. 118

7.2 Les paramètres non fonctionnels (PNF) des services .............................................................. 118

7.3 Modèle de services orienté paramètres non fonctionnels...................................................... 120

7.4 L'utilisation des politiques pour la modélisation de paramètres non fonctionnels ................ 124

7.5 La construction du processus collaboratif ............................................................................... 131

7.6 Évaluation et prototype ........................................................................................................... 142

7.7 Conclusion ............................................................................................................................... 150

117
7.1 Introduction

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

118
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.

119
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éputatio Temps Lieu Sécurité Monitoring Méthode de

Service n d'exécution Payement
S1 200 € 80% 1 days France, 128‐ bit key Phone, VISA,
Italy email MasterCard
S2 150 € 100% 12 hours France 128‐ bit key Web portal, VISA,
phone MasterCard
S3 120 $ 95% 8 hours France, ‐‐ email, Web VISA
UK, portal
Germany
S4 200 € 70% 24 hours Italy, 512‐ bit key ‐‐ MasterCard,
Germany 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.

120
 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),

121
 • 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

122
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

123
 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)

124
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

125
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

126
 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.

127
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

128
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.

129
 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.

130
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,

131
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

132
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.

133
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

134
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

135
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.

136
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 :

137
 ƒ 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 :

Evaluation rule rule‐name

NFP Category NFP‐category
Scale Type scale‐type
Policies source‐policy, member‐policy
Action evaluatePolicyCompatibility (source‐policy, member‐
policy)
Une règle d'évaluation est identifiée par un nom et elle est spécifique à une catégorie de
paramètre non fonctionnel et une échelle de mesure particulières. L'attribut action d'une règle
d'évaluation contient une fonction booléenne evaluatePolicyCompatibility (source‐policy,
member‐policy) qui retourne "vraie" quand la politique source est compatible avec la politique
membre ou dans le cas où la politique membre est négociable. La logique interne de cette
fonction dépend de la catégorie et de l'échelle de mesure des deux politiques.

Les fournisseurs de communautés doivent spécifier les traitements convenables de la fonction

evaluatePolicyCompatibility. Dans ce qui suit, nous allons présenter deux exemples de règles
d'évaluation en relation avec la catégorie "Response Time" et la catégorie "Monitoring".

138
Evaluation Rule rule‐ResponseTime Evaluation Rule rule‐Monitoring
NFP Category Response Time NFP Category Monitoring
Scale Type Ratio Scale Type Nominal
Policies P1 , P2 Policies P1 , P2
Action evaluatePolicyCompatibility (P1 , P2) Action evaluatePolicyCompatibility (P1 , P2)
{ |
|

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 :

139
 , , … ,
, , … ,
(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
ème
dissimilarité entre deux politiques , et , .. , est la k 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 (4)
max
, ,
(5)
, ,
1
max
, ,

, ,
(6)
1
max
, ,

140
 , ,
(7)
1
max

™ 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 :
1
, , , 2 , , , , , , (8) ,
2
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.

1
1 (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

141
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).

142
 Services Temps de Réponse Coût Méthode de payement
85 100 VISA;MasterCard;AmericanExpress
S1
N N NN
91.75 93 VISA;MasterCard
S2
N NN NN
117 90 MasterCard
S3
NN NN NN
70 90 VISA;MasterCard;AmericanExpress
S4
NN NN NN
105.2 90 VISA;MasterCard
S5
N N NN
224 90 VISA
S6
NN NN NN
99.2 89 VISA;AmericanExpress
S7
NN NN NN
108.2 88 VISA
S8
N NN NN
125.2 88 AmericanExpress
S9
N NN NN
110.3 87 MasterCard
S10
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.

143
 Requête 100 90 MasterCard
85 100 VISA;MasterCard;AmericanExpress
S1
N N NN
70 90 VISA;MasterCard;AmericanExpress
S4
NN NN NN
105.2 90 VISA;MasterCard
S5
N N NN
110.3 87 MasterCard
S10
N NN NN
Tableau 7.3 : Vérification de la compatibilité

Requête 100 90 MasterCard

0.6277916 1.7692308 0.3333333
S1
N N NN
0.2555831 1.0 0.3333333
S4
NN NN NN
1.1290321 1.0 0.25
S5
N N NN
1.2555832 0.7692308 0.0
S10
N NN NN
Tableau 7.4 : Vérification de la compatibilité

Services Distances finales

S4 1.0846353311832513
S10 1.4724826052663202
S5 1.5287947920618226
S1 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.

144
 Nombre de service

400
350
300
250
200
Web service
150 returned by
100 the request

50
Nombre de
0
PNF
0 2 4 6 8 10 12

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.

Execution time (ms)

2500

2000

1500

1000 Execution time

500

0 Number of
0 2 4 6 8 10 12 NFPs

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.

145
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

146
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)).

147
 (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).

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
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

149
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

150
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.

151
152
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

153
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

154
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 :

155
 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

156
 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

157
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.

158
 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.

159
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.

160
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:
http://www.techniques‐
ingenieur.fr/dossier/la_flexibilite_dans_les_organisations_industrielles/AG3100.
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.

161
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.

162
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.

163
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/.

164
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.

165