Intégration des approches SOA et orientée objet pour...
Transcript of Intégration des approches SOA et orientée objet pour...
Numéro d'ordre : 2010-ISAL-0060 Année 2010
Institut National des Sciences Appliquées de Lyon
InfoMath : École Doctorale Informatique et Mathématiques
Intégration des approches SOA et orientée objet pour
modéliser une orchestration cohérente de services
Thèse de Doctorat
(Spécialité informatique)
Par
Alida ESPER
Soutenue publiquement le 1 septembre 2010 devant la commission d'examen
composée de :
Dominique RIEU Professeur, Laboratoire LSR – IMAG, Saint Martin d’Hères présidente de jury
Hervé PINGAUD
Professeur, École des Mines d’Albi-Carmaux Rapporteur
Samir TATA Professeur, TELECOM & Management SudParis
Rapporteur
Frédérique BIENNIER
Professeur, LIESP – INSA de Lyon Directeur de thèse
Youakim BADR Maître de Conférences, LIESP – INSA de Lyon Co-Directeur de thèse
Laboratoire d’informatique pour l’entreprise et les systèmes de production
REMERCIMENT
Je tiens à remercier,
Mme Dominique RIEU de me faire l‟honneur de présider mon jury
de thèse.
M. Hervé PINGAUD et M. Samir TATA pour avoir accepté de lire
et d‟évaluer mon travail de thèse.
Mme. Frédérique BIENNIER pour ses conseils et son aide pendant
la rédaction de ma thèse.
Mr. Youakim BADR pour son apport tant au niveau des
connaissances, mais également pour ses encouragements, ainsi que son
soutien tout au long de la thèse.
Mes amis pour me supporter à avancer toujours.
Toute ma famille en Syrie, et plus particulièrement mes parents, mes
sœurs et mes frères qui m‟ont toujours encouragé.
Un grand merci à mes parents à qui je dois ce que je suis devenue.
Alida ESPER
Résumé
Pour faire face aux contraintes économiques, le développement de stratégies
« au plus juste » (lean manufacturing) impose à la fois un recentrage métier,
la mise en place de logistique de production « agile » et l‟organisation de
collaborations inter-entreprises. Ces collaborations conduisent à
l‟émergence d‟entreprises virtuelles et font largement appel aux
technologies de l‟information et de la communication. Or les réponses
technologiques apportées peuvent constituer un frein, les Systèmes
d‟Information (SI) d‟entreprise ne sont que peu agiles. Et manquent de
capacité d‟interopérabilité. En effet, l‟infrastructure informatique
(matérielle et logicielle, i.e. ERP, CRM, CAD, SCM, MES…) présente une
forte complexité technologique, manque d‟interopérabilité et limite donc les
possibilités « d‟interconnexion » entre les processus d‟entreprise et
l‟échange d‟information entre partenaires.
Pour surmonter ces limites, l‟implémentation du système d‟information
selon une architecture orientée services (SOA) définit une nouvelle
approche pour organiser les applications d'entreprise et optimiser les
processus métier.
Néanmoins, ces infrastructures sont essentiellement destinées à soutenir
l'interopérabilité intra-entreprise car elles reposent sur une définition mono-
contexte du processus d'affaires. Or un écosystème de services inclut un
environnement multi-contextuel d‟exécution de services.
Pour surmonter ces limites dans notre travail de recherche, nous proposons
d‟intégrer une architecture supportant différents contextes d‟exécution pour
favoriser le déploiement de systèmes d‟information interopérables au sein
de l‟entreprise et donc faciliter la collaboration des processus inter -
entreprises.
Pour cela, nous proposons d‟utiliser une architecture de collaboration à base
d‟hypergraphe. Afin de propager efficacement le contexte, nous proposons
de définir des règles de propagation des mécanismes d‟héritage issus de
l‟approche objet pour assurer une contextualisation des services à la
demande. Pour cela, notre modèle est basé sur trois concepts : le service, le
répertoire et le processus de collaboration (processus commun) qui est
défini par différents vues (gestion, sécurité et médiation). Ces différentes
vues permettent de composer simplement le service contextualisé.
Mots clés : Collaboration interentreprises, Architecture Orientée Services
(SOA), Service Web, composition de service, Approche Orienté Objet.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
vii
ABSTRACT
To face the economic constraints, the development of just in
time strategies (lean manufacturing) requires the organization of
collaborations between enterprises. These collaborations lead to the
emergence of virtual enterprise and needs the communication and
information technologies. However the technological answers can
constitute a brake as the enterprise Information systems (IS) lack of
agility. Indeed, the infrastructure (hardware and software, ie ERP
(Enterprise Resource Planning), CRM(Customer Relationship
Management), MES (Manufacturing Execution System)...) has a high
technological complexity, lack of interoperability and therefore limits
the potential interconnection between business processes and exchange
of information between partners.
To overcome these limits, the implementation of the
information system according to an orientated architecture services
(SOA) defines a new approach to organize the applications of enterprise
and to optimize the business processes. Nevertheless, these
infrastructures are primarily proposed to support the interoperability
inter-enterprise because they rely on a mono-context definition of the
business process. However an ecosystem of services includes a multi -
contextual environment of execution of services.
To overcome these limits, we propose to integrate an
architecture supporting various contexts of execution to support the
deployment of information systems interoperable within the enterprise
and improving interenterprise collaborative processes enactment.
Based on an hypergraph organisation, our architecture includes
context propagation rules and extends the inheritance mechanisms from
the object oriented approach to allow a simple service contextualisation.
Our model is based on three concepts: service, repository and
collaborative process (associated to the common process). Different
views (management, mediation, security) are used to support a simple
contextual service composition.
Key-words: Enterprise collaboration, Service Oriented Architecture
(SOA), Web service, service composition, and Approach objet oriented.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
viii
Table de matières
Chapitre 1 Introduction ............................................................................................................. 1
1.1 Problématique ................................................................................................................... 1
Chapitre 2 Etat de l’art ............................................................................................................. 5
2.1 Introduction ...................................................................................................................... 5
2.2 Méthodes de modélisation ................................................................................................. 6
2.2.1 CIMOSA ...................................................................................................................... 7
2.2.2 GRAI ............................................................................................................................ 9
2.2.3 PERA ......................................................................................................................... 11
2.2.4 GERAM...................................................................................................................... 12
2.2.5 Méthodes orientées « système d’information » ............................................................. 16
2.2.6 Conclusion .................................................................................................................. 20
2.3 Approche basée processus ............................................................................................... 20
2.3.1 Eléments caractéristiques d’un modèle de processus ..................................................... 21
2.3.2 Typologie des processus .............................................................................................. 24
2.3.3 Gestion de processus métier ......................................................................................... 26
2.3.4 ARIS : une méthode de modélisation orientée processus ............................................... 27
2.3.5 Stratégies d’interconnexion de processus ...................................................................... 29
2.3.6 Conclusion...................................................................................................................... 32
2.4 Architecture orientée service : une réponse à l’interopérabilité technologique .................... 32
2.4.1 Description de service ................................................................................................. 34
2.4.2 Communication entre service ....................................................................................... 37
2.4.3 Publication de service .................................................................................................. 37
2.4.4 Description de la partie opérative des services .............................................................. 39
2.4.5 Composition et orchestration de services ...................................................................... 42
2.4.6 Conclusion .................................................................................................................. 45
2.5 Démarches orientées objet ............................................................................................... 46
2.5.1 Concepts de base de l’approche objet ........................................................................... 46
2.5.2 Définition des Objets métier (Business objects) ........................................................... 49
2.5.3 Méthodes de modélisation orientée objet ..................................................................... 50
2.5.3.1 IEM ........................................................................................................................ 50
2.5.3.2 UML ....................................................................................................................... 51
2.5.4 Conclusion .................................................................................................................. 56
2.6 Des modèles au logiciel ................................................................................................... 56
2.7 Conclusion...................................................................................................................... 62
Chapitre 3 La collaboration des processus de l’entreprise ...................................................... 66
3.1 Introduction .................................................................................................................... 66
3.2 Architecture globale ........................................................................................................ 72
3.3 Spécification des différentes vues .................................................................................... 79
3.3.1 La vue de gestion ........................................................................................................ 79
3.3.2 La vue de médiation .................................................................................................... 85
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
ix
3.3.3 Vue de sécurité ........................................................................................................... 88
3.3.4 Conclusion .................................................................................................................. 90
3.4 Exploitation du modèle : ................................................................................................. 91
3.5 Conclusion...................................................................................................................... 95
Chapitre 4 Modélisation d'entreprises collaboratives par des graphes de d’héritages de
services .................................................................................................................. 96
4.1 Introduction .................................................................................................................... 96
4.2 Mécanismes d’héritage .................................................................................................... 99
4.3 Héritage entre services (objets) ...................................................................................... 100
4.3.1 Héritage avec les propriétés fonctionnelles ................................................................. 100
4.4 Les propriétés non fonctionnelles et le mécanisme d’héritage .......................................... 101
4.5 La construction de l’hypergraphe ................................................................................... 103
4.6 Construire l’arborescence des instances ......................................................................... 106
4.7 Collaboration entre les entreprises à base d’hypergraphe ................................................ 108
4.8 Orchestration contextualisée de “type de service“ ........................................................... 111
4.9 Les contraints de transition entre les types de service ..................................................... 114
4.10 L’enchaînement des types de services ............................................................................ 116
4.11 Les relations de dépendances entre les Services .............................................................. 118
4.11.1 La relation d’agrégation (A) ...................................................................................... 119
4.11.1.1 Les cardinalités ..................................................................................................... 120
4.11.1.2 La spécification de contraintes globales .................................................................. 120
4.11.1.3 La propagation des contraintes dans une composition .............................................. 121
4.11.2 La relation de recommandation (R) ............................................................................ 121
4.11.2.1 La relation de similarité (S) ................................................................................... 122
4.11.2.2 La relation de collaboration (C) ............................................................................. 123
4.12 Intégration des relations de dépendances dans les processus métiers ................................ 123
4.13 Conclusion.................................................................................................................... 125
Chapitre 5 Conclusion générale et perspectives .................................................................... 127
5.1 Conclusion général et perspective .................................................................................. 127
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
x
Table de figures
Figure 1 : Cube CIMOSA [16] page 138 .................................................................................... 7
Figure 2 : les outils GRAI ....................................................................................................... 10
Figure 3 : éléments méthodologiques de GERAM [20], page 5. ................................................ 14
Figure 4 : Cycle de vie de GERAM [21] page 10 ...................................................................... 15
Figure 5 : La modélisation d’une activité ................................................................................ 17
Figure 6 : Les éléments principaux pour la modélisation d’un processus métier [10] page 16. ... 22
Figure 7 : l'architecture d'ARIS [41] page 40 .......................................................................... 28
Figure 8 : Aris les niveaux de modélisation pour le processus de l’entreprise [41] page 3 ....... 28
Figure 9 : modèle de Service Web [51] page 5 ......................................................................... 33
Figure 10 : La description d’un service web grâce à WSDL [53] p86 ........................................ 35
Figure 11 : Ontologie OWL-S .................................................................................................. 36
Figure 12 : Mécanismes d’accès aux services fournis par un UDDI Registry [51] page 117. ..... 38
Figure 13 : Modèle structurel des données de UDDI Registry [51] page 119 ............................ 39
Figure 14 : La connexion entre un processus BPEL et des services [59] page 74. ...................... 40
Figure 15 : Le document XLANG [59] page 251 ...................................................................... 42
Figure 16 : Le model de coordination [53] page 4 ................................................................... 44
Figure 17 : exemple d'association ........................................................................................... 47
Figure 18 : Exemple d'agrégation ........................................................................................... 48
Figure 19 : exemple de généralisation ..................................................................................... 48
Figure 20 : Schéma d’un objet encapsulé ................................................................................. 49
Figure 21 : le modèle général d'activité d'IEM ......................................................................... 51
Figure 22 : Représentation des relations entre classes [34] page 20. ........................................ 52
Figure 23 : Exemple d'agrégation et de composition [34] page 21. ........................................... 52
Figure 24 : Exemple d'une collaboration dans un diagramme de structure composite [34] page
29 .......................................................................................................................................... 53
Figure 25 : Représentation d'un design pattern dans un diagramme de structure composite [34]
page 29 .................................................................................................................................. 54
Figure 26 : Les niveaux de modélisation .................................................................................. 57
Figure 27 : Les catégories de modèles dans MDA. ................................................................... 58
Figure 28 : Exemple de PIM [40] page 8. ................................................................................ 59
Figure 29 : Relation entre PIM et PSM en modélisation EJBexpanded [40] page 9 ................... 59
Figure 30 : Etapes du processus MDA [40] page 6. ................................................................ 60
Figure 31 : Exemple d’utilisation des modèles pour réaliser une applica tion [38] page 5. ......... 61
Figure 32 : Transformations des modèles [38] page 6. ............................................................. 61
Figure 33 : Comparaison entre processus collaborati fs traditionnels et multi-contextuels ......... 71
Figure 34 : Les concepts de base d’une collaboration contextualisée ........................................ 72
Figure 35 : Description du contexte permettant une sélection et exécution multi -contextuelles de
services .................................................................................................................................. 75
Figure 36 : Génération du processus concret en choisissant les services concrets convenables .. 76
Figure 37 : Vue d’agrégation du processus permettant la propagation des informations ............ 76
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
xi
Figure 38 : Architecture globale ............................................................................................. 78
Figure 39 : Relations entre le participant, le rôle, et le service abstrait .................................... 80
Figure 40 : les relations entre les concepts dans le processus de collaboration. ........................ 81
Figure 41 : les éléments de modèle de collaboration (génération le service) ............................. 81
Figure 42 : Exemple montrant la sélection du service abstrait à partir du rôle .......................... 83
Figure 43 : Exemple montrant la règle de sélection des services concrets à partir des services
abstraits ................................................................................................................................. 84
Figure 44 : Définition d’un service .......................................................................................... 85
Figure 45 : Mécanisme de propagation de contraintes de sécurités via le médiateur ................. 88
Figure 46 : Les droits d’accès et l’héritage entre les objets ...................................................... 89
Figure 47 : Construction du processus de collaboration par une série de transformation de
modèles (MDA) ....................................................................................................................... 91
Figure 48 : Modélisation des processus en termes d’hypergraphe ............................................. 98
Figure 49 : Le modèle de service vu comme un objet qui encapsule les propriétés et les méthodes
............................................................................................................................................ 100
Figure 50 : L’héritage entre les services ................................................................................ 101
Figure 51 : héritage avec les propriétés non fonctionnelles .................................................... 103
Figure 52 : Exemple d’arborescence ..................................................................................... 104
Figure 53 : Les attributs de la classe ..................................................................................... 105
Figure 54 : L’ensemble des attributs de l’objet ...................................................................... 106
Figure 55 : L’arborescence de l’objet .................................................................................... 107
Figure 56 : Les liens entre les classes et les objets ................................................................. 107
Figure 57 : Les liens avec des objets appartenant à différentes classes ................................... 108
Figure 58 : Principe de présenter les services ........................................................................ 109
Figure 59 : Arbre d'héritage de service <achat> ................................................................... 110
Figure 60 : rôle le médiateur ................................................................................................ 110
Figure 61 : Le rôle de médiateur pour sélectionner le service contextuel ................................ 111
Figure 62 : L’Orchestration de type de service ...................................................................... 113
Figure 63 : Les différents états de transition .......................................................................... 114
Figure 64 : Service composé l’acheter de produits informatiques ........................................... 117
Figure 65 : Vue statique du processus métier composite en relations d’agrégation .................. 120
Figure 66 : Relation de recommendation < RoomBookingWS, R, SightSeeingWS > ................. 122
Figure 67 : Relation de similarité < RoomBookingWS, S, RoomReservationWS > ................... 122
Figure 68 : Relation de collaboration < AirTicketPurchaseWS, C, 0,5, RoomBookingWS> ...... 123
Figure 69 : Un processus métier et les différentes types de relations de dépendances entre les
services ................................................................................................................................ 125
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
1
Chapitre 1
Introduction
1.1 Problématique
L‟évolution de la demande pour des associations
produits/services nécessite l‟organisation de collaborations « à la
demande » entre entreprises pour répondre aux besoins des clients. Ce
changement structurel au niveau du marché laisse donc prévoir une
croissance exponentielle des écosystèmes de services dans les
prochaines années et le développement de nouvelles structures
organisationnelles permettant de pouvoir organiser des collaborations
« à la demande » entre les entreprises. Ce changement de contexte
impose d‟accroître non seulement l‟agilité de l‟entreprise (définie
comme “the ability of an organization to sense environmental change
and respond efficiently and effectively to that change [1] page1 ") qui
constitue un élément clef de succès [2] pour les entreprises mais aussi de
résoudre les problèmes d‟interopérabilité tant au niveau organisationnel
qu‟en ce qui concerne le niveau technologique.
Pour ce qui concerne le niveau organisationnel, la mise en
place de stratégie de collaborations et de partenariat entre entreprises
impose de formaliser les différents processus afin de pouvoir ensuite
construire un processus commun interconnectant les processus propres
des différents partenaires. Pour cela, il faut modéliser à la fois les
processus (définis comme des séquences de tâches) et les échanges
d‟information entre ces tâches, ce qui nécessite la prise en compte de
différents points de vue :
1. La vue fonctionnelle permet de décrire les différentes
fonctions (en termes de processus, activités et opérations) et les
contraintes de cohérence liées à l‟enchaînement de différentes fonctions.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
2
2. La vue informationnelle est utilisée pour décrire les objets de
l‟entreprise et leur gestion mais aussi l‟échange d‟information en entrée
et sortie des fonctions et activités décrites précédemment
3. La vue des ressources est utilisée pour montrer les rôles des
ressources et leur mode de gestion (qui fait quoi et avec quoi).
4. La vue organisationnelle sert à la description des
responsabilités intervenant dans les prises de décision (qui est
responsable de quoi).
Cette phase de modélisation, si elle donne une vision globale et
précise du fonctionnement de l‟entreprise, est relativement lourde à
mettre en place. Or les règles de gestion des entreprises sont assez
souvent similaires aussi les différentes méthodes de modélisation
proposent elles une architecture intégrant des modèles génériques
(représentant des « bonnes pratiques ») à instancier et particulariser.
Toutefois, cette logique top-down ne permet pas de s‟adapter
dynamiquement aux différents contextes de collaboration puisque le
processus de modélisation, instanciation, particularisation doit être
repris depuis le début. De manière à atteindre le nécessaire niveau
d‟agilité, il faut donc réorganiser l‟entreprise pour permettre une
construction « incrémentale » des activités dans une logique plutôt
« bottom-up ».
Au niveau technologique, les Systèmes d‟Information (SI)
d‟entreprise ne sont que peu agiles et ne permettent pas d‟adapter les
processus internes de l‟entreprises pour répondre « à la demande » aux
changements structurels imposés par le marché. Or, l‟infrastructure
informatique (matérielle et logicielle) repose sur une large variété de
composants spécialisés ERP (Enterprise Ressource Planning),
CRM(Customer Relationship Management), SCM(Supply Chain
Management),…) et présente donc à la fois une forte complexité
technologique et un manque d‟interopérabilité. Or la formalisation d‟une
collaboration pour répondre à un objectif commun induit la création
d‟un processus collaboratif liant et coordonnant l‟ensemble des
processus mis en œuvre par les différents partenaires. Ceci impose donc
de fortes contraintes d‟agilité et d‟interopérabilité sur les différents
systèmes support pour permettre la combinaison et la bonne
synchronisation de ces différents éléments. Ceci explique que le
développement important des technologies de l‟information et de la
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
3
communication, au lieu de devenir un élément moteur de la
collaboration inter entreprise soit vu comme des freins puisqu‟elles
limitent les possibilités « d‟interconnexion » entre les processus
d‟entreprise et l‟échange d‟information entre partenaires. Pour remédier
aux problèmes d‟interopérabilité technologiques, le développement de
l'architecture orientée services (SOA) [3] permet aux entreprises
d‟organiser leur système d'information et les applications qui le
composent en termes de services assemblés les uns avec les autres.
L‟utilisation de standards d‟interface et de middleware (les Entreprise
Service Bus ou ESB) permettent d‟apporter une réponse technologique
au besoin d‟interopérabilité. Néanmoins, ces architectures à base de
services ne permettent pas de contextualiser les services et leur
assemblage dans une chaîne de service supportant un processus est dicté
par l‟organisation du processus lui-même, spécification issue des
activités de modélisation…
Pour surmonter ces limites, nous proposons d‟intégrer une
architecture orientée service allant du niveau technologique au niveau
d‟affaire. Pour cela, nous proposons de redéfinir les processus de
manière abstraite au niveau de la logique d‟affaire en exprimant les
différents rôles à jouer. Ceci permet de contourner la vision « top-
down » de la modélisation traditionnelle en apportant une vision de
composition incrémentale par composition de services abstraits en
fonction des besoins. De manière à fournir le support technologique
indispensable, ces processus abstraits sont utilisés pour sélectionner et
interconnecter les services technologiques. De manière à faciliter la
contextualisation, il importe de définir une logique d‟assemblage
permettant d‟intégrer différentes logiques de médiation, de sécurité… en
composant des services technologiques adaptés au contexte.
Pour cela, nous proposons une nouvelle logique
d‟instanciation : il ne s‟agit plus seulement de dériver un modèle
générique pour le particulariser puis transformer ce modèle particulier
en un code exécutable, mais d‟adopter une logique de composition de
services exécutables à partir de modèles abstraits ou d‟informations
contextuelle. Pour cela, nous proposons une vision en hypergraphe qui
nous permet de tirer partie à la fois des avantages de l‟approche objet
(héritage, agrégation,…), de l‟ingénierie des modèles (logique de
transformation) et de la composition de service. En effet, cette
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
4
architecture nous permet non seulement de relier étroitement services
abstraits et concrets mais aussi d‟intégrer un « tissage » de modèles de
sécurité, de médiation, des relations de similarité… qui permettront
d‟organiser au mieux le processus « concret » support de la
collaboration en guidant les différentes opérations de composition.
La suite de ce mémoire de thèse est organisée en 3 chapitres principaux :
dans chapitre 2 consacré à l'état de l'art, nous concentrons d'abord sur la
modélisation d'entreprise et présenterons différentes méthodes
généralistes avant de nous intéresser plus spécifiquement aux méthodes
de modélisation orientées système d‟information. Nous nous
intéresserons ensuite aux approches orientées processus et aux apports
des architectures orientées services avant de détailler les approches
orientées objets et l‟ingénierie dirigée par les modèles. En effet, la
plupart des méthodes de modélisation propose une démarche de type
instanciation à partir de modèles générique pour créer des modèles
spécifiques. Ce processus pourrait donc être amélioré en intégrant les
apports de ces deux technologies.
Le chapitre 3 présente globalement notre architecture
permettant de générer des services contextuels « au vol » en combinant
différents points de vue. L‟organisation des différents modèles associés
est définie dans une structure à base d‟hypergraphe présenté de manière
plus détaillée dans le chapitre 4.
Enfin, le chapitre 5 rappelle nos principales contributions et
présente les perspectives ouvertes par ce travail.
Chapitre 2 Etat de l’art
2.1 Introduction
Les évolutions rapides du contexte économique (notamment la
prise en compte de stratégies de personnalisation « de masse », le
développement de stratégies au plus juste, la recherche d’une rentabilité
maximale…) conduisent les entreprises à se recentrer sur leur cœur de
métier tout en développant une stratégie d’ouverture conduisant à des
organisations collaboratives. Ce nouveau contexte impose aux
entreprises de formaliser leur organisation (contraintes contractuelles)
mais aussi d’adapter leur organisation et leur système d’information de
manière à pouvoir construire de manière efficaces des processus
collaboratifs interopérables permettant à l’ensemble des partenaires
d’atteindre un but commun. Aussi, dans un premier temps, nous nous
intéresserons aux méthodes générales de modélisation de l’entreprise
avant de nous focaliser sur les approches centrées processus. Dans un
deuxième temps, nous prendrons en compte les contraintes
d’interopérabilité technologique et présenterons comment les approches
orientées services et les standard associés peuvent apporter une réponse
consistante au nécessaire besoin d’ouverture des systèmes
d’information. Enfin, de manière à faciliter la conception des processus
collaboratifs et de pallier les lourdeurs et difficultés inhérentes aux
méthodes de modélisation classique, nous étudierons plus précisément
les applications possibles des approches objets et de l’ingénierie dirigée
par les modèles pour permettre la génération de processus informatique
« support ».
Ce tour d’horizon nous permettra, en en identifiant les limites
de ces différentes approches dans la conclusion de ce chapitre,
d’esquisser les pistes de recherche qui serviront de base à notre
contribution.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
6
2.2 Méthodes de modélisation
Avant de présenter différentes approches de modélisation, il
convient d‟en préciser l‟objectif et le périmètre. La modélisation
d‟entreprise est l‟ensemble des activités et des processus utilisés pour
développer les différentes parties d‟un modèle d‟entreprise dans le but
de [13]:
• Construire une vision et une culture communes
communiquées lors de l‟utilisation de modèles.
• Offrir une meilleure représentation et une meilleure
compréhension du fonctionnement d‟une entreprise.
• Capitaliser la connaissance et le savoir-faire de l‟entreprise
pour une utilisation ultérieure.
• Rationaliser et structurer les échanges d‟information.
• Concevoir et spécifier une partie de l‟entreprise (aspects
structurels, organisationnels, informationnels, fonctionnels ou
comportementaux).
• Analyser certains aspects d‟une partie de l‟entreprise
(analyse économique, organisationnelle, quantitative, qualitative, etc.).
• Simuler le comportement d‟une partie de l‟entreprise.
• Offrir des éléments pour l‟aide à la décision pour le
contrôle et l‟évolution de l‟entreprise (des processus, par exemple).
Les approches de modélisation d‟entreprise sont nombreuses et
intègrent différents points de vue permettant d‟appréhender globalement
l‟organisation et le fonctionnement de l‟entreprise . Parmi elles, nous
présenterons d‟abord la vision « intégratrice » de CIMOSA avant de
nous intéresser à d‟autres méthodes se focalisant sur des points de vue
plus spécifiques comme GRAI (pour la modélisation des décisions),
PERA avant de terminer par le cadre fédérateur de GERAM. Nous nous
intéresserons ensuite plus précisément aux approches de modélisation
orientées système d‟information puisque le fonctionnement de
l‟entreprise fait largement appel au système d‟information qui agit lui -
même comme un élément structurant de l‟organisation. Nous dresserons
ensuite un bilan de ces méthodes dans le contexte particulier de la
modélisation d‟organisations collaboratives.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
7
2.2.1 CIMOSA
La méthode CIMOSA (Computer-Integrated Manufacturing
Open Systems Architecture) est issue d‟un projet européen Esprit.
L‟objectif était de fournir un cadre de modélisation et un ensemble de
modèles favorisant la mise en place du « Computer Integrated
Manufacturing » [14] [15]. CIMOSA prend en compte à la fois un cadre
de modélisation multi points de vue, une infrastructure facilitant la
communication entre les différents éléments et une démarche
méthodologique de modélisation. L‟infrastructure est chargée d‟apporter
un ensemble de services :
Les services de gestion assurent la gestion, le contrôle de
l‟exécution des tâches ou activité du système.
Les services de communication garantissent l‟accès aux données.
Les services d‟interface supportent une représentation cohérente
des différentes entités du domaine considéré.
Le cadre de modélisation de CIMOSA, connu sous le nom du
cube CIMOSA qui est montré dans la (figure 1) organise la modélisation
de l‟entreprise selon trois axes [16]:
Figure 1 : Cube CIMOSA [16] page 138
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
8
L‟axe de génération ou axe des vues est associé aux différents
points de vue :
a. La vue fonctionnelle permet de décrire les «
fonctionnalités », la structure de contrôle et le comportement de
l‟entreprise en termes d‟opération, activité et de processus.
b. La vue information permet la spécification du système
informatique de l‟entreprise, la création d‟une structure adaptée afin de
stocker / mettre à jour / traiter Les informations (données et
connaissances) pour les besoins des utilisateurs et des Applications
(mémoire de l‟entreprise).
c. La vue ressources est associée à la spécification et la
description des composants requis et/ou implantés dans le système de
production servant de réalisation des tâches de l‟entreprise. Il s‟agit
aussi bien des composants de la technologie manufacturière que de ceux
de la technologie informatique (qui fait quoi, quand et comment).
d. La vue organisation sert à la description de l‟organisation
et des responsabilités intervenant dans les prises de décision (qui est
responsable de quoi). L‟organisation de l‟entreprise est exprimée en
termes de cellules, d‟unités et de niveaux de prise de décision.
L‟axe de dérivation permet d‟intégrer les différentes phases d‟un projet de
modélisation selon trois phases :
e. Expression des besoins : c‟est la construction d‟un modèle
utilisateur qui définit ce qui doit être réalisé dans l‟entreprise (le QUOI).
f. Spécification de conception : c‟est la construction d‟un
modèle de l‟entreprise non ambigüe et cohérent. Différents modèles
peuvent être développés pour étudier diverses alternatives par le biais de
la simulation.
g. Description de l‟implantation : c‟est la construction d‟un
modèle exécutable de l‟entreprise (le COMMENT).
L‟axe d‟instanciation permet à partir d‟un modèle générique global de
construire différents modèles partiels avant de les particulariser pour
définir des modèles spécifiques de l‟entreprise.
Les différents points de vue proposés par cette méthode offrent
un cadre riche permettant de définir les différentes représentations
abstraites de l‟entreprise. La possibilité de générer des modèles
particuliers pour l‟entreprise à partir de modèles génériques peut
représenter un gain de temps appréciable et permettre de réutiliser des «
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
9
best practices ». Mais CIMOSA ne permet pas de se focaliser sur le
processus de décision, capital en cas de développement d‟une stratégie
de collaboration. Pour cela, on peut recourir à la méthode GRAI.
2.2.2 GRAI
L‟objectif de la méthode GRAI [17] (Graphe de Résultats et
Activités Inter-reliés) est de faciliter l‟identification de toutes les
activités de décision d‟un système lors de l‟analyse et de la conception
de son système pilotage. Pour cela, la méthode GRAI propose deux
outils principaux : la grille GRAI et les réseaux GRAI [18] qui sont
présentés dans la figure 2.
La grille GRAI permet d‟identifier les activités des centres de
décision suivant les dimensions fonctionnelles et temporelles. Les
colonnes représentent les fonctions d‟un processus de décision. Les
lignes correspondent à des niveaux de décision. Chaque niveau de
décision est défini par un couple (horizon/période). Chaque centre de
décision est défini par une activité de gestion.
Les réseaux GRAI représentent le fonctionnement de tout ou
partie d‟un centre de décision. Ils permettent de modéliser les activités
d‟exécution et de décision.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
10
Figure 2 : les outils GRAI
La démarche GRAI comporte deux phases :
L‟initialisation inclut la prise de contact avec l‟entreprise (pour
définir les conditions de la collaboration et les objectifs à
atteindre).
L‟analyse de l‟existant débute par l‟établissement des grilles
GRAI associées au système étudié. L‟étape suivante est
l‟analyse ascendante qui permet la création des réseaux
décrivant les processus utilisé dans le centre de décision
identifié. Enfin, cette phase se termine par la rédaction du
rapport d‟analyse.
La conception du futur système : la grille GRAI permet de
décrire l‟architecture du futur système de gestion de
l‟entreprise.
Cette modélisation des mécanismes de prise de décision (qui
décide de quoi et sur quel horizon) nous semble bien correspondre aux
problèmes soulevés par l‟organisation d‟organisations collaboratives car
cela permet de définir clairement les limites de responsabilité. En outre,
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
11
la collaboration interentreprises fait largement appel aux technologies de
l‟information et de la communication. Ce point est également pris en
compte par GRAI dans la mesure où cette méthode a fait l'objet de
plusieurs extensions en intégrant les méthodes orientées « système
d‟information » comme IDEF0 et MERISE au processus de modélisation
GRAI pour former la méthodologie GIM (GRAI Integrated Methodology
ou GRAI-IDEF0-MERISE) vers les années 90.
GIM apporte une réponse à la question de prise de décision,
cependant, il n'apporte pas une réponse complète de gestion de ressource
humaine et il ne prend pas en considération le cycle de vie d'un modèle.
Pour surmonter cette limite, la méthode PERA peut être envisagée de
manière complémentaire.
2.2.3 PERA
PERA (Purdue Enterpris Reference Architecture) est une
architecture pour la modélisation d‟entreprise développée à l‟université
de Purdue aux Etats-Unis [19]. La méthodologie est basée sur les étapes
associées au cycle de vie d‟un système :
- Identification de l‟entité modélisée : cette étape concerne la
caractérisation du domaine couvert par l‟étude : entreprise dans son
ensemble, partie d‟une usine, …
- Conceptualisation : il s‟agit ici d‟exprimer les objectifs et
politiques que l‟entreprise souhaite atteindre ou mettre en œuvre.
- Définition : c‟est l‟étape d‟analyse fonctionnelle qui permet
d‟identifier les besoins, les tâches à mettre en œuvre pour permettre la «
réalisation » de ses besoins et les liens entre ces tâches.
- Conception : cette étape débute par une phase de conception
fonctionnelle destinée à définir les choix initiaux ou concevoir
globalement les architectures organisationnelles, humaines, de
production et informatique. Ces architectures sont ensuite précisées dans
la phase de conception détaillée pour aboutir à des architectures
d‟implémentation.
- Installation et construction : il s‟agit ici de transformer les
spécifications détaillées en une implantation effective des moyens
nécessaires à la réalisation de la mission du système. C‟est lors de cette
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
12
étape que les ressources humaines sont formées et que les machines et
équipements sont testés.
- Mise en œuvre et maintenance : c‟est l‟exploitation effective
de l‟installation en y intégrant les tâches de maintenance.
PERA répond aux inconvénients observés dans GIM,
néanmoins, cette méthode ne couvre pas plus que GIM tous les aspects
nécessaires dans l‟organisation de collaboration. Elle doit donc être
utilisée de manière complémentaire.
Ceci pose donc le problème de mise en œuvre d‟un cadre
fédérateur permettant « d‟articuler » différentes méthodes de
modélisation pour tirer le meilleur partie de chacune d‟elle a obtenir un
modèle le plus complet possible. C‟est l‟objectif du développement de
GERAM.
2.2.4 GERAM
Comme nous venons de le voir, les différentes méthodes de
modélisation d‟entreprise utilisent une démarche méthodologique
similaire tout en permettant d‟appréhender des points de vue différents
(décision pour GRAI, fédération des architectures informatique,
organisationnelles et de production pour PERA alors que CIMOSA
juxtapose les différents composants du système). GERAM (Generic
Enterprise Reference Architecture and Methodology) [20][21] est une
initiative issue du groupe de travail (IFAC/IFIP Task Force) sur les
architectures pour l‟intégration d‟entreprises et repose sur une analyse
critique de ces différentes architecture pour fournir un cadre de
modélisation générique permettant de fédérer différentes méthodes et
outils de modélisation.
Le cadre de travail de GERAM est composé de plusieurs
entités [20] (voir figure 3).
Une architecture générique de référence pour l‟entreprise
(GERA : Generic Enterprise Reference Architecture) définit
le cycle de vie de l‟entreprise.
Une méthodologie générique d‟ingénierie de l‟entreprise
(GEEM : Generic Enterprise Engineering Methodology)
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
13
permet de présenter les différents éléments à développer
pour réaliser l‟intégration d‟une entreprise.
Des outils et langages de modélisation génériques pour la
modélisation de l‟entreprise (GEML : Generic Enterprise
Modelling Tools and Languages) offrent le support
nécessaire pour l‟activité de modélisaiton
Des modèles génériques d‟entreprise (GEMS pour Generic
Enterprise Models) : ils sont formés de méta-modèles,
ontologies et de modèles d‟entreprise réutilisables. Ils
constituent une base de « bonnes pratiques » qui peuvent
être utilisées pour faciliter la modélisation d‟une entreprise.
Des modules génériques d‟entreprise (GM pour Generic
Enterprise Modules). Ce sont des implémentations
standards d‟éléments qui peuvent être utilisé dans la phase
d‟intégration pour une entreprise.
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 méthodologies et les langues utilisées pour la
modélisation d'entreprise 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).
Les modèles d'entreprise (Enterprise Models, EMs) qui
représentent l'ensemble ou une partie des opérations
d'entreprise, y compris son organisation et sa gestion ainsi
que ses systèmes de pilotage et d'information. Ces modèles
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
14
sont utilisés pour guider l'implémentation du système
opérationnel de l'entreprise (Particular Enterprise
Operational Systems, EOS). Ces modèles particuliers
peuvent être construits par « instanciation » puis adaptation
de modèles génériques
En fin Les modèles partiels (Partial Entreprise Model,
PEMs) représentent les modèles réutilisables pour les rôles
humaines, les processus ou les technologies.
Figure 3 : éléments méthodologiques de GERAM [20], page 5.
Outre ce cadre de référence, GERAM intègre aussi une
démarche de modélisation basée sur un cycle de vie en sept phases [21]
présenté dans la figure 4 :
Phase d‟identification du contenu : pour une entité
particulière, il s‟agit d‟identifier ses différentes activités, les
limites de responsabilité et les relations avec l‟environnement.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
15
Phase de définition des concepts de l'entité : C‟est l'ensemble
d'activités qui sont nécessaires pour développer les concepts
de l'entité fondamentale. Ces concepts incluent la définition
de la mission de l'entité, vision, ses objectifs, ses concepts
opérationnels, ses politiques, etc.
Phase de définition des besoins : Ce sont les activités
nécessaires pour définir les exigences opérationnelles de
l'entité de l'entreprise, ses processus et tous besoins
fonctionnels, comportementaux, informationnels.
Phase de conception : Ce sont les activités qui définissent la
spécification de l'entité avec l'ensemble de ses éléments qui
satisfont aux exigences de l'entité. Ces activités incluent la
conception de toutes les tâches humaines (tâches des individus
et des entités d'organisation), et toutes les tâches
automatisées.
Phase de démantèlement : Ce sont les activités qui définissent
toutes les tâches qui doivent être effectuées pour déconstruire
l'entité.
Phase de fonctionnement de l'entité : Ce sont les activités de
l'entité qui sont nécessaires au cours de son fonctionnement
pour fabriquer le produit demandé par les clients et réaliser au
bon fonctionnement de l‟entité.
Phase de recyclage de l'entité : ce sont les activités
nécessaires pour recycler, réaffecter ou dissoudre un
composant ou une entité toute entière en fin de sa vie.
Figure 4 : Cycle de vie de GERAM [21] page 10
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
16
Le cadre fédérateur de GERAM présente l‟avantage principale
de reposer sur une analyse critique des différentes architectures de
modélisation d‟entreprise pour fournir un cadre de modélisation
générique permettant de fédérer ces différentes méthodes et outils de
modélisation. En effet GERAM est fondé sur les concepts de trois
architectures (CIMOSA, GRAI-GIM et PERA) et a été définit dans un
but de généricité. GERAM devrait donc être applicable à n‟importe quel
type d‟entreprise [20] .
D‟autres avantages sont également présentés par GERAM (par
rapport aux autres méthodes) :
GERAM permet de présenter et fédérer les différents éléments à
développer pour réaliser l‟intégration d‟une entreprise.
le cadre méthodologique de GERAM couvre l‟ensemble du
cycle de vie non seulement d‟un projet de modélisation mais
surtout GERAM couvre la totalité du cycle de vie d‟une
organisation.
2.2.5 Méthodes orientées « système d’information »
Les entreprises créent de la valeur en gérant leurs Systèmes
d'Information (noté SI) qui représentent l'ensemble de tous les éléments
participant à la gestion, au traitement, au transport et à la diffusion de
l'information au sein de leurs organisations structurelles. La mise en
place d‟un système d‟information se révèle une démarche très difficile et
coûteuse. Il s‟agit dans un premier temps d‟étudier les différents
secteurs fonctionnels d'une entreprise (achat, production, administration,
ventes, maintenance, etc.) afin d‟aboutir à une structuration de ces
activités et à une capitalisation de l'ensemble de ces informations
échangées permettant ainsi d'en améliorer ses performances et son
évolutivité.
Il existe plusieurs méthodes d'analyse et de conception comme MERISE,
SADT, OSSAD ou UML. Les trois premières méthodes représentatives
de la conception du système d‟information dans une logique séparant
données et traitements ont été utilisées dans des projets de grande
ampleur de refonte d'un existant complexe ou le développement d‟un
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
17
nouveau système. La méthode UML en revanche respecte une logique
orientée objet et encapsule données et traitement dans des composants.
La méthode SADT (Structured Analysis and Design Technique) [22] est
une méthode graphique établie par Douglas T.Ross (Softech) vers 1974.
SADT distingue deux types de modèles : les actigrames qui représentent
les activités ou traitements du système modélisé et les datagrames,
représentant les données du système modélisé. SADT est basée sur le
principe de décomposition hiérarchique et structurée des fonctions de
l‟entreprise qui sont définies en termes d‟activité. Une activité peut être
considérée comme une fonction de transformation d‟entrées
(information ou matière) en sorties (informations ou matières) voir la
figure 5. Cette vision permet donc d‟agréger ces différentes vues.
Figure 5 : La modélisation d‟une activité
L‟exécution de l‟activité est déclenchée par un (ou plusieurs)
contrôle(s). La figure 6 représente une activité, les relations d‟une
activité avec les autres activités au moyen de flèches. Les flèches entrant
par le côté gauche du rectangle présentent les entrées de l‟activité, les
flèches sortant par le côté droit du rectangle représentent les sorties de
l‟activité. Les flèches entrant par la base du rectangle présent les
mécanismes utilisés par l‟activité (les ressources nécessaires au
déroulement de l‟activité. Enfin, les flèches entrant par le haut de
rectangle présent les contrôles de l‟activité.
En revanche, la méthode MERISE [23] [24,25] qui a été conçue pour
réaliser la conception et la mise en œuvre des systèmes d‟information
s‟appuie d‟une part sur la séparation des données et des traitements et
d‟autres parts sur l‟organisation de différents points de vue (conceptuel,
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
18
logique et physique). Basée sur la proposition du modèle
entité/association, la méthode MERISE, est très employée en France.
Cette approche entité / association a largement été diffusée à l‟échelle
mondiale par Peter CHEN. La méthode MERISE propose une démarche
d‟ingénierie des systèmes d‟information couplant approches bottom-up
et top-down : l‟étude de l‟existant doit permettre de remonter du niveau
physique (implémentation) jusqu‟à la construction d‟une vision
conceptuelle qui est ensuite améliorée. Une fois défini conceptuellement
les modèles de données et traitement, ceux-ci sont ensuite transformés
pour aboutir aux modèles physiques d‟implémentation.
Le niveau conceptuel permet la description de l‟entreprise
(objectifs généraux et contraintes). Il apporte la réponse à la
question “quoi“ (aspect fonctionnel) et représente le niveau le
plus stable du système-entreprise.
Le niveau organisationnel répond aux questions “ qui, où et
quand ?“. il décrit la structure à mettre en place pour satisfaire
les objectifs décrits au niveau précédent et représente un
deuxième niveau de variabilité du système.
Le niveau physique définit les moyens techniques à mettre en
œuvre pour réaliser le système d‟information. Il répond à la
question “ comment ?“.
Cette méthode initialement définie pour les grands systèmes a ensuite
été étendue pour y intégrer différentes évolutions technologiques.
La méthode OSSAD (Office Support System Analysis and Design) [26]
est une méthode de modélisation du système d‟information née dans le
contexte d‟un projet Européen ESPRIT (European Strategic Programme
for Research in Information Technology). Elle fonctionne suivant deux
niveaux :
Le modèle abstrait (MA) a comme objectif de formaliser les
caractéristiques stables et durables du système. Dans ce
modèle, on trouve des concepts qui sont liés à l‟activité. Il
s‟agit des concepts de Fonction (nom donnés aux processus),
de l‟organisation (exemple : marketing, production), de Sous-
fonction (sous processus) et d‟Activité. Notons que les
fonctions ou sous-fonctions échangent des messages qui sont
associés au concept de paquet d‟informations.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
19
Le modèle descriptif (MD) décrit la façon pratique dont le
travail est (ou sera) fait. Il propose les Rôles qui sont
l‟ensemble des Tâches/responsabilités confiées à une personne
: c‟est la “fonction“ professionnelle de l‟individu. Les Acteurs
sont des personnes remplissant un ou plusieurs Rôles. Les
unités sont des regroupements de rôles sur la base de
responsabilités identiques ou partagées.
Ces trois méthodes représentatives d'analyse et de conception
s‟articulent principalement autour de deux axes séparés à savoir les
modèles de données et les modèles de traitements (ou les activités).
Cette distinction entre les données et les activités nécessitent une
gestion particulière pour maintenir la cohérence entre les activités et les
données manipulées par ces activités. Cette gestion est fastidieuse
lorsque le métier d‟une entreprise évolue face aux changements
organisationnels, économiques ou technologiques.
De manière orthogonale, la méthode UML propose une stratégie de
modélisation orientée objet. L‟avantage de cette approche est
d‟encapsuler les données et les opérations qui les traitent sous forme de
classes. Ces classes représentent des objets métiers ayant un sens pour
des acteurs de l‟entreprise. Le modèle des objets métier, qui est
constitué d'un ou plusieurs classes (diagrammes de classe en UML), est
de très haut niveau par rapport au système d'information et permet de
donner une vision plus synthétique. Enfin, la large variété des modèles
proposés par UML permet d‟appréhender à la fois une description
statique portant sur les diagrammes de classes, de composants…
associés à l‟organisation effective de la solution et une vision
dynamique intégrant des cas d‟usage (les « use case »), l‟organisation
temporelle des échanges entre composants, une vision à base
d‟automates à états finis… En outre, les possibilités d‟instanciation et
d‟héritage entre classes permettent de synthétiser les descriptions et
améliorer la réutilisabilité.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
20
2.2.6 Conclusion
Comme nous venons de le voir, différentes méthodes de modélisation
d‟entreprise ont été proposées depuis les années 80. L‟organisation
d‟une entreprise regroupant différentes facettes, plusieurs méthodes
peuvent être nécessaires pour couvrir l‟ensemble des besoins. Ainsi, le
cadre de modélisation GERAM permet de les fédérer pour aboutir à une
vision la plus exhaustive possible tout en préservant la cohérence
globale. L‟ensemble de ces méthodes repose sur une conduite de projet
dans une logique « top-down » de construction de modèle et de
déploiement de la solution. Pour pallier les problèmes de complexité et
de lourdeur de la démarche de modélisation, ces méthodes reposent
toutes sur deux éléments invariants : l‟instanciation de modèles
générique et la transformation de modèles pour permettre d‟aboutir à
une solution déployable.
Si la modélisation d‟entreprise reste fondamentale pour décrire
globalement l‟entreprise et son organisation, la construction du système
d‟information (conditionnant fortement la structuration de l‟entreprise)
fait appel à d‟autres stratégies de modélisation se focalisant sur les
processus à mettre en œuvre et sur l‟organisation des données. Toutefois
ces méthodes spécialisées restent également complexes et lourdes à
mettre en œuvre.
Or l‟organisation collaborative repose sur la mise en place (rapide si
possible) d‟un processus commun permettant d‟aboutir au résultat global
souhaité objet de la collaboration et sur l‟organisation du support
technologique à la collaboration (i.e. modélisation du système
d‟information et organisation des interconnexions entre processus
différents). Pour cela, nous présenterons les caractéristiques principales
des approches basées processus dans la section suivante.
2.3 Approche basée processus
Le processus métier est au cœur de la collaboration entre les
entreprises : en effet, on peut le considérer comme un moyen pour
atteindre l‟objectif commun (à savoir répondre aux besoins du client).
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
21
Nous nous intéresserons d‟abord aux définitions usuelles d‟un processus
afin d‟en extraire les éléments de modélisation. Ensuite, nous
présenterons les différents types de processus. Une introduction sur les
technologies de workflow, qui permettent une mise en œuvre rapide des
modèles de processus sera ensuite présentée. Enfin, nous conclurons
cette section en repositionnant le processus dans un cadre plus large de
modélisation.
2.3.1 Eléments caractéristiques d’un modèle de processus
Différentes définitions du processus sont proposées dans la
littérature. Par exemple, [7] (p 9) définit le processus métier comme
« un ensemble de plusieurs activités reliées les unes aux autres pour
atteindre un objectif ». Cette définition, basée uniquement sur le but à
atteindre, peut être précisée par celle proposée par [8] en intégrant les
moyens nécessaires pour atteindre ce but : un processus est défini
comme un ensemble d‟activités ordonnées selon un ensemble de règles
procédurales pour réaliser un objectif précis au sein d‟une organisation
et réalisé par un groupe de personnes (par exemple, dans une entreprise).
Une vision plus « systémique » conduit à appréhender la notion de
processus comme un système composé d‟ensemble d‟éléments (activités,
rôles, acteurs, ressources, entrées, résultats…) qu‟il faudra prendre en
compte dans la modélisation du processus métier. On notera que ces
définitions sont essentiellement « descriptive » [9]. Or un processus peut
aussi être considéré comme un système dynamique orienté vers la
réalisation d‟un objectif [10].
Dans la figure 6 ci-après nous présentons une synthèse de ces
visions, intégrant à la fois les éléments statique (acteur, rôle, ressource,
activité…), la partie dynamique du système (événement, transition…) et
leur relations.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
22
Figure 6 : Les éléments principaux pour la modélisation d‟un processus métier
[10] page 16.
Le concept d‟activité peut être défini comme unité de
décomposition fonctionnelle du processus [10]. Les activités décrivent
comment l‟objectif d‟un processus (décrit de manière détaillée) pourra
être atteint.
Les concepts de rôle et d‟acteur sont fortement liés. On notera
d‟ailleurs que certains langages de modélisation n‟ont qu‟un seul
concept pour ces deux notions. Un acteur est un élément actif chargé
d‟une ou plusieurs activités dans le processus ([10] page 3). Un «
élément actif » peut être une personne physique, une entité
organisationnelle ou une machine. Ce sont les acteurs qui assurent
l‟exécution des travaux d‟un processus. Le concept d‟acteur permet de
faire apparaître les choix d‟automatisation (automate et / ou être
humains) et d‟organisation à plusieurs niveaux (individu, service,
département, etc.). Pour pouvoir être chargé d‟une ou plusieurs activités,
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
23
l‟acteur doit être capable d‟exécuter les travaux associés ou d‟en porter
la responsabilité.
Un rôle est un regroupement d‟activités (regroupement parfois
limité à une seule activité ou bien intégrant différentes activités
associées à des processus différents) données à un acteur unique. Le rôle
représente le comportement attendu de l‟élément actif à qui on a attribué
les activités associées à ce rôle.
Une transition exprime une contrainte d‟enchaînement entre
deux activités. On peut la considérer comme un lien orienté entre ces
activités. L‟ensemble des transitions d‟un processus représente
l‟ordonnancement de ses activités. Le concept de transition est utilisé
lorsque l‟on veut représenter un enchaînement de plusieurs activités. Si
la transition n‟est pas soumise à une condition, l‟enchaînement est
mécanique : la fin d‟une activité déclenche la suivante.
Une transition peut être soumise à condition. Elle peut être
utilisée simultanément avec ou à la place de concepts d‟événement,
d‟entrée et de résultat. Une condition peut être associée à une transition
et dans ce cas l la transition n‟est réalisée que lorsque la condition est
remplie. Cela signifie que la dernière tâche de l‟activité située au début
de la transition analyse l‟expression associée à la condition pour
déterminer si le passage à l‟activité suivante va s‟effectuer. Les
conditions sur les transitions permettent de représenter des chemins
alternatifs dans le déroulement du processus, ainsi que des boucles
d‟une activité ou un ensemble d‟activités tant qu‟une condition est
réalisée.
Une tâche est le plus petit élément de décomposition d‟une
activité. Lorsque l‟activité est décomposée, une activité peut être définie
comme un ensemble de tâches. La tâche n‟a pas d‟autonomie par rapport
à l‟activité dont elle dépend. Elle peut toutefois être soumise à une
condition d‟activation.
Une activité est activée par un événement. Cet événement
n‟implique aucun acteur de l‟activité et ne consomme aucune de ses
ressources. L‟événement métier “ déclencheur“ qui est à l‟origine de
l‟exécution du processus peut être un échange avec le monde extérieur
(par exemple : l‟événement “envoi d‟une lettre au client“ réclamant des
informations complémentaires pour traiter la demande est un événement
en sortie d‟une activité de l‟entreprise et sera « déclencheur » pour une
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
24
activité du client alors que l‟événement “réception de la réponse du
client“ est un événement déclencheur pour une activité de l‟entreprise
considérée). Un événement est toujours associé à au moins une activité
sur laquelle il agit. Un même événement peut agir sur plusieurs
activités : cela permet d‟activer des activités pouvant se dérouler en
parallèle. A l‟inverse, plusieurs événements peuvent être associés à la
même activité : celle-ci est alors dotée d‟une règle de synchronisation
qui indique si les événements doivent être ou non synchronisés.
On notera qu‟une condition peut être associée à un événement.
Cela signifie que certaines tâches sont implicites dans la description de
l‟activité. Ces tâches filtres analysent l‟expression conditionnelle
attachée à l‟événement pour décider de la prise en compte ou non de cet
événement. S‟il est interrupteur, cela signifie qu‟une tâche de
surveillance des événements peut arrêter le déroulement de l‟activité,
après réalisation éventuelle d‟une tâche spécifique d‟interruption,
soumise à une même condition. Si l‟événement est modificateur, il agit
sur le déroulement de l‟activité ; la condition se retrouve alors sur une
ou plusieurs tâches qui ne seront exécutées que si la condition est
remplie (ou à l‟inverse n‟est pas remplie).
Le résultat est un produit issu de l‟exécution d‟une activité. Il
est associé à l‟achèvement de l‟activité. Une activité peut produire
plusieurs résultats. Un résultat peut être de différentes natures : matériel,
documentaire, informationnel. Il peut également correspondre à un
changement d‟état d‟un élément du système.
Une ressource est un élément (matériel, documentaire,
informationnel, logiciel…) utilisé pour l‟exécution d‟une activité.
Selon la nature de l‟activité, plusieurs types de processus
peuvent être organisés. Le niveau de description a priori des activités va
dépendre directement du niveau de « répétitivité » de ces activités. Ceci
conduit donc à différents niveaux de modélisation. Dans le paragraphe
suivant nous présentons une synthèse sur les différents types de
processus métier.
2.3.2 Typologie des processus
D'après [9][11] les processus peuvent être classés selon quatre
catégories complémentaires :
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
25
1. Le processus d’administration : Il gère des processus
administratifs dont les règles de déroulement sont bien établies et
connues par chacun au sein de l‟organisation. Il est caractérisé par la
circulation de documents/formulaires à travers l‟organisation (par
exemple, demande de remboursement de frais de missions, demande
d‟inscription à une formation, etc.). De ce fait, il aide à transformer la
circulation de documents papiers en circulation de documents
électroniques. Les processus d‟administration ne sont pas d‟une très
grande valeur ajoutée pour une organisation d‟une part, et d‟autre part,
ils sont assez statiques si l‟on considère leur degré de répétition élevé.
2. Le processus de production : Il gère les processus de
production dans les entreprises. Il constitue généralement le cœur de
métier de l‟entreprise et la valeur ajoutée de l‟entreprise dépend
énormément de la qualité de ce processus. C‟est l‟efficacité de ce type
de processus qui assure à l‟entreprise des avantages compétitifs (par
exemple, processus de livraison pour une entreprise de vente en ligne,
processus de gestion des prêts dans une banque, processus de gestion
des demandes des dommages et intérêts au sein d‟une compagnie
d‟assurance, processus de gestion de la chaîne de production chez un
constructeur automobile, etc.).
3. Le processus de collaboration: Il gère la coordination au
sein du groupe lors d‟un projet commun (par exemple, conception
logicielle, réalisation d‟un plan de bâtiment, montage d‟un projet,
réalisation d‟une œuvre artistique, etc.). Il est caractérisé par une forte
valeur ajoutée au sein de l‟organisation, mais par un faible degré de
répétition. Il se distingue des autres processus par le grand nombre de
participants qui interagissent en permanence pour la réalisation du projet
en commun. La complexité de ce type de processus réside dans la
difficulté de modélisation de la méthodologie de travail à suivre surtout
qu‟il faut prévoir, pendant le déroulement du processus, l‟arrivée de
nouveaux participants, la création de nouvelles tâches à intégrer et à
gérer, etc. Il s‟agit par exemple, d‟un processus de coordination
apprenant-apprenant et apprenant-enseignant dans un environnement
d‟apprentissage coopératif (Computer Supported Cooperative Learning
ou CSCL), etc.
4. Le processus ad-hoc : Il représente une classe de processus
destinés à des situations spécifiques où la logique de déroulement à
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
26
suivre est définie durant l‟exécution. Il forme une solution hybride
rassemblant des caractéristiques d‟administration, de production et de
collaboration. Ce type de processus gère des situations uniques ou
causées par des exceptions. Généralement, ce type de processus ne
possède pas de structure prédéfinie, l‟étape ultérieure à suivre est
déterminée essentiellement par les participants du processus. Par
exemple, si un coordinateur envoie une note d‟information aux membres
de son équipe, ces derniers ont le choix de faire ce qu‟ils veulent avec
cette note. Ils peuvent éventuellement la renvoyer à d‟autres personnes
qu‟elle peut intéresser (par exemple, par messagerie électronique, dans
les newsgroups, au sein d‟outils groupware, etc.).
Comme on peut le constater, ces différents types de processus
vont nécessiter des descriptions et modèles plus ou moins complexes . Ils
impliquent des stratégies de gestion adaptées mais aussi le recours à des
outils supports différents. Dans la suite, nous présentons rapidement les
stratégies de gestion de processus métier.
2.3.3 Gestion de processus métier
Le concept de processus métier est souvent associé au concept
de Gestion des processus métier (ou BPM: Business Process
Management). Le BPM consiste à modéliser des processus métier pour
donner une vision globale sur ces processus et de leurs interactions afin
de pouvoir les optimiser dans la mesure possible [12][35].
Dans le cadre du BPM, la gestion de processus métier comporte
essentiellement trois étapes: l‟identification des processus; la description
(modélisation) des processus en vue de leur mise en œuvre; le pilotage
du processus en vue de son amélioration.
- L‟identification des processus consiste à répertorier les
processus de l‟entreprise en distinguant les processus liés au cœur de
métier et les processus de support. Cette identification porte aussi sur la
nature du processus (processus manuels ou informatisables).
- La description (modélisation) des processus permet de
formaliser le processus avec des outils spécifiques de modélisation ou de
BPM. Deux approches complémentaires peuvent être appliquées :
approches descendante ou ascendante. L‟approche descendante part du
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
27
général vers le plus détaillé par raffinements successifs. Le processus est
d‟abord découpé en sous-processus et qui eux-mêmes sont découpés
progressivement en activités, tâches et actions. Une approche ascendante
part des parties de processus déjà modélisées, isolées comme des
composants pour reconstruire un processus global par assemblage de
composants de processus.
- Le pilotage des processus est le passage obligé de leur
amélioration. Il passe par la recherche de données pertinentes
d‟exécution des processus, leur enregistrement dans une base de données
et le calcul d‟indicateurs d‟analyse et de performance permettant
d‟apprécier leur pertinence.
- L‟orchestration des échanges interentreprises est une gestion
des flux de messages qui gère le protocole de la transaction électronique
entre les systèmes d‟information des entreprises impliquées.
- La gestion de processus métier permet d‟orchestrer les
interventions de personnes de l‟organisation et de logiciels du système
d‟information dans la réalisation d‟un processus métier complet de
l‟entreprise.
Ainsi, les activités de BPM concernent l‟ensemble du cycle de
vie d‟un processus métier, depuis son identification jusqu‟à son
exécution en passant par les activités de modélisation. Pour ce dernier
point, on peut recourir à une méthode « spécialisée processus » comme
ARIS que nous présentons dans la section suivante.
2.3.4 ARIS : une méthode de modélisation orientée processus
La méthode ARIS (Architecture of integrated Information
Systems) [16][41] est un framework pour le développement et
l‟optimisation des systèmes d‟information intégrés et permet de servir
de cadre pour la création, l‟analyse et l‟évaluation des processus de
gestion.
ARIS permet la description des processus métier et permet de
réduire leur complexité en les décomposant selon différentes vues
(fonction, données, organisation et contrôle voir figure 7) et trois
niveaux de modélisation (modèle conceptuel, modèle technique et
implémentation voir figure 8).
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
28
Figure 7 : l'architecture d'ARIS [41] page 40
Figure 8 : Aris les niveaux de modélisation pour le processus de
l‟entreprise [41] page 3
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
29
Les différents niveaux peuvent être décrits comme suit :
- Niveau 1 : ingénierie du processus : Le processus
métier est modélisé selon le modèle organisationnel.
ARIS offre un cadre pour représenter tous les
aspects du processus métier, y Compris
l‟amélioration continue.
- Niveau 2 : planification et contrôle de processus. Le
processus métier est planifié et contrôlé selon les
méthodes d‟ordonnancements en prenant en compte
les contraintes de capacité et l‟analyse de coût.
- Niveau 3 : contrôle du Workflow. Les objets à
traiter sont transférés d‟un poste de travail au
suivant. Dans le cas où ces objets sont des
documents électroniques, les systèmes de gestion de
Workflow s‟occupent de ces transferts.
- Niveau 4 : systèmes d‟application. Les fonctions
impliquées dans un processus métier sont exécutées
via les systèmes d‟application, depuis les systèmes
d‟édition simples jusqu‟aux logiciels complexes
orientés objets de business.
Dans le cadre plus particulier des processus inter-entreprises, le
workflow représentant le processus commun est utilisé pour
interconnecter des processus propres à chaque entreprise associés à des
tâches à réaliser par l‟un ou l‟autre des partenaires. Cette interconnexion
pose un évident problème d‟organisation des communications et
échanges entre processus. Ce point est détaillé dans la section suivante.
2.3.5 Stratégies d’interconnexion de processus
L‟interconnexion des processus est un problème qui a été déjà
étudié depuis plusieurs années. L‟EDI (Electronic Data Interchange): est
défini comme un moyen d‟échange les données informatisées et les
documents commerciaux structurés entre différentes organisation [42].
L‟échange de données informatisées peut être utilisé pour transmettre de
manière dématérialisée des documents tels que des demandes d‟achat,
des avis d‟expédition et d‟autres types de correspondance commerciale
standardisée entre partenaire commerciaux. Il permet aussi de
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
30
transmettre des informations financières et des paiements sous forme
électronique.
Le standard principalement mis en œuvre dans le cadre de
l‟EDI est EDIFACT [43][44]. C‟est une norme de l‟UN/CEFACT
(Nations Unies) définissant les messages échangés dans les domaines du
commerce international, des achats, des transports, de la santé, etc.
Malgré les avantages liés à la dématérialisation, les
technologies traditionnelles d‟EDI sont considérées comme coûteux non
seulement dans le déroulement des échanges mais aussi pour ce qui
concerne les aspects de communication car ils recouraient fréquemment
à des Réseaux à Valeur Ajoutée (RVA “Value-Added Network VAN“).
Ceci a donc limité l‟adoption de cette solution, notamment par les
petites et moyennes entreprises.
Une stratégie plus légère consiste à construire de manière ad
hoc des modèles électroniques de collaboration permettant à différents
partenaires d‟interconnecter leurs processus. Pour cela, on peut utiliser
le langage XML (eXtensible Markup Language) [46] [47] pour définir
des échanges de documents structurés. Une solution basée sur XML est
moins difficile et moins coûteuse qu‟une solution EDI classique . XML
supporte, la structuration de données complexes en s‟appuyant sur des
principes simples et clairs qui sont :
La lisibilité à la fois par les machines et par les utilisateurs, la
définition sans ambiguïté du contenu et la structure d‟un document, la
séparation entre structure du document et présentation du document
constituent les principaux avantages de cette approche. Compte tenu de
son ouverture et des possibilités d‟extension de modèles, ce langage est
le standard le mieux standard adapté aux besoins actuels
d‟interopérabilité entre les processus d‟entreprise. Toutefois, si deux
processus utilisent XML, ils peuvent analyser les messages transmis,
mais cela n‟assure pas que le processus récepteur analyse correctement
les messages.
Ceci impose donc de revoir l‟organisation des processus et de
leur communication pour intégrer les contraintes de traitement sur les
données échangées dès la conception de ces processus. Ceci conduit de
facto à une multiplication des canaux de communication et introduit un
couplage fort entre les processus.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
31
De manière à permettre la communication entre applications et off rir un
couplage lâche, on peut utiliser un middleware (intergiciel) gérant
différentes interfaces. Les systèmes de type EAI (Entreprise Application
Integation) [45] offrent un ensemble de connecteurs permettant d‟éviter
l‟établissement de relations point à point spécifiques entre applications et
ainsi éviter le syndrome « spaghetti ».
D‟autres middleware sont orientés messages (Message Oriented
Middleware – MOM). Le message représente un contrat entre le serveur
qui gère le processus et le client invoquant les services du processus.
Ainsi, les interfaces des processus de l‟entreprise sont définies par ces
messages. L‟application cliente ne communique plus avec le serveur
mais directement avec le middleware. Ceci transforme donc le problème
d‟interconnexion entre processus en interconnexion du serveur et du
client avec le MOM. Ainsi, le client n‟a plus à gérer les informations du
module serveur (par exemple localisation, configuration, interface).
Il existe plusieurs plates-formes qui supportent cette stratégie
comme par exemple Microsoft MSMQ (Microsoft Message Queue
Server) ou le service d‟événement de CORBA (CORBA Event Service).
Une autre stratégie consiste à réorganiser le système
d‟information de l‟entreprise pour mettre en œuvre une architecture
orientée service. Outre un couplage lâche par échange de messages, ce
type d‟architecture présente également l‟avantage de séparer l‟interface
de l‟implémentation et offre plusieurs interfaces standardisées. Nous
détaillons cette approche dans la section 2.4.2.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
32
2.3.6 Conclusion
Comme nous l‟avons vu section 2.3, l‟organisation de
collaboration repose largement sur l‟organisation d‟un processus
commun. Ce processus collaboratif est organisé comme l‟interconnexion
des différents processus des entreprises partenaires. Cette stratégie
d‟analyse nous a conduit d‟abord à présenter la méthode ARIS, méthode
largement orientée processus avant d‟introduire les besoins de
communication entre processus. Si cette vision semble plus légère que
celle introduite par les stratégies de modélisation traditionnelles et
permet d‟aboutir plus rapidement à la génération d‟un système de
workflow support, le problème d‟interconnexion impose d‟utiliser une
stratégie de mise en œuvre recourant à des standards pour garantir
l‟interopérabilité technologique. Pour cela, les architectures orientées
services peuvent apporter une réponse.
2.4 Architecture orientée service : une réponse à l’interopérabilité
technologique
D‟après [48], un service peut être défini de la manière suivante:
“Services are autonomous platform-independent computational entities
that can be defined, published, discovered, selected, composed,
managed and programmed using XML artefacts for the purpose of
developing distributed interoperable applications“
Un service est un composant logiciel qui est représenté par
deux éléments séparés : son interface qui permet de définir les modalités
d‟accès au service (nom et paramètres des opérations publiques
définissant les signatures des opérations) et son implémentation. Les
éléments de l‟interface de chaque service sont : le nom du service, les
données d‟entrée et de sortie et les opérations. Les services sont
interconnectés via l‟échange de messages.
L‟ensemble des opérations associées à un service présente la
vue dynamique de ce service. Ces opération sont publié pour que être
retrouvée, composée puis invoquée.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
33
Chaque service peut être composé avec un autre service selon
une stratégie de composition séquentielle ou parallèle [49]. Dans une
logique de composition séquentielle, les services sont ordonnés et
présentés de manière séquentielle. Dans une logique de composition
parallèle, les services sont exécutés en parallèle
De manière plus spécifique, un Service Web est un système
logiciel identifié par une adresse URL, dont les interfaces publiques sont
définies et décrites à l'aide de XML. Sa définition peut être découverte
par d'autres systèmes logiciels. Ces systèmes peuvent alors interagir
avec le Service Web d‟une manière prescrite par sa définition, utilisant
les messages basé sur XML et transmis par les protocoles d'Internet [50]
page 7.
Le modèle d‟architecture à base de service Web se compose de
trois entités, le fournisseur de services, l‟annuaire de services et le
demandeur de services. La figure 9 représente une modèle de service
Web :
Figure 9 : modèle de Service Web [51] page 5
Le fournisseur de services crée ou offre simplement le service
Web. Le fournisseur de services doit décrire le Service Web dans un
format standard, qui est XML et publie cette description dans un
annuaire de services.
L‟annuaire de service contient des informations
supplémentaires sur le fournisseur de services, telles que l'adresse et des
détails techniques sur le service.
Le demandeur de service recherche l'information de l‟annuaire
et utilise la description de service obtenue pour se « lier » au service
(“Bind“) à et à invoquer le service Web.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
34
Les opérations de publication, recherche et liaison de services
permettent ainsi de supporter les communications entre applications
fonctionnant sur différentes plates-formes et écrites en différents
langages de programmation,
Le langage de description de service Web WSDL (Web
Services Description Language) utilise le format de XML pour décrire
les méthodes fournies par un Service Web. Cette description inclut aussi
les paramètres d'entrée et de sortie, les types de données et le protocole
de transport, qui est généralement HTTP. Le standard UDDI (Universal
Description Discovery and Integration ) permet de publier les services et
les informations concernant le fournisseur de service. Cet annuaire
représente une opportunité pour le demandeur de service pour trouver le
fournisseur de service et obtenir les détails sur le service Web.
Le protocole SOAP est utilisé pour l'échange de l'information
au format XML parmi les entités impliquées dans le modèle de service
Web.
Dans la suite de cette section nous présenterons les différents
standards permettant d‟atteindre un bon niveau d‟interopérabilité pour
les services.
2.4.1 Description de service
Afin de pouvoir interconnecter des services plusieurs formats
existent afin de décrire l‟interface de service (comme WSDL (Web
Service Definition Language)) ou de découvrir automatiquement un
service (comme OWL-S).
WSDL [52] est un format de description de l‟interface des services Web
basée sur XML. Le document WSDL définit les services comme des
collections de point finaux (points d‟entrée “endpoints“) de réseaux
aussi appelés “ports“. Via ces ports les services communiquent par
échange de message. Chaque port est associé à une liaison (binding)
spécifique.
C‟est la liaison (binding) qui détermine comment on peut naccéder à
l‟opération en utilisant un protocole de communication particulier
(SOAP, http, …).
Chaque opération est constituée d‟un ensemble de messages d‟entrée et
de sortie. Chaque message contient une ou plusieurs données définies
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
35
par des types. Une liaison (binding) établit une correspondance entre le
protocole utilisé pour communiquer, le port et l‟opération.
La description d‟un service web grâce à WSDL est montrée dans la
figure 10.
Figure 10 : La description d‟un service web grâce à WSDL [53] p86
Du fait du développement du web sémantique, un annuaire de
type UDDI ne suffit plus pour faire une sélection pertinente des
services. Pour cela, OWL-S (Web Ontology Language for Services) [54]
définit une ontologie de décrire les services en s‟appuyant sur le
framework OWL. Ce langage, standardisé par W3C est issu du
programme DAML-S du DARPA.
L‟initiative OWL-S issue du projet américain DARPA / DAML
vise à fournir une ontologie de service web basé sur OWL. Cette
description doit permettre d‟améliorer la découverte automatique de
services Web, leur invocation, composition… ainsi que la surveillance
de leur exécution.
Cette ontologie permet de fournir des informations sur l‟objet
du service et sur son fonctionnement. Pour ce qui concerne le premier
point, l‟accent est mis sur ce que fournit le service et ce qu‟il requière. Il
s‟agit majoritairement de son interface. Le deuxième point concerne le
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
36
comportement du service. Il se focalise sur la description des opérations
et des chemins possibles lors de l‟exécution.
Pour cela un service est défini selon 3 facette complémentaire
(service profile, service model et service grounding voir figure 11) que
nous détaillerons ci-après.
Figure 11 : Ontologie OWL-S
Le “ ServiceProfile“ fournit des informations sur un service qui peut
être utilisé par un agent pour déterminer si le service répond à ses
besoins, et s'il satisfait des contraintes telles que la sécurité, la localité,
l'accessibilité, etc.
Le profil d‟un service “ serviceProfiles “ se compose de trois types
d'information : une description du service et le fournisseur de services ;
le comportement fonctionnel du service; et plusieurs attributs
fonctionnels conçus pour l'automatisation de sélection.
Le profil inclut une description de haut niveau sur le service et son
fournisseur, qui typiquement serait présentée aux utilisateurs lors de la
navigation le registre de service.
Le ServiceModel permet à un agent : (1) d‟effectuer une analyse plus
détaillée pour savoir si le service répond à ses besoins ; (2) de composer
des descriptions de service pour exécuter une tâche spécifique ; (3) de
coordonner les activités des différents agents ; et (4) contrôler
l'exécution du service.
Les services sont accessibles au Web par des programmes ou
des périphériques. Leur opération est décrite en termes de modèle de
processus.
Les deux composants principaux du modèle de processus sont
“Process Ontology“ qui décrit un service en termes de ses entrées,
sorties, conditions antérieurs, effets, et “Process Control Ontology“ qui
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
37
décrit chaque processus en termes de son état, y compris l'activation,
l'exécution, et l'achèvement.
Le ServiceGrounding spécifie comment accéder aux détails de
service avec des formats de protocole et de message. Le
Servicegrounding présente comment invoquer le service. Dans DAML-
S, le ServiceProfile et le ServiceModel sont conçus comme des
représentations abstraites ; seulement le ServiceGrounding traite le
niveau concret de la spécification.
Dans la suite nous présenterons comment les services
échangent de messages grâce le protocole SOAP.
2.4.2 Communication entre service
SOAP (Simple Object Access Control) [53] [55] est un
protocole de communication et d‟échange de messages entre les Services
Web fondé sur XML. Le protocole SOAP permet d‟invoquer un objet
distance en communiquant les informations nécessaire à l‟appel (Nom
de la méthode et sa signature dans un message au format XML
communiqué via http). La réponse à la requête est aussi renvoyée
encapsulée au format XML.
Un message SOAP est une structure très simple qui comporte
une enveloppe (envelop) qui est la partie obligatoire du message et
contient le nom du message, l‟entête (header) est une partie optionnelle
utilisée lorsque le message doit être traité par plusieurs intermédiaires et
le corps du message. Le corps du message est une partie obligatoire et
peut contenir un ou plusieurs autres corps contenu dans le même
message. Il contient les données spécifiques à l‟application. Il permet
d‟échanger l‟information avec le destinataire final du message.
.
2.4.3 Publication de service
Universal Description Discovery and Integration (UDDI) est un
protocole qui permet non seulement la publication et l‟interrogation des
services Web mais aussi de découvrir des informations sur une
entreprise et ses services web. Le composant principal d‟UDDI est son
registre (figure 12. Il contient des documents XML où figurent des
informations sur les entreprises et les services publiés. L‟annuaire UDDI
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
38
facilite la localisation d‟un service web et l‟agrégation des services web
émanant d‟entreprises différentes.
Figure 12 : Mécanismes d‟accès aux services fournis par un UDDI
Registry [51] page 117.
UDDI encode de trois types d'informations sur les services Web :
1. Les pages blanches : elles comportent les informations sur les
entreprises et contiennent des informations sur le fournisseur de service
telles que le nom, les coordonnées (adresses), etc.
2. Les pages jaunes sont composées d‟informations permettant de
classifier l‟entreprise. Ces informations s‟appuient sur des standards de
classification industrielle normalisée.
3. Les pages vertes fournissent des informations techniques concernant
les services publiés. Ces pages contiennent des informations sur les
processus métier, des descriptions de service, et des informations de
liaison sur les services.
L‟UDDI comporte quatre structures de données définies sous forme de
schéma XML : BusinessEntity, businessService, bindingtemplate et
tmodel :
La structure BusinessEntity représente les informations sur
l‟entreprise qui offre les services dans l‟annuaire UDDI.
Le businessService inclut les informations relatives aux services
offerts par l‟entreprise.
BindingTemplate définit les informations concernant le lieu du
service, le point d‟entrées du service (URL) et comment accéder
au service (protocole d‟accès).
tModel : comprend l‟information concernant le mode d‟accès au
service.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
39
La figure 13 représente les principaux éléments et relations entre entités
du modèle d‟information UDDI sous forme de diagramme de classes
UML.
Figure 13 : Modèle structurel des données de UDDI Registry [51] page
119
Nous avons définit dans les sections précédentes que les services
communiquent en utilisant différent standards pour décrire leurs
interfaces et encoder leurs messages comme les protocoles SOAP,
UDDI, et WSDL pour réaliser l‟interconnexion. Ces standards utilisent
XML. Mais pour réaliser une interconnexion cohérente entre l‟ensemble
de services il faut bien définir l‟enchaînement des services selon un
canevas prédéfini afin de les composer dans un processus métier pour
répondre à des demandes qu‟un seul service ne peut pas la réaliser.
2.4.4 Description de la partie opérative des services
La prise en œuvre d‟un processus via des services web suppose non
seulement de pouvoir retrouver les services répondant aux besoins, les
composer dans une chaîne cohérente mais aussi de pouvoir définir
précisément le comportement de ces services. Comme nous l‟avons vu
précédemment, ces services interagissent en échangeant des messages
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
40
[Plusieurs standards proposent des langages permettant de décrire la
partie opérative des processus et des services [56].
Au niveau du processus, BPML (Business Process Markup language)
[57], il est destiné à la modélisation des processus métier. Il définit un
modèle formel pour l‟expression de processus exécutables ou abstraits
supports du processus métier.
BPEL (Buiness Process Execution Language) [58] est un standard à
permettre la description de l‟enchainement des actions pour réaliser un
processus en invoquant des entités comme des services. BPEL fournit
une sémantique riche qui permet d‟exprimer le comportement de
processus métier. Ce langage fait suite à des langages comme XLANG
ou WSFL développés par Microsoft ou IBM. WS-BPEL ou BPEL4WS
utilise donc un ensemble de balises pour définir l‟exécution de services.
Dans un scénario typique, le processus BPEL reçoit une requête puis il
invoque alors les services web impliqués et envoie la réponse au
demandeur. Les processus BPEL communiquent avec d‟autres services
web s‟appuient fortement sur la description WSDL.
BPEL introduit des extensions à WSDL qui permettent de spécifier
précisément dans le processus les relations entre plusieurs services web.
Ces relations sont appelées les liens vers des partenaires. La figure 14
montre ces connexions entre un processus BPEL et des services web
(liens vers des partenaires).
Figure 14 : La connexion entre un processus BPEL et des services [59]
page 74.
Tout processus BPEL précise l‟ordre exact dans lequel les services web
participants doivent être invoqués. Cette invocation peut être
séquentielle ou parallèle ou conditionnelle. L‟appel d‟un service peut
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
41
par exemple dépendre d‟une valeur provenant d‟une invocation
précédente.
Un processus BPEL est constitué d‟étapes. Chacune d‟elle est appelée
une activité. BPEL prend en charge les activités élémentaires et les
activités structurées. Les activités élémentaires sont utilisées pour
interagir avec une entité externe pour réaliser des tâches communes.
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.
XLANG est un langage qui a été créé par Microsoft pour l‟orchestration
de service Web [60]. XLANG est déjà implémenté dans le serveur
BizTalk. XLANG définit un langage de description du comportement
individuel d‟un service web qui participe à un processus métier. Il décrit
également comment combiner de tels services web pour produire un
processus métier multi participant Il s‟appuie sur la spécification WSDL
(figure 15) Etendant la description WSDL, XLANG s‟attache à prendre
en compte les fonctionnalités suivantes [60]:
La construction de flux de contrôle séquentiels et
parallèles,
Les transactions longues avec compensation,
La corrélation de messages,
La gestion des exceptions de traitement internes et
externes,
La référence de service dynamique,
WSFL est un langage également basé sur XML permettant de
décrire des orchestrations des services web. Proposé par IBM, WSFL
définit deux formes d‟orchestration de services web [59][61]. Le
premier décrit les processus d‟entreprise comme des chorégraphies des
services web comme XLANG, le second type définit les processus
métier en explicitant les relations producteur/consommateur de message
entre les différents services web constituant le processus global.
Pour illustrer le premier style de composition (processus métier ou
modèle de flux), nous proposons de prendre le cas d‟une entreprise
souhaitant mettre en place une application web pour le traitement de bon
de commande à l‟aide de services web externes et internes déjà
développés. Il s‟agit d‟identifier :
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
42
Les processus élémentaires (par exemple, la vérification du
crédit du donneur d‟ordre, le rejet d‟un bon de commande, le
traitement de la commande, l‟envoi des marchandises, etc.).
Les conditions d‟enchaînement des processus élémentaires,
qualifiées de règles métier dans la terminologie WSFL (tout
d‟abord, vérifier le crédit de l‟acheteur puis, suivant le résultat,
rejeter ou traiter la commande, puis envoyer les marchandises).
Le flot de données à chaque étape (prendre le bon de commande
comme paramètre d‟entrée et le passer à la procédure de rejet ou
de traitement, etc.).
Dans WSFL les étapes du processus sont appelées activités et sont
reliées par des liens de contrôle (passage explicite du contrôle d‟un
processus élémentaire à un autre) et des liens d‟information (passage de
données, avec transformation éventuelle, d‟un processus élémentaire à
un autre). On indique pour chaque activité l‟identité du service web
responsable de son exécution et les opérations à appeler grâce aux
éléments <Export> et <PlugLink>. Les activités sont exécutées sous la
responsabilité d‟un rôle qui les déroule dans un espace de travail
spécifique, appelé lane.
Figure 15 : Le document XLANG [59] page 251
2.4.5 Composition et orchestration de services
Lorsqu‟un service associé à un processus implique l‟interaction avec des
autre services (pour appeler leurs fonctionnalités), on parlera de service
composé ou composite. La composition de services permet de combiner
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
43
les fonctionnalités de plusieurs services dans un même processus métier
afin de répondre à des demandes complexes qu‟un seul service ne peut
pas réaliser. La composition nécessite les étapes suivantes :
Tout d‟abord il faut découvrir les services qui peuvent répondre aux
besoins de la composition. Cette opération de découverte se fait via les
annuaires. Il faut ensuite définir l‟ordre d‟invocation des différents
services et organiser l‟interaction entre les services qu‟on veut
composer : il s‟agit alors d‟orchestration et de chorégraphie [66].
L‟orchestration organise a priori les interactions entre plusieurs services
et organise à l‟avance la gestion des échanges de messages, condition
d‟activation… La chorégraphie quant à elle est réalisée « au fil de
l‟eau » et ne concerne donc qu‟un seul service.
Si on s‟intéresse maintenant au contrôle de l‟exécution, il faut prendre
en compte à la faut la spécification des conditions de coordination et de
gestion de transactions.
La coordination de séquences d'opérations est nécessaire pour assurer
l'exactitude et la cohérence. Pour cela, de nouveaux protocoles et
abstractions sont nécessaires. Afin de fournir des abstractions de
modélisation et de simplifier le développement de services Web,
différents efforts de standardisation ont été menés aboutissant par
exemple à la proposition de WS-Coordination [62] par IBM.
WS-Coordination décrivent un framework pour coordination de service
qui se compose de(figure 16):
Un service d'activation comportant une opération qui permet à
une application de créer un contexte de coordination.
Un service d'enregistrement comportant une opération qui
permet à une application d‟enregistre aux protocoles de
coordination.
un ensemble de protocoles de coordination.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
44
Figure 16 : Le model de coordination [53] page 4
Les applications utilisent le service d'activation pour créer le
contexte de coordination pour une activité. Une fois qu'un contexte de
coordination est défni par une application, il peut alors envoyé par tout
moyen à une autre application. Le contexte contient l' information
nécessaire pour s'enregistrer dans l'activité et spécifier le comportement
de coordination que l'application suivra.
Une application qui reçoit un contexte de coordination peut
utiliser le service d'enregistrement de l'application originale ou peut en
utiliser un qui est spécifié par un intermédiaire. De cette manière une
collection arbitraire de services Web peut coordonner leurs opérations
conjointement.
Outre les problèmes de coordination, l‟exécution d‟un service
composite peut nécessiter un temps long et des échecs peuvent survenir
lors de l‟exécution de certains services. Ceci conduit donc à devoir
annuler tout le processus. Pour cela, on peut s‟intéresser aux travaux
menés dans le domaine de la gestion de transaction. Une transaction est
un groupe d'opérations logiques qui doivent toutes réussir ou échouer
[63]. On peut dire qu‟une transaction est une séquence d‟opérations qui
permet de passer d‟un état stable à un autre état stable.
Les spécifications de Transaction de service se séparent en
deux parties les transactions atomiques (Atomic Transaction (AT)) et les
Activités métier (Business Activity (BA)).
Une transaction atomique est une transaction qui remplit les
propriétés ACID [64] [65] (Atomicité, Cohérence, Isolation, Durabilité)
qui sont utilisées pour coordonner les activités de courte durée. La
transaction atomique aussi garantit que tous les participants confirment
ou annulent la transaction dans une logique de type "tout ou rien". Une
transaction atomique est terminée soit dans l‟état "commit" (transaction
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
45
validée) soit dans l‟état "avort" (transaction annulée). Dans le cas d‟une
transaction validée, toutes les modifications liées à son exécution
deviennent durables. En revanche quand la transaction est avortée,
toutes les modifications amenées par son exécution doivent être
annulées.
Une activité métier est utilisée pour coordonner les activités de
longue durée. Des transactions de compensation sont utilisées dans cette
activité pour garantir la cohérence et remettre le système dans l‟état
stable initial si un utilisateur décide a posteriori d‟annuler une
transaction (par exemple un utilisateur commande un bien par internet
puis annule ultérieurement sa commande : il faut alors faire un
mécanisme de rollback pour annuler le payement). Cette nouvelle
transaction appelée transaction de compensation « compense » les effets
de la transaction originale. Il faut donc en prévoir la spécification lors de
la conception d‟un processus métier.
2.4.6 Conclusion
L‟approche orientée service présente plusieurs avantages dans le cadre
de l‟organisation d‟un processus collaboratif :
- La possibilité de publication de services permet
de diffuser largement une interface des
processus privés de l‟entreprise qui pourront
ensuite être « composés » dans une chaîne de
services correspondant au processus commun
- Le processus de sélection / composition permet
quant à lui d‟organiser rapidement une chaîne
de services répondant aux besoins exprimés
- L‟utilisation de standards permet d‟obtenir des
systèmes interopérables nativement
Toutefois, ces services ne peuvent être contextualisés ce qui conduit à
une multiplication des services correspondant aux différents contextes
d‟exécution et donc à des risques d‟incohérence puisqu‟aucune relation
ne peut être définie entre services ni entre services et modèles de
processus.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
46
2.5 Démarches orientées objet
La programmation orientée objet a été introduite dans les
années 70. Il s‟agissait alors d‟identifier des objets du monde réel et leur
associer des briques logicielles. L‟objet encapsule données et traitement
associé et permet de modéliser plus simplement le monde réel en
identifiant des objets et les relations entre eux. Dans le contexte de
travail collaboratif inter-entreprises, cette approche qui embarque
simultanément les données et processus dans des objets et ne doit
présenter qu‟une interface pour rendre l‟objet utilisable pourrait
permettre de garantir une relative indépendance entre les parties
publiques et privées. En effet, puisque tous les accès transitent par une
interface publique, il devient donc possible de « masquer » les éléments
internes (et donc de garantir le respect de contraintes de confidentialité
dans le cas d‟un processus inter-entreprise interconnectant plusieurs
objets privés propres aux différentes entreprises).
Outre ce premier avantage, l‟approche objet présente aussi une
certaine similarité avec les méthodes de modélisation d‟entreprise. En
effet, il est possible de construire de nouveaux objets en utilisant les
mécanismes d‟héritage de manière similaire à la génération de modèles
particulier par instanciation de modèles génériques. La définition des
instances lors de la création est donc largement facilitée puisque une
grande partie des informations et méthodes pourront être héritées des
classes de niveau supérieur.
Ce sont ces éléments qui motivent notre recours à l‟approche
orientée objet. Dans une première sous-section nous présenterons
d‟abord les points clef de cette démarche avant d‟introduire quelques
méthodes de modélisation basée sur cette approche.
2.5.1 Concepts de base de l’approche objet
L‟approche objet propose de modéliser un ensemble d‟entités
du monde réel sous forme objets, c.à.d. sous formes d‟unités atomiques
unissant un état, un comportement et une identité [27][28]. L‟état d‟un
objet est représenté par l‟ensemble de ses attributs (ou propriétés), c'est -
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
47
à-dire l‟ensemble des informations qui caractérisent l‟objet. Le
comportement d‟un objet est défini via des méthodes (ou opérations). Ce
sont ces opérations qui permettent à l‟objet de communiquer avec
l‟extérieur (par exemple avec d‟autres objets. A ce titre, l‟opération
(décrite par son nom de méthode) est l‟un des paramètres des messages
échangé lorsque deux objets communiquent. L‟identité permet de
distinguer cet objet des les autres objets (exemple : l‟identité d‟un objet
voiture peut être donné par son numéro d‟immatriculation).
Un objet comporte donc à la fois une partie statique (associée à
son état) et une partie dynamique décrivant son comportement (via les
opérations). Plusieurs objets peuvent posséder une structure et un
comportement communs. Il est alors possible de regrouper ces objet
dans un modèle générale (la “classe“). On dit alors que l‟objet est une
instance de la classe. Chaque classe est définie par un ensemble
d‟attributs (appelés variable d‟objet) qui décrivent la structure des objets
associés à cette classe, et des opérations, appelées méthodes.
Les liens qui relient les objets correspondent à une relation
entre leur classe. On distingue trois familles de relations ayant des
sémantiques différentes :
- l‟association et l‟agrégation,
- la généralisation et spécialisation,
- l‟héritage.
L‟association est utilisée pour lier les classes appartenant à des
environnements similaires (exemple : lier un étudiant et son université,
la relation entre l‟étudiant et l‟université est une association) voir la
figure 17.
Figure 17 : exemple d'association
La relation d‟agrégation permet de rassembler les propriétés et
de construire des objets complexes à partir d‟autres objets, appelé objets
composants. L‟agrégation exprime un assemblage fort entre les objets.
L‟agrégation est une relation de type “partie de“ ou “composé de“ (c.à.d.
une relation composant/composé) voir la figure 18.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
48
Figure 18 : Exemple d'agrégation
La généralisation et la spécialisation sont exprimées sur les
hiérarchies de classes. La généralisation permet de regrouper des classes
qui ont les mêmes caractéristiques dans une classe plus générale [28]
(voir la figure 19). Inversement, la spécialisation permet de créer des
classes plus spécialisées à partir d‟une classe existante.
Figure 19 : exemple de généralisation
La relation d‟héritage permet la réutilisation de propriétés par
spécialisation de classes. La classe spécialisée est appelée sous -classe et
la classe qu‟on spécialisé est appelée superclasse [28]. Ces liens
d‟héritage permettent de transférer des propriétés (attributs et méthodes)
de la class mère (superclasse) vers sous-classes. Ce dernier point nous
intéresse particulièrement dans notre travail dans la mesure où il permet
de générer des objets plus « précis ».
Enfin, l‟encapsulation permet de masquer les détails de l‟objet
pour n‟en présenter qu‟une interface. Ceci permet de préserver
l‟intégrité de l‟objet en différenciant l‟interface (publique) et
l‟implémentation (invisible) [29]. Ainsi un objet et les données qui lui
sont associées ne peuvent être manipulées que par les méthodes
explicitement définies (et donc dont les noms et paramètres de ces
méthodes figurent dans la spécification d‟interface) lors de la création
de cet objet (voir figure 20). L‟encapsulation définit donc deux
représentations de l‟objet : niveau externe (publique) et le niveau interne
(partie privée). La spécification d‟interface (niveau externe) regroupe la
partie visible de l‟objet c.à.d. les données communes et les méthodes
publiques (noms et paramètres) c'est-à-dire les méthodes qui peuvent
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
49
être invoquées depuis l‟extérieur. En revanche, les données et méthodes
figurant dans la partie privée ne peuvent être accédées que par des
méthodes de ce même objet.
Dans notre cas de processus collaboratif, la démarche objet
permet de protéger efficacement les informations, savoir et savoir faire
organisationnels privés d‟une entreprise en ne les rendant invocable
qu‟au travers d‟une interface publique. Ceci justifie donc de privilégier
des méthodes de modélisation orientée objet dans notre cas.
Figure 20 : Schéma d‟un objet encapsulé
2.5.2 Définition des Objets métier (Business objects)
L‟objet métier est un concept utilisé pour représenter des
ensembles d'information du Système d'Information de l‟entreprise. Un
objet métier est définit selon [30] page 4 “ 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. A business
application can be specified in terms of interactions among a
configuration of implemented business objects. “
Ce concept de “business object“ permet donc de modéliser des
entités (les « choses » qui existent dans l‟entreprise, ce sera par exemple
la notion d‟employé) et les activités qui y sont associées [31]. Comme
pour un objet traditionnel, l‟état d‟un objet métier est déf ini par les
attributs de cet objet et son comportement est défini par les actions que
cet objet métier peut exécuter pour atteindre un but [32]. Enfin, la prise
en compte de relations de composition permet aussi définir
récursivement les objets métier à partir d‟un objet pivot (représentant le
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
50
concept principal) et des éléments complémentaires (objets métier de
plus bas niveau).
L‟organisation de relations entre les objets permet de modéliser
un système par agrégation de plusieurs objets. Les opérations
représentent la vue dynamique de l‟objet métier [31][36].
2.5.3 Méthodes de modélisation orientée objet
Notre contexte d‟étude étant lié à l‟organisation de processus
collaboratifs inter-entreprises et à la possibilité de générer les
composants associés, nous limiterons notre présentation à deux
méthodes, l‟une IEM orientée modélisation d‟entreprise et l‟autre UML
orientée informatique.
2.5.3.1 IEM
IEM (Integrated Enterprise Modelling) utilise la modélisation orientée
objet pour modéliser des processus d‟entreprise [33][37]. Les concepts
principaux utilisés par IEM sont l‟encapsulation des fonctions et des
données dans un objet, le concept de classe et le principe d‟héritage.
IEM représente les différents aspects d‟une entreprise manufacturière au
travers d‟un modèle unique composé de 8 vues. Les vues fonctionnelle
et informationnelle sont axées sur la représentation des processus de
l‟entreprise indépendamment des aspects technologiques induits. Les
aspects technologiques sont détaillés dans quatre vues : applicatifs,
stockage de données, réseaux et matériel. Enfin deux vues, personnel et
qualifications d‟une part et unité d‟organisation d‟autre part sont
affectées à la gestion des ressources humaines.
La vue informationnelle regroupe les objets de l‟entreprise. Les
objets sont structurés en trois classes de base, selon leur usage dans les
processus modélisés : les produits, les commandes et les ressources.
La vue fonctionnelle représente les traitements effectués sur les
objets dans le cadre du processus de production. Le concept de base
utilisé pour la modélisation des traitements est l‟activité. Une activité
transforme des objets au moyen de ressources sous l‟action de contrôles.
IEM définit un modèle générique d‟activité, représenté en figure 21.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
51
Figure 21 : le modèle général d'activité d'IEM
Une activité avec toutes ses entrées et sorties définies est
appelée activité complète. Si seules les entrées et sorties d‟objets sont
définies, on parle de fonction. Enfin, en l‟absence d‟entrées et de sorties,
on dit qu‟on a affaire à une action.
En dehors des vues fonctionnelle et informationnelle, à chaque
vue additionnelle est associés une classe qui est la racine de tous les
objets compris dans ces vues.
La modélisation des processus est réalisée selon les cinq
étapes traditionnelles :
L‟identification des objets.
L‟identification des fonctions manipulant ces objets.
L‟organisation des fonctions. Leur enchaînement est défini au
moyen “ d‟opérateurs de connexion “ qui sont la séquence,
l‟exécution en parallèle, l‟alternative, la jointure et la boucle.
La description de chaque fonction au moyen des objets affectés,
c'est-à-dire la définition des entrées et des sorties de chaque
fonction.
La décomposition des fonctions en sous-fonctions si le niveau de
détail du modèle le requiert.
2.5.3.2 UML
The Unified Modeling Language (UML) [34] propose un
ensemble de diagrammes permettant de représenter un système
informatique et son utilisation prévue dans l‟entreprise.
UML couvre les différentes étapes du développement d‟un
objet en offrant différent types de diagramme.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
52
Le diagramme de structure définit les concepts statiques (ex :
classe, attribut, opération, composants, package) qui sont nécessaires
pour les diagrammes de classes, de composants et de déploiement . Cette
partie comporte trois packages (Class, Composite Structure,
Components).
Le diagramme de classe représente la structure d‟une
application orientée objet en montrant les classes et les relations qui
s‟établissent entre elles. La représentation d‟une classe comporte trois
parties, à savoir (1) le nom de la classe et ses propriétés, (2) les attributs
et (3) les opérations. Plusieurs types de relations permettent de relier les
classes : la généralisation, l‟association et la dépendance comme indique
dans la figure 22. Ce diagramme permet de définir toute la structure
conceptuelle d‟une application et toutes les contraintes ou règles de
gestion. Dans ce diagramme l‟agrégation et la composition sont deux
précisions supplémentaires de l‟association (relation qui peut s‟établir
entre instances de classes) qui introduisent la notion de composition
comme le montre par exemple la figure 23.
Figure 22 : Représentation des relations entre classes [34] page 20.
Figure 23 : Exemple d'agrégation et de composition [34] page 21.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
53
Dans cet exemple on présente une relation d‟agrégation “ une
zone “ inclut plusieurs stations c-à-d qu‟elle est implicitement composée
de plusieurs stations.“ La relation de composition est une relation de
type agrégation mais comporte en plus une règle sur la gestion du
modèle. Dans l‟exemple présenté, “ un client possède obligatoirement
un compte et la suppression d‟un client entraîne implicitement la
suppression de son compte.
Le package de type « Composite Structure » contient plusieurs
sous-packages qui permettent de spécifier la structure interne d‟une
classe. Il décrit deux types de composition possibles : la collaboration et
la classe structurée. La figure 24 représente la collaboration dans un
diagramme de structure composite.
Figure 24 : Exemple d'une collaboration dans un diagramme de
structure composite [34] page 29
Ce diagramme montre comment est réalisée la collaboration en
définissant les rôles et les classes qui y participent. Les rôles sont reliés
entre eux par un connecteur qui représente tous les moyens qui permet à
deux objets de se connaître afin de s‟échanger de l‟information : passage
d‟une référence, communication par opération, définition d‟une variable
commune, etc.
Les collaborations servent à exprimer les rôles des classes dans
la réalisation d‟un patron de conception (design pattern) voir la figure
25.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
54
Figure 25 : Représentation d'un design pattern dans un diagramme de
structure composite [34] page 29
Le package « Components » inclut plusieurs modèles :
Le diagramme de cas d‟utilisation (Use-Cases) définit
les concepts qui permettent de spécifier les cas
d‟utilisation d‟une application. Un cas d‟utilisation
représente une séquence d‟interactions entre
l‟application et ses utilisateurs.
Le diagramme d‟état consiste à décrire l‟évolution d‟un
système. Cette évolution est définie par les états(les
états sont des conditions ou situation durant la vie d‟un
objet qui satisfont certaines conditions, réalisent
certaines activités et attendent certains événements.)
Le diagramme d‟activité est destiné à modéliser les
processus et les fonctions sans nécessairement recourir
au concept d‟état.
Les diagrammes d‟interaction décrivent principalement
des objets échangeant des messages. Il y a deux types
de diagrammes d‟interaction.
Le diagramme de séquence décrit les échanges
de message entre les objets.
Le diagramme de communication permet de
spécifier l‟ordre de séquencement, les messages
sont numérotés suivant une logique
hiérarchique.
UML présente plusieurs avantages pour modéliser un processus
collaboratif :
- Le diagramme des cas d‟utilisation permet de
décrire précisément l‟organisation du processus
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
55
collaboratif et les interactions entre les
différents partenaires
- Le diagramme de composants permet de
présenter plusieurs niveaux de description
permettant de séparer l‟interface (associée à un
processus public publié par l‟entreprise) de
l‟implémentation réelle (processus privé de
l‟entreprise)
- Le diagramme de classe permet quant à lui de
spécialiser progressivement les différents
éléments. Cette approche hiérarchique peut
permettre de regrouper des services
« contextualisés » dans une même classe afin de
bénéficier des mécanismes d‟héritage et une
meilleure réutilisation.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
56
2.5.4 Conclusion
L’approche objet offre un ensemble de concepts et méthodes de
modélisation pouvant apporter une réponse pour modéliser des
processus collaboratifs entre entreprises. En effet, l’encapsulation
permet de protéger raisonnablement le patrimoine propre de chaque
entreprise (données et processus traduisant son savoir-faire) tout en
offrant la nécessaire ouverture sur le système (via la spécification des
interfaces).
Les nombreuses facettes permettant de décrire un objet proposé
par la méthode UML permet également de bien couvrir la spécification
d’un processus collaboratif. Le cas d’usage permet aux partenaires de
décrire effectivement ce qu’ils prévoient de faire de manière
« ponctuelle ». Les autres diagrammes permettent ensuite de préciser le
« comment » et le « qui fait quoi et quand ».
Toutefois, modéliser ne peut suffire à mettre en œuvre un
processus de collaboration. Il importe d’une part de pouvoir transformer
les modèles en logiciel support de ce processus.
2.6 Des modèles au logiciel
L‟ingénierie dirigée par les modèles propose un environnement
permettant d‟organiser les différentes étapes de modélisation pour
aboutir à un logiciel de qualité. Cette démarche permet de bénéficier des
possibilités d‟abstraction des modèles et d‟augmenter les possibilités de
réutilisation. Parmi les initiatives mettant en œuvre cette démarche,
l‟OMG, a proposé l‟approche MDA pour permettre d‟accroître
l‟interopérabilité des applications en séparant clairement les
spécifications fonctionnelles d‟un système des spécifications de son
implémentation sur une plate-forme donnée [38][39]. Plusieurs niveaux
de modélisation sont définis dans la figure 26 :
Le niveau M0 (ou instance) : il définit les informations correspondant
aux objets du monde réel.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
57
Le niveauM1(ou modèle): il décrit les informations de M0. Les modèles
UML appartiennent au niveau M1. Les modèles M1 sont des instances
de M2.
Figure 26 : Les niveaux de modélisation
Le niveau M2 (ou méta modèle) est composé de langages de
spécification de modèles, tels que UML, profil UML qui permet
d‟étendre le méta modèle UML.
Le niveau M3 (ou méta-méta-modèle) : est le plus haut niveau
d‟abstraction pour une architecture de méta modélisation. Il comporte
une entité unique qui s‟appelle MOF et qui permet de décrire la
structure des méta-modèles.
La démarche proposée par MDA est la construction d‟un ou plusieurs
modèles indépendants des plates-formes (Platform Independent Model,
PIM) suivie de la transformation de ces modèles en modèles dépendants
des plates-formes (Platform Specific Model, PSM). Les différents
niveaux de modélisation permettent de gérer les connaissances
nécessaires à ces transformations.
L‟approche MDA comporte différents modèles qui sont présentés dans
la figure 27 ci-après.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
58
Figure 27 : Les catégories de modèles dans MDA.
Le modèle d‟exigences CIM (Computation Independent Model
ou modèle indépendant de la programmation) est aussi appelé modèle de
domaine. Il modélise les exigences du système. Un modèle d‟exigences
ne contient pas d‟information sur la réalisation de l‟application n i sur les
traitements ce qui justifie son appellation CIM. Il montre simplement le
système dans l‟environnement organisationnel dans lequel il va être
exécuté. La première étape à faire pendant la construction d‟une
nouvelle application est de spécifier les besoins du client. L‟objectif de
ce modèle est d‟aider à comprendre le problème et permet de représenter
ce que doit être fait par le système. Les exigences qui sont exprimées
dans le CIM doivent être transmises dans le PIM et le PSM [38]
[39][40].
Le modèle de description de plateforme PDM (Plateform Description
Model) contient les informations nécessaires sur la plateforme afin de
transformer des modèles PIM en modèles PSM puis en code adapté pour
une plateforme spécifique [39].
La construction du modèle d‟analyse et de conception abstraite PIM
(Platform Independent Model) est la première étape de la démarche
MDA. Un exemple de PIM est présenté dans la figure 28. Cette famille
de modèles décrit le système sans montrer les détails des plateformes.
Un modèle de cette famille (représenté par un diagramme UML)
représente par exemple les différentes entités fonctionnelles du système
ainsi que les connexions entre celles-ci. Ce type de modèle peut aussi
être décrit avec un langage de contrainte comme OCL (Object Contraint
Language) [40]. Cette indépendance de la plateforme permet d‟assurer
une interopérabilité fonctionnelle.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
59
Figure 28 : Exemple de PIM [40] page 8.
Le modèle de code ou de conception concrète PSM (plateforme
Specific model) est quant à lui dépendant des plates-formes techniques.
Les modèles de cette famille servent de base à la génération de code
exécutable vers les plates-formes techniques. Il existe plusieurs niveaux
de PSM. Le premier est obtenu directement à partir de modèle PIM. Il
est représenté par un schéma UML. Les autre niveaux de PSM sont
obtenus via la transformation jusqu'à l‟obtention du système exécutable
(obtention du code dans un langage spécifique (Java,C++, etc) comme
c‟est montré dans la figure 29 [40].
Figure 29 : Relation entre PIM et PSM en modélisation EJBexpanded
[40] page 9
Les transformations de modèles (voir figure 30) concernent à la
fois les transformations de modèles d‟exigences (CIM) en modèles
fonctionnels (PIM) puis de modèles fonctionnels en modèles
« technologiques » liés à la plateforme (PSM) puis en code [40]. Ces
transformations sont essentielles à la pérennité des modèles : elles
garantissent les liens de traçabilité entre les modèles et les besoins
exprimé par le client.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
60
La transformation de CIM vers PIM permet de construire des
modèles de type PIM partiels à partir des informations contenues dans
les modèles d‟exigences (CIM). L‟objectif est de s‟assurer que les
besoins exprimés dans les modèles d‟exigence (CIM) sont retranscrits
dans les PIM.
Les transformations de modèles PIM à PIM sont généralement
appliquées pour ajouter (ou enlever) des informations à des modèles. Par
exemple quand on passe de la phase d‟analyse à la phase de conception,
cette transformation permet de raffiner les modèles pour améliorer la
précision des informations qu‟ils contiennent. Ces transformations qui
comportent une grande part de connaissances ne sont pas généralement
automatisable.
Figure 30 : Etapes du processus MDA [40] page 6.
Les transformations de modèles fonctionnels (PIM) vers des modèles
spécifiques des plateformes utilisées (PSM) sont les plus importantes de
la démarche MDA car elles garantissent la pérennité des modèles. Pour
réaliser ces transformations vers des modèles intégrant les spécificités
des plateformes il faut enrichir le modèle initial (de type PIM) pour le
spécialiser vers une plate forme donnée. Cette opération consiste à
ajouter des informations liées à une plateforme technique pour pouvoir
enfin générer le code. Les principales plates formes PSM possible sont
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
61
J2EE, CORBA, XML/SOAP, ces plates formes sont montré dans la
figure 31[38].
Figure 31 : Exemple d‟utilisation des modèles pour réaliser une
application [38] page 5.
Des transformations de type PSM vers PSM s‟appliquent sur un
modèle spécifique afin d‟obtenir un autre modèle spécifique à la même
plate-forme. Ces transformations sont utilisées lors des phases de
déploiement, d‟optimisation, de raffinement ou de configuration (figure
32).
Figure 32 : Transformations des modèles [38] page 6.
Enfin, une démarche de rétro-ingénierie peut utiliser une
transformation de type PSM à PIM afin de revenir à un modèle
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
62
indépendant de plate forme(PIM) à partir d‟un modèle spécifique de
plate forme (PSM). Ce type de transformation complexe à réaliser et
plus difficile à automatiser.
Cette démarche dirigée par les modèles est très riche dans la
mesure où elle permet de prendre en compte les différents points de vue
de modélisation. Sa richesse constitue à la fois son principal atout et son
principal handicap pour le domaine qui nous concerne, à savoir la
collaboration entre entreprises. Nous identifions trois limites pour ce
contexte particulier. D‟une part la modélisation de collaboration entre
entreprise s‟appuie principalement sur une vision « processus » et ne
doit pas remettre en cause la totalité du système d‟information. D‟autre
part la complétude de ces démarches imposent une durée d‟ingénierie
d‟autant plus élevée que nombre de transformations ne sont pas
automatisables. Cette durée peut s‟avérer incompatible avec la durée de
vie du « projet de collaboration » (en d‟autres termes, il ne faudrait pas
que la mise à disposition de l‟environnement de collaboration soit plus
long que la collaboration elle-même). Enfin, sir la démarche de
transformation permet d‟organiser une certaine interopérabilité
applicative au niveau fonctionnelle, elle ne permet pas de définir une
réelle interopérabilité au niveau technologique.
2.7 Conclusion
L‟organisation de collaborations inter-entreprises (voire de co-
industrie) conduit à l‟émergence d‟entreprises virtuelles et fait
largement appel aux technologies de l‟information et de la
communication. Ces pratiques collaboratives sont limitées à la fois en
raison de la nécessaire modélisation et structuration des processus et des
contraintes technologiques liées aux systèmes d‟information
d‟entreprise, organisés en silo fonctionnels, et limitant la mise en place
des collaborations du fait de leur rigidité (ils ne répondent donc pas au
besoin d‟agilité) et de leur manque d‟ouverture (ce qui pose un problème
d‟interopérabilité).
La première limite, liée à la formalisation les processus de
collaboration et les informations échangées suppose que chaque
partenaire dispose de modèles permettant de décrire son activité et son
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
63
SI. Or les méthodes de modélisation traditionnelles sont souvent lourdes
et nécessitent une durée de projet incompatible avec l‟horizon court ou
moyen terme impliqué par une collaboration. Pour faciliter cette activité
d‟ingénierie, la plupart des méthodes proposent des architectures
permettant d‟utiliser un modèle générique puis de le particulariser. Cette
approche, assez similaire au processus d‟instanciation de l‟approche
objet, permet effectivement de simplifier l‟ingénierie en définissant des
« bonnes pratiques » mais ne permet pas de s‟adapter à l‟organisation de
l‟entreprise et aux changements de contexte : les modèles sont
particularisés dans une approche top-down et tout changement impose
de recommencer l‟activité d‟ingénierie. En outre, les méthodes de
modélisation d‟entreprise n‟interfèrent que peu avec les méthodes de
modélisation permettant la génération de code, introduisant ainsi une
dichotomie entre espace de business et espace technologique. De la
même manière, les processus de générations proposés dans la démarche
MDA sont aussi organisés de manière hiérarchisée dans une logique top-
down et ne permettent pas de « tisser » dynamiquement différents
modèles contextuels.
La deuxième limite que nous avons identifié concerne la
réponse technologique : outre les coûts liés à l‟infrastructure
informatique (matérielle et logicielle), les Systèmes d‟Information (SI)
d‟entreprise ne sont que peu agiles et ne prennent pas réellement en
compte les logiques de production. Les démarches d‟urbanisation et
l‟organisation d‟architectures orientées services, visant à rendre les SI
agiles, sont basées sur une organisation « métier » de l‟entreprise,
reflétant plus l‟organigramme (achat, production, relation client…), que
l‟organisation industrielle ce qui ne permet ni de pouvoir construire à la
demande des organisations de co-production efficientes ni de rendre le
système d‟information réellement adaptable (pour suivre de manière
continuelle les stratégies industrielles) et pervasif (pour s‟adapter aux
différents modes de suivi et de traçabilité de la production).. Si les
architectures à base de services assurent une interopérabilité
« syntaxique » et technologique, elles n‟apportent pas de réponse au
niveau organisationnel. En outre, elles ne permettent pas de gérer des
services contextualisés.
Pour pallier les limites, il faudrait pouvoir apporter la
flexibilité et l‟agilité des opérations de composition de service aux
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
64
stratégies de modélisation. Pour cela, nous proposons d‟étendre les
travaux de thèse de Sodki Chaari [69] réalisés dans notre équipe. Il
s‟agit de transformer l‟organisation traditionnelle de l‟entreprise en une
organisation « d‟entreprise orientée service ». Ainsi, une entreprise
pourrait publier ses offres de services comme base pour établir des
collaborations. L‟organisation d‟un processus collaboratif entre
entreprises reviendrait ainsi à sélectionner et « composer » les services
d‟entreprises pour former une chaîne répondant aux besoins du client
puis générer le support informatique correspondant à ce contexte de
collaboration.
Pour offrir le meilleur niveau d‟interopérabilité possible, nous
proposons de coupler plus étroitement les niveaux d‟affaire et
technologique : l‟expression des besoins du client permet de définir les
rôles et services qui devront être combinés pour former le processus
collaboratif correspondant. Une fois identifiés ces services d‟affaire, ils
sont composés dans une logique de processus et en fournissent donc un
modèle abstrait. Pour aboutir au modèle « concret » du système support,
il faut pouvoir transformer ces services abstraits en services
technologiques composés en prenant en compte les contraintes de
contexte. Pour cela, nous proposons de dépasser le simple cadre « top-
down » de l‟ingénierie dirigée par les modèles pour passer à une logique
de composition issue de l‟architecture orientée services d‟une part et de
l‟héritage purement hiérarchique de l‟approche objet d‟autre part pour
permettre de composer (ou « tisser ») des modèles selon le contexte et
être capable de propager ces contraintes contextuelles le long de la
chaîne de services. Pour ce faire, il importe de définir une organisation
non plus hiérarchique mais mixte en hypergraphe permettant d‟une part
d‟améliorer la génération de services particuliers en utilisant pleinement
les mécanismes d‟héritage et d‟autres part d‟utiliser les relations
« latérales » pour propager les contraintes de contextes et améliorer les
possibilité de substitution de services. Notons également que les
possibilités d‟encapsulation apportées par la structure d‟hypergraphe
peut permettre de masquer la complexité et le savoir-faire des processus
propres de l‟entreprise en n‟en publiant que la vision « publique », c'est-
à-dire le service de haut niveau.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
65
Dans le chapitre 3, nous présenterons globalement le principe
et l‟architecture retenue avant de détailler les différentes relations et
mécanismes de construction de l‟hypergraphe dans le chapitre 4.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
66
Chapitre 3
La collaboration des processus de
l’entreprise
3.1 Introduction
L‟organisation d‟un système de collaborations entre entreprise
suppose d‟abord une analyse de cette stratégie de collaboration : si dans
le passé les entreprises pouvaient opérer seules dans des environnements
relativement stables, les évolutions du marché (prise en compte de la
dimension produit service, customisation de masse, recherche de
réduction des coûts, globalisation,…) les conduisent à se recentrer sur
leur cœur de métier et à construire de plus en plus de relations de
collaborations plus ou moins durables avec des partenaires industriels.
Les défis principaux de cette stratégie de collaboration sont (1) la
sélection de partenaires industriels et / ou commerciaux appropriés, (2)
l‟organisation et la mise en œuvre de processus appropriés en réponse
aux besoins exprimés par les clients et ce avec des coûts de production
acceptables et (3) disposer des moyens informatique nécessaires pour
supporter ces fonctions de sélection et disposer rapidement des outils
supports nécessaires pour l‟exécution de ce processus commun. Le
premier défi suppose de pouvoir identifier les « services » proposés par
les partenaires potentiels de manière à pouvoir les sélectionner. Le
deuxième défi quant à lui impose une réorganisation des processus de
l‟entreprise à la fois pour améliorer la productivité mais aussi pour avoir
plus de souplesse et d‟agilité afin de répondre rapidement aux
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
67
changements de contextes liés au marché. Le troisième défi est quant à
lui lié au développement des TIC induisant une nouvelle stratégie
économique (économie numérique) et facilitant les échanges
dématérialisés d‟information. Cette possibilité de recourir à une
distribution des informations à large échelle a permis de faire émerger
des entreprises virtuelles, c‟est à dire des entreprises regroupant dans
une organisation collaboratives plusieurs partenaires partageant des
ressources et travaillant ensemble pour atteindre un objectif commun.
Le développement de ces stratégies de collaboration implique
souplesse et agilité des entreprises tant en ce qui concerne leur
organisation qu‟en ce qui concerne leur système d‟information. Ce
développement bénéficie largement du développement des TIC et des
technologies basées sur l‟Internet. En effet, le développement des
services et des technologies de services web permet aux entreprises de
pouvoir développer de manière plus rapide les supports informatiques
nécessaires au développement de leurs processus en combinant des
services mais cela pose d‟évidents problèmes d‟interopérabilité. Ainsi,
un processus collaboratif peut être développé en construisant une chaîne
de services intégrant des services offerts par différents fournisseurs à
condition de pouvoir sélectionner puis « interconnecter » ces services,
c'est-à-dire à condition que les entreprises publient ces services et
développent des interfaces standardisées (ce qui est le cas lorsqu‟on
utilise des technologies à base de services web). L‟enjeu principal est
alors la capacité de s‟organiser pour collaborer et de partager de
l'information entre les entreprises. Ceci pose alors le problème de
l‟interopérabilité, tant en ce qui concerne l‟organisation (ce qui impacte
l‟organisation et les conditions de travail) qu‟en ce qui concerne les
technologies utilisées dans le système d‟information support.
Pour répondre à ces exigences, nous nous focaliserons sur deux
dimensions importantes : l‟agilité du système d‟information d‟une part
et la construction de processus de collaboration d‟autre part. En effet,
les systèmes d‟information d‟entreprises étant constitués de nombreux
outils dédiés à des espaces métier particuliers (ERP, SCM, CRM…), il
existe une forte complexité technologique et chaque système est
relativement « figé » ce qui ne permet pas des (re)configurations
rapides. En outre, ces systèmes étant relativement « fermés » et les
formats d‟interfaces étant définis de manière spécifique (et souvent
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
68
incompatible), les échanges d‟informations (compréhensibles) entre
partenaires sont donc limités. Dépasser cette limite impose d‟obtenir un
niveau d‟interopérabilité suffisant. L‟interopérabilité dans l‟entreprise
est définie comme la capacité des systèmes d‟information et des
processus à supporter l‟échange des données et de permettre le partage
d‟information et des connaissances [67].
Depuis quelques années, de nombreux travaux ont porté sur
l‟interopérabilité, principalement pour ce qui concerne les applications.
De nombreuses approches dans ce domaine ont pour but l‟adaptation des
types et structures des paramètres d'appel quand un processus
d‟entreprise doit invoquer un autre processus. Ceci a par exemple
conduit au développement des architectures orientées services (SOA) [1]
en réponse aux problématiques d'interopérabilité entre les différents
systèmes qui implémentent les systèmes d'information des entreprises.
Si cette approche apporte une solution adaptée au problème
d‟interopérabilité dans l‟entreprise (donc interopérabilité entre les
différents systèmes « métier »), elle reste limitée par une vision « mono-
contexte » du service, ce qui ne correspond pas réellement aux besoins
d‟une collaboration inter-entreprises. En effet, un écosystème de
services inclut un environnement multi-contextuel d‟exécution de
services. Ainsi, l‟approche SOA impose de multiplier les services :
chaque entreprise doit fournir plusieurs services, chacun relié à un
contexte particulier, pour pouvoir intégrer convenablement les fonctions
selon des besoins propres à chaque contexte. Ceci augmente donc la
complexité du système et les risques d‟incohérence.
Pour s‟adapter au contexte de collaboration inter-entreprises, il
faut réorganiser l‟entreprise pour présenter une structure interopérable à
tous les niveaux, i.e. niveaux organisation, d‟affaires (métier) et,
technologiques :
o L‟interopérabilité du niveau organisation impose d‟adapter les
structures et les moyens d'organisation pour pouvoir
construire des organisations dynamiques capables de fournir
des réponses appropriées aux différents scénarios de
collaboration.
o L‟interopérabilité du niveau d‟affaire doit permettre la
construction de processus de collaboration (pour la fabrication
de produits ou de services) à partir des différents processus
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
69
appartenant aux différents partenaires. Les éléments
industriels doivent être décrits, publiés et rendus accessibles
par des plates-formes adaptées.
o Enfin, l‟interopérabilité du niveau technique concerne les
choix et moyens technologiques. Les entreprises doivent alors
analyser leur système d'information afin de les adapter aux
stratégies dynamiques de collaboration et faciliter
l‟interopérabilité.
Nos propositions pour améliorer l‟interopérabilité reposent sur
un modèle multi-vues (gestion, médiation et sécurité) pour réaliser une
bonne interconnexion entre les différents processus d‟entreprise. Comme
dans la thèse de Mlle Rajsiri (voir [76]), nous proposons que le
processus collaboratif soit conçu comme une chaîne de services. Ceci
impose donc que chaque entreprise publie les services, pouvant
intervenir dans un processus de collaboration, dans un répertoire propre.
Ainsi, le processus de conception du processus collaboratif repose donc
sur une sélection / composition. Comme dans [76], cet espace de
conception s‟apparente à un modèle de type CIM : les services sont alors
définis de manière abstraite et associé à des rôles. La transformation de
ce modèle CIM en PIM puis PSM impose de transformer ces services
abstraits en services concrets puis en services exécutables. Toutefois, à
la différence de [76], notre modèle vise d‟une part une génération
contextuelle des services et d‟autre part à faciliter la réutilisation, les
processus de sélection/composition en ajoutant différentes relations
entre les services d‟autres part.
Tout d‟abord, nous lions la transformation du service abstrait
en service concret au contexte (qui invoque le service, à partir de quel
mode d‟accès, quand, avec quels besoins en qualité de service et sous
quelles politiques de sécurité). Par exemple, un service abstrait d‟achat
en ligne peut être réutilisé par plusieurs processus avec un rôle
« Achat ». Selon le contexte d‟accès au service (accès par un client final,
un professionnel partenaire, un personnel de l‟entreprise) et
l‟infrastructure d‟accès utilisé (PC et réseau privé, accès via internet,
accès par téléphone portable…) différentes politiques de sécurité et
différents services concrets (gérant des interface utilisateur spécialisées )
pourront être déployés.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
70
Ensuite, de manière à assurer la cohérence des services générés
(modèles d‟interface, règles opératoires communes…) selon le contexte,
nous avons choisi d‟encapsuler des services dans des objets pour utiliser
pleinement le mécanisme d‟héritage (ce qui assure la cohérence entre les
objets et facilite les opérations de mise à jour).
Enfin, la structure du registre est enrichie par différents types
de relations :
- La relation d‟agrégation permet de définir des
services comme englobant un chaîne de services
élémentaire ce qui permet de gérer simplment
plusieurs niveaux de détail dans la spécification
des services et augmente les possibilités de
réutilisation
- La relation de similarité permet de définir des
équivalences entre les services ce qui accélère
notablement la sélection d‟un service adapté au
moment de l‟exécution (sous réserve de
disposer d‟un système de « late binding »
adapté) ce qui est très important dans une
logique de passage à l‟échelle (problème de
scalabilité)
- La relation de collaboration permet de disposer
d‟informations objectives sur les collaborations
précédentes pour sélection le(s) bon(s)
partenaire(s)
- La relation de recommandation permet enfin
d‟assister l‟utilisateur dans la conception de la
chaîne de service en indiquant quels autres
services ont pu être utilisés conjointement.
Ces relations et différentes descriptions permettent de sélectionner
les services en fonction des besoins et de construire le processus commun
comme une chaîne de services abstraits comme illustré dans la Figure33.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
71
F
i
g
u
re 33 : Comparaison entre processus collaboratifs traditionnels et multi -
contextuels
L‟intégration des différentes vues permet de « superposer »
différents éléments de contexte et, grâce à un « arbre d‟héritage », de
contexualiser le service abstrait et donc aboutir à un service et un
processus concrets. Pour cela, on intègre les contraintes de médiation
entre les services (issues de la vue médiation) et les éléments de sécurité
(déduit des politiques de sécurité exprimées dans la vue sécurité). Pour
répondre à la contrainte de dynamicité, nous proposons que ces politiques
soient exprimées dans une logique ECA (Event, Condition, Action) :
l‟action est effectuée quand un événement donné se produit et que la
condition est satisfaite.
Pour prendre en compte ces différentes dimensions et permettre
des héritages multiples, notre modèle est basé sur un hypergraphe
permettant d‟introduire différentes stratégies d‟héritage et de multiples
niveaux de description.
Dans ce chapitre, nous présentons d‟abord l‟architecture
globale avant de détailler les différentes vues et le processus de
transformation avant de présenter le principe de construction d‟un
Vue Médiation
Vue Gestion
Vue Médiation
Processus à base de services concrets
Contexte
Processus à base de services abstraits multi-contextuels
VS
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
72
processus collaboratif. Le fonctionnement de l‟hypergraphe et son
utilisation pour une orchestration cohérente seront quant à eux détaillés
dans le chapitre suivant.
3.2 Architecture globale
Notre architecture propose un modèle destiné à supporter la
collaboration en sélectionnant les services nécessaires pour construire le
processus collaboratif. Ce modèle repose sur les concepts suivants
comme illustrés en Figure 34.
Figure 34 : Les concepts de base d‟une collaboration contextualisée
1. Le service abstrait : ce service fournit une description abstraite
d‟une activité métier sans une description technique de son
implémentation et son invocation. Il manipule les objets métiers
passés comme des entrées et aide les partenaires à se concentrer
sur la conception de processus de collaboration sans maitrise
technique des services concrets.
2. Le service concret : est un service informatique qui implémente
un service abstrait en respectant un modèle architectural
(Service Web, DCOM, composant CORBA, etc.) et un langage
de programmation (Java, C#, etc.). Dans notre approche les
services concrets respectent la propriété du couplage lâche pour
faciliter la réutilisation mais ils sont reliés par des relations
sémantiques qui permettent de contextualiser l‟exécution
(relation d‟héritage), faciliter la propagation des contraintes
(relation d‟agrégation) et enrichir la robustesse et disponibilité
(relation de similarité et relation de substitution).
Service Abstrait Services concrets Répertoire local Répertoire public
Répertoire partagé de processus
collaboratifs communs
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
73
3. Le répertoire local de services concrets : ce répertoire contient
les services concrets et maintient les relations entre services. Il
est interne à l‟entreprise et n‟est pas partagé avec les
partenaires.
4. Le répertoire public de services abstraits : ce répertoire
contient les services abstraits qu‟une entreprise souhaite
partager avec ses partenaires. Les services abstraits pointent sur
des services concrets interconnectés par les relations entre
services (graphes de services). Il contient également les objets
métiers manipulés par ces services abstraits. C‟est au moment de
l‟exécution,
5. Le répertoire de processus collaboratifs communs : le
processus collaboratif est conçu conjointement par les
partenaires à partir de leurs services abstraits. Ce processus est
vu comme une chaîne de services dont les informations
contextuelles se propagent. Il est similaire à un patron
(template) qui représente d'une manière abstraite les descriptions
des services à sélectionner au moment de l‟exécution en tenant
de compte des informations contextuelles et en s‟appuyant sur
les différentes vues (gestion, médiation et sécurité).
En général, nous considérons le service comme un objet
représenté par son interface qui permet de donner accès au service
abstrait. Les éléments associés à l‟interface d‟un service sont le nom du
service, les paramètres en entrée et sorties et les opérations. Seules les
noms, paramètres et opérations publiques sont présentées dans le
répertoire destiné à la collaboration (ce qui permet de préserver les
visions processus public et processus privé). Le service abstrait
représente l‟interface publique publiée par l‟entreprise : ceci permet de
masquer les implantations réelles et donc respecte la séparation publique
/ privée. Chaque service abstrait est ensuite lié aux services concrets qui
représentent des instances de services « concrets » qui seront
effectivement exécutés. La sélection du service concret est faite au
moment de l‟exécution. L‟interconnexion entre les services offre une
possibilité de couplage lâche qui repose sur l‟échange de messages.
Le répertoire public, propre à chaque entreprise, permet de
lister les services qu‟elle désire exposer. Ce répertoire permet de
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
74
présenter les services abstraits et leur interface. Notons que la
description des échanges entre les services est prise en compte en
associant les messages à la description des services (messages en entrée
et en sortie).
Lorsque plusieurs entreprises veulent collaborer, elles créent un
répertoire commun intégrant les différents services proposés par les
partenaires. Au cours du temps, d‟autres entreprises peuvent rejoindre ce
groupe et publier également leurs services dans ce répertoire commun.
Ceci permet d‟organiser des communautés de collaboration (breeding
virtual organisation) [68]).
Ensuite on peut créer un processus de collaboration (associé à
un répertoire commun) qui comporte les services qui venant de
différents partenaires. Dans ce répertoire au lieu de présenter les
services comme une liste, des relations d‟agrégation, de similarité…
détaillées dans le chapitre suivant permettent de compléter une stratégie
d‟héritage et de composition pour créer le processus commun . Ceci
représente le concept clef de notre architecture. Ce processus commun
permet de matérialiser les « opérations » nécessaires pour la réalisation
de la collaboration et atteindre l‟objectif fixé.
Le processus de collaboration est un concept clef de notre
architecture. Ce processus est construit pour répondre à une demande
spécifique et suppose que les entreprises partenaires soient d‟accord
pour collaborer et donc créer le processus abstrait. Ce processus est
constitué par assemblage de services abstraits qui viennent de différents
partenaires. Ces services sont associés à des rôles ce qui permet de
préciser la responsabilité de chaque partenaire dans l‟organisat ion du
processus commun. Ce processus est défini par un ensemble de vues :
gestion, médiation et sécurité, qui permettent de définir son contexte, dit
contexte global. De la même manière, nous proposons d‟associer ces
vues aux services abstraits constituant le processus ce qui permet de
décrire leur contexte propre. Par composition, ces différents contextes
permettent de construire le contexte global du processus commun.
La Figure 35 présente le contexte du processus collaboratif en
citant succinctement quelques éléments associés à ces vues.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
75
La vue de gestion permet de gérer le service abstrait. Un
ensemble de règles logiques est défini pour gérer les communications
entre services et la collaboration entre participants en permettant ensuite
de contextualiser le service.
Figure 35 : Description du contexte permettant une sélection et exécution
multi-contextuelles de services
Comme nous l‟avons déjà dit, ces services abstraits ne sont pas
associés à une implantation effective mais définissent l‟interface
publique d‟un service concret (entrées, sorties…), ce qui permet de
préserver la confidentialité sur les processus privés des entreprises. De
la sorte, un service abstrait peut être implémenté de manière « variable »
selon le contexte en masquant le processus « concret » effectivement
réalisé par chaque partenaire.
Processus collaboratif
Information Contextuelle
Vue Gestion
Qualité de service
- quantitatifs
- qualitatif
Préférences
Objets métiers
Règles métiers
Vue Sécurité
Authentification
Autorisation
Chiffrement
Certificat
Rôles
.
Vue Médiation
Appariement
- entrées
- sorties
Adaptation
- messages
- objets métiers
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
76
Figure 36 : Génération du processus concret en choisissant les services concrets
convenables
La vue de médiation permet transformer de le processus abstrait
en processus concret (ou d‟affaire). Pour chaque service abstrait il faut
trouver au moins un service concret en tenant en compte les
informations contextuelles au moment du déploiement. Au fur et à
mesure que le processus s‟exécute, le choix de chaque service concret
est révisé si les informations contextuelles sont changées. La sélection
est réalisé à partir du répertoire local de chaque entreprise : une requête
où figure les entrées et sorties nécessaires pour chaque service abstra it
est construite ce qui permet d‟extraire les services concrets
correspondants. Par ce biais, on peut composer dynamiquement une
chaîne de services concrets associés au processus de collaboration. La
Figure 36 illustre brièvement la génération du processus concret.
Chaque service abstrait dans le répertoire public est associé aux services
concrets qui les implémentent. C‟est la médiation qui trouve le service
convenable parmi les services concrets « candidats » en tenant compte
du contexte.
Figure 37 : Vue d‟agrégation du processus permettant la propagation des
informations
Les services concrets candidats
Médiation
Processus abstrait Processus concret
contexte
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
77
Enfin, la vue de sécurité permet d‟intégrer les contraintes de
sécurité dans la chaîne de services. Pour cela, chaque service concret
hérite d‟une politique de sécurité correspondant au contexte (rôle joué par
ce service, qui invoque ce service). Ceci permet d‟améliorer la gestion des
droits d‟accès en définissant globalement des politiques cohérentes
sélectionnées en fonction du contexte. La Figure 37 illustre comment un
processus collaboratif peut être représenté par la relation d‟agrégation
(top-down) qui relie ses services abstraits. Cette vue hiérarchisée permet
également de définir les informations contextuelles qui doivent se
propager moment de l‟exécution dans la chaine de services. A ce niveau, il
est possible de vérifier si les contraintes de sécurité, par exemple, peuvent
être s‟appliquées de bout en bout et si le médiateur devrait intervenir pour
assurer les transitions/transformations entre les contraintes à respecter par
chaque service. Dans la Figure 37 le rôle associé au processus est
„salesman‟ tandis que le rôle associé au service „S22‟ est „online
salesman‟. La médiation vérifie si le rôle „online salesman‟ peut avoir les
mêmes droits que le rôle „salesman‟ et elle assure ensuite la transition au
cours de l‟exécution.
Ces vues, qui seront détaillées dans la section suivante, sont
assemblées dans un Méta-Modèle d'entreprise (EMMA “Enterprise
Meta-Model Architecture“) pour permettre de générer des services
« contextualisés ». L‟architecture globale de notre approche est
présentée par la Figure 38. Elle présente deux répertoires publics de
deux entreprises (E1 et E2) qui contiennent respectivement leurs
services abstraits. Le répertoire partagé contient les processus
collaboratifs communs sous forme d‟hypergraphe conjointement conçus
par E1 et E2, et qui sont reliés aux services abstraits. Le médiateur qui
génère les objets contextes en tenant compte des trois vues, les rôles, et
les services abstraits.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
78
Figure 38 : Architecture globale
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
79
3.3 Spécification des différentes vues
3.3.1 La vue de gestion
Cette vue est destinée à supporter la première étape de sélection des
services pour construire un processus de collaboration puis d‟intégrer
leur spécification d‟interface pour composer une chaîne de services
cohérents, comme nous l‟avons vu dans la modélisation d‟entreprise,
nous proposons un logique d‟héritage pour permettre la définition de
services “particuliers“ instanciés à partir de modèles générique. Il faudra
définir d‟autres relations et règles de propagation car le seul mécanisme
d‟héritage seulement ne peut pas permettre la propagation des éléments
liés au contexte sur la chaîne de service qui représente le processus.
Dans la suite de cette section, nous présentons notre modèle de service
abstrait construit à partir d‟un modèle de collaboration défini ci -après.
Notre modèle de collaboration regroupe plusieurs participants
(donc plusieurs entreprises) désirant atteindre un objectif commun via la
collaboration. Un rôle définit la responsabilité d'un participant dans
l‟organisation du processus commun (par exemple dans l‟organisation
d‟une collaboration supportant une chaîne logistique, on trouvera des
rôles de vente, achat, production). Pour chaque rôle, on associe des
services abstraits qui permettent de remplir le cahier des charges fixé.
Un service abstrait est donc associé aux compétences liées au rôle. Ce
service peut aussi être associé à plusieurs services concrets qui décrivent
comment ce service abstrait sera mis en œuvre. Par exemple pour un
service de production (d‟un bien ou service), on pourra associer la
gestion de l‟approvisionnement, la production et la gestion des
expéditions). Cette modélisation réutilise pleinement les travaux de Mlle
Rajsiri [76] qui propose une ontologie CNO (collaborative network
ontology) qui couvre à la fois la collaboration d'interentreprises et les
domaines de collaboration des processus. Cette ontologie se compose
des concepts, relations et des règles de déduction propres au domaine de
l‟entreprise. Elle permet de représenter les comportements collaboratifs
entre les partenaires. Cette ontologie fédère plusieurs sous-ontologies, à
savoir :
- l'ontologie de collaboration (CO) est organisée en deux
parties principales : le participant et la collaboration.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
80
I) Le participant comprend trois concepts : le participant qui
peut être un acteur physique ou une entreprise qui utilise le réseau pour
atteindre un objectif commun avec d'autres participants, le rôle qui
définit le rôle d'un participant dans le réseau. Par exemple : vendeur,
acheteur et le service abstrait qui est un service qui décrit les
compétences du participant.
2) La partie de collaboration concerne les critères de
caractérisation de la collaboration : un objectif commun, participant,
relation.
- L'Ontologie de processus de collaboration CPO se réfère à la
conceptualisation d'un processus de collaboration.
Comme dans ce travail, le processus de transformation du
modèle CIM en modèle PIM puis PSM passe par un remplacement des
services abstraits par des services concrets (dits services de Business
dans les travaux de Mlle Rajsiri). Comme nous l‟avons dit dans la
présentation de notre architecture, nous enrichissons l‟approche de Mlle
Rajsiri en intégrant le contexte (cad qui invoque quel service, dans
quelles conditions en utilisant quels moyens d‟accès et avec quelles
exigences de qualité de service) dans le processus de recherche des
services concrets substituables aux services abstraits. Ceci nous conduit
donc à coupler la notion de contexte aux services abstraits.
La Figure 39 illustre les relations entre ces concepts.
Figure 39 : Relations entre le participant, le rôle, et le service abstrait
Un processus de collaboration est associé à un groupe d‟au
moins deux participants qui voudraient travailler ensemble en réponse à
un ou plusieurs objectifs communs. Une relation définit l'interaction
entre les participants comme par exemple une relation client/fournisseur,
une relation de type donneur d‟ordre / sous-traitance. Ces relations
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
81
permettent d‟intégrer le type de collaboration dans la spécification du
contexte global (Figure 40). La juxtaposition de ce contexte de
collaboration à la définition du service abstrait permet de construire le
modèle global (Figure 41).
Figure 40 : les relations entre les concepts dans le processus de collaboration.
Figure 41 : les éléments de modèle de collaboration (génération le service)
A partir de ce modèle, nous avons défini des règles logiques
destinées à représenter le service : une première permet de sélectionner
les services abstraits associés à des rôles alors qu‟une autre règle permet
de retrouver les services d‟affaire (donc les services concrets)
correspondant au contexte.
1) Sélection des services abstraits à partir du rôle : Cette
première règle de sélection des services abstraits repose d‟abord sur
l‟identification des rôles associés au participant pour ensuite extraire les
services abstraits pouvant être invoqué avec ces rôles. Si la liste de
services sélectionnés en fonction du rôle et du contexte n‟est pas vide,
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
82
la règle retourne le premier service de la liste. Ceci nous conduit à la
formalisation suivante :
Partner(x) HasRole(x, y) ListOfAbstractServicesByRole (y, z) Context(v)
SelectContextuelAbstractService(x, y, z, v).
La partie B de la Figure 42 montre comment la règle ci-dessus
fonctionne à partir d‟un exemple.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
83
Figure 42 : Exemple montrant la sélection du service abstrait à partir du rôle
Le participant A peut jouer un rôle de vendeur. A ce rôle, on
associe plusieurs services abstraits comme vendre un produit ou vendre
un service. Ces services abstraits sont différenciés car ils correspondent
à des processus différents dans l’entreprise, même si leur rôle dans une
chaîne de service est identique
2) Règle de sélection des services concrets (appelé aussi
services d’affaire) à partir des services abstraits : Soit un participant
x dans un processus collaboratif qui fournit un service abstrait, y, dans
un contexte bien défini, v. Il important de choisir le service concret
approprié. Cette règle commence par rechercher les services concrets qui
correspondent aux services abstraits fournis par le participant avant de
renvoyer la liste de services d‟affaire que le participant devrait utiliser
pour implémenter le service abstrait contextualisé.
Partner(x) HasContextuelAbstractService(x, z) ListOfConcretServices(y, z)
SelectConcretService(x, y, v).
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
84
La partie B de la Figure 43 montre comment la règle ci-dessus
fonctionne à partir d‟un exemple.
Figure 43 : Exemple montrant la règle de sélection des services concrets
à partir des services abstraits
Le participant A joue un rôle de vendeu. A ce rôle on associe
plusieurs service abstrait (vendre prouduit). A chaque service abstrait
on peutr associer un ou plusieurs services concrets élémentaires ou
composites. La recherche du service concret est réalisée en fonction du
contexte et peut nécessiter la composition de plusieurs services
élementaires pour supporter le processus effectif (depuis la gestion de la
commande, jusqu’à la préparation de la livraison et la facturation).
Une fois sélectionné, une règle contrôle l‟exécution du service.
Soit deux partenaires P1 et P2, fournissant des services abstraits x et y. Il
faut s‟assurer de la compatibilité des entrées et sorties pour permettre
une bonne composition :
Soient deux Participant P1, et P1, et respectivement leur service
concret s1 et s2. L‟exécution de s2 dépend de la compatibilité entre les
propriétés fonctionnelles et non fonctionnelles de deux services, du
contexte actuel et en particulier du rôle de chaque partenaire au moment
de l‟exécution. La règle de médiation est la suivante
PartnerConcreteService(P1, s1) PartnerConcreteService(P2, s2)
MediateFunctionalPropertiesBetween(Output(s1), Input(s2))
MediateNonFunctionalPropertiesBetween(Role(s1), Role(s2))
PropagateContext(s1, s2) InvokeService(s2)
Cette formalisation logique permet de raisonner sur les
services, d‟automatiser la sélection des services abstraits, concrets
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
85
contextualisés et la médiation avant l‟invocation. Ceci nécessite un
ensemble d‟ontologies décrivant, les propriétés fonctionelles et non
fonctionelles, le contexte et les rôles, et un ensemble de règles pour
implémenter les prédicats utilisés dans ces règles logiques.
En conclusion, nous avons vu comment la vue de gestion
permet de gérer la communication entre les services. Dans la section
suivante, nous nous focaliserons sur la vue de médiation avant de
prendre en compte les politiques de sécurité.
3.3.2 La vue de médiation
Dans cette vue nous considérons le service comme une boîte noire. Il
consomme un message et produit un autre message. Un message se
compose de plusieurs propriétés ou attributs. Chaque attribut est associé
à un type de données. Nous schématisons un service en fonction de ses
entrées et sorties comme montrer dans la Figure 44.
Nous avons vu dans la section précédente comment
sélectionner un service concret à partir d‟une liste de services concrets
qui implémentent réellement un service abstrait contextuel. Dans la
suite, nous expliquons comment construire cette liste de services
concrets qui correspond à un service abstrait identifié par les partenaires
pendant dans la construction du processus collaboratif commun. Dans un
premier temps, la construction de cette liste est basée sur les propriétés
fonctionnelles du service abstrait-- notamment les attributs d‟entrée et
de sortie --, la notions de sous-typage et la transformation des ces
attributs pour qu‟elles correspondent respectivement aux attributs
d‟entrée/sortie des services concrets.
Figure 44 : Définition d‟un service
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
86
Nous définissons le service concret noté S de la manière
suivante en prenant en compte ses entrée/sortie: S= {D entrée, D sortie}, où
D entrée= {di/di est l‟attribut de la donnée d‟entrée de type ti}
D sorties= {di/di est l‟attribut du donné de sortie de type ti}
De la même manière, nous définissons un service abstrait, noté
R par ses attributs d‟entrée/sortie R={R entrée, R sortie} où
R entrée= {d i/d i est l‟attribut d‟entrée du service abstrait de type t i}
R sortie= {d i/d i est l‟attribut de sortie du service abstrait de type ti}
Pour trouver le service concret (ou les services concrets) qui correspond
(correspondent) à un service abstrait R, nous proposons un mécanisme
de médiation entre les attributs d‟entrée et sortie du service abstrait et
les attributs d‟entrée et sortie de tous les services concrets du répertoire
local. Cette médiation s‟appuie sur la similarité sémantique (noté ) et
la similarité de typage (noté ): La similarité sémantique estime le
degré de proximité entre la signification de deux attributs et évalue la
relation sémantique qui les relie [73]. Le typage consiste à associer à un
attribut le type de sa valeur. Le type définit les valeurs que peut prendre
une donnée, ainsi que les opérateurs qui peuvent lui être appliqués. Un
type pourrait être un booléen (valeurs vrai ou faux), un entier (signé ou
non signé), un réel en virgule flottante et une chaîne de caractères.
Certains types correspondent à d'autres structures de données plus
complexes. Par exemple, le type composé adresse postale est composé
de numéro de rue, nom de la rue, et code postale. Le typage signifie en
plus que tout attribut a un type et que les attributs ne peuvent se
combiner qu'en respectant des règles de "typage". Par exemple,
concaténer une adresse (chaîne de caractères) et un numéro de téléphone
(entier positive). La similarité de typage entre deux attributs s‟assure
que leur types sont identiques ou bien qu‟il est possible de détecter une
conversion de type implicite (par exemple, un entier est un réel, un réel
est transformable en une chaîne de caractères, etc..). Nous nous
appuyons sur les travaux développés dans le cadre de la thèse de Patrick
Hoffmann [74] pour renforcer notre mécanisme de médiation et
implémenter la similarité sémantique et la similarité de typage en
utilisant des ontologies basées sur le contexte.
Etant donnée un service abstrait, il faut découvrir les services concrets
dont les attributs d‟entrée et sortie sont similaires. Ceci nous conduit à
la formulation suivante :
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
87
D entrée de service d‟affaire (concret) R entrée de service abstrait
D sortie de service d‟affaire R sortie de service abstrait
D entrée de service d‟affaire (concret) R entrée de service abstrait
D sortie de service d‟affaire R sortie de service abstrait
A partir d‟une chaîne de services abstraits, on peut alors utiliser
cette règle de médiation pour découvrir les services concrets candidats
qui peuvent implémenter le service abstrait . Puisque les services
concrets peuvent être implicitement interconnectés par des relations
d‟héritage pour exprimer une variation dans leur contexte d‟utilisation
(généralisation ou spécialisation), il s‟avère important de sélectionner
parmi les services concrets candidats le service correspondant au
contexte courant d‟exécution. Ceci se traduit par le parcours de l‟arbre
d‟héritage de ces services et la comparaison entre le contexte du service
abstrait et le contexte associé à chacun de ces services concrets.
On répète cette procédure pour chaque service abstrait. Ceci
permet donc transformer étape par étape la chaîne de services abstraits
en chaîne de services concrets. Il ne reste alors plus qu‟à intégrer les
contraintes de sécurité.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
88
3.3.3 Vue de sécurité
Pour sécuriser l‟interconnexion entre les différents services abstraits et
par conséquences entre les différents services concrets nous traiterons
les exigences de sécurité par le moniteur.
Pour améliorer la gestion des droits d‟accès et répondre aux exigences
de sécurité de manière cohérente entre les chaînes de service, nous
définissons deux classes de droits d‟accès liés à deux rôles différents :
propriétaire et membre. Chaque service a un propriétaire unique à un
moment donné. Le propriétaire définit le niveau de sécurité du service,
les niveaux d‟authentification et les droits d'accès affectés aux
utilisateurs ou services. Les membres sont considérés comme des
utilisateurs ou autres services qui ont l‟autorisation de manipuler le
service en question via son interface et via les méthodes d'accès.
Pour gérer les différents contextes, nous proposons d‟utiliser un
ensemble de services interconnectés par une relation d‟agrégation afin
de composer le processus collaboratif commun (i.e. la chaîne de
service). Chacun d‟eux est associé à un contexte particulier. En plus, le
processus collaboratif est associé à son tour à un contexte globale.
Figure 45 : Mécanisme de propagation de contraintes de sécurités via le médiateur
contexte
local
contexte global
S2
S3
S4
S5
Processus métier
S22
S21
S2
Processus métier
S5
S4
S3
contraintes sécurités
locales
contraintes sécurités
globales
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
89
Dans le contexte de la sécurité, la relation d‟héritage définit une relation
de référentiel entre les services dérivés pour traiter la propagation de
contraintes de sécurité d‟une façon similaire à l‟approche orientée objet .
A titre d‟exemple, nous considérons deux hiérarchies de services
(classes) C et D, et une relation d‟agrégation entre D et C. Chaque
service dans chacune de ces deux hiérarchies encapsule les méthodes
d‟accès aux données et les méthodes spécifiques utilisées pour
manipuler ses attributs. Comme illustré dans la figure, les deux services,
S1 et S2, font respectivement partie de C et D. S1 hérite les propriétés,
en particulier la sécurité des composants et des méthodes, de son service
de base (superclasse) dans l‟hiérarchie d‟héritage de C. Il en va de même
pour D. Comme il existe une relation d‟agrégation entre C et D, (c-à-d
C est un service composite ayant parmi ses constituants, un service de la
hiérarchie d‟héritage de D), la médiation (et par la suite le médiateur)
assure la comptabilité de sécurité et la propagation de ses contraintes
(par exemple, rôle, token, etc) du service composite au service
composant comme illustré dans la Figure 46.
Figure 46 : Les droits d‟accès et l‟héritage entre les objets
Les droits d'accès tels que l‟invocation d‟une méthode de
lecture ou d‟une méthode de modification de valeurs d‟attributs sont
principalement gérés par le propriétaire du service. Il accorde ses droits
aux membres identifiés par leurs rôles. Les droits sont présentés par un
triplet de règles d'accès définies par la relation suivante < R, S, m, o >
qui définit que le membre ayant le rôle R, sont autorisés à manipuler
l‟hiérarchie d‟héritage de services S (qui pourrait être un singleton), via
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
90
la méthode m selon les modes o de lecture (r), écriture (w), ou rien (x).
Ci-dessous un exemple de droits d'accès qui peuvent être modifiés et
ajustés, y compris en ajoutant de nouveaux droits d'accès et où en en
révoquant par le propriétaire du service AchatEnligne et le service
GestionVente.
< Salesman, AchatEnligne, validerCommande, r >
< Client, GestionVente, annulerCommande, x >
< Anonyme, AchatEnLigne, PasserCommande,w >
Les listes des droits d'accès sont continuellement ajustées : quand une
classe est modifiée, les sous-classes et les droits d'accès à l‟objet sont
également adaptés (ajout ou révocation dans la liste d'accès), sauf si le
propriétaire de l‟objet a manuellement changé cette liste.
La mise en place de cette vue permet donc d‟adapter
dynamiquement le contrôle d‟accès au contexte d‟invocation du service
et de simplifier la spécification de ces droits d‟accès.
3.3.4 Conclusion
Dans cette section, nous avons présenté les différentes vues de
notre modèle qui permettront de faciliter la contextualisation des
services. Ainsi, nous avons défini une vue de gestion associée à des
services abstraits, eux-mêmes associés à des rôles. La notion de contexte
(qui accède à quoi avec quelles exigences de qualité et via quels moyens
d‟accès) a été utilisée pour permettre de « tisser » les différentes
politiques et sélectionner les services concrets adaptés. Ceci est réalisé
grâce à la vue de médiation qui permet de définir des relations vers des
services concrets. Enfin, la vue de sécurité permet de définir les
éléments liés à la politique de sécurité. Cette organisation multi -vues
enrichie la démarche de Mlle Rajsiri [76] en permettant une
contextualisation des services lors de la transformation CIM vers PIM
puis PSM et prolonge la séparation multi-niveaux introduite par [69]: en
spécifiant des relations de rôles entre service, il devient plus « simple »
de sélectionner les services abstraits répondant à un besoin puis
d‟exploiter les relations existants avec les services concrets et éléments
de sécurité pour permettre de construire un processus concret
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
91
contextualisé. Ces différents principes sont présentés dans la section
suivante.
3.4 Exploitation du modèle :
Pour montrer comment les différentes vues de ce modèle sont
exploitées pour former un processus collaboratif, nous allons nous
intéresser à la phase de conception de ce type de processus. En effet,
lorsque des partenaires veulent collaborer, ils décrivent un processus
abstrait qui servira de base aux contrats de collaboration. Pour cela, la
notation graphique BPMN est fréquemment utilisée. Plusieurs travaux
de recherche ont porté sur la transformation d‟un modèle décrit en
BPMN (donc de manière abstraite) en processus concret BPEL.
Figure 47 : Construction du processus de collaboration par une série de
transformation de modèles (MDA)
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
92
Notre démarche est différente comme l‟indique la Figure 47:
dans un premier temps, la chaîne de services abstraits est conçue en
utilisant la notation BPMN. A la différence des autres travaux, la
transformation en BPEL n‟est pas réalisée en interprétant le processus
défini en BPMN mais en procédant par substitution. Ensuite, nous allons
rechercher dans les répertoires les services abstraits correspondant au
besoin en nous intéressant aux opérations qui doivent être réalisées par
le participant en fonction du rôle qu‟il doit jouer dans le processus
Transformation
Processus à base de services abstraits multi-contextuels (BPEL abstrait)
Vue Médiation
Vue Gestion
Vue Sécurité
Contexte
Processus à base de services concrets multi-contextuels (BPEL Concret)
Moteur BPEL étendu
Processus collaboratif commun (BPMN)
Transformation
Exécution
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
93
collaboratif : on procède d‟abord à une extraction du rôle du participant
puis on extrait les services abstraits utilisables avec ce rôle : on utilise
alors la vue de gestion. Ensuite, pour chaque service abstrait, on va
rechercher les services d‟affaire qui peuvent le mettre en œuvre : il
s‟agit alors d‟exploiter la vue de médiation. Pour chaque service
abstrait, on recherche alors les services d‟affaire substituable dans le
répertoire du partenaire concerné. De cette manière, les interfaces sont
respectées. Ceci nous conduit à formaliser la règle suivante :
Soit un processus de collaboration PC composé de services
abstraits yi et Soit un partenaire P i pouvant fournir un service concret x i
permettant de mettre en œuvre les fonctionnalités du service abstrait yi.
On dira que si le service xi concret correspond au service yi abstrait
alors le service concret x i peut être substitué au service abstrait y i.
Pour établir une collaboration, les partenaires sélectionnent les
services abstraits et construisent ensemble le processus collaboratif
commun. On établit des relations entre services abstraits qu‟on répercute
ensuite entre les services concrets. Nous notons P i un partenaire offrant
un ensemble de services (abstraits et concrets) s (s Pi) noté pi(x). Ces
services sont répartis en services abstraits yi et services concrets xi
associés aux services abstraits. Si y1 est un service abstrait de partenaire
P1, y2 est un service abstrait du partenaire P2 et que y1et y2 sont liés par
une relation R, alors cette relation R est répercutée entre les services
concrets associés aux services abstraits : une relation R’ est créée entre
les services concrets x1 et x2 associés respectivement aux services
abstraits y1 et y2.
Cette logique de transformation par substitution de services
permet à la fois de respecter la séparation entre processus publics
(publiés comme des services abstraits) et privés (services qui seront
effectivement exécuté et intègre des connaissances sur le
fonctionnement exact de l‟entreprise) et de composer et orchestrer le
processus de collaboration « au vol » et donc de choisir le service
concret qui sera invoqué en fonction du contexte exact.
Une fois réalisée la sélection du service concret convenable, la
dernière étape consiste à intégrer les services « techniques » de sécurité.
En effet, si la séparation entre services publics et privés offre un premier
niveau de protection aux entreprises, il importe également de prendre en
compte les politiques de sécurité (gestion des droits d‟accès en
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
94
particulier). Pour cela, nous définissons deux services « techniques »
d‟authentification et d‟autorisation qui peuvent être ajoutés lors de
l‟opération de composition avant d‟invoquer un service concret :
1) Le service d‟authentification : Ce service vise à établir de
manière certaine l‟identité de celui qui invoque un service
soit pour conserver la trace « nominative » de l‟invocation
soit en préalable d‟une demande d‟autorisation. Lors de la
récupération des informations nécessaires à
l‟authentification, ce service prend en charge la protection
de ces informations (chiffrement des échanges, signature
du message…) afin de garantir qu‟aucune capture
d‟information conduisant à une usurpation d‟identité
ultérieure ne puisse être faite. De même, les bases
contenant ces informations seront protégées.
2) Le service d‟autorisation définit les droits d'un service et
les autorisations sur un système. Une fois l‟identité prouvé
(donc après l‟invocation du service d‟authentification), le
service d‟autorisation détermine ce que l‟utilisateur du
service invoqué (humain ou service appelant) peut
effectuer sur le service invoqué (utilisation d‟une opération
particulière par exemple).
Par exemple dans le cadre d‟un processus d‟achat en ligne de
pièces détachées, on aura une chaîne de différents services : présentation
et sélection des produits, gestion de la commande, gestion du paiement.
Dans le cadre du service de paiement, on devra échanger de manière
sécurisée des informations financières (numéro de carte de crédit,
gestion de l‟authentification du client). Pour cela, il faudra donc
composer les services d‟authentification et de gestion des autorisations
auprès de la banque pour poursuivre la transaction. En revanche, lorsque
le processus d‟achat est mené par une entité de l‟entreprise (par exemple
commande interne de pièces détachées par le SAV), le processus de
facturation interne n‟impose que l‟authentification de l‟utilisateur qui
invoque le service et non une quelconque demande d‟autorisation
bancaire.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
95
3.5 Conclusion
Pour faciliter la collaboration entre entreprise, nous avons proposé de
recourir à une stratégie « orientée service » permettant de composer un
processus commun. En dotant chaque entreprise d‟un répertoire, des
services abstraits (représentant son offre de collaboration) peuvent être
exposés. L‟organisation en hypergraphe permet de définir différentes
vues pour permettre, grâce à la spécification de relations typées, de
faciliter la définition de services concrets contextualisés. L‟organisation
précise de ces mécanismes est présentée dans le chapitre suivant.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
96
Chapitre 4
Modélisation d'entreprises collaboratives
par des graphes de d’héritages de
services
4.1 Introduction
Afin d‟assurer la collaboration et l‟interconnexion de processus
inter entreprises, nous avons introduit une approche originale qui
s‟appuie sur une collaboration à base de services multi-contextuels. Les
services métiers qui sont partagés par les partenaires sont modélisés
selon trois vues différentes et complémentaires à savoir la vue de
gestion, la vue de médiation et la vue de sécurité. En plus, nous ne
considérons pas ces services comme des composants fonctionnels
indépendants facilitant ainsi la composition de processus collaboratifs
mais nous introduisons plusieurs types de relations implicites et non
intrusives entre les services. Ces relations, qui sont maintenues par des
répertoires, facilitent la découverte des services, enrichissent la
composition et permettent l‟exécution en tenant compte du contexte.
Dans ce chapitre nous définissons le concept d‟hypergraphe d‟un
service. En effet, les hypergraphes sont des grappes de graphes qui
permettent de spécialiser des relations sémantiques entre les services et
les processus offerts par les partenaires. Les relations visent à faciliter la
mise en place des processus collaboratifs et mieux gérer leurs
interactions. En particulier, nous considérons les relations de type
héritage qui sont vues comme un procédé de partage et d‟échange
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
97
d‟information dans une structure hiérarchique regroupant des sous
ensembles d‟entités (services ou processus métiers). Dans ce contexte,
les services sont décrits par des caractéristiques ou propriétés
fonctionnelles et non fonctionnelles. La structuration hiérarchique nous
permet de factoriser les propriétés communes à plusieurs entités afin de
faciliter leur définition et la maintenance de l‟ensemble (meilleure
cohérence). Ainsi, une propriété qui caractérise une entité est héritée par
toutes ses sous entités inférieures. Chaque sous entité se définit par ses
propres propriétés ainsi que par les propriétés héritées des entités
supérieures. Dans cette organisation, il est possible d‟associer un
mécanisme capable de restituer la définition complète d‟une entité à
partir de ses propriétés propres et héritées. De façon plus abstraite, nous
regroupons les entités en graphes : un arc représentent une relation
d‟ordre partiel appelée relation d‟héritage et les nœuds représentent les
sommets du graphe annotés par des propriétés fonctionnelles et non
fonctionnelles. La relation d‟héritage est unidirectionnelle et orientée du
plus spécifique au plus générique. Elle exige en plus que chaque nœud
hérite des propriétés des nœuds les plus génériques. Dans notre contexte,
la collaboration entre les entreprises s‟appuie sur un répertoire commun
comprenant des structures d‟hypergraphes permettant la réalisation des
objectifs métiers et des scénarios de collaboration. Une entreprise
pourrait aussi être représentée par des hypergraphes représentant ses
activités en termes de processus ou services à partager. Les relations
d‟héritage permettent d‟offrir une variété d‟utilisation de ces processus
ou services dans des différents scénarios d‟utilisation. Figure 48, illustre
un hypergraphe contenant les processus ou services métiers composites
(nœuds) et des liens génériques d‟interconnexion entre eux.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
98
Figure 48 : Modélisation des processus en termes d‟hypergraphe
Dans les sections suivantes, nous présentons la collaboration
entre les entreprises en utilisation les hypergraphes afin de construire les
chaînes de collaboration globale à base de services. Nous également
discutons l‟enchainement des services et les contraintes de transaction
entre eux. Enfin, nous enrichissons la construction d‟hypergraphe en
utilisant différents types de relations entre les services à savoir les
relations d‟héritage, d‟agrégation, etc…
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
99
4.2 Mécanismes d’héritage
Dans notre contribution nous proposons d‟adopter le
mécanisme d‟héritage développé dans l‟approche orientée-objet et
l‟appliquer aux développements de services métiers et aux
collaborations contextuelles. En effet, dans la vie pratique de
l‟entreprise, nous avons constaté que la plupart de services métiers qui
sont mis à disposition des partenaires ont subi des modifications
successives selon la variété d‟utilisation dans des contextes différents.
Cette tendance est bien connue dans le secteur de l‟innovation qui
favorise la différenciation de produits existants en ajoutant quelques
fonctionnalités afin de fournir de nouveaux produits et conquérir de
nouveaux marchés. La relation d‟héritage permet ainsi d‟établir un lien
indiquant qu‟un service est une spécialisation d‟un service plus
générique (super-service). La spécialisation d‟un service existant décrit
un contexte plus restreint pour son utilisation tout en gardant le
sémantique métier hérité de son super-service. Ce recours à l‟approche
et le sémantique objet est issu du constat que le concept service
ressemble au concept classe de l‟approche orienté-objet, qui s‟avère être
utile dans le domaine de génie logiciel.
Nous expliquons dans cette section le mécanisme d‟héritage
pour innover et développer de services contextuels. Il s‟agit d‟une
approche incrémentale pour différencier les services à fournir aux
partenaires ainsi que leurs intégrations dans des processus collaboratifs.
A l‟exécution, les informations contextuelles pourraient guider le
moteur d‟exécution d‟un processus collaboratif à bien choisir un service
convenable sans mettre en cause la construction entière du processus.
Avant d‟introduire le mécanisme d‟héritage entre services et en
particulier l‟héritage de propriétés fonctionnelles et non fonctionnelles,
nous rappelons que le concept classe ou objet est définit par identifiant,
type et méthodes :
L‟objet est défini par son nom et les propriétés associées à
lui. Par exemple : O1 : [nom : Jaque, numéro compte : 1993]
et O2 : [nom : Eric, numéro compte : 2404]
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
100
Type d‟objet : La structure d‟un objet comporte des
propriétés (attributs) simples (entier, réel, chaîne, etc..) ou
complexes et les méthodes (opérations). Un objet est dit de
type complexe s‟il est une structure qui regroupe plusieurs
types simples ou complexes (récursives).
Les méthodes (ou opérations) : chaque objet est spécifié par
un ensemble de méthodes. Exemple d‟un attribut pour
réserver un avion [numéro : intègre, nom : string, date allé :
date, prix de billet : real] et une méthode pour payer le prix
d‟un ticket, payer(montant : real).
4.3 Héritage entre services (objets)
Afin de détailler le mécanisme d‟héritage, nous nous intéressons aux
propriétés des objets qui représentent les services dans notre contexte.
Dans chaque service il existe des propriétés fonctionnelles (messages
d‟entrée, messages de sortie, conditions, etc.) et des propriétés non
fonctionnelles (sécurité, QoS, etc.). La Figure 49 illustre une vue
abstraite du modèle service.
Figure 49 : Le modèle de service vu comme un objet qui encapsule les propriétés et les
méthodes
4.3.1 Héritage avec les propriétés fonctionnelles
Le mécanisme d‟héritage entre les services permet d‟hériter
les propriétés et les opérations. Notons que les propriétés héritées
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
101
peuvent être redéfinies ou renommées. Ce mécanisme permet la
transmission de propriétés, attributs et méthodes des services/objets qui
sont dans les super-classes (services) vers les services/objets qui sont
dans les sous-classes (services). En conclusion, les sous-services
pourraient redéfinir, renommer les attributs ou modifier le
comportement de certaines opérations. Dans notre cas quand le
service 2S hérite du service 1S , 2S peut garder les mêmes paramètres
mais on peut aussi ajouter de nouveaux paramètres. Par exemple
l‟héritage entre les deux servies 1S (consulter compte en France) et
2S (consulter compte depuis l‟étranger), nécessite de prendre en compte
un nouveau paramètre (pays) comme illustré dans la Figure 50.
Figure 50 : L‟héritage entre les services
4.4 Les propriétés non fonctionnelles et le mécanisme d’héritage
Les propriétés non-fonctionnelles de services fournissent des
informations supplémentaires pour que les services s‟exécutent dans les
meilleures conditions possibles et dans différents contextes. Ces
propriétés incluent à titre d‟exemple les paramètres de qualité de
service QoS tels que la fiabilité, la sécurité, la performance, le temps de
réponse etc.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
102
Selon [70] la qualité de service est définie comme “quality is
expressed referring to observable parameters, relating to non-
functional property“.
La qualité de service peut être divisée en deux catégories
comprenant la qualité d'exécution et la qualité métier.
1) La qualité d'exécution représente la mesure de propriétés qui
sont liées à l'exécution d'une opération, Nous distinguons cinq
catégories de qualité d‟exécution à savoir: le temps de réponse, la
fiabilité, la disponibilité, l'accessibilité et l'intégrité [71][72][56].
Temps de réponse : mesure le délai prévu entre le
moment où une opération envoie une requête et le moment
où les résultats sont reçus.
Fiabilité : concerne les échanges des messages entre les
différents services. Elle assure les messages envoyés et
reçus par les demandeurs de service et les fournisseurs de
services ne sont ni perdus ni erronés.
La disponibilité : elle concerne la capacité du système à
offrir les fonctionnalités pour lesquels il a été conçu. Il
s‟agit de s‟assurer que le service est opérationnel au
moment où il est sollicité [56]..
L'accessibilité : elle mesure le degré selon lequel une
opération d‟un service est capable de répondre à une
requête venant d‟un service web. L‟accessibilité peut être
exprimée comme une probabilité mesurant le pourcentage
de succès ou la chance de succès d‟instanciation du service
à un instant donnée. (on différencie le cas où le service
Web est fonctionnellement disponible mais ne peut être
effectivvement instancié (manque de ressources locales…)
[56].
L'intégrité : mesure la capacité d‟une opération de service
à assurer correctement l'interaction.
L’exactitude : est définie comme le taux d'erreur produit
(généré) par le service dans un intervalle de temps. Cette
variable doit être minimisée.
La performance : est mesurée en termes de débit
(throughput) et de latence (latency). Le débit représente le
nombre de demandes de service Web servis dans une
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
103
période donnée. La latence : est le temps qui s‟écoule
entre l'envoi d'une requête et la réception de la réponse
([75] page 44).
La qualité métier permet l'évaluation d'une opération de
service d‟un point de vue métier. Par exemple : le coût
mesure le prix qu'un demandeur de service doit payer pour
invoquer l'opération de service.
Dans l‟héritage de propriétés non fonctionnelles, les besoins sont hérités
de la super-classe. Par exemple, quand le service 2S hérite du service 1S
il prend les valeurs des attributs de sécurité de S1 mais aussi les valeurs
associées aux exigences non fonctionnelles en ce qui concerne le
contexte d‟exécution (temps de réponse, coût,…), voir la Figure 51.
Figure 51 : héritage avec les propriétés non fonctionnelles
4.5 La construction de l’hypergraphe
Afin de réaliser les interconnexions entres les différents
services, nous nous sommes basés sur le mécanisme d‟héritage. Par la
suite, nous généralisons ce concept pour construire un hypergraphe de
service contenant tous les services métier de l‟entreprise. L‟hypergraphe
est composé par les services interconnectés par différents types de
relations à savoir : la relation d‟agrégation, la relation de
recommandation, et la relation de collaboration.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
104
Nous définissons l‟hypergraphe Ch comme un ensemble de
services concrets qui forment les nœuds et qui sont reliés par des arcs.
Les arcs désignent les relations d‟interdépendance entre les services
(nœuds). Soient deux services ci et cj de l‟hypergraphe, l‟arc qui relie
ces deux services est noté par cjci a =( ic , jc ).
Pour permettre de contextualiser les services concrets, nous
organisons le répertoire locale de chaque entreprise dans un hypergraphe.
Nous définissons l‟hypergraphe Ch comme un tuple (C, A) ; c-à-d
Ch =(C,
A) sachant que C désigne l‟ensemble de tous les services concrets de
l‟hypergraphe Ch tel que C = {ci} et A l‟ensemble de tous les arcs entre les
services de l‟ensemble C tel que A = { cjci a }.
La Figure 52 présent graphiquement un exemple d‟arborescence d‟un
hypergraphe Ch et montre que la relation ciacj relie sémantiquement les
deux services ci et cj. Par analogie à l‟approche orienté objet, les
services sont similaires aux classes, les arcs sont similaires aux relations
d‟interdépendance (par exemple héritage). Chaque service peut être
exécuté en parallèle plusieurs fois dans un contexte de montée en charge
ou en gestion transactionnelle ce qui ressemble aux objets instanciés
d‟une classe donnée. Les services sont présentés par des rectangles et les
instances sont présentées par des cercles. Par exemple, le service ci a
deux instances qui s‟exécutent en concurrence.
Figure 52 : Exemple d‟arborescence
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
105
Nous notons par Mi l‟ensemble de tous les attributs d‟un service ci. Mi,p
désigne l‟attribut p du service ci Dans notre contexte, les attributs
représentent les messages d‟entrée et de sortie et les propriétés non
fonctionnelles d‟un service. Par exemple dans la Figure 53, le service ci
possède implicitement par le mécanisme d‟héritage l‟ensemble des
attributs des tous ses services supérieures, notamment les attributs mo,1 et
mo,2 du service co, mh,1 du service ch et mi,1, mi,2 et mi,3 du service ci.
Figure 53 : Les attributs de la classe
A l‟exécution, un service peut être exécuté en plusieurs
instances. Pour cela, nous proposons de différentier les instances de
services dans un hypergraphe afin d‟apporter un traitement individuel à
chaque instance et établir de relations inter-instances de services qui
reflètent la situation réelle de l‟exécution à un moment donné. Dans la
section suivante nous construisons l‟hypergraphe des instances et nous
montrons son utilité. Dans le paragraphe suivant nous expliquons
comme noter les instances d‟un service de l‟hypergraphe.
Nous notons par oim l‟instance appelée m du service ci.
L‟ensemble de tous les instances du service ci est noté par oi tel que oi
= { oim } et oi
m oi. La notion d‟instance est importante dans le
contexte d‟une gestion transactionnelle et d‟exécution répartie de
service. En effet, certains fournisseurs de services exécutent en
parallèle plusieurs instances d‟un service pour monter en charge et
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
106
répondre aux requêtes avec un temps de réponse acceptable, même en
cas d'affluence massive. L'équilibrage de charges consiste à distribuer
un service sur un pool de machines afin de s'assurer de la disponibilité
d‟un service, en n'envoyant des requêtes qu'aux instances en mesure de
répondre.
En conséquence, les attributs d‟une instance oim d‟un service ci
est noté aipm pour p=1, ..,n Toute instance oi
m possède implicitement,
de plus de ses attributs, les attributs de l‟ensemble de toutes ses super-
instances. Elles constituent l‟ensemble aipm des attributs de l‟instance
oim (voir Figure 54)
Figure 54 : L‟ensemble des attributs de l‟objet
Une instance possède autant d‟attributs que son service et hérite
aussi les attributs aim de toutes les instances qui la précédent dans
la hiérarchie d‟héritage.
4.6 Construire l’arborescence des instances
Après la construction de l‟hypergraphe nous présentons la
construction de l‟arborescence des instances. L‟arborescence des
instances constitue une vue réelle d‟un ensemble de services au cours
de l‟exécution à un moment précis. Cette vue est utile pour décrire les
cycles de vies des services en termes d‟états de transition (activé,
annulé, échoué, compensé, terminé, etc..) et expliquer comment les
contraintes sont propagés au cours de l‟exécution. Le mécanisme de
transition et la propagation seront introduits plus tard dans ce chapitre.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
107
Soient l‟arborescence hc et deux sommets ci et cj tels que cj est
le successeur direct de ci , tout sommet oim peut être relié à un ou
plusieurs sommets ojn par un arc
nj
mi
o
cj
o
ci a à condition que les attributs ain
de l‟instance ojn soient identiques à l‟ensemble des attributs ai
m de
l‟instance oim
O={m
io },
nj
mi
o
cj
o
ci a =(m
io ,n
jo ), a=
nj
mi
o
cj
o
ci a2o , oh =<o, a>, voir la Figure 55.
Figure 55 : L‟arborescence de l‟objet
Le service ci peut joindre un ou plusieurs services par
l‟intermédiaire des relations. Une relation joignant ci à cj est
noté : ),( jicck ccL
ji . Si deux services ci et cj possèdent une
relationjicc
kL , les instances respectives de ces deux classes peuvent
être reliées par un arc noté nj
mi oo
cicjL et qui désigne un lien entre ces
instances. La Figure 56 montre que le service ci est interconnecté
au service cj par la relation cijL , et inversement le service cj est
relié au service ci par la relation cjiL , les instances oim du service ci
peut être reliée aux instances ojn du service cj par la relation
nj
mi oo
cicjL .
Figure 56 : Les liens entre les classes et les objets
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
108
Une instance d‟un service peut avoir des liens avec des instances
appartenant à différents services à condition qu‟il existe des liens entre ce
service et les services correspondants aux instances considérées (voir
Figure 57). En effet, l‟instance oim possède des liens avec plusieurs
instances d‟un même service.
Figure 57 : Les liens avec des objets appartenant à différentes classes
Une instance oim peut être lié à des instances oj
n et ok
p appartenant
à différents services, s‟il existe des liens respectivement entre les services
ci , cj et ck.
4.7 Collaboration entre les entreprises à base d’hypergraphe
Pour établir une collaboration entre deux entreprises, nous avons
proposé dans le chapitre précédent que chaque entreprise gère son
répertoire local de services concrets et publie ses services abstraits dans
un répertoire global. Le répertoire global contient les informations
génériques sur ses activités, l‟ensemble de services abstraits et de
processus à partager ainsi que leurs interfaces afin de faciliter leur
découverte et déploiement. Il est important de noter que ce répertoire
local ne contient pas la liste de services indépendamment les uns des
autres mais prend aussi en compte des relations d‟héritage et d‟autres
types de relations sous forme d‟hypergraphes. L‟architecture globale est
illustrée en Figure 58 et montre que les hypergraphes de services dans
les répertoires locaux sont utilisés pour établir des chaînes de services
de collaboration enregistrées dans un répertoire commun. Les chaînes de
services sont également représentées en tant que hypergraphes grâce à
des relations comme la relation d‟héritage. Ainsi, la relation d‟héritage
dans un hypergraphe permet la réutilisation des propriétés de services
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
109
par une relation de généralisation/spécialisation similaire à l‟approche
orientée-objets : la classe spécialisée, c.à.d. la sous-classe, hérite les
propriétés et les méthodes de la classe que l‟on spécialise, c.à.d. super -
classe. L‟héritage entre les classes permet la transmission de propriétés
(attributs et méthodes) de la super-classe vers les sous-classes.
Figure 58 : Principe de présenter les services
Supposons que les entreprises E1 et E2 souhaitent collaborer.
Pour cela, elles négocient et établissent une chaîne de services à partir
de leurs services abstraits. Elles déposent dans le répertoire commun la
chaîne de service globale en tant que “hypergraphe“ de services.
D‟autre part, nous désignons par le terme “type de service“ un
arbre d‟héritage d‟un service particulier comprenant l‟ensemble de ses
services hérités. Le type de service pointe sur le service racine et tous
ses sous-services hérités. Le schéma dans la Figure 59 montre l‟arbre
d‟héritage du service d‟achat, noté “<achat>“ et qui inclut plusieurs
sous-services tels que achat en ligne, achat par portable ou bien achat
sur web :
<achat> = achat online achat portable achat web.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
110
Figure 59 : Arbre d'héritage de service <achat>
Au moment de la génération du processus de collaboratif
correspondant à le chaîne de services concrets à partir de la spécification
ne com :portant que les services abstraits, le médiateur cherche le type
de services qui correspond au service abstrait en tenant compte du
contexte (par exemple, le contexte d‟exécution, les périphériques
d‟accès, le profil de l‟utilisateur etc.). Le médiateur permet de choisir le
service contextualisé en s‟appuyant sur son type de service (voir Figure
60).
Figure 60 : rôle le médiateur
Par exemple, lorsqu‟un utilisateur décide d‟acheter un ticket de
train en utilisation son portable, le médiateur choisit de l‟arbre
d‟héritage du service Achat (type de service <Achat>), le service
“Achat Portable ».
Sachant que la chaîne de service globale désigne un processus
de collaboration générique qui décrit le flux d‟information et le sens
d‟exécution de services, la prise ne compte du contexte permet de
développer des services contextuels qui nécessitent un mode
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
111
d‟orchestration ou de composition particulière. Le médiateur devient un
élément essentiel pour une orchestration proactive qui s‟appuie sur les
relations entre les services. L‟architecture présentée Figure 61 montre
une vue globale d‟un processus générique à base de type de services et
le rôle du médiateur qui consiste à choisir tardivement et en fonction du
contexte le service à exécuter. Dans la section suivante, nous détaillons
le mécanisme d‟orchestration de service.
Figure 61 : Le rôle de médiateur pour sélectionner le service contextuel
4.8 Orchestration contextualisée de “type de service“
L‟orchestration de services permet explicitement de décrire
l‟enchaînement de l‟exécution des services. Elle permet également de
spécifier les messages échangés et les interactions qui se produisent au
niveau de ces messages [63].
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
112
Pour réaliser une orchestration contextualisée en se basant sur
le concept “type de service“, nous définissons formellement un type de
service par un triplet de trois nœuds(ne(s), nrc(s), ns (s)) tels que :
ne(s): désigne l‟ensemble des “attributs d‟entrée“, ne1,ne2,…..nen du
service S.
ns : désigne l‟ensemble des “attributs de sortie“, ns1, ns2,… nsm du
service S.
nrc : désigne l‟ensemble de règles de contrôle qui s‟appliquent sur les
attributs d‟entrée et sortie. Les règles nrc1, nrc2,… nrcn contraignent
l‟exécution du service S en posant des conditions sur les attributs,
conditions à satisfaire avant l‟exécution et après l‟exécution .
A titre d‟exemple, les règles de contrôle pour une réservation
d‟un billet d‟avion sont définies en termes de ses ressources et leurs
propriétés sont listées dans le Tableau 1.
Tableau 1 : Règles de contrôle pour une réservation de billet
d‟avion
Dans ce cas, les règles de contrôle sont définies comme suit :
a. le service « Acheter un billet d‟avion » est exécuté si les
conditions prix<500 euro et le jour de départ est “dimanche“ sont
valides.
b. le service « AutoriserRéservation » est exécuté si la condition
« passeport du client n‟est pas expiré » est valide.
En cours d‟exécution, un service est prêt à être exécuté si et
seulement si toutes les valeurs des attributs d‟entrée sont fournies et que
toutes les conditions définies par les règles de contrôle (nrc) sont
accomplies ou réalisées. Dans le cas contraire, le service est considéré
“non disponible“. Les règles de contrôle sont considérées comme une
condition préalable (pré-condition) sur la disponibilité d‟un service.
Nous définissons le mécanisme d‟orchestration comme une
extension à l‟orchestration BPEL en redéfinissant les activités (invoke)
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
113
pour appeler le médiateur et détecter les informations du contexte avant
de choisir un service dans la hiérarchie de l‟hypergraphe du type de
service en question.
Afin de passer les messages d‟un “type de service“ à un autre
“type de service“ comme indiqué dans la Figure 62, le médiateur
applique les règles de contrôle pour assurer une cohérence dans
l‟exécution.
D‟autre part, nous proposons un mécanisme de gestion
transactionnelle générique qui s‟applique sur un hypergraphe d‟un type
de services. Ce mécanisme s‟appuie sur un ensemble de contraintes de
transition et des états pour que le processus collaboratif fonctionne
malgré une défaillance ou une monté de charge. Grâce à ce mécanisme,
le médiateur choisit ou réplique les instances d‟un service et met à jour
l‟hypergraphe des instances.
Figure 62 : L‟Orchestration de type de service
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
114
4.9 Les contraints de transition entre les types de service
La gestion transactionnelle joue un rôle très important dans la mise en
place de processus collaboratifs. Elle est un facteur déterminant pour la
robustesse, la fiabilité et l‟intégrité des données manipulées par les
services. Elle définit le comportement d‟un service dans les cas
d‟inconsistance des données ou de concurrence d‟accès. Les aspects
importants de la gestion transactionnelle locale par rapport à un type de
service est le diagramme d‟état qui décrit les différents états possibles
de son cycle de vie. Pour contrôler l‟exécution d‟un type de service,
nous définissons les transitions possibles qui relient ses différents états.
On note par :
“E “ l‟ensemble de tous les états possible
“ T “ l‟ensemble de toutes les transitions
SE,T = { S. E S*T }/ e E , t T, S. E le type de service dans l‟état E et
S*T : est la transition de type de service S.
Nous définissons les états suivants {début, abandonné, activé, annulé,
échoué, terminé, compensé} et les transitions entre ces états par le
diagramme dans la Figure 63.
Une fois qu‟un service particulier est déployé, il est en état “début“,
ensuite il transite dans plusieurs états, par exemple abandonné (avant
d‟être exécuté) ou activé s‟il est en cours d‟exécution. Dans l‟état activé,
le service continue son exécution ou décide d‟annuler à cause d‟un
problème. Si le service n‟est pas annulé pendant son exécution, il
s‟exécute jusqu‟à son terme en succès ou il échoue.
Figure 63 : Les différents états de transition
La transition indique le changement d‟état d‟un service.
L‟activation d‟une transition contrôle le comportement d‟un service.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
115
Nous définissons la transition T sur un type de service S qui s‟applique
en exécution sur ses services choisi par l‟orchestrateur comme suite :
Nous définissons la transition d‟un type de service par :
Les transitions entre les différents états sont définies de la manière
suivante:
1) La transition abandonner permet d‟abandonner l‟exécution du type
de service avant d‟être activé et lui permettre de passer d‟un état début à
l‟état abandonné.
2) La transition activer permet d‟activer un type de service et lui
permettre de passer de l‟état début à l‟état activé.
3) La transition annuler permet d‟annuler un type de service pendant son
exécution et permet de transiter l‟état activé à l‟état annulé.
4) La transition échouer permet d‟indiquer l‟échec de type de service et
permet de transiter de l‟état activé à l‟état échoué.
5) La transition terminer permet d‟indiquer la transition d‟un type de
service avec succès, transiter de l‟état activé à l‟état terminé.
6) La transition ressayer permet d‟activer un type de service après son
échec et transiter de l‟état échoué (avorter) à l‟état activé.
S*annuler= S. activé S. annulé.
S*T = {E1 E (S) ; E(S) est un ensemble états de S, E2 E (S)} ; E1 E2 où E1 est l’état de S
avant l’activation S*T et E2 est l’état de S après l’activation de S*T
S*T T : S. ES. E ; S. E est le type de service dans l’état E.
S*abandonner : S. début S. abandonné.
S*activer = S. débutS. activé.
S*échouer = S. activé S. échoué
S*terminer= S. activéS. terminé
S*essayer= S. échoué S. activé
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
116
7) La transition compenser, après que la transition ressayer se termine
avec un échec, elle permet de transiter de l‟état échoué (avorter) à l‟état
compensé.
La gestion transactionnelle locale implique un choix de la stratégie
adéquate et appropriée à adopter pour soutenir une collaboration robuste
et performante. Dans la suite nous présenterons un exemple qui montre
l‟enchaînement transactionnel du service.
4.10 L’enchaînement des types de services
Nous illustrons le mécanisme de transition par un exemple pour mieux
comprendre l‟enchainement transactionnel du service. Nous considérons
une application d‟achat en ligne de produits informatiques, par exemple
l'ordinateur personnel et USB Bluetooth. Cette application est réalisée
par un processus collaboratif à savoir :
S1 : Le service de spécifications des besoins de client. Ce service est
utilisé pour passer la commande du client.
S2 : Le service d‟achat de clés USB Bluetooth.
S3 : Le service d‟achat d‟ordinateur personnel.
S4 : Le service de paiement par carte de crédit. Ce service est utilisé
pour payer par la carte en ligne.
S5, S6 : deux services pour conditionner et livrer les produits achetés
(par exemple un ordinateur et une clé USB). Un type de service
composé peut être définit comme ensemble de type de service
composants. Pour définir l‟enchainement de type de services, nous
définissons les pré-conditions sur les types de services.
Par exemple le service composite présenté dans la Figure 64
spécifie que le type de service S4 (paiement en line) va être activé après
la terminaison des services acheter USB et acheter l’ordinateur. La pré-
condition de l‟activation de la transition activer du type de service
S*compenser= S. échoué S. compensé
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
117
paiement en line sera dans ce cas : La terminaison le service acheter
USB et la terminaison du service acheter ordinateur.
Figure 64 : Service composé l‟acheter de produits informatiques
1) Dans cet exemple, l‟enchainement et l‟activation du type de
service S1 (spécification les besoins du client) et le type de service S2
(acheter USB) indiquent que le type de service S2 (acheter USB) est
activé après le type de service S1 (spécification des besoins du client est
terminé). Cet enchainement exprime une relation de succession entre les
deux types de services. L‟enchaînement d‟activation de S1 vers S2 existe
si et seulement si la terminaison de S1 peut déclencher l‟activation de
S2.
L‟enchaînement d‟activation S1 vers S2 est définit de la manière
suivante: Enchact(S1,S2)=(pré-condition de S1, transition S2).
La pré-condition de S1 S1.PT et la transition S2 S2 T.
2) un enchainement d‟abandon du service S1 vers le service
S2 indique que S2 est abandonné lorsque S1 échoue, annule ou
abandonne. Cet ensemble {échoué, annulé, abandonné} est la pré-
condition de S1. Cet enchaînement est défini par :
3) un enchainement alternatif entre le type de service S5 vers
le type de service S6 indique que le S6 est activé lorsque le service S5 est
dans l‟état échoué. Cet enchaînement spécifie S6 comme un service
alternatif de livraison. Ainsi, l‟enchaînement d‟alternatives permet
d‟exprimer des alternatives d‟exécution. Dans ce cas, un enchaînement
Ench act(S1,S2) = Ench(S1.p terminer,S2 activer).
Enchaban(S1,S2)=Ench(S1.p abandoner,S2 abandonner) Ench(S1.p
échouer,S2 abandonner) Ench(S1.p annuler,S2 abandonner).
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
118
alternatif de S5 vers S6 existe si et seulement si l‟échec de S5 peut
déclencher l‟activation de S6.
4) l‟enchaînement de compensation de S2 vers S3 indique que S3
est compensé quand S2 échoué. On note
5) l‟enchaînement d‟annulation de S2 vers S3 indique que S3 est
annulé en cours d‟exécution quand S2 est échoué à son tour. On note
Enfin, nous avons présenté dans cette section la
collaboration entre les entreprises en nous appuyant sur le concept des
hypergraphes de type de services. Nous avons défini une architecture
basée sur un médiateur qui permet de contextualiser l‟exécution des
services et qui s‟intègre dans une orchestration proactive en fonction du
contexte d‟exécution. Le moteur d‟orchestration est supporté par un
mécanisme de gestion transactionnelle à base d‟états pour plus
d‟autonomie en tenant compte de l‟approche d‟hypergraphe.
Dans la section suivante nous présentons la construction d‟un
hypergraphe en utilisation les éléments issus de l‟approche-objet.
4.11 Les relations de dépendances entre les Services
Les répertoires, tels que les annuaires UDDI, sont limités aux
descriptions fonctionnelles des services et ne permettent pas la
représentation des dépendances ou les relations inter-services. Modéliser
les interactions entre les services s‟avère utile dans plusieurs cas
d‟utilisation. Par exemple, un système de recommandation en
s‟appuyant sur certains types de relations pourrait remplacer un service
défectueux ou non disponible par un service similaire, ou bien proposer
un ou plusieurs services facultatifs pour enrichir la composition d‟un
nouveau processus métier.
Nous présentons dans la section suivante plusieurs types de relations
entre services. Ces relations peuvent être définies à priori et utilisées au
Ench alt(S5,S6)=Ench(S5.p échouer, S6 activer).
Ench comp(S2,S3) = Ench(S2.p échouer, S3 compenser).
Ench annul(S2,S3)=Ench(S2.p échouer, S3 annuler).
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
119
moment de la composition ou de l‟exécution de services. Ces relations
sont caractérisées par des liens symétriques ou asymétriques entre deux
ou plusieurs services (nœuds). Le graphe constitué par ces relations nous
permet d'identifier des communautés homogènes de services selon les
types de relations sous-adjacentes. Ces communautés regroupent les
modes d'interaction (patterns) entre les types de services Web dans le
but d'offrir une meilleure interactivité et autonomie à l'avenir dans
différents contextes de composition ou d‟exécution de services Web.
Nous définissons plusieurs types de relations entre les services pour
construire l‟hypergraphe à savoir, la relation d‟agrégation, la relation de
recommandation, la relation de similarité et la relation de collaboration.
4.11.1 La relation d’agrégation (A)
Un processus métier (ou un servie composite) est souvent
représenté par ses services/composants reliés par un flux d‟information
qui véhiculent les messages d‟entrée/sortie et détermine l‟ordre
d‟exécution de ces services. Il s‟agit d‟une vue dynamique qui
représente la composition à un seul niveau de profondeur et qui ne
contient que les services atomiques et composites. Cette vue ne permet
pas de présenter récursivement les services composants de certains
services composites. La relation d‟agrégation permet de construire une
vue statique et hiérarchique contenant à la fois les services composites
ainsi que leurs services atomiques. Les services qui se trouvent en bas
de la hiérarchie sont exclusivement atomiques tandis que les services
intermédiaires et la racine sont des services composites.
La relation d‟agrégation est présentée par un n-tuple <S1, A,
S11, S12, S1n>. Elle signifie que S1 est un service composite et S11, ….
S1n sont respectivement ses composants. Notons que cette définition
s‟applique récursivement aux services composants qui pourraient être
eux-mêmes des services composites. La relation d‟agrégation est
asymétrique et non récursive.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
120
Figure 65 : Vue statique du processus métier composite en relations d‟agrégation
La (Figure 65) présente un processus métier (service
composite) sous le perspective d‟une vue dynamique. Dans cet exemple,
S1, S3, S4 et S5 sont des services atomiques alors que le service S2 est un
service composite. Ce processus est représenté à droite par une
hiérarchie d‟agrégations qui révèle les composants de S2 (S21 et S22) et
les composants de S22 (S221, S222 et S223).
4.11.1.1 Les cardinalités
La relation d‟agrégation permet en outre de spécifier des
contraintes au niveau de services composants qui doivent les respecter.
Par exemple, la paire de cardinalité (min, max) permet de préciser que le
service composant doit créer entre min et max instances pendant
l‟exécution pour compenser une montée en charge. La cardinalité (1,1)
est la cardinalité par défaut d‟une relation reliant un composite à un
composant.
4.11.1.2 La spécification de contraintes globales
En outre, la relation d‟agrégation permet de spécifier
facilement des contraintes de qualités de services (QoS) globales sur le
service composite où les services composants doivent ensemble les
satisfaire. Par exemple, si le temps de réponse du service composite doit
être inférieur à 5 secondes, la somme de temps de réponses de tous ses
services composants ne devrait pas dépasser 5 secondes. Cette contrainte
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
121
globale est prise en considération au moment de la composition et c‟est
grâce au contrat de service (SLA) de chaque service que chaque sous
service doit s‟engager à fournir un temps de réponse individuel
acceptable. Le système de composition devrait prendre en considération
la vérification du temps de réponse globale.
4.11.1.3 La propagation des contraintes dans une composition
La relation d‟agrégation permet d‟élaborer un mécanisme de
propagation de contraintes dans une hiérarchie de composition. Nous
définissions deux types de propagation à savoir la propagation molle et
la propagation dure (ou explicite). Une propagation dure permet de
spécifier un ensemble de contraintes sur un service composite et de les
propager récursivement jusqu‟aux services composants atomiques qui
occupent les feuilles dans la hiérarchie d‟agrégation. Les services
composites intermédiaires ne peuvent pas réécrire les valeurs de ces
contraintes. Par exemple, la contrainte « Binding » qui précise que le
protocole de transmission est HTTP pour échanger les messages SOAP,
est spécifiée au niveau de la racine dans la (Figure 60). Dans une
propagation dure, tous les services composants doivent garantir une
implémentation du protocole SOAP-HTTP. Si la propagation est molle,
la valeur de la contrainte « Binding » pourrait être réinitialisée par les
services composants et intermédiaires à n‟importe quel niveau. Par
exemple, si SOAP-RPC est la nouvelle valeur de la contrainte « Binding
» au niveau du service S22, ses services composants, notamment S221,
S222 et S223, doivent implémenter le protocole SOAP-RPC et non le
protocole SOAP-HTTP.
4.11.2 La relation de recommandation (R)
Elle établit une dépendance simple entre deux services. Cette
relation permet au moment de la composition de services de proposer au
concepteur des services susceptibles de l‟intéresser pour enrichir sa
composition avec des fonctionnalités supplémentaires. Le concepteur est
libre d‟accepter ou de refuser les services recommandés dans sa
composition finale. La relation de recommandation est présentée par un
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
122
triplet <S1, R, S2> qui signifie que S1 recommande S2. La relation de
Recommandation est asymétrique.
La (Figure 66) montre que le service SightSeeingWS est relié
par une relation de recommandation au service RoomBookingWS. Si le
service RoomBookingWS participe dans une composition, il pourrait
recommander le service SightSeeingWS pour enrichir le processus par
un service susceptible d‟être intéressant.
Figure 66 : Relation de recommendation < RoomBookingWS, R,
SightSeeingWS >
4.11.2.1 La relation de similarité (S)
Elle permet de rassembler en communauté les services ayant
des fonctionnalités similaires. Cette relation permet au moment de
l‟exécution de proposer un service alternatif pour le substituer à un
service faisant partie d‟une composition en cours d‟exécution. Le
service sera substitué suite à une défaillance ou à un changement externe
ou interne qui ne garantit plus les paramètres de qualité de services
(QoS) entre le fournisseur du service et le consommateur du service.
La relation de similarité est présentée par un triplet <S 1, S, S2>.
Elle signifie que S1 similaire à S2. La relation de similarité est
symétrique.
La Figure 67 montre que les services RoomBookingWS et
RoomReservationWS sont reliés par une relation de similarité. Pendant
l‟exécution le service RoomBookingWS pourrait être remplacé par le
service RoomReservationWS sous certaines conditions contextuelles.
Les deux services appartiennent à la même communauté.
Figure 67 : Relation de similarité < RoomBookingWS, S,
RoomReservationWS >
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
123
4.11.2.2 La relation de collaboration (C)
Le système de composition mémorise les interactions entre
services pour établir les relations de collaborations. Elles correspondent
souvent aux flux d‟information échangés entre les services. En se basant
sur la qualité des interactions précédentes entre deux services, le
système met à jour les poids pondérés affectés à leur relation de
collaboration. Ceci permet d‟ajuster le processus de composition en
choisissant les services qui ont le mieux collaboré dans des
compositions précédentes et accroître la confiance sur la collaboration
entre deux services. La relation de collaboration est présentée par un
quadruple <S1, C, w, S2>. Elle signifie que S1 et S2 ont déjà collaboré et
leur degré de collaboration a une valeur de w. Cette relation est
symétrique et le poids de la relation de collaboration est défini de la
manière suivante.
W(S1, S2)= Ci/Cn
Ci= nombre de fois S1 et S2 sont réellement collaborés
Cn= nombre de fois S1 et S2 sont sélectionnés pour collaborer,
La Figure 68 montre que les services AirTicketPurchaseWS et
RoomBookingWS sont en collaboration. Au moment d‟une composition
de services, la requête qui interroge le registre UDDI pour sélectionner
les services similaires d‟une communauté (à collaborer avec
AirTicketPurchaseWS par exemple) se base sur le poids de collaboration
le plus élevé pour favoriser le choix d‟un service particulier parmi
plusieurs services de même type (RoomBookingWS).
Figure 68 : Relation de collaboration < AirTicketPurchaseWS, C, 0,5,
RoomBookingWS>
4.12 Intégration des relations de dépendances dans les processus
métiers
La découverte des services Web dans un répertoire s‟appuie sur des
langages de requêtes qui spécifient les propriétés fonctionnelles
notamment les messages d‟entrée et sorties, les pré- et post-conditions et
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
124
les propriétés non-fonctionnelles dont entre autres les préférences de
sécurité. Les types de relations entre les services favorisent la création
de processus collaboratifs qui s‟adaptent aux changements du contexte
de collaboration. Le processus a un comportement dynamique ajusté au
fil du temps. Figure 69 montre que le processus métier n‟est plus isolé
mais ses différents services sont interconnectés par les différents types
de relations de dépendances. Ces relations sont exploitées au moment de
la composition et de l‟exécution de la manière suivante :
1- Exploitation des relations au moment de la conception des
services : Tout d'abord, le concepteur établit différents types de relations
entre les services Web atomiques/simples. Ensuite, il interroge le
répertoire par des requêtes pour sélectionner les services susceptibles de
participer à une composition afin de créer un nouveau processus métier
(service composite). Les requêtes ne doivent pas seulement prendre en
considération les propriétés fonctionnelles et non- fonctionnelles mais
elles devraient aussi traiter les relations de dépendances entre les
services Web pour ajuster la sélection.
2- Exploitation des relations au moment de l'exécution des
services : Le moteur d'exécution des processus métiers (moteur BPEL)
pourrait prendre certaines actions (situations d‟échec par exemple) en
s‟appuyant sur les relations de dépendances et les scénarios de
compositions précédentes.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
125
Figure 69 : Un processus métier et les différentes types de relations de
dépendances entre les services
Les relations ne sont pas seulement préservées au moment de la
conception mais elles sont également exploitées pendant l‟exécution et
elles sont enrichies pendant le cycle de vie de chaque pair de services.
Les relations acquièrent donc une importance égale aux services-mêmes.
4.13 Conclusion
Nous avons défini la collaboration entre les entreprises en
utilisant l‟hypergraphe. Nous avons aussi défini la construction de notre
hypergraphe que nous exploitons ensuite pour introduire des stratégies
d‟héritage antre les services. Ensuit nous avons défini l‟orchestration
entre les services et les contraints de transition entre eux avant .de
définir le mécanisme d‟héritage entre les services et les différentes
relations entre les services.
Dans le chapitre suivant nous présenterons la conclusion
générale et notre perspective.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
127
Chapitre 5 Conclusion générale et
perspectives
5.1 Conclusion général et perspective
L‟évolution de la demande pour des associations produits/services
nécessite l‟organisation de collaborations « à la demande » entre
entreprises pour répondre aux besoins des clients. Ce changement
structurel au niveau du marché laisse donc prévoir une croissance
exponentielle des écosystèmes de services dans les prochaines années et
impose de pouvoir organiser des collaborations « à la demande » entre
les entreprises ce qui implique des changements radicaux dans la
structure organisationnelle des entreprises. Ces collaborations
conduisent à l‟émergence d‟entreprises virtuelles et font largement appel
aux technologies de l‟information et de la communication. Or les
réponses technologiques apportées peuvent constituer un frein : les
Systèmes d‟Information (SI) d‟entreprise ne sont que peu agiles et
manquent de capacité d‟interopérabilité. En effet, l‟infrastructure
informatique (matérielle et logicielle, i.e. ERP, CRM, CAD, SCM,
MES…) présente une forte complexité technologique, manque
d‟interopérabilité et limite donc les possibilités « d‟interconnexion »
entre les processus d‟entreprise et l‟échange d‟information entre
partenaires.
Pour surmonter ces limites, l‟implémentation du système d‟information
selon une architecture orientée services (SOA) définit une nouvelle
approche pour organiser les applications d'entreprise et optimiser les
processus métier. Néanmoins, ces infrastructures sont essentiellement
destinées à soutenir l'interopérabilité intra-entreprise car elles reposent
sur une définition mono-contexte du processus d'affaires. Or un
écosystème de services inclut un environnement multi -contextuel
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
128
d‟exécution de services. Chaque entreprise fournit plusieurs services
reliés à des contextes d‟exécution particuliers. Cette approche qui vise à
développer des services multi-contextuels est un environnement
complexe à mettre en place. En plus, il est exposé à des risques
d‟incohérence entre les différents services qui offrent les mêmes
fonctionnalités.
Dans notre travail de recherche, nous proposons un cadre générique qui
s‟appuie sur la composition de chaînes de services multi -contextuels
(i.e. supportant différents contextes d‟exécution) et qui favorise le
déploiement de systèmes d‟information interopérables et collaboratifs.
Pour cela, nous avons présenté une approche qui permet la réalisation de
plusieurs scénarios de collaboration inter entreprises en se basant sur les
concepts clés tels que le service, l‟hypergraphe, les relations
d‟interdépendance et différentes vues notamment la vue de gestion, la
vue de médiation, et la vue de sécurité. Ces concepts visent à enrichir la
composition de services et assurer une exécution contextuelle. Dans
notre travail, nous proposons que chaque entreprise maintienne un
répertoire local de services à partager avec ses partenaires et participe à
la gestion d‟un répertoire commun contenant les chaînes de services
fournies par les différents partenaires. L‟originalité de notre approche
consiste à conserver la propriété du « couplage lâche » qui est nécessaire
pour le mécanisme d‟orchestration, et proposer plusieurs types de
relations entre les services afin d‟enrichir la composition et assurer une
exécution tardive et contextuelle en fonction des informations perçues
par l‟environnement d‟exécution. Dans notre travail de recherche, nous
avons défini les types de relations suivants : la relation d‟agrégation, la
relation de recommandation, la relation de similarité, la relation de
collaboration et la relations d‟héritage.
Les travaux réalisés dans le cadre de cette thèse ouvrent
diverses perspectives et plusieurs travaux futurs peuvent être envisagés :
Améliorer les relations de dépendances inter-services :
Nous nous sommes limités dans la démarche que nous avons
présentée dans cette thèse à plusieurs types de relations entre les
services. Ceci constitue un point de départ important pour associer à
chaque type de relation un poids qui mesure son importance. Par
exemples, un service sélectionné pourrait recommander plusieurs
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
129
services grâce à la relation de recommandation. Or ces relations peuvent
avoir de poids différents et le service sélectionné pourrait choisir le
service avec le poids le plus élevé. Nous envisageons aussi d‟introduire
plusieurs formules pour calculer les poids associés à ces relations.
Etendre la conception de services multi-contextuels :
La modélisation de services multi-vues que nous avons
développée prend en compte l‟environnement multi-contextuel
d‟exécution. Ces vues sont assez simples et indépendantes et plusieurs
extensions peuvent être prises en compte. Nous voudrions introduire un
modèle holistique de vues interconnectées où la modification d‟une vue
entrainerait la mise à jour de tous les vues. L‟enchainement de ces vues
nécessite une intégration cohérente et une transformation de modèles qui
décrivent ces vues.
Améliorer les capacités de l’orchestrateur pour une
exécution multi-contextuelle:
L'idée de développer un médiateur pour supporter une
exécution multi-contextuelle s'avère être très intéressante vue
l'importance d'une telle médiation dans la mise en place d'une
orchestration SOA. Nous envisageons d‟étudier ce type d‟orchestration
pour prendre en compte les différentes vues et leurs propriétés non-
fonctionnelles. Un point important à développer sera la gestion
transactionnelle de ces services en se basant sur les types de relations
afin d‟assurer une autonomie dans l‟exécution de chaînes de services.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
130
Bibliographie
[1] E. Overby, A. Bharadwaj, and V. Sambamurthy, “A Framework for Enterprise
Agility and the Enabling Role of Digital Options,” Business Agility and
Information Technology Diffusion, vol.180,Springer,Boston, 2005, pp. 295-312.
[2] E. Overby, A. Bharadwaj, and V. Sambamurthy, “Enterprise agility and the
enabling role of information technology,” European Journal of Information
Systems, vol. 15, 2006, pp. 120-131.
[3] T. Erl, “Service-Oriented Architecture: Concepts, Technology, and Design,”
Prentice Hall PTR, August 2005, pp. 792.
[4] A. Esper, L. Sliman, Y. Badr, and F. Biennier, “Towards Secured and
Interoperable Business Services,” Enterprise Interoperability III,Springer,Berlin
2008, pp. 301-312.
[5] A. Esper, Y. Badr, and F. Biennier, “Organization of Contextual Enterprise -
Service Bus,” Proceeding of the 3rd International Conference on Information &
Communication Technologies: from Theory to Applications (ICTTA‟08),
Damascus , Syria , Avril 2008, pp. 1-5.
[6] A. Esper, Y. Badr, and F. Biennier , “ Hypergraph of Services for Business
Interconnectivity and Collaboration,“APMS (International Conference on
Advances in Production Management Systems à Bordeaux, France, 2009.
[7] Modélisation des processus de l‟entreprise: Etat de l'art et conseils pratiques,
projet SPINOV, 2006, disponible à
http://www.citi.tudor.lu/SI/Livrable.nsf/96F59447CF
4CCF05C125701C004C6BA9/$File/RS_BP%20Modeling_Etat%20art%20et%20c
onseils%20pratiques_1.0.pdf, la dernière visite 14/06/2010.
[8] M. Brahimi and L. Bouzidi, “Eléments d‟architecture pour une mémoire
d‟entreprise orientée processus métier.” Revue électronique suisse de science de
l'information, 2007, disponible à http://cours.ebsi.umontreal.ca/sci6144/lecture/
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
131
seance%208/S%C3%A9ance%2008%20%C3%89l%C3%A9ments%20d'architectu
re%20pour%20une%20m%C3%A9moire%20d'entreprise.pdf, la dernière visite
14/06/2010.
[9] D. Georgakopoulos, M. Hornick, and A. Sheth, “An overview of workflow
management: From process modeling to workflow automation infrastructure,”
Distributed and Parallel Databases, vol. 3, 1995, pp. 119–153.
[10] C. Morley, “Un cadre unificateur pour la représentation des processus,”
International Conference on Information Systems Pre-ICIS, Washington, USA,
décembre 2004, disponible à http://www-dsi.int-evry.fr/files/chap2.pdf, la
dernière visite 14/06/2010.
[11] BPMI, The Business Process Management Initiative. 2007 disponible à
http://www.bpmi.org/" la dernière visite 14/06/2010.
[12 ] L. Fischer , “Innovation and Excellence in Workflow and Business Process
Management,” Excellence in Practice, Volume V, ISBN 0-9703509-5-3.
[13] F. Vernadat, “Enterprise Modeling and Intergration: Principles and
Applications,” (Champan& Hall, london) ,1996,455 P.
[14] K. Kosanke, “CIMOSA: Overview and status,” Comput. Ind., vol. 27, 1995,
pp. 101-109.
[15] K. Kosanke, F. Vernadat, and M. Zelm, “CIMOSA: enterprise engineering
and integration,” Comput. Ind., vol. 40, 1999, pp. 83-97.
[16] W.S. August, ARIS - Business Process Frameworks, Springer, Berlin: 1998.
[17] G. Goumeingts, “ Méthode GRAI : méthode de conception des systèmes en
productique, thèse d‟Etat, Université de Bordeaux 1,” 1984.
[18] D. Chen, B. Vallespir, and G. Doumeingts, “GRAI integrated methodology
and its mapping onto generic enterprise reference architecture and methodology,”
Comput. Ind., vol. 33, 1997, pp. 387-394.
[19] T.J. Williams, “The Purdue Enterprise Reference Architecture,” Comput.
Ind.,USA, vol. 24, 1994, pp. 141-158.
[20] IFIP-IFAC, GERAM: Generalised Enterprise Reference Architecture and
Methodology, 1999, disponible à:
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
132
http://www.cit.griffith.edu.au/~bernus/taskforce/geram/versions/geram1-6-
3/GERAMv1.6.3.pdf, la dernière visite 14/06/2010.
[21] P. Bernus and L. Nemes, “Requirements of the generic enterprise reference
architecture and methodology,” Annual Reviews in Control, vol. 21, 1997, pp.
125-136.
[22] SADT & IDEF une méthode de spécification,” 2010; availabla at
http://psylon.free.fr/formatio/doc/sadt.doc, la dernière visite 14/06/2010.
[23] M. DIVINÉ, “MERISE:60 Affaires classées,” Paris, Eyrolles, 2008,291P.
[24] H. Tradieu, A. ROCHFELD, R. COLLETTI, La méthode MERISE, principes
et outils, Ed. d‟Organisation, Paris, 1986.
[25] H. TARDIEU, A. ROCHFELD, R. COLLETTI, La méthode MERISE :
Principes et outils, Paris, les Ed. d'Organisation, 1998, 344 p.
[26] P. Dumas and G. Charbonnel, La méthode OSSAD, éditions d'organisation,
1990, disponible à http://dumas.univ tln.fr/Docs_PDF/ OSSAD %20vol1
%20020315.pdf, la dernière visite 14/06/2010.
[27] W.P. M. Blaha, “A catalog of object model transformations,” In 3rd Working
Conference on Reverse Engineering, november 1996
[28] J. Ferber, Conception et programmation par objets, Hermè, paris, 1991, 50P.
[29] C. Pasquier, P. Roucoulet, and M. Lin Lanaspèze, l'approche objet. Hermes,
1995, 217 P.
[30] “OMG Business Object DTF Common Business Objects,” 1997, disponible à
http://www.omg.org/docs/bom/97-12-01.pdf, la dernière visite 14/06/2010.
[31] W.V.D. Heuvel, M.P. Papazoglou, and M.A. Jeusfeld, “Configuring Business
Objects from Legacy Systems,” Proceedings of the 11th International Conference
on Advanced Information Systems Engineering, Springer-Verlag, 1999, pp. 41-
56.
[32] A. Caetano, A.R. Silva, and J. Tribolet, “Using roles and business objects to
model and understand business processes,” Proceedings of the 2005 ACM
symposium on Applied computing, USA, March 2005, pp. 1308-1313.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
133
[33] K. Mertins, R. Jochem, Planning of enterprise-related CIMstructures, in:
Proceedings of 8th International Conference CARS and FOF, Metz, France, 17-19
August 1992.
[34] F. Vallée, “ UML pour les décideurs“ Paris, Eyrolles, 2005, 273 P.
[35] H. Smith and P. Fingar, Business Process Management: The Third Wave,
Meghan-Kiffer Press, 2003, disponible à http://www.bpm3.com/, la dernière
visite 14/06/2010.
[36] M.H. Dodani, “From Objects to Services: A Journey in Search of
Component Reuse Nirvana.” Journal of Object Technology, 2004, disponible à
http://www.jot.fm/issues/issue_2004_09/column5/, la dernière visite 14/06/2010.
[37] K. Mertins, R. Jochem, and F. Jäkel, “A tool for object-oriented modelling
and analysis of business processes,” Comput. Ind., vol. 33, 1997, pp. 345-356.
[38] S. Andre, “MDA (Model Driven Architecture) principes et états de
l‟art,”Technical report, 2004, disponible à
http://wwwesto.ump.ma/mounir/mda/these%20mda/MDAv1.8.pdf, la dernière
visite 14/06/2010.
[39] H. Kadima, MDA:Conception orientée objet guidée par les modèles,
Numilog, Dunod, 2005, 240 P.
[40] X. Blanc, MDA en action, Paris Eyrolles,1ère édition,2005, 270 P.
[41] A. Wilhelm Scheer, ARIS: des processus de gestion au systeme integré
d'applications , Springer-Verlag, 2002.
[42] M.A. Emmelhainz, EDI = L'échange de données informatisées, Masson,
1993, 267P.
[43] Berge, J., The EDIFACT Standards. Manchester, England, NCC Blackwell,
1991.
[44] C. Huemer, G. Quirchmayr, and A.M. Tjoa, “A Meta Message Approach for
Electronic Data Interchange (EDI),” Proceedings of the 8th International
Conference on Database and Expert Systems Applications, Springer-Verlag,
1997, pp. 377-386.
[45] D. Linthicum. Enterprise Application Integration. Addison-Wesley, 2000,
377 pp.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
134
[46] T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and Y. François,
Extensible markup language (XML) 1.0 (second edition)- W3C recommendation“.
Disponible à http://www.w3.org/TR/REC-xml/, la dernière visite 15/06/2010.
[47] B. Alexendre, XML, Paris, Eyrolles,2007, 240P.
[48] J. Yang, “Service oriented computing: the challenges and opportunities in
business development, 2005, disponible à
http://www.ict.csiro.au/MU/Trends/Presentations/Jian%20Yang.pdf , la dernière
visite 14/06/2010.
[49] J. Yang and M.P. Papazoglou, “Service components for managing the life -
cycle of service compositions,” Inf. Syst., vol. 29, 2004, pp. 97-125.
[50] D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, and
D. Orchard, “Web Services Architecture, W3C Working Group Note 11,
February, W3C Technical Reports and Publications,” 2004.
[51] H. Kadima and V. Monfort, Les Web services - Techniques, démarches et
outils : XML-WSDL-SOAP-UDDI-Rosetta-UML, Dunod/01 Informatique, 2003,
411.
[52] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, “Web
Services Description Language (WSDL) 1.1,”,W3C, Mar. 2001, disponible à
http://www.w3.org/TR/wsdl, la dernière visite 15/06/2010.
[53] J.M. Chauvet, Service Web avec SOAP,WSDL, UDDI,ebXML , 2002,528P.
[54] D. Martin, A. Ankolekar , M. Burstein , G. Denker , D. Elenius, J. Hobbs , L.
Kagal , O. Lassila , D. McDermott , D. McGuinness , S. McIlraith , M. Paolucci ,
B. Parsia , T. Payne , M. Sabou , C. Schlenoff , E. Sirin , M. Solanki , N.
Srinivasan , K. Sycara , and R. Washington , “OWL-S Coalition, OWL-S
Specification,” 2004,disponible à http://www.daml.org/services/owl-s/, la
dernière visite 15/06/2010.
[55] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F.
Nielsen, S. Thatte, and D. Winer, “Simple object access protocol (SOAP) 1.1,”
http://www.w3.org/TR/SOAP/, la dernière visite 15/06/2010.
[56] Q. Yu, X. Liu, A. Bouguettaya, and B. Medjahed, “Deploying and managing
Web services: issues, solutions, and directions,” The VLDB Journal, vol. 17,
2008, pp. 537-572.
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
135
[57] A. Arkin, “Business Process Modeling Language, Version 1.0,” Business
Process Management Initiative (BPMI.org), Tech. Rep., June 2002.
[58] A.Tony, C. Francisco, D. Hitesh, G. Yaron, K. Johannes, L. Frank, L. Kevin,
R. Dieter, S.Doug, T. Satish, T. Ivana, and W. Sanjiva.“ Business process
execution language for web services version 1.1“. Technical report, May 2003.
http://www.oasisopen.org/committees/download.php/2046/BPEL%20V11%20Ma
y%205%202003%20Final.pdf, la dernière visite 15/06/2010.
[59] D. Djidel, B. Mathew, and M. Juric, Orchestration de services web avec
BPEL, guide pour architectes et développeurs, Packt, 2004, 413P.
[60] S. Thatte, “XLANG : Web Services for Business Process Design,” Microsoft.
2001.
[61] F. Leymann. Web Services Flow Language (WSFL 1.0). IBM, May 2001.
[62] S. Felipe, G. Copeland, M. Feingold, T. Freund, J. Johnson, C. Kaler, J.
Klein, D. Langworthy, A. Nadalin, D. Orchard, I. Robinson, J. Shewchuk, and T.
Storey, “Web Services Coordination (WS-Coordination),” 2004,disponible à
http://schemas.xmlsoap.org/ws/2004/10/wscoor/ la dernière visite 15/06/2010.
[63] F. Cabrera, G. Copeland, B. Cox, T. Freund, J. Klein, T. Storey, and S.
Thatte, “Web Services Transaction (WS-Transaction),” 2002, disponible à
http://xml.coverpages.org/WS-Transaction2002.pdf, la dernière visite 15/06/2010
[64] J. Gray and A. Reuter, “Transaction processing Concepts and Techniques",
Morgan Kaufmann, 1993, 887P.
[65] J. Gray, “The transaction concept: virtues and limitations (invited paper),”
Proceedings of the seventh international conference on Very Large Data Bases -
Volume 7, Cannes, France: VLDB Endowment, 1981, pp. 144-154.
[66] C. Peltz, “Web Services Orchestration and Choreography,” Computer, vol.
36, 2003, pp. 46-52.
[67] F. Vernadat, Interoperable enterprise systems: Principles, concepts, and
methods, Annual Reviews in Control, 31(1), 2007, pp. 137-145.
[68] H. Afsarmanesh, L.M. Camarinha-Matos: A framework for management of
virtual organizations breeding environments. Proceedings of PRO-VE'05 -
Alida ESPER
Thèse en informatique / 2010
Institut National des Sciences Appliquées de Lyon
136
Collaborative networks and their breeding environments, Springer, Valencia,
Spain, 26-28 Sept, 2005, pp. 35-48.
[69] C. Sodki., Interconnexion des processus Interentreprises: une approche
orientée services, thèse INSA Lyon, 2008,198 P .
[70] H. Ludwig, “Web services QoS: external SLAs and internal policies or: how
do we deliver what we promise?,” Web Information Systems Engineering
Workshops, 2003. Proceedings. Fourth International Conference on, 2003, pp.
115-120.
[71] J. Cardoso, A. Sheth, J. Miller, J. Arnold and K. Kochut, Quality of service
for workflows and web service processes, Web Semantics: Science, Services and
Agents on the World Wide Web,2004, pp. 281-308.
[72] M. Conti, M. Kumar, S. K. Das and B.A, Shirazi, Quality of service issues
in Internet web services, IEEE Transactions on Computers, 2002, pp. 593-594.
[73] P. Resnik, Semantic Similarity in Taxonomy: An information-based measure
and its application to Problems of Ambiguity in Natural language. Journal of
Artificial Intelligence 11 (1999): 95-130
[74] P. Hoffmann, Similarité sémantique inter-ontologies basée sur le contexte,
thèse de doctorat, 1999. 82 pages.
[75] L.B. Yanne., Towards the conception of extended information systems
organized around a web service platform, Univesité Lyon 1, 2008, 127 P.
[76] Rajsiri V., Knowledge-based system for collaborative process specification,
Thèse de doctorat, Thèse de l‟Ecole des Mines d‟Albi-Carmaux, 2009, 223 P.